Working on some refactoring today around the saving/restoring/initialising code for Productive. I'm trying to keep the "Map" class fairly generic, so that teachers and students can write more interesting map types later on. Part of that is deciding which parts of the setup are configurable in the map.

If we make every little setting configurable (e.g. the amount of starvation resistance that is restored by being fed properly for a given period), then the file-format becomes intimately tied to the implementation. If we make those values not part of the map, then when we improve the algorithms the game-play will change (hopefully improving)... but then it's a different game than the players were playing when they saved the game-state.

Obviously could just be an option, but I don't think we want to get to the level of asking a user "would you like to restore the STARVATION_RECOVERY_FACTOR" from your saved games (otherwise you get into configuration dialogues like freeciv, where the array of options is pretty much impenetrable to a new user). For now I'm thinking we'll store the settings in the game definition, but we won't load them. They'll be there for the clients to use for animations and the like, but the simulation will override them on load/restore, sending out the values it's currently programmed to use. When we've stabilised enough we can look at restoring game parameters.

Oh, starvation, territory control and the like all work now. Only major pieces missing are the timers (to slow down various processes) and the path-finding stuff as far as the simulation is concerned.

We just need the networking, introduction/lobby screen and the statistics readout. Even without the path-finding stuff and the timers, the simulation is still pretty interesting. You can play it as-is, it's just a really fast game, as everything is instantaneous, and there's no defensive walls or the like possible, so you have to react to any incursion immediately (active rather than passive defense).