2
\$\begingroup\$

I'm trying to develop a 2D game like Zelda. The game is divided in screens with exits linking each other. I store each screen data (including objects and NPC positions) on a separate file, and when the main character steps on the exit, the next screen data is parsed and the screen is loaded. Everything works just fine so far.

I'm now trying to implement the game progression system, along with the save system. I've read a lot about some ideas on how to do that, finite state machine design, what to store on save files, serialization and everything, but I'm kind stuck here.

Let's say that action X triggers event Y, moving some NPC from point A to point B. The player then saves and quits the game. When the game is loaded, it must position that NPC on point B. To achieve that, should I rewrite the files that contains screen data so when the screen is parsed it draws the NPC on its new place? Or should I store its new position on a separate file, and apply the changes on the screen after its loaded? Or maybe there's a better and less ugly way.

Any suggestions are welcome.

\$\endgroup\$
  • 1
    \$\begingroup\$ For a Zelda-like would you not reset the stage when the player reloads. You never continue in your same position in the dungeon - just at the beginning. \$\endgroup\$ – Jesse Dorsey Aug 4 '14 at 23:49
  • 3
    \$\begingroup\$ I strongly suggest that you keep your static map data and your dynamic game progress separate. Should be much cleaner and more manageable that way. \$\endgroup\$ – Raginmari Aug 5 '14 at 7:18
  • \$\begingroup\$ I'm confused what exactly the question is. Are you asking how to create a save system? \$\endgroup\$ – Anko Aug 5 '14 at 10:13
  • \$\begingroup\$ @Anko not exactly. In my game, when player enters a screen, the screen data containing everything needed to render the screen properly is parsed from a file and the screen is shown with everything in place. This file however contains only the initial state for the screen (like when you start a new game). What I'm looking for is a good way to apply the changes to the screen after the player makes progress in game. For example: draw the screen in the initial state and then apply the changes stored in save file or something like that. \$\endgroup\$ – Tinadm Aug 5 '14 at 11:45
3
\$\begingroup\$

A common solution for this is to have variables you save together with the players state and objects which have a conditional state depending on these variables.

Example:

  1. When the player flips the switch on screen 42, you set the persistent variable "switch_42_state" to "flipped".
  2. On screen 76, you have a conditional door tile. When "switch_42_state" is "flipped", it is loaded as an open door, otherwise it is loaded as a closed door.

Similarily, you can have NPCs which only spawn when certain variables are set to specific values or which have different dialog depending on the variables.

Implementation detail: It is usually advisable to not use "real" programming language variables for this. It is usually better to store the variables and their states in a key/value data structure (binary tree, hash map, dictionary, associative array or whatever is available in your programming language), because it allows you to add new variables just by mentioning them on a screen file, makes saving and loading more straight-forward and avoids name collisions with internal variables.

| improve this answer | |
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.