Saved Games vs. Patch/Version Upgrades

[WSUCougar]

Three-pronged thread.

First, a basic "why" question, based on my very limited comprehension of game programming issues: Why is it so difficult from a programming perspective when upgrading a game (via patch or a new version) to similarly convert the information in a saved game file?

Secondly (and this is dependent upon the first question), why is this seemingly a low priority from the game developer/programmer perspective, when it often is so high from a game player's standpoint?

Finally, as a discussion topic, how important is this to you as a gamer? For me, it varies from game to game. The thought of losing the continuity of IHOF should there be a new FOF version is brutal, such that I probably wouldn't even want to do it. Other games that have deep "buy in" to career mode (such as CM/FM, TCY, OOTP) spring to mind.

Any opinion on this?

[Cringer]

As a gamer, it is not too important when it comes to solo play for me to have this ability to carry over a saved game. It would be nice, as far as text sims, but I can live without it.

But with FOF, there is now the MP angle to think about. Running the Imperial League is something I love, and I love the group of owners we have. A new version would clearly have to have the ability to continue with the next game, since I can't see an end to this league for a long time. But, on the positive side, everyone in the league already has the game, so if it is a must to continue on this version of FOF when a new one came out.

[stevew]

I did like the fact that Markus didnt require you to buy 6.5 in order to continue in an online league using that had switched(you can still use 6.1x). Stuff like that goes a long ways toward good will. If the new FOF came out, and wasnt compatable, id be pretty dissapointed.

[JonInMiddleGA]

I'll leave the first two questions to the experts, but I'll offer my personal view of the third one.

For me, the importance depends on a)what the changes are & b) what the status of my current career/campaign is.

If the game was unplayable or there was nothing I considered "active" in my mind, then no biggie about forward compatability. If I've got something still running & there's no showstoppers to be fixed by the patch, then I usually avoid patching until whenever I've abandoned any interest in the active career.

In a case like the EHM situation today, I'll simply avoid the patch until whenever I'm satisfied that I've finished my Gwinnett Gladiators campaign & then get it later. It's disappointing but not devastating.

[WSUCougar]

If I've got something still running & there's no showstoppers to be fixed by the patch, then I usually avoid patching until whenever I've abandoned any interest in the active career.
I guess this is the crux of the issue to me. I tend to invest myself in just a few very deep careers, rather than cranking out a bunch of different ones. Thus the patch vs. saved game dilemma tends to give more grief if it rears its head.

[Buzzbee]

** DISCLAIMER **

Not a programmer, but I did stay at a Holiday Inn Express.


My initial guess is that a new version will likely have a new database structure with new fields and new data. While it programatically might be possible to convert the old save file, it probably isn't worthwhile to take the time and make the effort to do so. Depending on how things are coded, I imagine you might have to

1) create temporary tables in a database,
2) copy the old save game data into those tables
3) fill in any missing data as a result of new fields
4) copy the old save game data from the temporary tables into new tables, making sure to not overwrite any necessary data in the permanent tables
5) delete the old tables to free up space/resources.

To write that process would take up a bunch of time that could be better spent on improving the game.

EDIT: Also, it might not even be possible to fill in data that wasn't in the previous version, so the process might not even be feasible. END EDIT

As for patches, if a new field was added as a result, then you'd run into the scenario above. If it is simply a code change, it might be possible to use an old save game, depending on what was changed.

[Solecismic]

Here's the big one: modifiying new AI routines to handle data fields that didn't exist in the old version.

I wouldn't even consider the issue for an SP-only game.

MP is another story. The AI is less important in the MP world, and continuity is much more important.

So, I would handle it by developing a program that could convert old saved MP universes to the new format. And that's probably as far as I'd go. I would not integrate the program into the game - it would be a separate add-on installed along with the game.

[WSUCougar]

Here's the big one: modifiying new AI routines to handle data fields that didn't exist in the old version.
So in grossly-oversimplified layman's terms, the AI in the original version looks for five data fields but in the updated version it looks for six?

[gstelmack]

From my perspective as a tactical FPS developer:

There are a couple of possible issues that can make saved game support difficult. One common issue is caused by new features or even bugs in old ones. What default value do you put in for a new field required for new features in the game? Or what default value do you use if you ship and discover later you missed a field? Those are often the types of changes that break saved games for us.

But it is entirely possible to work around the problem. Version your saved games, and have your read routines handle all possible versions (going back to the last breaking one). When reading older versions, supply an intelligent default of some sort, and if you can't that's where you have to break things off. The common mistake for new developers is forgetting to put the versioning support in from day one, but you tend to only make that mistake once.

Fortunately, I don't have the problems Jim does, where you go to a whole new version of the game with a differing game design, but still want to continue games saved with an older version. The closest I've come is with mission packs, which tend to add features but aren't a complete rework of the engine. I can't even imagine trying to support saved games across sequels, but the approach he described (convert to a new saved game once and be done with it) is about the only one with a chance of success. The complicating factor here is making sure you don't radically alter the structure of the game. For example, if you're adding a new player attribute, you need to set it in such a form that a star QB in the old universe doesn't suddenly tank thanks to the switch to the new version. This is similar to the "what default value do you provide?" quandary I mention above.

The fun part is testing all this. You've got to save games in all kinds of situations with all different versions you've shipped, and then verify they load in the new version. Our saved games are pretty complex, as we're saving the complete state of a real-time physical simulation (dealing with things like grenades in the air, people in the middle of reloading their weapons, what the AI is thinking) and trying to make sure that saving/loading the game does not give the player an advantage (think of the Rome: Total War issue where saving a campaign caused the AI to "forget" its current strategy and abandon sieges). This makes testing saved games in the single version configuration complex, as now you're adding lots of versions to the mix.

[Solecismic]

You can retrofit versioning support. It's a little harder, but I've done it many times. The key is to make all adjustments in the open function right off the bat.

However, setting an intelligent default value isn't so easy. In many functions, you need variety among the data set. Setting everything to a median default value (or to a zero) can play havoc with the AI.

Sometimes, like with the "number of championship rings" variable I added with FOF 2004 5.1 (or thereabout), setting a default of 0 for everyone works just fine. But if it were a player rating, not so fine. You'd need to insert a random rating distribution function (fortunately, I have a lot of those already in the code - many of the FOF ratings use vasty different distribution models).

[Buzzbee]

So in grossly-oversimplified layman's terms, the AI in the original version looks for five data fields but in the updated version it looks for six?
And to extend that, the data in that sixth field has to be created (since it isn't in the original save file). That's what is tricky, because you can't necessarily set everything to 0.

If that new field was an 'intimidator' rating, you can't just go assigning random values because player ratings would change from the old save to the new version (since the new AI would use the aggregate ratings to come up with an overall. Joe "Mad Cow" Holstein might drop from an 85 rating to a 74. Joe Wolfe might change from a 52 to a 60.

Therefore to retrofit, you'd have to create a routine to assign an 'intimidator' rating based on the players overall rating so that the new Intimidator rating didn't affect the balance of the old save game. It just isn't worth it.

That is just one extreme example, but demonstrates the complexity. Patches are somewhat easier (I believe) because they don't usually involve database structure changes. However, even then a small code change can have big ripple effects as that code might be executed numerous times.

[cuervo72]

If that new field was an 'intimidator' rating, you can't just go assigning random values because player ratings would change from the old save to the new version (since the new AI would use the aggregate ratings to come up with an overall. Joe "Mad Cow" Holstein might drop from an 85 rating to a 74. Joe Wolfe might change from a 52 to a 60.

In this case, I think I'd just write a function that based it (in part) off of leadership and play to win. :p

[WSUCougar]

In this case, I think I'd just write a function that based it (in part) off of leadership and play to win. :p
Yeah, but you design pink flamingo helmets, so what do you know? :D

[Icy]

I agree that the problem is when the new patch adds new field to the database as you can't random fill them for the existing savegame without affecting a it lot.

Btw, Gstelmack you made me curious, which tactical FPS are you developing? do you work for a known one?

[cuervo72]

Yeah, but you design pink flamingo helmets, so what do you know? :D

I know how to design pink flamingo helmets.

[gstelmack]

Btw, Gstelmack you made me curious, which tactical FPS are you developing? do you work for a known one?
I don't talk about it much as I'm here as a fellow sports fan, fan of FOF and some of the other text sims, and general right-wing conservative nutbag, not as a company rep (i.e. I don't want to and in most cases CAN'T answer questions about the products, etc). But a quick web search will turn up your answer...

[Buzzbee]

For the lazy, I found this:

http://www.roguespear.com/logs/

[gstelmack]

For the lazy, I found this:

http://www.roguespear.com/logs/
Hehe. I haven't been to work at 8AM since my daughter was born. And boy did this bit stir up a firestorm:

A3D 2.0 is a wavetracing standard. To support it, we'd have to munge our geometry and pass it down to their API. This is not an easy task with our maps and so is not going to happen any time in the near future.
I had some fun discussions with the Aureal guys over that one...

[Icy]

Wow gstelmack, i did a search and awesome curriculum, congratulations on the awesome games you have worked in. I'm a big fan of realistic tactical games and have playerd some of those, i'll look at you with other eyes from now http://www.prodeportes.com/images/bow.gif http://www.prodeportes.com/images/bow.gif