xmld20 - an XML Schema for d20 gaming systems - intermediate stage

As mentioned before, the intermediate stage is an XML result that will further be used by end-user tools to get a final result. This result might be a character sheet, a stat block, or data for a combat simulator. This intermediate XML will have all of the calculations from the character sheet, races, classes, equipment, skills and feats applied to it, and will have all information needed for generating any of the above results.

What do we mean by "all information"? One feature that I enjoy while playing Dungeons and Dragon Online is the ability to mouse-over different values, such as AC, and have a pop-up tell me the make-up of the total. To support such a feature (or at least, the ability to provide it), we cannot just have the AC as a total in the final XML.

In version 3, I had a diagnostic XSL template that would pull out the fully-merged data from the character and dump it out; this let me see the result that the character sheet generators and statblock generators were using. This is a good starting point for the structure of the XML we'll be aiming for. Here's an example of what the aboleth generated:

<Character xmlns:xmld20="http://crwth.org/2006/xmld20">
   <Name>aboleth</Name>
   <Race>aboleth</Race>
   <Environment>Underground</Environment>
   <Organization name="solitary"/>
   <Organization name="brood">2-4</Organization>
   <Organization name="slaver brood">1d3+1</Organization>
   <Organization name="slaver brood" subname="skum">7-12</Organization>
   <Treasure name="standard">2</Treasure>
   <Alignment name="lawful" subname="evil">usually</Alignment>
   <Advancement name="huge">9-16</Advancement>
   <Advancement name="gargantuan">17-24</Advancement>
   <LevelAdjustment>-</LevelAdjustment>
   <Speed name="walk">10</Speed>
   <Speed name="swim">60</Speed>
   <Size>2</Size>
   <Type>aberration</Type>
   <Subtype>aquatic</Subtype>
   <Language name="aboleth"/>
   <Language name="undercommon"/>
   <Language name="aquan"/>
   <Space>15</Space>
   <Reach>10</Reach>
   <RacialSkill subtype="aboleth" name="swim" conditional="yes">8</RacialSkill>
   <SpecialAbility subtype="aberration" name="darkvision"/>
   <Level subtype="aberration" name="darkvision" unit="ft.">60</Level>
   <SpecialAbility subtype="aquatic" name="aquatic subtype" super="subtype"/>
   <Skill name="concentration">11</Skill>
   <Skill name="knowledge" subname="any one">11</Skill>
   <Skill name="listen">11</Skill>
   <Skill name="spot">11</Skill>
   <Feat name="alertness"/>
   <Feat name="combat casting"/>
   <Feat name="iron will"/>
   <HD subtype="aboleth" racial="yes">8</HD>
   <BAB>6</BAB>
   <SavingThrow name="fortitude">2</SavingThrow>
   <SavingThrow name="reflex">2</SavingThrow>
   <SavingThrow name="will">6</SavingThrow>
   <AC name="natural">7</AC>
   <Weapon subtype="aboleth" name="tentacle" super="tentacle"/>
   <Damage onto="tentacle">1d6</Damage>
   <Extra onto="tentacle">slime</Extra>
   <Attack name="attack1" weapon="tentacle"/>
   <FullAttack name="fullattack1" weapon="tentacle">4</FullAttack>
   <SpecialAbility name="enslave" spelllevel="4" casterlevel="16" ability="charisma"/>
   <SpecialAbility name="psionics" casterlevel="16" class="wizard" ability="charisma"/>
   <SAbility subtype="aboleth" name="hypnotic pattern" onto="psionics" frequency="at will"/>
   <SAbility subtype="aboleth" name="illusory wall" onto="psionics" frequency="at will"/>
   <SAbility subtype="aboleth" name="mirage arcana" onto="psionics" frequency="at will"/>
   <SAbility subtype="aboleth" name="persistent image" onto="psionics" frequency="at will"/>
   <SAbility subtype="aboleth" name="programmed image" onto="psionics" frequency="at will"/>
   <SAbility subtype="aboleth" name="project image" onto="psionics" frequency="at will"/>
   <SAbility subtype="aboleth" name="veil" onto="psionics" frequency="at will"/>
   <SpecialAbility name="slime" spelllevel="4" ability="constitution"/>
   <SpecialAbility name="mucus cloud" spelllevel="4" ability="constitution"/>
   <Ability name="strength">26</Ability>
   <Ability name="dexterity">12</Ability>
   <Ability name="constitution">20</Ability>
   <Ability name="intelligence">15</Ability>
   <Ability name="wisdom">17</Ability>
   <Ability name="charisma">17</Ability>
   <CR>7</CR>
   <Level subtype="class" name="aboleth">1</Level>
   <Variable name="strengthbonus">8</Variable>
   <Variable name="dexteritybonus">1</Variable>
   <Variable name="constitutionbonus">5</Variable>
   <Variable name="intelligence">2</Variable>
   <Variable name="wisdombonus">3</Variable>
   <Variable name="charismabonus">3</Variable>
</Character>

This doesn't have the breakdown of the totals as I want, but it does show the kind of data that we need. Additionally, this result still didn't compute certain things, such as the to-hit on the weapons, or any bonuses to calculations that feats might provide. That was left to the output code, which doesn't make much sense. So what kinds of things would we want to add to this result?

Name

In this example, the aboleth is an aboleth, and that's that. But what if this was the aboleth wizard, next to it in the Monster Manual? And what if it was a character? Perhaps something like this?

	<Name>
		<Name>Ulg-glu-lul</Name>
		<Race>Aboleth</Race>
		<Occupation>10th-Level Wizard</Occupation>
		<Title>Aboleth Mage, 10th-Level Wizard</Occupation>
	</Name>

Except for the "Aboleth Mage" part, this is all calculable, but should that be left up to the "user", that is, the code that uses this result? We're not preventing them from calculating it, of course, but I think we could provide it here. Other entries could exist here, if the character has honorifics (Prince), aliases (Gluu-oo-ull), or nicknames (The Slimy One).

Organization

Since we're not traversing this with self-appending code, there's no reason to fear hierarchical data, so this can be changed to something more reasonable:

   <Organizations>
	<Organization name="solitary"/>
	<Organization name="brood">2-4</Organization>
	<Organization name="slaver brood">1d3+1</Organization>
	<Organization name="slaver brood" subname="skum">7-12</Organization>
   </Organizations>

Look familiar? Yep, this is the structure that appeared way back here when we were originally refactoring the structure in version 1, such as seen here. In fact, it's a really good starting point, since we were generating the aboleth entry from this in the beginning -- the only things missing are the extra bits of information I want added. So, instead of going step-by-step through the output above, I'm going to take the old aboleth entry, reform it, and then come back and discuss the changes. The aboleth, of course, doesn't cover everything that might appear, but it's our original test creature.

The problem with coming up with this intermediate form is thinking up the standard elements that should be used. For instance, if a creature has a Challenge Rating of 7, is it enough to say

	<CR>7</CR>

I don't think so, because you not only want the total, but the breakdown; in this case (our aboleth), the CR comes solely from its monster HD, so we might want to say so:

	<CR>7
		<Bonus type="class" subtype="aboleth">7</Bonus>
	</CR>

Two problems here: I don't like the "7" just sitting there as the text portion of the element, mixed in with the child element. While this is valid XML, I've never really liked it, and want to put the total in its own child tag, or perhaps as an attribute. Also, what about the name "Bonus"? It's not really a bonus, but what is it? Bonus works because that's the kind of thing that most of the values will be made up from, bonuses to armor class, to hitpoints, to abilities. Do we want a different name? What would it be? For now, let's stick with Bonus, so we have

	<CR total="7">
		<Bonus type="class" subtype="aboleth">7</Bonus>
	</CR>

Should the attribute be "total"? Should it be a more generic "value"? Should it differ per item, or be standardized? And I'm getting tired of my overuse of "type" and "subtype". In this case, the TYPE of the bonus is undefined; instead, there should be sources for this bonus, and should record it that way:

	<CR total="7">
		<Bonus sourcetype="class" sourcename="aboleth">7</Bonus>
	</CR>

Why keep track of the "sourcetype" and "sourcename"? Another nice feature would be to have a way to go instantly to this source when looking at the result; if the code that generates this aboleth character shows that the CR comes from the aboleth class, and can provide a clickable link, the system will be all the better for it. If the character sheet or stat block just wants to allow a pop-up saying that it came from the aboleth class, that's fine too. But both of these are functionalities that I want to allow and support. Note that this is just an inherent "bonus" from being an aboleth. I think that knowing that the aboleth class contributed the CR is useful, but it might also be useful to know at which levels of the class the CR went up. Or is it? I don't see off-hand how that might be displayed in a pop-up, or frankly, how useful that is -- if you provide a clickable way to get to the class in question, the user can see where the CR was gained.

What's the "type" of the bonus to AC from Dexterity? Is it "dexterity"? Is it "ability"? And, is it a bonus, or is it a modifier?

For the code, of course, it doesn't care -- it's just going to add things together. But for display purposes, should we differentiate between a "bonus" and a "modifier"? What's the difference? My guess is that a bonus is always positive, where a modifier can be either positive or negative. Thus, AC is

	10 + armor bonus + shield bonus + Dexterity modifier + size modifier

This tiny little issue is frustrating... do I want to have to worry about the distinction between the two? Do I really want to code an armor check penalty as a "bonus"? FINE! I'll use both "bonus" and "modifier", for now.

As for the name of the Dexterity modifier? The monk is a good example here, where they get a modifier for Dexterity, and a bonus for Wisdom to their AC (that is, they don't suffer from a Wisdom of less than ten). This modifier and bonus stack, so we can either store them as having "type" of "dexterity" and "wisdom", or both as "ability", with the rules knowing that "ability" bonuses/modifiers stack. Oh, sure, and I just read the PHB definition on "modifier", and it brings up "penalty" as another term.

In the end, I have to do all three. Yes, the math is still there, but for correctness, I should be able to say, for something like Tumble:

	 5 Base
	-2 Dexterity modifier
	 2 Synergy bonus
	-1 armor check penalty

I like the look of it, with all three types, so the user, if they're wise to the terminology, can see what's what. But back to the abilities... looking at the definition for skills:

	Skill modifier = skill rank + ability modifier + miscellaneous modifiers

Ability modifier! This game is driving me crazy.

So, the intermediate form looks pretty good; I'm able to generate our test cases, the aboleth and the pit fiend, for both the old and new statblocks. These were good tests for seeing what needs to be in the intermediate section, but it isn't all-encompassing, of course. The issue now is how to come to this intermediate representation from the data provided and the scripts we will write. x

<--Version 5

^--xmld20--^

Intermediate stage, part 2-->