devtrackers.gg
Hello, long time no talk, we've got some catching up to do...
Almost 1 year ago (FFF-365) we said "we don't think that [the expansion] will take less than a year to develop". Well it has been less than a year and it is not finished, so we kept our word on that :).
But while it might not be finished, there is a still a lot we have done so far.
Expansion news
We still don't want to be specific about many things, not even the expansion name, but we can start by giving you some general idea about the scale of the project. The general goal is to make the expansion feel like as big an addition as the whole vanilla game. This is why we plan to price it at $30.00, and put in enough content to make it well worth the price.
Honestly, making the price (and thus the expected scope) a little bit more concrete in this way, motivates us not only to make enough, but also to not overshoot, so we wouldn't spend another 9 years doing it. Generally the fact that the team size has increased, and there are a lot of things in the engine that we already solved, should hopefully imply that the expansion takes way less time than the base game.
7 step plan
Step 1 - High level plan
We decided and planned the general topics of the expansion. This is comparable to when we were deciding to add trains to the game. We knew that we wanted to control how the intersections work, and that it should act as the largest scale logistics option, but the details weren't laid out yet.
Step 2 - Basic shape
This is the step where we start to make the actual game objects, even when they don't even do anything at that point. For the rail example, this would mean that we make mock objects for rails, trains, train stops and signals, so different people can start implementing the behaviour in parallel, and start making it interact as they go. In this phase, as things stop being as abstract, a lot of the most basic unexpected problems start to show.
Step 3 - Implementation of sub systems
The goal of this part is to get the individual mechanics and their object definitions into place, but they are usually the minimum necessary to test it. It's like implementing biter and spawner mechanics, but having just 1 type of biter, not connecting it to pollution, and having no sense of balancing with the player weapon systems.
Step 4 - Connecting systems into a prototype
Here we put all the sub systems together and try to connect them. A lot of bigger structural problems can be discovered at this point, which might require some wild removals, changes, or additions, required to make it all work together.
This is where we are now in the expansion progress. Big parts of the game are playable, and we are approaching a state where we can playtest from start to finish.
Step 5 - First pass of tweaking
This part should feel much better, as the content is more stable and the chance of removing things is lower. This is where we can actually have the semi-final list of requirements for the graphics department, which allows us to start making reasonable time estimates. At this point, we do more playtesting, and we can start polishing the roughest edges. This polishing is mainly focused on basic balancing, the biggest UX issues, broad pacing improvements, etc.
When I come back to the parallel of the train implementation, this is the phase where the trains are fully functional, but it's cumbersome to control them, so we need to improve the way rails are built, provide the trains overview, improve the schedule editing, etc.
This is kind of a loop, where we implement additional things based on the feedback from the previous loop of playtesting. This step is also waiting on graphics, and we have also learned that UX improvements are not easy, so it will take a long time.
Step 6 - Beta test
At this point, most of the graphics are in place, and the game is fully playable. When the game feels close to finished, we can tweak the final details, like new simulation screens, tips and tricks, achievements, and so on. We can also start to invite a limited number of players to help us find the most obvious bugs. We want to also invite some of the mod makers to help us test the modding API, and let them prepare for the release. Same goes for our top community translators/proofreaders on Crowdin.
Step 7 - Release
The tricky part is, that we want to release basically directly to stable, without an experimental phase, like when we released 1.0. The reason is the obvious problem we would have otherwise: An experimental release is not interesting to many people, but by the time it becomes officially stable, it is old news and nobody cares. Hopefully the focus on automated tests and beta testing should make it smooth enough.
Release strategy
The original plan of just releasing the expansion as a big update sounded very natural. We imagined, that 1.1 would basically become completely stable and we wouldn't have to worry about it, and just focus on the new versions. However, this proved to not actually be possible, and maintaining both versions is just more work. On top of that, the huge refactors we made in our current master branch made the process of merging fixes and changes into 1.1 quite painful. Also, if we wanted to change anything structural, we would have to keep the migrations from 1.1. forever, and we would also need to support the 1.1 map version loading indefinitely.
This lead us to a different plan. We will release the 1.2 update to the base game, and the expansion will be based on the same version, and will also contain the expansion mod. The executables will be slightly different, so you couldn't just install the expansion mod without having the expansion executable, but other than that, the code will be identical.
This has some very nice implications:
- The expansion content will be just a mod that you can actually turn off, so you can easily play a non-expansion playthrough if you want to.
- Since the versions are compatible, the expansion version can connect to non-expansion multiplayer games by disabling the expansion mod.
- All the changes to the game, modding, and scripting API etc. will be done just once, so we don't have to keep 2 versions of Lua docs for example.
- Lots of the quality of life (and other) improvements we prepared for the expansion will just appear for everyone, so the expansion will be more strictly about the new content and mechanics.
To be clear, the expansion will not be 'just' a mod, the game engine itself will have some significant improvements and technical backing to make many of the new gameplay features possible. These engine capabilities will be available with the expansion build/executable, and we will add a mod info flag like 'uses_expansion_features', that will mean the mod will only try to load in the expansion (and this will also be used for other things, such as mod portal filtering).
Graphics department
The requirements on Factorio graphics are often heavily rooted in the behavior and mechanics of entities. When the gameplay is just getting designed and tested as we outlined in the plan above, changes and even removals are common.
To avoid reworking or scrapping graphics which take a lot of time and care to create, we try to work on things with the most solidified gameplay mechanics first... or improvements that don't change the mechanics at all!
Mp4 playback not supported on your device.
Or concept art of new stuff.
We hope you enjoyed this small update, and you can let us know what you think at the usual places.