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 _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel