| <--Refactor, continued | ^--xmld20--^ | Version 5--> |
<Code calc="Save"> <If this.name="fortitude"> <Increase type="SavingThrow" name="fortitude">2</Increase> </If> <If this.name="reflex"> <Increase type="SavingThrow" name="reflex">2</Increase> </If> <If this.name="will"> <Increase type="SavingThrow" name="will">2</Increase> </If> </Code>It doesn't make sense, of course, to have the SavingThrow name in there, since it's in a Save element. It doesn't make sense to have the fortitude name in there, since that's part of the this.name. So perhaps we should move this to
<Code calc="Save"> <If this.name="fortitude"> <Bonus subtype="astral deva">2</Increase> </If> <If this.name="reflex"> <Bonus subtype="astral deva">2</Increase> </If> <If this.name="will"> <Bonus subtype="astral deva">2</Increase> </If> </Code>Note that we also forgot to say the source of the increase, so I've added it in here. This <Bonus> idea is the same that we used when talking about the Ability scores, in the strength example. This is likely what should be used in most areas, and this is the approach I'm going to switch to, as long as the idea of "Bonus" applies. Note that with the Abilities, we also had a <Base>, but this doesn't make sense for saves (or starts at an implicit 0).
I'm also thinking of changing the "subtype" to "source" where we're keeping track of the race/class/item/etc. that gives this change; it's more applicable, but will require a little re-working of the existing language. I think I'll also change from the bonusname attribute to just name.
I've finally caved in, I think. Using XML to represent the scripting language was becoming quite unwieldy. It worked, admittedly, but it just didn't feel right. I do enjoy the fact that the parser for the scripting language can be written in XSL, since the language itself is XML, and that meant that the scripting processor fit seamlessly into the main code, and have full access to the data, since it was also in XML.
The idea has been floating around, but the urge to resist, to use the XSL processor, was quite strong indeed. But today I was explaining how something like synergy would have be done for skills, and that's when it hit me how bulky the XML version is.
Here's an example of how the code might go with the current setup:
<Skill name="knowledge" subname="arcana"> <Code calc="Skill"> <If this.name="spellcraft"> <IfCalc Skill.knowledge.arcana >= "5"> <Add type="Bonus" subtype="synergy">2</Add> </IfCalc> </If> </Code> </Skill>Of course, this wouldn't work... first of all, you can't say ">=" in an XML element for an attribute -- it's only "=". So while this works fine to do IfCalcs on specific values, it doesn't help out here. Second, if we could get away with the ">=", we'd be comparing the total skill, not the number of ranks, which is the correct value. Third, we awkwardly had to append the subname of the skill using another "."; we could say that that's the convention, but that means we can't use ".ranks" as a subcalculation. Would we really want "Skill.knowledge.arcana.ranks"? Where would the parser break that down?
Instead, using a "real" scripting language, we could write something like
<Skill name="knowledge" subname="arcana">
<Code>
Skill["spellcraft"] {
if (Skill["knowledge (arcana)"].ranks >= 5) {
return Bonus["synergy",2]
}
}
</Code>
</Skill>
Or something like that. The actual method with which one defines which
Skill this is a calculation for, or how to fetch Skill ranks, or Skill
totals, or Skills with names and subnames, or how to return the Bonus,
all needs to be figured out.
One thing that comes to mind is Xquery, since it's procedural-like in its form, and deals with XML. Of course, our scripting language doesn't only need access to XML, it has to know how to calculate things -- the XML version had the idea of IfCalc which would figure out the Base and Bonuses of a specific value, and know how to add those together. Xquery doesn't have that inherent knowledge, but we write an extended version of Xquery that has a way to query for a calculation instead of just a lookup in the XML.
So what, then? I'm considering PHP/Javascript, for a number of reasons. First, they're "web languages", which allows the system to work on remote servers and in browsers instead of requiring an installer or a specific operating system. PHP has XML support, and while I don't know how good it is, it likely has enough to find and read the entries we need at any given time. If supports the idea of an "eval", which greatly simplifies coding dynamically, and it supports the idea of running external code, which means that it can both be the base system as well as the scripting language. Javascript can then handle to user interface, though whether it'll make calls to PHP code and process it, or the PHP will generate HTML+Javascript will have to be decided.
| <--Refactor, continued | ^--xmld20--^ | Version 5--> |