Bones storage method
For christ's sake, someone needs to take a look at this. It seems terribly inefficient. Do me a favor. Go to your IVAN directory, right click the bones folder, and check the properties. How much data is stored in there? A megabyte? Two? Ten? Try fourty. I have 25 bones files, with sizes ranging from 800 KB to nearly two megs, for a total of 38 MB. Now, 38 MB really isn't a whole lot, except for the fact that the REST of the game is only about 8 and a half. The source doesn't compile on my machine, or I'd try to tinker with it myself. (Aside from that fact I also just archived it onto a disc, so I don't have it on my drive to tinker with anyways.)

(Note -- in this post I use the word "byte" a lot. You can replace it with whatever data size you like, it's all good.) Okay, you're definately right here. The amount of room needed to store the ground and wall tiles of an entire dungeon the worst way possible should be about 32 kilobytes, but each bone file is closer to 1.5 megabytes. I can't imagine the items and monsters of the dungeon taking up the rest of that, even uncompressed. I can't find the bones saving code for the life of me, though, so I'll assume nothing horribly stupid is going on and we're just dealing with a lot of uncompressed data. Let's consider what there is to save when a character dies... -The map, including both the undertiles and overtiles. -The character who died -Whatever was wandering around the place, mostly monsters, knowing IVAN -Items on the ground -Items in things hands -Blood and other liquid effects -Gas clouds and spiderwebs and such Now, right off the bat, I'd like to say that if we're not already tossing out the blood/liquids/clouds/spiderwebs/whatever, we really aught to be. There's no reason to save something when, by all reasonable expectations, that something should be gone by the time someone finds the bones. The maps in IVAN could be compressed very well with RLE (Run Length Encoding -- write a control byte whenever you have repeated data, then write a length byte and it'll just write whatever the last real data byte you had was that many times). However, I just came up with something a little off the wall that'd rock RLE's socks off. Excuse me if I've mentioned it before, as the idea seems to be working too well in my head for this to be the first time I've thought of it. Skip the next paragraph if you don't want to read lots of technical details. Alright, the idea is 2D RLE. Whe have two control byte values (FF and FE or something), one for normal RLE, and one for 2D RLE. When we hit a 2D RLE control byte, the next two bytes are used to specify a width and height. The loader does the normal RLE thing with the width, then skips ahead to the next rows and drops the same row of data into the next many rows, and then pops back up on the end of the first row it wrote and goes back to normal. The normal RLE works exactly as RLE always does, with one exception -- when the RLE would tell it to go over an area that we already wrote data for, it would just skip writing on that area. The normal data, of course, would also skip over these areas. It sounds crazy, I know, but it would compress the typical IVAN dungeon's ground tiles down to about 150 bytes, instead of 4096 uncompressed (the wall tiles would experience significantly lesser performance, but that's not saying much). I'm willing to code it if someone else helps me find the save routine. Items are a little more complicated, as they have a few traits that can vary. However, I think the vast majority of the items are exactly the same except for their positions. We could sort the items by type prior to saving, then compress out everything but their positions using a normal RLE. Though I don't know if this would be worth it -- you'd be saving probably four bytes (one of those is for liquid on the item, which we probably should be ignoring in the first place) per item and losing six per type of item. Also, either way, we don't need to store whether an item is in someone's hands, because we can just list the items in hands and the items on the ground in two different places for practically free. The same approach as for items could be used on monsters and such with more luck. Presumably, every hedgehog is the same except for where it is and how much it's been killed, but IVAN probably stores every piddling detail about them ranging from arm strength to charisma to sexual history. Anyone have more luck than I at figuring out how IVAN's doing it now? I think I can pull off the code, depending on how the game does a bunch of stuff.

AFAIK IVAN remembers names and bitmaps for all tiles. I guess this is a simple although unefficient solution in case of save games, but could be stripped from bones without anyone noticing.