Using the config module for game saves?

edited April 2014 in Help request
There is a wiki entry that has been empty since I started using orx, and that's the "using the config module for savegames" entry. Now I'm curious. How would you go about doing such a thing? Would it be efficient? Is there any way to make it secure so that people can't cheat? (Not that I would, but I'm curious).

It seems like a good idea, but I want to know the ups and downs, and how to actually do it if I decide to. Thanks guys, you're great!


  • edited April 2014
    Ah yes, I should probably write that section one day and actualized some other config-related ones. :)

    Actually I'm using the config system for my savegames in a very straightforward way, nothing really fancy.
    I usually have a config section that I name Save in which I stored what I need. Sometimes I need other sections as well, either I reference them in a list stored within Save, or I base their name on a given pattern to easily filter them when saving to disk.

    When I need to save on disk, I pass a filtering function to orxConfig_Save that will only keep the Save section (and the extra ones if needed). I also use encryption so that the files wouldn't be human-readable. In order to do that, I simply set a custom encryption key with orxConfig_SetEncryptionKey and pass orxTRUE to encryption parameter of orxConfig_Save. Note that the encryption key has to be set prior to reading back the savegame or you'll end up with garbage.

    There are more efficient way of storing savegames, especially if you need to save a lot of data, but fore modest needs it's actually pretty convenient.

    I use the same system for storing preferences (sound & music on/off, fullscreen/windowed, ...) as well, except this time it doesn't have to be encrypted.

    Lastly, as we're on the topic of alternate uses of the config module, I also have a section I usually call RunTime that only exists, well, at runtime.
    I use that section as a blackboard used to have different systems communicate. I'll likely stored GUID of some main/singleton objects, like the menus, the splash screen, the game scene, the music dummy object, some global gameplay variables, etc...

    This way I can easily retrieve those special objects either from code or from timelines/commands. I often end up with a small generic track that allows me to easily store object's GUIDs when they are created:
    0     = > Object.GetName ^                                  # ; Gets object's name
            > Config.GetValue < ID                              # ; Gets the value of its ID property from config
              Config.SetValue RunTime < ^ ; Stores object's GUID under RunTime.<ID>
    ; In addition to all its regular properties, we'll store its GUID under RunTime.MainMenu
    ID = MainMenu
    TrackList = T-StoreID

    Now let's say I want to delete the main menu, I can do it from anywhere. All I have to do is:

    With a track:
    0 = > Config.GetValue RunTime MainMenu # Object.SetLifeTime < 0

    Or in code:
    orxU64 u64MainMenuGUID = orxConfig_GetU64("MainMenu");
    orxOBJECT *pstMainMenu = orxOBJECT(orxStructure_Get(u64MainMenuGUID));
    if(pstObject != orxNULL)
      orxObject_SetLifeTime(pstObject, orxFLOAT_0);
  • edited April 2014
    The Runtime idea sounds brilliant! I'll keep that in mind.
    Although it's not going to be relevant to me for a while, how would you handle large save files?
  • edited April 2014
    Well it all depends on what you want to save. Do you have more details?
  • edited April 2014
    No, I was just thinking about how to implement saving games on a larger scale. Like RPGs or something.
  • edited April 2014
    The way it's usually handled is by having a serialization system tied to the objects member variables you want to save.
    There are additional strategies one can use on top of that to reduce the size of the savegames, such as using delta encoding, for example.

    This approach can also be overkilled when possible object states are limited.
Sign In or Register to comment.