Jump to content

  • Log In with Google      Sign In   
  • Create Account


[C#] Game Saving Problems, Files are too large


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
10 replies to this topic

#1 iXenocider   Members   -  Reputation: 120

Like
0Likes
Like

Posted 13 June 2012 - 12:49 PM

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
Let me give you a brief example of how it works. The world consists of an array (20 x 20) of maps, and in each map, there is an array (20 x 20) of blocks. For further information, I am using C#, and XNA.

Problem
I use serialization to save the whole world but when I do, the file size is at least 170 Mb. Maybe I am doing it wrong, but I do not know why it is such a large file. If you guys could help me by giving me a better way to save data that would be awesome!

Extra
I did make it so it only generates the maps that you go into, and the file size is relatively small. But once the player starts playing the game and starts exploring, the file size will eventually be way too large.

Thank you in advance.

Edited by iXenocider, 13 June 2012 - 12:56 PM.


Sponsor:

#2 szecs   Members   -  Reputation: 2099

Like
0Likes
Like

Posted 13 June 2012 - 01:23 PM

*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?

#3 iXenocider   Members   -  Reputation: 120

Like
0Likes
Like

Posted 13 June 2012 - 01:40 PM

*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.

#4 szecs   Members   -  Reputation: 2099

Like
0Likes
Like

Posted 13 June 2012 - 01:48 PM

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.

Edited by szecs, 13 June 2012 - 01:52 PM.


#5 Narf the Mouse   Members   -  Reputation: 318

Like
1Likes
Like

Posted 13 June 2012 - 02:09 PM

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.

#6 orizvi   Members   -  Reputation: 266

Like
2Likes
Like

Posted 13 June 2012 - 04:29 PM

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?

#7 laztrezort   Members   -  Reputation: 954

Like
1Likes
Like

Posted 13 June 2012 - 04:41 PM

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?

#8 Thekill473   Members   -  Reputation: 213

Like
0Likes
Like

Posted 14 June 2012 - 07:10 AM

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.

#9 Explodinator   Members   -  Reputation: 119

Like
0Likes
Like

Posted 14 June 2012 - 12:47 PM

serialized classes are huge. avoid them when dealing with anything that has fields other than raw types.

#10 Xanather   Members   -  Reputation: 703

Like
0Likes
Like

Posted 16 June 2012 - 09:31 PM

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.

#11 Cagnazzo   Members   -  Reputation: 140

Like
0Likes
Like

Posted 16 June 2012 - 10:47 PM


*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.


Combining those two will solve each others' problems, actually.

You break the massive world object down into subobjects, and compress those (or encode them in an efficient manner of your own devising, which is really the same thing.)

Your world is smaller, as everything is compressed. And since you don't have to decompress it all at once, you don't have huge lag spikes - only the portion being loaded has to be decompressed.

It has other benefits too - your RAM usage will be a lot lower, your disk reads will be a lot smaller (though, admittedly, they'll happen less predictably), and so on.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS