Object: AnimatedPosted: 2014-05-15 Filed under: Coding, General | Tags: animated object Leave a comment
I had tagged my son with creating an adventure module (for low level characters) a little while back, and he got back to me telling me had included animated objects and zombies. Zombies (in the OGL world) are created by templates, so I knew I’d have to tackle them eventually. Animated objects seemed like a relatively simple thing, but the more I dug into it, the murkier it became.
So far, the only “species” I had worked on were a gaggle of humanoid-type classes suitable for player characters (including the goblin), and a gargoyle, since he’s a good testbed for flight, increased size by power-dice, and can take class levels.
In all of these I had a single abstract method that had to be overridden when connecting the species to a creature, and another when disconnecting the species. I refactored this into a whole slew of overridable functions, one for each major area, like body construction, abilities, requirements, senses, and movements (etc. etc.)
I also defined a Slam natural weapon and a slam item slot (animated objects use slam). So far, this was some simple refactoring to help guide future species construction, but then the oddities set in…
Animated Objects have no Constitution score, they do not gain feats or skill points per power die (in fact they don’t really “gain” anything, as they are almost like a template applied to objects). While not as obvious, it was just as simple to make them not gain ability boosts every 4 power die.
The lack of CON and the immunities required some validation and creation of lots of little handlers and filters to block interactions from things like poison, or handle the absence of non-lethal damage. Also I defined some adjuncts that can filter out other adjuncts by explicit type, source magic type or source magic power descriptor and prevent them from anchoring to the creature. I revamped the way adjuncts bind and defined that adjunct binding was an interaction so that it could use the HandleInteraction-style of monitoring, prevention and alteration. Previously I used a ChangeMonitor class that allowed other things to connect and signal their intention to veto the change.
Also, the size-ranges for animated objects as they “progress” in power dice don’t work like the standard set, so I had to factor in custom size ranges. The ability scores and natural armor follow their own path for animated objects. Weapon damage for animated objects also doesn’t follow any normal weapon progression, so I had to virtualize the roller lookup and retain the standard as a default when no custom lookup by size is supplied.
And…animated objects come in different forms, materials and aspect ratios (tall versus long), exposing some weaknesses in my original model of dealing with reach squares upon size changes. I had to provide level 1 advancement requirements for some of these, but some others (such as aspect ratio and partial power die) I deemed reusable enough to be in the BaseMonsterClass. Dealing with a creature that can have a fractional power die proved a bit problematic, but ultimately resolved (as a level 1 requirement flag that prevents advancement past 1 until the flag is set to non-fractional). This also led me to having the functions to “count” creature power dice accounting for fractions when the number of power-dice affected becomes relevant to a magic power.
I also cleaned up some code that made refreshing the character sheet in WPF workshop a bit easier (except for attack modifiers which are still a bit wonky right now).
Not quite “done” with the animated object, but definitely past the bulk of it.