Let's look at what serialisation is required for Kharne:
- Storing '@' information, such as current location, stats, inventory and current effects that he/she(/it) is subject to. The player is represented by a specific instance of the TCreature Class.
- Storing the dungeon information. Ironically, I'm finding that this is the simplest to serialise, since the Dungeon class (cunningly called TDungeon) is basically just a multi-dimensional array of integers and booleans.
- Storing the monster information. Monsters (also instances of the TCreature class) are stored in a TObjectList, and there are soft references to them in the dungeon class (by soft, I mean absolute ID addressing, not pointer referencing).
- Storing the item information. Items are stored in a TObjectList, and there are soft references to them in the dungeon class. However, there is an added difficulty in that Items themselves are effectively compound objects (consisting of a base TItem and optionally one or more TItemEnchantment classes to represent magical properties of the item).
- Storing the high-score table and any bones files.
The old Kharne did all this successfully enough, but with one major drawback: the save files lacked any soft of compression and were stupidly big (20 Mb!). This was due to the crude method I previously used for handling saves files (basically, standard Pascal WriteLn/ReadLn). This bloat is unacceptable however in the new Kharne. Fortunately, if I switch to using a more modern implementation, i.e. streaming (which Delphi supports extremely well using both TFileStream and TMemoryStream) and also use one of the many compression libraries, the save files can be reduced to an acceptible size.
Now, there are plug-in Delphi libraries available that implement serialisation but I'm not convinced that using them would be any easier than using the above methodology. I will have to do further investigation on these.