Hello, technically this post is the π Friday Facts, but unfortunately we can't think of anything special to do... maybe someone can make a Combinator cake... that can calculate π?
We released 0.17.69 as stable this Tuesday. It seems it all went very smoothly, no avalanche of crashes, and only a handful of technical support emails about updating video drivers.
Click to view full resolution
Apart from stable, essentially no development work has happened this week; nearly everyone is on vacation (I am even writing this as I sit in the airport waiting to fly to London for a wedding). We're hoping that at the start of next week, with all the relaxation over, and the pressure of stable off our shoulders, we will get cracking on the next updates with renewed energy.
In fact I might be a little optimistic in saying this, but I think we are in for some exciting times here in the team. Before now, we have always done a cycle of having the whole team on development for a few months, then the whole team bug fixing for a few months. This binary approach is what gives us the traditional 'stable' and 'experimental' labels. This is not to say that all bug-fixing would stop once stable it out, quite the contrary, but this has been the general strategy.
What we are planning, if the logistics of it turn out okay, is to have significantly smaller feature releases, containing only a handful of new features. This is to have a sort of mixed cycle, and a mixed cycle in two similar ways:
For example, while one developer works on a feature for the next feature release, another will be bug-fixing the features in the current release. This is only practically possible if the feature release frequency is relatively high.
This new structure has been a long time brewing in our minds, and we think now is the right time to try it out. With the GUIs we really need to do quick iterations and receive fast feedback to the changes. The traditional release flow meant that we could add a new feature to the game, and players wouldn't get their hands on it for months. Then once it is released and we start getting feedback on it, extra time is spent just re-orienting ourselves to the code and how it was written. If the feedback is given expediently, the rework and improvement is much more efficient.
Furthermore, I think it is more psychologically effective to work on a mix of bug-fixing and development. This is just theory now, but grounded in some observations I have made over time.
Development work, a new feature, new GUI, etc. is generally a long-form creative process. New systems have to be created out of pure thought-matter, ideas for implementation have to be evaluated and determined, and it also involves a lot of 'background processing'. Feature development always has more room for extension, and it is very hard to say 'It is finished'. It is also quite a subjective result, so sometimes it is hard to know if you 'did a good job'.
Bug-fixing on the other hand is very short form and challenge oriented. It is like investigating a murder mystery, and really feels like a complete story. Tracking down a problem inside the game engine engages a logical part of your brain, trying to piece together and backtrace where the fault is occurring. Generally the bug has a very clear 'win-condition', and you can close the game and let your mind rest peacefully. The result of a bug-fix is grounded strictly in objective measurements, so you can be reasonably sure if you 'did a good job'.
So these two parts of the job are in a way, quite distinct and separate: Development is a long-form creative process; Bug-fixing is a short-term logical process. From all this, my reasoning is that focusing on only one for a long period of time leads to quicker mental fatigue, and that a balanced workload will keep us happier and more productive. In essence, doing development lets our bug-fix circuits rest, and doing bugs lets our development battery recharge.
There are also some pragmatic reasons I think the smaller/quicker releases will make things move along more smoothly:
At the start of the year, I read a book called "Rolling Rocks Downhill" by Clarke Ching. It is a book about software project management, it was quite an enjoyable read, and gave me a lot of inspiration to try and optimize our development effort. At that time we were just wrapping up 0.17, so there wasn't a whole lot of room to make changes to the way we do things. Now that we have stabilized 0.17, and with it, completed the 'traditional' cycle, there is opportunity for a fresh approach. I guess I will give the book another read next week...
As you might know, I've spent quite a considerable amount of time playing World of Warcraft classic the past few weeks. I find it very interesting that many people (me included) find this version of the game way better than the modern version, there are many reasons for it that I see (and some that I don't), yet it deserves some small analysis as it is always better to learn from mistakes of others. By that I mean, that I wouldn't want to spend next 10 years working on better versions of Factorio just to find out, that the old ones were better for some reason.
The topic that connects it all is "Making things more convenient isn't always making things better". There are a lot of activities in life and games that we would like to remove or make more convenient, but we don't really see the hidden benefits of it. Something like making an elevator to save time and effort, and feeling bad for moving less in the long run.
One of the things in wow is nicely illustrated by in this video. When people had to gather group for a dungeon back in the days (and now in classic), they had to do it manually. They had to spam LFG (*Looking for group) channels, ask in guilds or find long-time buddies to play with. In modern wow, they made a dungeon finder that allows you to just select a role and automatically teleport you to a dungeon with the appropriate people. It seems like a great convenience. But in fact, it removes so much that it is considered to be one of the most hated feature by many people.
Another big example is level scaling. The idea is again nice, to make it more convenient. With level scaling, monsters conveniently scale to your level in the zone where you are, so you can quest at any place without having to avoid too high or low levels areas relative to your level.. But I consider this to be actually plague of any game where it appears. Instead of zones, their levels and your level meaning something, and the progress being clearly visible every level, suddenly it all disappears. The world isn't a place to explore, but rather arcade-like place that all resolves around you. Your level doesn't mean much, as it being too low isn't a problem anymore. The moments of having to run from areas where you are too weak to get back later are one of the most important in RPGs, and suddenly they are gone. The progress you see in games is like looking from a window of a train, if the train moved and the landscape moved the same way, you wouldn't feel like you are moving at all.
There are much more lessons learned while playing the game. Not only the mistakes made in modern version, but also lessens of good game design obviously. How could these be related to Factorio? I believe that on the deeper level, there could be a lot of parallels.
Anyway, thanks to all of you for such a great year so far, thanks to all our friends on the forum and throughout the community who have helped us in the great bug war of 0.17, and as always, let us know what you think on our forum.
