Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags
(+1)

Congrats on getting featured in Alpha Beta Gamer! Did they approach you or did you ask them to check your game out? 

A blog on how you handle saving would be worth reading! I've been interested in how this is done in games.

(1 edit) (+2)

it happened out of the blue: there was just a sudden surge in downloads and I even had to follow the url referrals to find out why
but alas the download count is back to normal now .. my 15 minutes of fame is over 😔

anyway..
I guess my method of making the save files is a bit unorthodox :
- every actor in the game is derived from a single base class
- each actor has an unique id
- they use this to refer to each other instead of pointers (a big hash map is used to pair id and actor pointers)
- this saves me a lot of trouble: actors can refer to each other without smart pointers and pointers don't need to be turned to handles during saving
- one problem though is that there are about 400 different actor classes (it's a mess)
- when you load a game you need to figure out which object class need to be recreated
- for this the class name is saved (there is a handy function called "typeid" to extract this)
- and to ease the pain of creating an object factory I abuse a C/C++ feature where you can set
a variable using a function (with macro magic each actor has a seperate function to create itself - a pointer to this function is registered into a list of character array at the very start - of course this is not a good practice and it's a big hack but works great)
- for saving everything is stored in a giant xml file:
   -  this has the advantage that the order of variables doesn't matter
    (if I add new variables later in patches I don't necessarily break old saves)
  - and also I can use the save files for debugging (e.g. to test if saving is correct I can reload the save - save it again and compare the save files)
  - the disadvantage is that it's slightly slower than storing them in binary
  (also they can be hacked very easily - but I don't mind that)
- they also have a somewhat big file size and stored in a compressed form
- there is also extra data stored at the start for the save menu to know the date and map name
but in hindsight this info should have been stored in a seperate file (like the screenshots)
 also I guess compressing them is a bit of an overkill (there is not much space saved approx 1.5mb  files  compresed down to 150kb  size)
- for maps only the name of the map is stored - to save space - but this means if I update a map I potentially break saves

- and of course there is a seperate file to store which map was reached for level select - but this is just a single value

sorry for the wall of text - I don't really have idea how to illustrate this - it's mostly code related stuff

(+1)

Thanks for the detailed explanation -- it sounds way more intimidating than it probably is. Good to know though that using xml won't "break old saves". I've seen SOOO many games here on Itch and on Kickstarter where the developer has to put out a notice saying something like, "Hey guys, v5.0 of my game is out . . . but old saves won't work with it." And of course the players get very irritated at that. But sounds like you got that part figured out, so good for you! :)