Well, maybe not a *whole* engine quite yet, but certainly two thirds of one.
I’ve generated about 500 little XML files to hold all of the skill and spell data for dynamic runtime loading. It’s all pretty neat — skills and spells can be tweaked by hand without having to compile any code (though the MUD requires a reboot) and they’re loaded at runtime, stored in a Dictionary type, and accessed based on their names.
There isn’t a single hard-coded spell or skill value in the engine. Hardcoded values were something that always bothered me.
Another thing I did in this process is embed “logical preference” data in the skill and spell files so that the AI engine can be improved while at the same time removing the need for thousands of lines of “spaghetti code” like in Basternae 2. You see, each spell and skill check in B2 was hardcoded in a specific order and with a specific percentage chance. Adding a skill or rearranging mob AI meant editing these in more than one place.
Instead (when the AI code is done), we’ll be able to set a few flags on each spell or skill and it will handle it automatically (unless a specific mob has a personality override file).
Oversimplified example:
Fireball.xml: Type = offensive, Preference = 65, Likelihood = 40
LightningBolt.xml: Type = offensive, Preference = 50, Likelihood = 50
This means, essentially, that a mob would have a 40% chance of casting fireball during combat, and if that didn’t go off, it would have a 50% chance of casting lightning bolt. Changing the way the mob performs in combat is just a simple number tweak.
I have some pretty huge plans for mob AI, but this new spell/skill system goes a long way toward making those plans easy to implement.
I also have yet to embed all necessary custom code in the spell/skill files, but one thing that’ll be done is that most information needed to trigger a spell will be embedded in the file. Instead of manually writing a dozen lines of the same code for each spell to validate the target, check saving throws, set damage type and amount, send messages, and deliver the affect(s), most spells will use one general-purpose function that checks the spell types and flags and executes the spell’s action.
This means that most standard spells that are just damage or single-affect, like “soulshield” or “fireball” won’t have any embedded code at all. Instead, only super-involved custom spells like the enchantment spell “earthen smith” will have their own embedded instructions.
Well, that was long-winded. It had to be — I’ve done a lot and I’m pretty proud of what I’ve accomplished with this.
