[Adonthell-devel] Charedit File Format

[Andrew Phillips]

Y'all,

Rather than perform thread necromancy, I'm starting a new thread. I'm
both asking for suggestions and trying to work things out for myself.
I don't think I've reached any firm conclusions just yet.

Last time, we reached two conclusions (possibly three)
1) No specific (file|record) format guidelines exist
2) Form follows function
3) Eventually, whatever format we decide upon might need to be
workable within the context of a single, monolithic character file.

The record format I've been using as I pull charedit together has
changed a few times. Each format has had its merits, I think, but at
some point, they became incompatible.

The simplest useful format seems to be

Name:Race:$Label:Strength:$Label:Hardness:$Label:Agility:$Label:Willpower

However, this design leaves out alignment, level, and all property
values. However, as a basic template for things that will be built and
leveled when they are instantiated (Wolf359, for example) it might
work. The $Label's are literal labels, signaling the next attribute in
the list. I put them in as a guide, both because C++ core string
handling is a bit primitive and because a long series of integers and
floats delimited only by colons needs something to make it more human
readable. Evolutions of this design contain alignment, level, and AP
available, all found in the character "header" and recorded values for
each property. Records in that format get rather long.

Of course, this leaves out character ID, unless name and character ID
are one and the same. There seem to be two flaws in this design. The
first is that because every field after Name and Race is subject to
change, any changes would overwrite the previous values. The character
would contain no history of itself and provide no chance of restoring
to a previous state should data become corrupted. The second flaw is
that properties are stored as a single value. A given property value
could likely be factored to derive its multiplier and modifier, but
this seems either non-trivial or less trivial than I would like. Also,
it breaks the database normalization rule about storing values that
can be calculated from other fields.

The other basic format contains no labels and (at least initially)
recorded each new level and its attribute values on a separate line.
Name and Race would still be together at the top of the (file|record),
while alignment, AP, level, and attributes would recorded for each
level that is saved to a file. Alignment and AP are currently not
included in each level's record, but adding them would be trivial and
probably a very good idea.

Name:Race:
Level0:(Align:AP:)STR:HAR:AGI:WIL
Level1:(Align:AP:)STR:HAR:AGI:WIL
LevelN:(Align:AP:)STR:HAR:AGI:WIL

This design, originally, seemed like a very good idea to me, since it
would allow for longitudinal record-keeping, and would help manage
record size, but I've discovered in the process of writing code to try
to read these files that the newline character seems to break any
attempt to tokenize the record. So I've had to strip out the newlines.
The tokenization works reasonably well without them.

The flaw in this record format is that it would be very, and
arbitrarily, long, particularly if I roll in the property modifier and
multiplier stuff from the other basic design. Also, it contains no
labels, so navigating through the record would be non-intuitive
without good documentation of the format. Labels would certainly help
make everything more navigable, particularly where finding information
on previous levels is concerned.

Name:Race:Level0:(Align:AP:)STR:HAR:AGI:WIL:Level1:(Align:AP:)STR:HAR:AGI:WIL:LevelN:(Align:AP:)STR:HAR:AGI:WIL

A high-level character recorded this way could have a very long record
indeed, without even taking property values into account.

Finally, it seems to me that whatever record format is chosen, it
should ideally be easily convertible to well-formed XML, since we are
already using XML for character storage in worldtest.

Andrew