[C#] Game Saving Problems, Files are too large
Hello fellow GameDevs, I have been having a pretty big problem recently. I am trying to find the best way to save data for my map files.
Overview
Problem
*Um.... How about using multiple files? One file per map.
*If there's a lot of repetition on the maps you could compress the map (for example with zlib)
*What do you mean by "it only generates the map"? Can't you save only the necessary data and rebuild the map?
*If there's a lot of repetition on the maps you could compress the map (for example with zlib)
*What do you mean by "it only generates the map"? Can't you save only the necessary data and rebuild the map?
*Um.... How about using multiple files? One file per map.
That would not help with anything, the total file size would be exactly the same.
*If there's a lot of repetition on the maps you could compress the map (for example with zlib)
I can try that thanks, but it takes time to compress and decompress. I don't want them to be waiting for 3 minutes just to save or load their game.
*What do you mean by "it only generates the map"? Can't you save only the necessary data and rebuild the map?
It only generates the maps that they walk into. I can try and think of a way to save only necessary data.
You should also save the level separately from the save game. Each level is one file, and the save file only saves the stuff that populates the levels and that can change between different saves.
As far as I know, Zlib is quite fast.
For the "generating" I thought you mean procedural generation, or something like that.
As far as I know, Zlib is quite fast.
For the "generating" I thought you mean procedural generation, or something like that.
From the sounds of it, you're serializing the maps as entire objects. Instead, use a StreamWriter to save only the data as integers, floats, bytes, etc.. Serializing an entire object results in far larger files than simply serializing the objects' data.
You will have to handle objects stored in more than one location yourself. The easiest solution is to store one copy of each object somewhere and then simply index that data.
You will have to handle objects stored in more than one location yourself. The easiest solution is to store one copy of each object somewhere and then simply index that data.
If your areas are randomly generated... Depending on how you generate them - couldn't you just store the initial seed and any persistent changes as a result of game play?
I think you need to provide some more information in order to get meaningful replies.
What kind of objects are you saving? What exactly does a single "block" consist of? How are maps being stored in memory? How exactly are you serializing?
What kind of objects are you saving? What exactly does a single "block" consist of? How are maps being stored in memory? How exactly are you serializing?
I think I might know what the problem is. does each block store the texture file because if so your saving the texture for each block thus the large file size. Try making a block data class which has a path to the texture. And the make a constructor for the block class which can input a data class.
serialized classes are huge. avoid them when dealing with anything that has fields other than raw types.
I haven't read all the posts but you should try to create your own save/load algorithm instead of serialization. It may take a while to develop depending on how many different groups/fields you have but it should save space, especially if the classes your are serializing have textures in them. For example for a tile based system you could generate something like this and save it to a file.
"t|x,y|s't|x,y|s't|x,y|s't|x,y|s"
"" = end/start of save/load
t = type of tile
x = x location
y = y location
s = solid or not
' = splitter for next set of data
etc... etc...
If the tile classes have textures saved to them, as Thekill473 says, then there is your real problem.
"t|x,y|s't|x,y|s't|x,y|s't|x,y|s"
"" = end/start of save/load
t = type of tile
x = x location
y = y location
s = solid or not
' = splitter for next set of data
etc... etc...
If the tile classes have textures saved to them, as Thekill473 says, then there is your real problem.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement