No; not a random chance thing, nor a gambling thing, nor even a mush-mouth attempt to say a common phrase.
I’ve got it in my head to make sure Wizards and Clerics can have prepared spells when being edited in the workshop application. So I started (re)-looking at what I had done. Apparently I hadn’t done that much, and what I had done was a bit Byzantine (apologies to Constantinople, but your courtly operations became an adjective for a reason).
The whole set of Caster Classes have been back on the drawing board. But when I’m done with this little bit, I should be able to prepare standard spells, specialist spells, and cleric influence spells within the workshop so that I can run simulated tactical encounters with more than just weapons and magic items. Plus, I’ll be able to confirm spell targeting without the use of a wand.
As is per usual, my time is crunched by normal work, my sister’s baby-shower (the guys are going to get together also), the premier of Doctor Who Series 8, and a possible trip to Hershey Park to compensate for an abortive trip earlier this summer because my brother-in-law had to work on Saturday.
Alright, first a little explanation: the title refers to a method in the BaseMonsterClass that handles changing the creature’s size down one step, such as going from Medium to Small or Small to Tiny. Now for some background: I have been working on targeting and activity building for a few weeks now. I’m pretty comfortable with how it’s shaped up (more on that later), but while using it I discovered a little problem with the melee-strike range for the animated objects that fall into the “tiny” category.
An animated object with 1 power-die is small, an animated object with a partial power-die is tiny. The system and workshop handle this by allowing the creature to have an option when editing the 1st power-die to pick a partial power-die instead of a full one. The BaseMonsterClass has the capacity to use standard or custom size ranges to control and modify the body when the size should change due to power-dice change in the editor. StepUpSize worked just fine, it uses the size range information to add additional values to physical creature ability scores and natural armor. The natural reach is, however a fixed value (not a change value).
So…when I wrote StepDownSize, I copied StepUpSize and pasted, using the previous size range and subtracting them out (I just had to change the additions to subtractions). However, the natural ranges were not something that could be size reversed, so I ended up assigning the old larger size reach to the smaller body. Tiny animated objects could reach 1 cube away. Simple enough fix once I realized it…
Although I’ve been doing a lot besides making models over the past month, I just thought I’d share this bit of skeleton with a working rib-cage. I’ve actually been working a bit on the targeting process, and will post some images of that in a bit, just want to make sure the auto-aiming of pre-selected attack targets is where I want it to be.
From left to right, Greatsword, Bastard sword, longsword, short sword and dagger. They’re all using the same coloring schemes so only the sizes and parts vary.
Even though I’ve had the warhammer model fragment for awhile, I still think it looks pretty cool when properly painted with gradient materials. I was tightening up some of the other content tools, and also finished the 3D models fragments for the great sword, bastard sword, dart and javelin, as well as tightened up the long sword now that the great sword and bastard sword are around for comparison.
If I feel so inclined I’ll add images of some of them as well.
All thanks to my face creator program…
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.
Since January, I have actually been a bit busy; I just haven’t been posting as much.
I had previously gotten a solid animations (TransientVisualizations) implemented and tested for Magic Missile. I hadn’t, at that time, done much with the Disabled/Dying/Recovery sequence of conditions (which became apparent when I Magic Missiled my target dummy to negative health points). It turns out to be a bit convoluted, but I managed to re-do some stuff and make it all work.
During that core-rules sweep, I started getting a bit wrapped up with fatigue and exhaustion (the game conditions, not me personally), and noticed that sleep wasn’t required or forced by game-mechanics (*sigh*) not entirely sure on what that will mean going forward. Certainly sleep is needed for spell-casters, but non-casters could theoretically stay awake for-ever without any game-mechanic penalty. I’ve read some ideas, but I think I’ll defer for now.
Anyway, after that I planned to work on action aiming, which would require some substantial client-UI work and view-models. I had been planning on adding multi-character capabilities in the “test client” for some-time, and it seemed like I should do that before adding the aiming UI. I also wanted a more-flexible UI and decided (eventually) to use AvalonDock, as it would allow dockable and floatable windows.
I started working with AvalonDock on the host application, and had enough success and knowledge gain to begin the same with the client. The main challenges have been converting the control-routed-event model I originally used years ago, and converting it to a more MVVM-ish model. I had already moved a good part of the client to MVVM, but now saw that I had much more to do (commands in the model!)
After I get the UI re-factor done (and add multi-character login support), I’ll include some screenshots here.
I forget to bring my cell-phone with me today (so my wife would have to call on my direct desk-phone line), but that’s not the basis of the title. Instead, after tweaking and prodding the spell target delivery mechanism so that Magic Missile would yield its animations to the local map context, I got a (semi-)successful test working. Unfortunately, since Magic Missile doesn’t use an attack aim, but instead an awareness aim, I only had immediate access to what is called the “PlanLine” when deciding on animation end-points.
The PlanLine is the first line-of-effect between the source and target that is not blocked, which goes from corners to corners (at the moment) and starts testing for lines-of-effect at the “bottom”. So, the “bolt” currently travels right along floor level such that I pretty much missed it the first couple of times I fired a magic missile from a wand. I did, however, see the “splash” of the missile making contact (also at floor level) so I knew animations were being added, transmitted to clients, and rendered. I’ll have to alter the awareness aim animation start and end points to be the centroid of the map-locators holding objects causing the action, and being targeted.
There are some other things to work out on when the animations should be rendered and re-rendered, as the damage roll side-panel (for the spell caster) pops up while the Magic Missile is still visibly flying in the post-action redraw sweep, and if you change target selections the animations are re-run as time hasn’t changed. I’ll probably have to separate “re-run animations” from “scene redraw”.
Here’s a snapshot of pretty much every XAML Icon I have so far. I’ve been a bit busy making sure I could load these into packages as resources and share them between resource referenced packages. I also have built code to associate these with in-game objects and provided mechanisms to override and pass them through from the server to the client. I still need to build the client and add icon display in the client and the workshop.