Anchored to the world: Saving the game – Part 2

Posted on by admin

This is the second part of a series that details my design thought process of a save system and describes the practical considerations involved in how this specific thing will work within a game. It’s probably best to read the first part over here.

So after exploring what the goals of this save system are, we concluded that:

  • Saving is a physical act in the game world and uses a game object
  • The game object can be stored in the players inventory
  • Players can drop the object to save the game and collect the object after saving

Additional questions were also generated during this exploratory phase of the design process:

  1. What variables, elements and states within the game need to be saved?
  2. What player feedback is needed?
  3. How will the player deploy the game object in the world?
  4. Where will the game object appear in the world?
  5. How will the player collect the game object?
  6. What visually happens in the world when the player deploys the game object?
  7. What visually happens in the world when the player collects the game object?
  8. How does the player load a save game?

Let’s start fleshing out the design further by stepping through and answering what variables, elements and states within the game need to be saved.

Variables, elements and states

We should probably begin by saving information pertinent to the player, such as:

  • The player’s location
  • The players current health and cohesion levels (Cohesion refers to the games survival mechanic)
  • The players inventory contents

The next thing to consider are level specific aspects:

  • Character animation states
  • Trigger states
  • AI states
  • Game object visibility
  • Local variables specific to this level
  • Action lists / Cutscenes
  • Audio
  • Menu states

We also need to include global variables which are not included in the above lists.

We now have a bunch of things we need to save. As the player deploys the save game object in the world, all of the above should be saved to a file that the game can access, for example save_game_0. If it’s the first time the game is being saved, a new save file should be created so we can actually save our data. If there is an existing save however, the save system should overwrite the previous save. It should be noted here that for The Corridor: On Behalf Of the Dead, we used the excellent Adventure Creator framework which is a plugin for the Unity game engine. Adventure creator provides a robust save system which takes care of much of the above list. However, there are always custom aspects of a game that need to be included in the save system, in our case, the players cohesion levels (to be discussed in a following post).

We can see how this will work here:

So, we now have a conceptual idea of which game elements the save system should save within the game’s save file.

I’ll leave this here and continue the process in the next post.

Thanks for reading.

Leave a Reply