As usual the save/load routine has involved more work than I thought. I've reduced it to the hardest part which is saving the level map. The old map with individual 'byte' maps for each layer was easy to save, because the byte map had a built in RLE (run-length encoding) packing. The estimation for 50 levels each average size of 100x100 tiles is 3,5Mb of space unpacked. How much is it compared to modern save files I don't know (I don't play PC games (other than roguelikes)), but it would be much less when compressed.
As expected the compression routine must be custom created to be compatible for both the save file format and map format which contains four mandatory variables to be saved: the tile itself (terrain), fov value (known tiles), mask and room id. These four variables can't be reproduced from any other data. The mask value is mostly used in the level's creation process, but it might just be used during the game in pathfinding situations.
RLE in theory is easy to implement, but the custom data structure and save format makes it somewhat more complicated. RLE also works quite nicely with typical dungeon levels of rooms and other areas with mostly 'empty' space (walls) between them.
Wednesday, 20 May 2015
Tuesday, 12 May 2015
Double dragon
I've divided todo items to RPG and "engine" lists. The list for engine items is interestingly short and I'm working on it. Currently I'm writing a new save and load game which is bit of a complex thing, yet easy compared to the beast of RPG system.
When you add or remove something from a class that has to be saved you should add it to save/load routines. Guess who didn't do that? Well I think it's good to go through everything anyway to make sure absolutely everything is saved. Of course there are still some difficult parts, in particular the new level map class that replaced the old implementation.
A minor refactoring is going on with the level map vs. level, because I noticed the Level class has a double data of width and height which also the Level_Map has. Now.. I know, this doesn't sound like a big issue, but for me it is. I have always tried to remove double data as soon as I notice it exists. It's just something I hate even often it doesn't make the source code that much worse. Still it's always risky if there are doubles of some data, because you need to synchronize it.
When I get save/load ready it's an important step, because I can then start to test it in a way where the current situation is always loaded when I'm running the game. In the debug mode it's impossible to die so it makes long term testing of save/load possible.
When you add or remove something from a class that has to be saved you should add it to save/load routines. Guess who didn't do that? Well I think it's good to go through everything anyway to make sure absolutely everything is saved. Of course there are still some difficult parts, in particular the new level map class that replaced the old implementation.
A minor refactoring is going on with the level map vs. level, because I noticed the Level class has a double data of width and height which also the Level_Map has. Now.. I know, this doesn't sound like a big issue, but for me it is. I have always tried to remove double data as soon as I notice it exists. It's just something I hate even often it doesn't make the source code that much worse. Still it's always risky if there are doubles of some data, because you need to synchronize it.
When I get save/load ready it's an important step, because I can then start to test it in a way where the current situation is always loaded when I'm running the game. In the debug mode it's impossible to die so it makes long term testing of save/load possible.
Subscribe to:
Posts (Atom)