ID:151356
 
So, this morning OasisCircle and I were talking about quick ways to save maps. I came up with the idea that, under certain circumstances where the atoms always have the same values (ie, a lever is a lever, a trap is a trap, etc) one could handle saving of a large area simply by saving a character as an identifier for an atom, and reading and writing the map starting at 1,1,1 and going from there. Given that every object would be the same no matter what, one would have to save only the turf, and then an object or mob on that turf, meaning that rather than saving all of the variables, you only have a single character representing that tile.

For example, say you have 2 5x5 rooms. Possible turfs are a wall (0) and floor(1), and possible objects/mobs are none (0), lever (1), button (2), trap (3), goblin (4), and skeleton (5). The save file for the room would end up looking something like this:
00,00,00,00,00,00,10,11,10,00,00,10,14,10,00,00,10,10,10,00, 00,00,10,00,00}{00,00,10,00,00,10,10,10,00,10,15,10,00,00,10 ,10,10,00,00}
This would dictate a map where the first z level is loaded as a 5x5 room with walls surrounding the entire room, with a goblin in the center, a lever directly to the south of that, and an opening in the top center of the room. The second floor would have an opening in the bottom center, and a skeleton in the center.

If you have more than 9 possible atoms for a turf, the syntax for a tile could easily be changed. Where you have 10, You could have 1,0; turf,atom/movable; and the semi-colon would be your token to say that's one tile.

As far as saving instructions like where to warp to when you hit the tile of a wall, that could be handled either with pre-determined logic defined in the source code (ie going NORTH always adds 2 to your z value), or it could even be incorporated into the save file in one of two ways, as an x,y,z value, or as an identifying character, or string of characters.

For example, if you were to say that one tile is to send you to another tile at 15,15,3, the save for that turf could look something like: 10[15,15,3]. Using the other option for a unique identifier, you could go about it one of two ways: connect linking turfs (ie edges of rooms) with like identifiers: 10[a],...10[a] or you could break the identifier into its own set of values: 10[a,b],.... Where 10[b,a] is the turf|object ID and [b,a] is [location_id,destination], location_id being the identifying marker for the turfs location when warping tiles, and the destination being the location_id of the turf to be sent to.

When all is said and done, you could have a .txt file with all of the pertinent data required to load a map all provided for you in a text string. This allows for relatively small save file, as you don't need to save any icons and everything is a string, and would be helpful for sharing maps with others, and allowing them to be easily editable. If security is your thing, and you don't want people tampering with the saves, all you would need to do is encrypt them before writing, and decrypt before reading.

Hate to burst your bubble here, but have you ever considered opening a .dmm file in a text editor and looking at it? It's a pretty similar format.
In response to Jp
I can't say as I ever have, but the driving force behind this idea is that you only save what's absolutely necessary. This way you can save some time and resources by not having to save and load the big values like icon
In response to F0lak
The DMM format only saves variables if they differ from their initial value, if I recall correctly.

If you're looking to save space, I would suggest doing some RLE compression (run-length encoding). So AAAAAAAA would be saved as "8 of A" in some form. This can also potentially decrease loading speed, as you don't have to parse as many individual values. I'm not sure how it would affect saving speed, as there will be a trade-off in extra computation versus less text to write to the file.
In response to DarkCampainger
Better yet, just run
zip
over the output of your map-saving procedure. :P
In response to F0lak
In response to DarkCampainger
DarkCampainger wrote:
If you're looking to save space, I would suggest doing some RLE compression (run-length encoding). So AAAAAAAA would be saved as "8 of A" in some form. This can also potentially decrease loading speed, as you don't have to parse as many individual values. I'm not sure how it would affect saving speed, as there will be a trade-off in extra computation versus less text to write to the file.

So essentially, rather than save a large chunk of walls or empty turfs as 1,0;1,0;1,0;.. etc one could say, save 1,0:5 , the colon symbolizing a count, rather than an atom.