Lady: making savegames easy

[Robin]

I made another library. This one is intended to make savegames almost trivial to do.

Here's the GitHub repo.

1. Use lady.register_class on every class whose instances could end up in the savegame
2. Use lady.save_all(filename, wholegamestate) to write to a savegame
3. Use wholegamestate = lady.load_all(filename) to read from a savegame
4. Profit!

It currently supports MiddleClass, SECS (at least the basic version), hump.class and Slither.

30log is also supported, as long as you:

1. Don't call `tostring` on any loaded instance of a 30log class.
2. Don't have methods that make use of upvalues in any 30log class.

[Roland_Yonaba]

Lady... I like that name. Very nice!

[Robin]

Actually, looking at it again, I think it works for 30log as long as you don't try to use tostring() or have methods that use upvalues. Neither of those is really fixable with the current version of 30log.

Slither may be easier to support than I thought.

EDIT: Slither is now supported.
EDIT2: Also, 30log is now "supported", with the exception of the two things I mentioned in this post. That required no code change, I just needed to do some tests before adding the claim in my README.

[adnzzzzZ]

Silly question, but how does it handle things that can't or shouldn't be saved like images, shader instances, physics bodies and so on?

[Robin]

Not yet! I realised after releasing Lady that it didn't yet do those things.

The way I would handle them would depend on use-cases, though. If anyone wants to use Lady for something that it doesn't yet support, please share the structure of your game data with me (what kind of LÖVE objects are you using, how are you using them, where are you putting them, what kind of resource management do you use if any).

EDIT: At this point, the suggested solution is to keep gamedata (player position, etc) separate from resource data. For example, if you have something like entity.img, let that be a string or something that indexes a global images table that contains the actual images.

The only alternative I see at the moment is Lady wrapping all LÖVE resource loading to keep track of them, but that doesn't really work for things like Sources...

[adnzzzzZ]

I have a very limited understanding of how save libs work, but I've been looking at Ser and Slib since I'm gonna add saving soon to my engine. Have you thought about implementing an option to not save certain table parameters like http://love2d.org/forums/viewtopic.php?f=5&t=77295 does? In his case he simply lets you define which attributes to not try to save in the save call, i.e.:

Code: Select all

save(table, {ignore = {"image", "body"}})

Or something like this. I dunno how this translates to your lib, if it'd be better to point what to ignore in the register_class call or in the save call. Either way, this seems like a clean solution to the problem.

[Robin]

Hm, no, that has problems, because if you load a game, it doesn't have the images or bodies it needs and you'll probably get an error the very next frame.

I have an idea, though.

[adnzzzzZ]

Sorry if I'm getting annoying but you mentioned something else that I forgot to ask about: how do you handle the possibility of threading or of using coroutines? From the github page you have a register, save and load call. I imagine save/load do the whole work, but if you're saving/loading a lot of stuff this can take time, especially since you're writing to/reading from disk. How could the save/load calls be split up to allow me to do other things while the game is being saved/loaded?

[Robin]

Lady now has support for most physics objects (not yet Joints, and I probably won't be supporting Contacts ever)! WIthout any need for registering anything!

As an example how it works with physics objects, I have in the attachment someone else's code that I took from the forums, and added saving/loading. Rightclick = spawn body, S = save, L = load.

---

I see what you're saying. I don't think there will be a significant delay to either save or load.

The problem of coroutines is that things will get messy. Some parts of the savegame will be a different state from other parts, because it gets modified while you're saving it, which will probably lead to a corrupt savegame.

Threads fix this, but they fix it by requiring you to copy everything over to another thread, so it might actually take up longer, depending on how much stuff there is to copy.

All in all, I don't think there is a good way to do this, but I'm open to suggestions.

[Snuux]

Good day! "Lady" - best name ever!
But I don't understand, for what you want to save classes? Why not usual tables?