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.
Do you plan to handle MOB AI all within the B3 code? Or will it be split between the code and the zone editor. I’m probably not writing correctly what I want to ask…One of the great features in my opinion of TE (Toril Editor) is that it allows the zone creator to add AI (simple AI) to a zone making the zone come to life – not just a simple hack and slash with no uniqueness.
For instance there is a simple procedure to add MOB AI – where the mob will act based on a set of player inputs/actions (i.e. triggers). You could set % for different actions such as:
Mob VNUM: 38XXX
Condition: 1 (i.e. 1 out of combat, 2 in combat)
Trigger: 3 (i.e. player start to cast offensive spell at target – other conditions existed)
Target: 2 (i.e. 1 random player, 2 Trigger person, 3: caster, 4 etc etc)
Action: Bash, 50 <50% chance to trigger
Action: Cast ‘silence’, 25 <-% chance to trigger
~
Condition: 2
Action: Say “Your soul will be devoured”, 50
Action: Cast ‘swarm’, 25
~
so on and so on. These were individual files that went along with the zone submission. We had something similiar in B2 – they just didnt work too well and involved an actual coder to tweak them. Having these available made quest writing more dynamic as you could trigger off words to teleport players – or change the quest randomly so there were different outcomes/rewards/requirements – all done from the editor. In fact, the only thing we needed a coder for was to add a function to a weapon – that was good for balance sake. Anyway, kinda long winded – but thats the point of a blog 🙂
Honestly I hadn’t put a whole lot of detailed thought into editing of the AI. To give a partial answer:
I plan to have all AI handed in-code by default, but intend to come up with some sort of system where builders can override or augment the default behaviors. How that’ll be done is anybody’s guess, but however it ends up working, the editor will be able to work with it.
I always hated the MobProg system. It was almost useful, but it was limited, klunky, and awkward, so even though it worked not many people used it.
I’ve also added a handful of extra quest types/rewards, such as faction standing bonuses/penalties, skill/spell/song learning, and spellups (i.e. mob casts ‘haste’ on you when the quest is completed).
that was it mobprogs. If I emailed you the Toril/Sojourn set-up and how it was written do you have any interest in looking at it? It was much more dynamic than what I did with Duris and Basternae. It was kinda klunky but klunkiness is overlooked when a mob says/does something players dont expect….
Also, along the same lines, Toril had “Zone Echoes”….lines that would echo only in a zone. Kinda like in Waterdeep a line would randomly appear saying “A Harbor Bell Rings off In the Distance.” or “The Captain of the Waterdeep Guard Curses as he walks past.” Insignificant in the grand scheme of the mud – but again for those in the zone or rooms where the echo takes place it adds a little uniqueness. This was also done with the zone editor and contained a seperate file.
Sure, I’d like to take a look at how they’re doing it. I like your point about zone echoes, and it’d be pretty easy to add them to the editor. My email address is at yahoo.com if you don’t have it handy.