next »

[IndieDev717]

Hi Everyone,

I'm currently working on coding the save system for an indie game. The way I am designing it is when you start a new game you select a slot to store game data in for that particular play-through. So as you save your progress it will always be updating the same save file rather than choosing other slots to store data for the same play-through and creating additional files to deal with. I realize the biggest downfall of this design is that once it saves your data, you can't load prior data. Thoughts?

Appreciate any feedback! Thanks,
IndieDev717
 

[LStro]

So like the same way it works in Zelda games?

[IndieDev717]

Yep very similar to that. I have 5 slots and let's say you start a new game and choose slot 1, that creates a file and stores it in a specific directory. Anytime you save the game the same file gets updated. Anytime you load slot 1, it will grab data from that file.

[LStro]

That sort of save structure is good, but it really depends on the game. For a linearly (ish) progressing game such as Zelda, it works great. But there are other game types where saving a single slot might put the player in a really bad spot.
For instance, imaging playing Half-life and having a single save slot, you could mess up big time and need to restart from scratch if you saved with too low health or ammo to continue in that game save.

So, it really depends on the game. What sort of gameplay/progression do you use?

[IndieDev717]

You're definitely right and I liked the example you provided. This game is going to have a fairly linear story but will also allow players to explore. The whole point of exploring is to obtain items to help them survive, but also to gather more details surrounding the story that they wouldn't get if they didn't explore (like certain pieces to a puzzle).

Actually, the way it's setup I could still allow them to save progress in another slot (which would create a new file). I just haven't gotten that far yet. I'm thinking for the sake of possibly screwing up big time and then saving...it would be better to let them decide which slot to save at that point, and just override the current file that holds the slot they selected, if it wasn't empty beforehand.

Something else I was curious about that I should have put in the original post was whether or not to let them save no matter where they are or to have specific locations in the world where they have to go to save. The reason for going down the route of specific locations would be because of how dynamic the environment is and everything that will be going on around them. As a gamer, do you prefer one over the other?

[ThemsAllTook]

There are a lot of advantages to restricting save locations to specified places in the world. You get to build tension in a way that's not possible with the ability to save any time, and unwinnable saves are less of an issue. The big disadvantage is that it doesn't allow the player to put down the game without losing progress if they suddenly need to go somewhere or can only allocate a little bit of time at once to play. This is particularly important to people with children.

Skyrim's save system allowed saving at any time, and it seems to keep full history of every save you've ever made. This is great for backtracking, but becomes unmanageable if you're playing multiple characters at once, since there are no slots; all saves for all characters are kept in one big list. Autosaves are frequent enough to clutter up the list, but not frequent enough to avoid major loss of progress if you die too long after one has happened.

The ideal system in my mind would work something like this:

• Starting a new game creates a save slot. (Why have only 5? Is there a reason to limit it?)
• Save points placed in the world create a new save in that slot. By default, the latest save is loaded from the slot, but you can drill down to full save history if you want to go back in time.
• At any time, you can suspend the game, create an instant save, and quit. This isn't a save slot entry; it stops existing once the game is resumed, and reloading will put you back at the last real save.
• Periodically, the game creates an instant save automatically, so that progress isn't completely lost in case of a crash/power outage/other circumstance that doesn't allow the game to exit cleanly.

This depends on the nature of the game, of course. This pattern only fits certain genres.

[oahda]

Not sure yet if my game is going to have autosave or manual, but it's not going to be through elements in the game world, because I feel that's a terrible breaking of immersion and doesn't help a believable story in my case. Might be fine for you, but that's worth considering for each individual game, I think.

Either way, saving is essentially going to be like in Ocarina of Time, I've figured – one can save any time, or it auto-saves with every area or milestone, but the game doesn't load from the exact spot where the saving was done, because this, as was mentioned, might screw things up if the game has gone buggy and gotten the player stuck in a wall or something.

Instead, each area will have a hard-coded spot at which the player will be put upon reloading, generally not too far from where they saved (I'm thinking of even subdividing each level into save zones, so that in a tower that's just one open level, every room will have its own save spot and so on, so that one doesn't have to start over from the bottom after getting all the way to the top and then saving).

My biggest problem is automatic versus manual saving – as has been mentioned, one might want to consciously save in order to have a specific spot and state to reload from, and that might be bad to take away from the player. Maybe I can mix it up, where there's a main slot that autosaves, while manual saves can be stored in extra slots? Well, essentially copying the file, which is also possible in OoT, actually. I think that might work for me, at least.

[Sik]

(Why have only 5? Is there a reason to limit it?)

Probably tradition. When save support was first starting to appear in games the space was really limited, just a few KB (if even that), so games limited the slot count in order to ensure things could fit. These days it's not a problem so the only excuse I can find is making it harder to screw up (it's easier to program a hardcoded limit than one that can change at any moment).

Periodically, the game creates an instant save automatically, so that progress isn't completely lost in case of a crash/power outage/other circumstance that doesn't allow the game to exit cleanly.

Shouldn't saving be immediate, without having to wait for the game to exit?

There's still the potential of the problem coming up during saving though, which would render the data unusable. One needs to make sure that it's possible to recover a working save when this happens (even if that means rolling back to the previous save). Same deal with the settings, or anything that can be stored. That's beyond the discussion here though (this applies to any save system).

[bdsowers]

My biggest problem is automatic versus manual saving – as has been mentioned, one might want to consciously save in order to have a specific spot and state to reload from, and that might be bad to take away from the player. Maybe I can mix it up, where there's a main slot that autosaves, while manual saves can be stored in extra slots? Well, essentially copying the file, which is also possible in OoT, actually. I think that might work for me, at least.

Some Rogue-Likes get around this problem by allowing the player to save any time, but once they load the game it destroys that save file. This allows arbitrary saving but prevents exploits. I never much cared for that approach, but it's an option.

Your suggested approach of having the main slot auto-save but still allowing the player to utilize other slots is pretty common. Different games handle this in a lot of different ways (ie: once you choose a new slot, that slot becomes the 'main' slot).

(Why have only 5? Is there a reason to limit it?)

Probably tradition. When save support was first starting to appear in games the space was really limited, just a few KB (if even that), so games limited the slot count in order to ensure things could fit. These days it's not a problem so the only excuse I can find is making it harder to screw up (it's easier to program a hardcoded limit than one that can change at any moment).

There's also a usability consideration here. Presenting the player with a fixed number of save slots may be easier for them to 'grok' then allowing them to save in a million spots, but then they have to go hunting for the right save sometimes.

[Christian Knudsen]

If this is a PC game, you should be really careful and have a very good reason for limiting when and where players can save. Most PC players don't like to be restricted like that and feel it's a console thing (which it is). Shadowrun Returns, for example, received a lot of flack for limiting saving -- which they then eventually changed.

[IndieDev717]

This will be a PC game first, and then hopefully ported to consoles down the road if it is successful. I can see how people would be frustrated, on PC, with a limited number of slots. 5 is what I currently have but can easily increase that to a higher number. The reason why I was thinking of a fixed amount is so that it is easier to maintain. Dynamic lists can sometimes get a little buggy, especially if those lists are instantiating UI components like buttons and or scrollable lists. The way this game will progress I think it wouldn't make sense to constantly be updating a list of saved files like elder scrolls and fallout do.

From all the feedback I have been receiving I am learning towards incorporating an autosave feature. I could have it autosave every set amount of minutes and/or when the complete milestones. Milestones will definitely trigger and autosave but I thought doing this every set amount of minutes would give people peace of mind in case of a crash or outage of some sort. In my own personal experiences, I have been very grateful for autosaves that are frequent as I have had times where the game would freeze or crash, but I only lost several minutes and gameplay instead of hours. Along with the autosave feature I'm thinking about bumping up the number of slots by a significant margin just so it's easy to manage in the code, but also gives players the option to choose a different slot so they can backtrack if they'd like. Is 15 or 20 slots reasonable? I know when I play skyrim and fallout 3 I'm never thinking about loading a previous save from months ago lol.

[Sik]

I think that the problem with autosaving every set amount of time is that it can decide to autosave at the worst moment (forcing you to go through the save list instead of just quickloading, assuming the saves before that still exist). It's probably more reliable to only autosave at milestones and then make said milestones come up more often to compensate (eventually the end result will be similar).

[riksteri]

If this is a PC game, you should be really careful and have a very good reason for limiting when and where players can save. Most PC players don't like to be restricted like that and feel it's a console thing (which it is). Shadowrun Returns, for example, received a lot of flack for limiting saving -- which they then eventually changed.

This seems like a perception thing - there's no rational reason why console games should not allow saving any time as well. (Edit: I'm assuming technical limitations such as disk space and such do not prevent this these days. This assumption might be wrong.)

I think that the problem with autosaving every set amount of time is that it can decide to autosave at the worst moment (forcing you to go through the save list instead of just quickloading, assuming the saves before that still exist).

That does not sound like a problem that would occur frequently. The player would only have to do the manual save selection once - to ensure that, you can make it so that automatic loading loads either the most recently saved or loaded save, whichever is more recent. I'd say the benefits greatly outweight the problem of some players occasionally having to select the second most recent save.

Along with the autosave feature I'm thinking about bumping up the number of slots by a significant margin just so it's easy to manage in the code, but also gives players the option to choose a different slot so they can backtrack if they'd like. Is 15 or 20 slots reasonable? I know when I play skyrim and fallout 3 I'm never thinking about loading a previous save from months ago lol.

I'd say "15 or 20 slots" is perfectly reasonably for the vast majority of players, but I think it still is an unnecessary limit. For instance, I know individual cases where a player of an open world game has stored a save file just before talking to an NPC that gives a new mission - for each and every mission of the game. This way, when they want to replay a specific mission, they have a save file to load. I'd expect this to be an out lier case, but I'm a big advocate of not limiting what the player can do with the game when not absolutely necessary.

[IndieDev717]

Well said. The only reason for limiting the amount of saves to a set number was strictly for coding purposes. I'm a huge fan of lists and using loops to grab data from those lists. I also want the game to be as bug free as it can be and having a set number of slots makes that a little easier to accomplish. With that being said, I have started to restructure the design to work with a list that can keep on growing as auto/manual saves occur. The save object includes both the file name as well as the time the save occurred so that I can include a "continue" button at the main menu which will look for the most recent save file and continue from there or the player can choose "load" which will display a list of all files started with the most recent at the top. I really do appreciate all of the feedback here.

Now I know this might be getting a little deeper into things from the original post, but what is your preferred method for deleting files? By this I mean from a UI perspective... Single, mass delete, etc.?

[oahda]

Scrollbar is your friend.

[Sik]

I think that the problem with autosaving every set amount of time is that it can decide to autosave at the worst moment (forcing you to go through the save list instead of just quickloading, assuming the saves before that still exist).

That does not sound like a problem that would occur frequently. The player would only have to do the manual save selection once - to ensure that, you can make it so that automatic loading loads either the most recently saved or loaded save, whichever is more recent. I'd say the benefits greatly outweight the problem of some players occasionally having to select the second most recent save.

I said saving every set amount of time (i.e. regardless of whatever is going on currently), that doesn't mean other forms of autosaving cause that problem. Autosaving at reasonably safe points (e.g. when reaching a location or certain events happen) doesn't have that problem, for instance, there the only problem is how often you put those.