Hallo,
I am investigating the use of object->u8vector for serialisation of game state. It seems pretty straightforward, but I am concerned with future updates. I suppose that if I alter the structure in future versions I must change the 'id' field as well, so the old serialised structures won't be recognised as of the same type? Are there other gotchas I should be aware of?
Cheers,
Afficher les réponses par date
I've been thinking of a similar solution for game states. It would generally be clean and safe. The only problem I've been studying is upgrading previous game states, because you don't want want to throw out previous ones. I've been thinking of writing functions to upgrade one version of the game state to the next. When you load a game state, you find its identity according to the "id" parameter, and upgrade it accordingly if necessary.
- James
On Tue, Dec 1, 2009 at 1:00 PM, Alex Queiroz asandroq@gmail.com wrote:
Hallo,
I am investigating the use of object->u8vector for serialisation of game state. It seems pretty straightforward, but I am concerned with future updates. I suppose that if I alter the structure in future versions I must change the 'id' field as well, so the old serialised structures won't be recognised as of the same type? Are there other gotchas I should be aware of?
Cheers,
-alex @asandroq http://www.ventonegro.org/ _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Hallo James,
On Tue, Dec 1, 2009 at 6:08 PM, James Long longster@gmail.com wrote:
I've been thinking of a similar solution for game states. It would generally be clean and safe. The only problem I've been studying is upgrading previous game states, because you don't want want to throw out previous ones. I've been thinking of writing functions to upgrade one version of the game state to the next. When you load a game state, you find its identity according to the "id" parameter, and upgrade it accordingly if necessary.
So you would keep the old structure, with the same id, and create for instance a new type game-state-2, with a different id, and a converter procedure update-game-state-1->2?
Cheers,
On Tue, Dec 1, 2009 at 1:14 PM, Alex Queiroz asandroq@gmail.com wrote:
So you would keep the old structure, with the same id, and create for instance a new type game-state-2, with a different id, and a converter procedure update-game-state-1->2?
The more I think about it, the more I realize that we are basically dealing with the same problems as SQL schema evolution. It's a hard problem. I suppose you would have to keep all the old structures laying around. You could only rename old structures though, and keep the current one the same name. The update functions are equivalent to SQL "patches" which sequentially patch a database to produce a final updated schema. It's an annoying solution, but if you want to keep backwards compatibility, I can't think of anything else.
If you don't care about throwing away old game states, then simply changing the id would work.
- James
-
Alex Queiroz -
James Long