Yes, game 2 will allow game saves. This is not necessarily an indication that the missions will be intrinsically longer, just a realization that some maps and some players sometimes need to be able to save a map and continue it later. I suppose it may also lead to a ‘gray’ market in saved game files, but that’s a price I’m willing to pay.
So, for the last few days I’ve been working on the save game infrastructure and it’s every bit the pain I remembered it to be. “Why so painful?”, you may say. Well, the state of the terrain, creeper, units, packets, and game metrics all have to be persisted and then reloaded. Sounds straight forward…. for the creeper just record the creeper array and then reload it… and same for the terrain. For most units there are variables that change (like its state, its position, its health, ammo load, etc). These numbers are easily persisted.
But then along comes something like a packet. A packet begins at some location on the map and then remembers the target unit that it is headed for. It has to remember its target unit because the target unit might be moving around while the packet is en route. The target could even be destroyed before the packet reaches it. So the packet needs to know where the target is at any moment. Naturally, I simply stored the object reference of the target unit in each packet during run-time.
This means that when I save a packet in the save game file I have to know what target unit it points to. To solve this problem, each of my units have UIDs (Unique IDentifiers). These UIDs are just integers and no two units have the same integer. So now a packet just needs to save the UID of the target when it is saved in the save game file.
Upon reloading, I have to look up the object reference of the target unit based on its UID. The packet does then when it is being loaded and created from the save game file. Of course this means that the target unit must already exist and have been loaded already! This means load order is important….
So, this solution works as long as cross object referencing is minimal and manageable. If two objects each held a reference to each other, no load order could resolve the issue. In this case, object construction would have to proceed “on demand” and not really in the order the objects are encoded in the save game file. Or, the assignment of the object references would have to be lazy and done at some point after all objects are constructed.
Anyway, technical issues aside, there will be save games… yay!