On 8/15/07, Kai Sterker <[EMAIL PROTECTED]> wrote: > Most classes of the Adonthell engine that can be serialized provide > the methods put_state(base::flat &out) and get_state(base::flat &in). > That will get them into a common format that can then be stored either > in human readable XML or gz compressed binary format. Optionally, some > classes provide put_state(std::string filename) and > get_state(std::string filename) to save a single class instance to a > single file.
I guess I better design toward those methods, even if I can't compile or use them for myself just now. > The charedit prototype for 0.3 used the first approach. It saved each > character into individual files and a second progam, mergechars, read > all those and created the character.data file required by the engine. > So this is perfectly okay, and under the current circumstances I > believe it would be a good idea to.do it that way. > > Actually, the final conversion could be performed by a little python > script, which would make all those string operations much simpler. Oooh. Not doing the string processing in C++. I like that idea quite a lot. > The only real benefit of the second method would be that one could > reuse parts of the engine for the editor (not so tricky as with 0.3, > with the nice shared libs we now have for the different modules), it > could simplify the editor code somewhat. It's what I'll try to do with > questedit, once I get around to it ... I'd also like to see some of what I'm doing in charedit re-used where appropriate, but I suppose it would make more sense to the leveling methods than file parsing or such like. > (Think for example about equipment or inventory required for NPCs, what spells > and feats they know, etc). I had wondered how item-related things might work with the ridiculously long chain of values design. In sum, they probably wouldn't, not without some fairly painful kludging and contortion. > Not sure if it really makes sense to store any kind of character > history. During game creation, character data can be version > controlled in CVS. During game play, a new character data file will be > written for each saved game. Reverting would be as simple as loading > an older save. I suppose I keep forgetting that we have version control available. > If we really want a clean format that can be expanded fairly easily in > the future, maybe something like an .ini file would work: [..snip..] > It's a bit cumbersome to parse line by line, but by using the right > data structures it might not be too bad. (i.e. keep all attributes, > skills, etc. in a hashtable, so you can access the corresponding > object by the identifier left of "=" and let it parse whatever is on > the right side.) You'll probably have to handle the [General] section > manually, but for the other sections you'll know what type of property > they contain and only need to iterate over each line. Adding entries > to a section later on (or completely new sections like [Equipment] or > [Spells]) will not break the whole format. > > Not sure if that is really the best solution for the problem at hand, > but at least it is simple, expandable, practically self-documenting > and still fairly easy to implement. It may not be as efficient as a > completely custom file format (in respect to both file size and > parsing), but I figured some time ago that being more explicit helps > making things (be it code or file formats) easier to understand. Also, an ini file is already half-way to being in XML. There's a line in the Tao of Programming about the dangers of premature optimization. Seeing your proposed file format compared to the several I've played with, I think I may have fallen into said trap. Or I might still be shaking off some brain damage left over from having to learn COBOL in college. I'll work on implementing your design, starting with how hash tables work in C++. Thanks. Andrew _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel
