LÖVE

Hey everyone,

i've been thinking about how to implement savegames or savestates a lot. I'm working on an engine/library thingy which will do all the donkeywork not handled by love so I'm basically looking for an idiot-proof one-size-fits-all kinda solution (clientwise not implementation-wise), though I'm beginning to doubt there is one.

I know the easiest (and probably most responsible) way would just be to write all relevent data to a table and then serialize it, save it and then reload it with dofile, require etc... This approach has many throwbacks tough. First of all you always have to keep track of all needed values and object (which can be alot in a complex game), possibly strip them of userdata, pull them into global space, save it and then pull them back into the engine state when loading the data, making sure you dont break anything while doing so. This seems to be very error prone so you probably have to implement some sort of savepoint system to make it a little more predictable. Savepoints especially become a must with coroutines (which I'm using heavily) because i don't know of a way to save coroutines and re-establish them with their previous state.
Even with savepoints it seems kind of hard to do as my project is heavily object-oriented and I would have to write Save/load function for all my object states.

Facing all those problems, the other way seems like more convinient. Most PC games let you save wherever you want. In the old Lucasarts games you could save whenever you wanted, which seems really convinient for every player. At least in this case, they (probably) did it by just saving the whole script environment and then retaining it. I don't know if you can do that with love but it has been done in lua, at least this guy claims to have done it for grim fandango http://www.grimfandango.net/?page=articles&pagenumber=2.
Probably you would have to get rid of love userdata when saving and then reloading it which could be handled by an asset manager quite easily.

Maybe there is a third way, I just haven't thought of yet? Tell me your experiences with implementing savegames!

Implementing a serialization method for each class is a reasonable way to go.

A save state at its simplest is you dumping the contents of _G to a file, and all objects or classes exist as a table or subtable from _G. Nothing exists in locals. Then, on reloading the save state, you walk the loaded table (which I'll call _S) and where appropriate, you copy from _S to _G. This *may* work but would require a lot of tweaking and massaging to get right.

Save Games are about figuring out what combination of data you believe is minimally sufficient in order to resume the game from a point you think the gamers will find appropriate. So, in a platformer with a set of levels, saving is just a matter of keeping track of which level the player is on, how many lives and coins he has, and his current score. Reloading is then just loading that level, filling in the blanks, and then going for it.

The Mechanism for saving is love.filesystem.write and loading is love.filesystem.read. As for what data to put and take out of the strings, that requires either writing a DSL, or serializing to something that's a valid Lua table so you can eval it with loadstring.