Re: [Adonthell-devel] Charedit File Format

[Andrew Phillips]

On 8/15/07, Kai Sterker <address@hidden> 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