xmld20 - an XML Schema for d20 gaming systems - design, part 3

• The Monster id tag is missing.
  It's a small thing, but I should look into what the naming scheme is for the "srd:ABOLETH". For now, let's just copy it in. This is an XSLT change, not an XML change.
• Name should be called Kind
  While reading the Savage Species book, they refer to a monster's name as its Kind. In keeping with that terminology, I'll change that over, and modify the XSLT as needed.
• HitDice is hard-coded to monster levels
  This is another XSLT-only change, as we're already ready to copy with multiple level sources. We currently just read in the number of dice for the monster levels, but of course we anticipate class levels as well.

  There are two parts to the HitDice section: the list of hitdice from all levels, and the average hitpoints. The list of hitdice is easy to do, but the hitpoints are another matter. XSLT doesn't allow variables to be assigned more than once. This is a problem, because we have to do two things to calculate the average hitpoints -- loop through each of the classes, and then sum the average hitpoints from each. This isn't easy to do, because there are no true functions in XSL, nor can template call output be part of an expression.

  Luckily, XSL is very similar to functional programming, and that gives us a Turing-complete language, so it's definitely possible, just awkward.

• HitDice is hard-coded to the aboleth
  By fixing the previous problem, we got rid of the aboleth-specific code in that section, but there are still a few gaps in the templates used in that calculation. For now, we'll hard-code the types in, along with the hitdice of the basic classes. Eventually we should store these in external files and read them with the document() XSL function.
• Initiative only accounts for Dex
  Right now, we'll hard-code in "Improved Initiative", but truly, we should go through every feat, special ability, etc. and search for items that modify Initiative, based on their description (perhaps in another file), instead of hard-coding it in the XSLT.
• Speed is hard-coded to the aboleth
  Instead of specifically pulling out the walk and swim speeds specific to the aboleth, we'll loop through all supplied Speeds.
• Armor class ignores other bonuses
  In the same way as the Initiative, the abilities and equipment of the creature should have tags that are found and applied to this calculation. We'll deal with this once we get to encoding the power of feats, and weapons, etc. We can, though, change the size AC calculation to remove the aboleth-specific code.
• BaseAttackAndGrapple is hard-coded to the aboleth
  Because this is a similar problem as the HitDice one, where we have an iterative sum, we used the same, ugly method to do that here as there.
• Attacks don't deal with ranged attacks, touch attacks, etc.
  I don't know all the possible attack types (that don't fall into SpecialAttacks), but we need some differentiation between the melee and ranged attacks at least. We'll add some code to determine natural weapon damage, which is a bit of a hack for now -- I believe it should figure out what the size of the natural weapons should be for a given creature, and compute it that way. The damage bonus, though, should definitely be a computed value, not hard-coded, based on stength.
• SpaceAndReach is hard-coded to ft.
  So was the Speed, but until we have a schema, we can't support default values, so they'll stay.
• SpecialAttacks don't link to their later entry
  I don't really know what the standards are for linking in XML, not having read anything about XLink yet. Even worse, in the design right now, the SpecialAttacks are in lower-case text, while later in the SpecialAbilities section, the names are capitalized, so matching as-is won't work. Instead of changing the exact spelling of one or the other, we'll leave this one for now, and wait until we know the correct way.
• SpecialQualities are hard-coded to the aboleth
  This refers to the "implicit" SpecialQualities that the XSLT builds up based on the Type and SubType. Even though this is iterative (through Type and possibly multiple SubTypes), there's no operation involved other that appending the strings, so it's not nearly as complicated as the HitDice or BaseAttack were.

  The one issue we might have to come back to is the fact that in monster descriptions, terms like "aquatic subtype" or "construct traits" are used to lump a bunch of SpecialQualities together -- what we really want, though, is the code to have access to all of them. For now, we'll just stick with the generic terms, but will have the lists later.

• SpecialQualities don't link to their later entry For the same reason as above, we'll wait until we figure out the proper way to do links before we commit to this.