• 9
• 16
• 15
• 12
• 9

# Instance duplication during saving

This topic is 805 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hello World,

I'm making a rougelike and like all rougelikes, it has some enemies, some levels and a dungeon. Development is going well, but I'm keep having trouble keeping track of instances when saving the game. When I reload the game, the instances often get copied and thus references are broken.

I'm using Java and it's built in Serialization, so there's generally no problem since it supports keeping references. The trouble is that I want to save each level out to a different file so I don't need to load every Level at once. The levels have some references that need to be shared between the levels (see below for examples). Now when I write a Level out to a file, it saves all the shared objects data into that Level file, thus, when I reload the file, it constructs it own set of all the shared data. Which means changes from one level are not reflected in the changes to another level.

How do people here solve the problem of shared data duplication across file boundaries? Maybe I've structured the saving progress wrongly? While I'm working on the core of the game, its obvious when references are copied, but I can see that in future subtle bugs could easilly be introduced.

You can stop reading here, but here's some examples of things that are shared between levels:

• The Dungeon (which basically the global game state  - how many Potions have spawned, what rooms still need generating, etc.),
• The level themes (defines how tiles look and can dynamically change based on what the hero does so the same reference must be kept)
• A reference to the player (an extra complication here that thwarts some solutions is that the player holds a reference back to the level)

##### Share on other sites

The easiest solution would be to serialize entities first to a separate file, and then instead you just save an entity ID number of the likes instead of the actual object.

##### Share on other sites

You may not be able to use Java's built-in Serialization interfaces to save everything (I honestly don't know; I don't use Java) as it may not give you the option to save object handles instead of the object values themselves. A more capable third-party (or custom) serialization library may be required.

##### Share on other sites

What you probably need to do is have one file for each level, and then one file for shared objects. I am not sure if I understand what you are saying, but as I understand it, you are storing a copy of shared objects in every level file. Like you say, this can lead to many bugs since older versions of shared objects can exist, and some objects could have references to them. Your process for loading a game would look something like this in psuedocode:

load StaticObjects;
level=staticObjects.currentLevel;
StaticObjects.player.location=level;


The players reference to the dungeon needs to be nullified before serializing, so the serialized won't accidentally serialize the dungeon with the level. The value is likely to change anyway after loading a new level. For switching level, it would work like this:

StaticObjects.player.location=null;
save level;
StaticObjects.player.location=newLevel;


the process for saving the entire game is very similar, just make sure you reload your files in the right order.

I hope this helps.

##### Share on other sites
@theagentd

Yeah, this sounds like a good solution for some many components. I'll try it out.

@Mousetail
You've understod me perfectly. The trouble with the solution is that it seems so hacky. It feels too easy to accidentally save a reference that is shared.

Ultimently, I had really hoped that there was some way so that it was (nearly) impossible to stuff up the saving process. Even if it requires a full redesign of the code structure, I'd be interested to hear it.