Friday Facts #91 - Being the evil guy

[Balinor]

I eagerly await the day when we can send out battalions of combat robots to fight the alien hordes. That is my dream destination for Factorio currently.

[Peter34]

I eagerly await the day when we can send out battalions of combat robots to fight the alien hordes. That is my dream destination for Factorio currently.

Why not strat with Drone towers. You know, ones that can host and repair and recharge (recharging their timers) Defender Capsules, and other more advanced such drones that already exist in the game, but can currently only be used by the player directly.

[Balinor]

I eagerly await the day when we can send out battalions of combat robots to fight the alien hordes. That is my dream destination for Factorio currently.

Why not strat with Drone towers. You know, ones that can host and repair and recharge (recharging their timers) Defender Capsules, and other more advanced such drones that already exist in the game, but can currently only be used by the player directly.

Yeah something along those lines would be cool. In the past the developers have mentioned a possible rts direction for combat in Factorio but I don't recall them ever elaborating on what thoughts they had on it or even if it will ever actually make it into the game. Perhaps the subject of a future thoughts post from the devs there?

[y.petremann]

Combinators alone, what can they do...?

Make lamps blink in funny ways.

The usefulness of that is up for debate of course.

Lamp are just receptors, but with that you could do some maths and more complex logic units for your factory ...
For my case, it would make the main factory panel chest to be powerful by being able to select factory speed.

[fragzilla]

As a long time software developer, software dev manager, and now a VP over dev/ops/qa of a software company, I totally sympathize with this blog post.

The best advice I can give you, after having fought over 15 years with this problem you describe is: Shipping cures all wounds. Ship early, ship often. Your fans won't mind you shipping small updates often. The temptation to have a big release and to fix everything is a natural one for developers and it's extremely hard to resist, but every time I've shipped fewer things more frequently it's worked out for the better and every time I held back a release to wait for big things or lots of things, it turned into a disaster.

I would highly recommend you allocate some devs to work on making the release/update process fully automated and then commit to a schedule of releasing weekly or every other week. Even if it's just one bug fix or two tweaks to graphics, your fans won't mind at all and will appreciate seeing progress.

If there's a bigger feature or fix that takes more time, release it when it's ready in the next release package going out. If you're releasing every two weeks and a feature takes 6 weeks or 2 months, that's fine, ship it in the next release window. Shipping often doesn't mean "coding faster" it just means not keeping a huge inventory of features/bugfixes until an imaginary or self-imposed magical "major release". Keeping inventory of unplayed features and untested bugfixes only hurts your ability to code and deliver more features/bugfixes

One thing I've found is that developer morale skyrockets with this approach. The feeling of shipping something, however small, is the best feeling in the world for a developer and doing that often really spurns more creativity, effort, and most importantly enjoyment of developing which spurns even more goodness.

I can't speak highly enough of shipping often. It cures almost all the dysfunction that occurs on most software projects.

[vampiricdust]

As a long time software developer, software dev manager, and now a VP over dev/ops/qa of a software company, I totally sympathize with this blog post.

The best advice I can give you, after having fought over 15 years with this problem you describe is: Shipping cures all wounds. Ship early, ship often. Your fans won't mind you shipping small updates often. The temptation to have a big release and to fix everything is a natural one for developers and it's extremely hard to resist, but every time I've shipped fewer things more frequently it's worked out for the better and every time I held back a release to wait for big things or lots of things, it turned into a disaster.

I would highly recommend you allocate some devs to work on making the release/update process fully automated and then commit to a schedule of releasing weekly or every other week. Even if it's just one bug fix or two tweaks to graphics, your fans won't mind at all and will appreciate seeing progress.

If there's a bigger feature or fix that takes more time, release it when it's ready in the next release package going out. If you're releasing every two weeks and a feature takes 6 weeks or 2 months, that's fine, ship it in the next release window. Shipping often doesn't mean "coding faster" it just means not keeping a huge inventory of features/bugfixes until an imaginary or self-imposed magical "major release". Keeping inventory of unplayed features and untested bugfixes only hurts your ability to code and deliver more features/bugfixes

One thing I've found is that developer morale skyrockets with this approach. The feeling of shipping something, however small, is the best feeling in the world for a developer and doing that often really spurns more creativity, effort, and most importantly enjoyment of developing which spurns even more goodness.

I can't speak highly enough of shipping often. It cures almost all the dysfunction that occurs on most software projects.

While I fully agree with you, I just wanted to mention save breaking changes. Those changes should probably be a bigger package with other game breaking stuff. The fewer game breaking updates the better, but even they should be reasonable. Another part of this is the early access. In early access there is always the fear of project abandonment. Developers who are consistent & update regularly are overwhelming given positive reviews

[DaveKap]

I'm really sad to see the platform getting pushed back. I've been awaiting new gameplay features and that seemed to be a huge game changer. Meanwhile, most of .12 just seems like optimizations and quality-of-life features. Now, instead of looking forward to .12 to come back and play, I'm instead looking forward to .13.

That said, major props to the developers for making these decisions when they need to be made instead of letting their code turn into a quagmire of buggy inconsistency. Keep up the amazing work.

[ssilk]

One thing I've found is that developer morale skyrockets with this approach. The feeling of shipping something, however small, is the best feeling in the world for a developer and doing that often really spurns more creativity, effort, and most importantly enjoyment of developing which spurns even more goodness.

I can't speak highly enough of shipping often. It cures almost all the dysfunction that occurs on most software projects.

I can underline that. My team deploys some times a week. Since we do that now (about a year), the productivity rises - we can measure it. The fun rises, since we get a soon response to our work and the quality rises, because we can fix errors in time, because the changes between two releases are minimal.

Continuous deployment is eventually not the right thing for a game. There needs to be a stable phase between major releases, to test it and to prevent, that the game needs to be updated all the time.

[Cordylus]

I think that the best way to push updates has Minecraft.
There are major releases from time to time, and weekly snapshots for the brave ones.
Everyone are happy:
Players, because they can choose version to play: newest or stable.
Devs, because they have instant feedback about the new changes and bugs.
Modders, because they have stable release to mod and new version to look forward the changes.
Testers (like me), because they can easily look forward the bugs and translation problems.

[Peter34]

The best advice I can give you, after having fought over 15 years with this problem you describe is: Shipping cures all wounds. Ship early, ship often. Your fans won't mind you shipping small updates often.

This.

I'm still new to this Early Access thing, but I'd really like for my two favourite EA games, "Factorio" and "7 Days to Die", to release new versions more often. Madmole over at The Fun Pimps keeps talking about switching (back) to that style, but so far it hasn't happened, with there bing a long wait for alpha 9, then a very long wait for alpha 10 and another very long wait for alpha 11, and at least a long wait for alpha 12 but possibly a very long one (time will tell).

Nobody wants that.

[vampiricdust]

Continuous deployment is eventually not the right thing for a game. There needs to be a stable phase between major releases, to test it and to prevent, that the game needs to be updated all the time.

That actually is a good point. There are also mods to consider. Updating too often means modders have to work more to ensure each change isn't breaking something. Some mods will keep up just fine, others may stick to stable releases, and others will be randomly updated or abandoned more quickly.

I must say I'm quite happy waiting and playing all the mods that have been coming out. I'm starting to wonder how many mods does it take to break my game...

[Lupoviridae]

Combinators alone, what can they do...?

I am so excited for just combinator implementation. With just them you can build an entire working computer, though UI will be very limited. Still, it will be enough to get the memory up and running... working on laying out all the wiring now in preparation ^.^

[Koub]

Tbh, I'm not mad the schedule for circuit networks (and all this kind of stuff) is delayed, especially when the reason for it is pushing an update with endgame content.
I really feel the advanced logic stuff will only be used to full potential by a very tiny part of the players, the remaining will just be totally overwhelmed by its complexity and will use the most basic features and/or copy fancy designs found on Youtube without bothering understanding their logic.

Hell I have played Factorio maybe 400 or 500 hours, and didn't even dare throw myself into trains because I feel it's too complicated (and I'm sure I'm not the only one), and I simply don't want to learn via a let's play.

It's like you know, most people use excel to add three numbers add the VAT, and that's all, while others make pivot tables with dynamic graphes, macros, and all.

Don't get me wrong. I hope one day there will be all the features everyone has ever dreamt of. But I'm really glad the devs have chosen to make small regular updates instead of one major update every year that changes about everything in the game.

So TL;DR : Good thing that the content that will be useful to 90+% of the players is chronologically favored over a content that will be useful to maybe 5 or 10% of the players.

[FrozenOne]

Whats the deal with trains? Isn't that more of a psychical block? Place rails, locomotive, wagon behind it and ride with the wind! That isn't anything that a bushman who saw train at least once couldn't figure out.
Everyone feeling like that should try it, you'll see it's in fact easy!

Placing stops along the way and selecting them in a locomotive so that the train goes by itself also doesn't require degree in science. And placing signals is just bonus for people who like to play with many trains on one track.

[leeknivek]

I know it kind of takes away from the theme, but assuming this pollution is carbon-based emissions, shouldn't plant life be flourishing??

[Koub]

I know it kind of takes away from the theme, but assuming this pollution is carbon-based emissions, shouldn't plant life be flourishing??

Try to feed your plants with carbon monoxyde and carbon microparticles. Not every carbon pollution is CO2

[Akhiros]

I'm under the impression "pollution" isn't any particular thing, but is all-encompassing, even including things like dust and noise. (it really took me by suprise when I first noticed that mining expansions produced copious amounts of pollution) Assuming pollution includes things that could cause acid rain, damage to trees seems reasonable.

[Takezu]

If i see the pollution stats on the various buildings, i'm under the impression thats everything, like unused byproducts, CO CO2 nitrous gasses (the infamous acid rainmaker), waste like leftovers from assembly, who the f.... knows what comes out of the chemplant and refinerys
The tree destruction is a logical thing if all that get pumped into the enviorment.

[Cordylus]

If i see the pollution stats on the various buildings, i'm under the impression thats everything, like unused byproducts, CO CO2 nitrous gasses (the infamous acid rainmaker)

CO (carbon monoxide) is non-toxic for plants, because it immediately turn into CO2 - the main photosynthesis substrate. Carbon monoxide is toxic only for animals with the red hem-based blood. For example insects (biters?) are immune to the CO.
Nitrous gases are also the substrates of the fertilizers. The main acid rainmakers are sulfur oxides.

[Takezu]

Nitic acid is as agressiv to plants as it is to everything else, and to much Carbonoxide isn't helping plants, there is a point at which the balance collapses.
A system is healthy as long as it is in balance, you as player throw the balance off, and that has consequences. Yes Plants use CO, rather more CO2, and produce o2 and Carbonhydrats, but too much Carboncompounds, more then 1% per cubicmeter air, can have the opposite effect. And if i look at the pollution thats pumped out by a standart factory, you are skyroketing way higher then that