Hello,
Pretty much half of the office has been sick in the past week, but that still hasn't stopped us from progressing in the development of your favourite pollution-generating game (though I have been playing some Cities skyline recently and there you can screw the nature around quite creatively as well).
The reason for infinite research is mainly to give some optional resource sinks for people that like to make huge factories. The research cost/gain ratio is going to have diminishing returns so the player bonuses don't become too absurd.
The main problem was to define the way to specify the research requirements growth. Sometimes it should be linear, sometimes quadratic, sometimes exponential. To make the modding of it free enough, we allowed to specify it via a formula, so for example, the Worker robot speed research 6+ has the formula specified like this:
count_formula = "1000*2^(l-6)"where the l stands for the level of the research.
I wrote our own small math formula parser for Factorio, so the formula is parsed only once and stored internally as the graph of the expression, so it can be evaluated quickly for different values. We might find handy usages of this on other places in Factorio later on as well.
Anyway, the formula as it stands means, that the level 6 costs 1000:
As every other level costs twice of the previous one, the level 10 costs already a ton:
This change was easier than I expected and the plan is to have infinite research for most of the upgrade technologies in the game, which is now very simple to add to the game. I'm looking forward to see how far I can go with my playtesting base with these. I'm thinking of a way to improve the circuit production already :)
We have made quite some progress on the Blueprint Library, which will be one of the bigger 0.15 features. Check out the introduction in the FFF-156 if you need. At the moment the basics for the singleplayer usage are finished. You can have blueprints stored locally in the game as well as in the persistent (across saves) storage.
There is (hopefully) intuitive GUI to work with the library. You can export blueprints and blueprint books from the game to the library. There it is possible to move the blueprints around simply by dragging either within the same storage or for instance from game storage to the persistent storage or vice versa. Of course you can move the blueprints in and out of the blueprint books as well.
Detail GUIs for blueprints and blueprint books are very similar to the GUIs already in the game with additional possibility of (instant) crafting and deleting the blueprint / book from the library.
Screenshots show the proof of concept with details of a single blueprint book and then a blueprint within that blueprint book opened.
The next point in the Todo list is to make the whole thing work for the multiplayer as well - you can see other players' blueprints and download them. This will require some fragmentation tricks to avoid hiccups when sending a lot of blueprint data over the network.
As part of multithreading update preparations, another nice little optimisation came up. It is related to situations like this:
The problem is, that there are a lot of chunks where nothing happens, only pollution needs to be calculated. The pollution simulation is written in a way, that every chunk updates its pollution spread only once per 60 ticks (once per second). Every chunk updates at different moments of the 60 tick cycle, so the CPU drain is distributed. The problem is, that the code was written in this way:
// handle pollution (every second for performance reasons)
if (tick % 60 == uint32_t(abs(this->position.x) + abs(this->position.y)) % 60)
... handling pollution logic ...
This means, that for all of those chunks that have nothing else but pollution, the game has to go through and check whether its pollution shouldn't be updated this particular tick or not.
As I know when the chunk is going to be updated next time (in 60 ticks), I can just add it to the particular queue of chunks to be updated in the 60 ticks ahead. This means that these particular chunks (as long as something else doesn't interfere) will not have to be accessed at all in the meantime:
This change itself improved the performance of big factories by something like 7%.
As you probably know we intend to polish the game and user experience within the coming releases. This includes the GUI overhaul, improving the existing missions and adding the so called mini-tutorials or interactive tips and tricks (mentioned in the previous FFF) - Klonan has actually started to work on these and he will bring some news soon.
With all these plans ahead we have figured that we really need a dedicated UI/UX designer to work with us on these projects (and maybe some others). As the situation stands all the work would be done by Albert, however finding a contractor who would come here to Prague and cooperated with us on these would be a big relief of workload for Albert and it would allow him to focus on improving the in-game content. Not mentioning that professional UI/UX designer would ideally have the skills to start working on this immediately, while Albert would need some time to do his research.
Long story short, if someone you know (or you yourself =)) would fit the job description and find the work interesting, send him our way=) It will most probably end up being a couple of months cooperation when we will require the designer to come to Prague occasionally to discuss the progress.
And as always, stop by at our forums and let us know what you think.