i believe one next step is to identify the metadata we will be working with in creating a stub builder-someday-automated character sheet. the main goal of identifying the metadata is to break down the various aspects of the game-system-of-choice, in this case the 3.x SRD, into the numeric values and concepts necessary for programming.
please feel free to correct and add to my thoughts and suggestions.
for purposes of design, i shall refer to each aspect of a character sheet as an "asset".
assets consist of:
Assets of a Character- race (sub-races, type, subtype, special ability)
- template (inherited and acquired)
- class (prestige, racial sub levels, special ability)
- alt class feature
- feat
- skill (skill tricks)
- stat (stat mods)
- equipment (weapons, armor, items)
- money
- languages
- spell
- power
- optional rules
- derived characteristics
now to examine metadata in some small detail.
taking the asset of "feat" as an example, a casual perusal yields the following "obvious metadata":
MetaData for Feats- feat name
- feat type
- short desc
- prereq
- benefit
- normal
- special
here we run into our first problem. some feats have more than one prereq. i believe the best way to handle this is to put the data into database tables. rather than use prereq for the metadata type, i suggest that we use prereq0 through prereq 9. if there are any feats with more than 10 prereqs, then instead we would have to use prereq00 through prereq11, or whatever. Also, the prereq will reference the name of another assest on the sheet, and its' value.
come to think of it, in the case of feats with more than one type, we can do the same thing with type as well.
now we run into our second problem. this is not all the metadata actually contained in any given feat. there is a set of "non-obvious metadata" which also needs to be extracted, specifically from the benefit and special sections. given in the descriptions of the benefits and special section are special rules which describe how the feat works, and what it does.
for example, weapon focus adds plus one to the attack value of the character if they use a particular weapon. this metadata can be referred to as "affects0(name)" and "affects0(value)". in the case of weapon focus, it would be "affects0(weaponName:toHit)" and "affects0(1)" again, if there is a feat that affects more than ten things, then the naming scheme would have to be changed to use double digits.
additionally, the source of the feat should be contained within the metadata, perhaps with page number for convenience, especially since many feats have more than one version published across different sources. errata will necessitate the need to decide whether to automatically include all errata, or to list the errata changes as a separate feat. This becomes potentially relevant to changes between 3.0 and 3.5, which may also need a metadata tag.
so the final metadata for a feat would look something like this:
MetaData for Feats- feat name
- feat type
- short desc
- prereq0(name)
- prereq0(value)
- prereq1(name)
- prereq1(value)
- prereq2(name)
- prereq2(value)
- benefit
- normal
- special
- affects0(name:partname)
- affects0(value)
- affects1(name:partname)
- affects1(value)
- sourceName
- sourcePage
- editionVersion
the exact number of prereqs and 'affects' metadata would be different for each feat. for purposes of testing this idea programatically, we would only need the featName, featType (both for sorting checks), the prereq metadata and the affects metadata.
thoughts, comments, questions?
ps: I can set up a site for hosting dev work, and other helpful additions.
