Topic: Saving feature details

Just as I did with sonic rebirthon dreamcast, the save feature should take as less space as possible, well here's how I think it should be more or less.

It should be saved in binary format, and have a few int variables like:

int lives;
int continues;
int score; ( maybe this would require a higher data type... )
int emeralds;
int zone; ( current zone )
int act;

Any other variable you might want to add?

The best way to do it I think its using the standart C  file saving functions, and maybe all of these variables should be in one struct, then when saving just output the struct to a file.
I could write the code for that if you want Alex.

Re: Saving feature details

That wouldn't work, as we have custom quests and our needs may change as the years pass.

In order to keep things simple and compact, let's impose a limit (say, 3) for the number of SAV files per quest.

Quests may or may not allow saving (the developer of the quest decides this - it's ridiculous to have a save system for the tutorial quest for example). Let's say you made your own custom quest, neoblast.qst, and it allows saving. So, there would be 3 files:


Since we need to save space, here's my idea:

  • FILE SIGNATURE: 24 bits (3 bytes)
    Something like "OS1", "OS2", "OS3", etc. It tells us that this is an Open Sonic save file and also the version of the saving algorithm (so, if we need to add new features in the future, we can provide backwards-compatibility)

  • CURRENT LEVEL: 8 bits (1 byte)
    We can have up to 256 levels (1 act each) or 85 levels (3 acts each) per quest. A quest is basically a list of levels, so this information already includes in what act the user stopped playing.

  • NUMBER OF LIVES: 8 bits (1 byte)
    Unless the player is hacking the game, I assume she/he can't get more than 255 lives per quest.

  • SCORE: 32 bits (4 bytes)
    Stores a value between 0 and 2^32 - 1 (inclusive)

  • BONUS ITEMS: 8 bits (1 byte)
    Bonus stages aren't implemented yet, but we should add this anyway. This is NOT an item count. We also want to keep track of which items (not necessarily emeralds) the player has got so far. Assuming that the number of items is always 8 or less (i.e., 7 emeralds), we can do some nasty bitwise operations to keep track of this.

This seems good enough for a first version of the saving algorithm, and we only used 10 bytes! New versions of the algorithm should use a little bit more space.

(offtopic: if you really want to do some programming for opensonic, consider developing a new level editor program instead. THAT is something we really need, and I don't see myself making it anytime soon, as it's very time consuming)

Re: Saving feature details

Hummm, so the main game will be a quest and itwill include the list of all zones, ok.
Well 10 bytes, fair enough, but newer versions would require more.

About the level editor, it is very time consuming, and I have to fully understand the level/theme stuff. If it was a tile based game I could make in in much less time as there are a lot of open source editors with that option and really customisables, but it's brick based so it will take a little more...