Object: Animated

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.


Docked at the Island of Avalon

Quick peek at a screen-grab of the host application after I refactored it through AvalonDock from Xceed.  It was my “get the feet wet” implementation, as I have been doing much the same for the client application (I’ll get some grabs of them a little later).


Fade-Out, Fade-In

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.


Visual Studio 2013 Express Desktop

I had been toying with upgrading to a newer Visual Studio (was on 2010 for 4 years), but couldn’t feel compelled to fork over more money than I had for upgrading from Visual Studio 2008 to 2010 to get to the next level.  If I was making money on Ikosa, it would be a different story.  Anyway, I had rejected the express editions due to Source Control integration issues (or lack of support).  The 2013 editions support Visual Studio online source control integration, so I made the plunge and shifted my development to VS 2013 and TFS. The only thing I really miss is class diagramming 😐, and I can’t work with WCF projects (directly as VS project types, though I can edit their project files to be libraries, and I can still host services) since Express for desktop lacks designer and host launch support for WCF debugging.


Direct Line

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”.


Visualizing the Future

The last month hasn’t been idle time. I’ve been working towards TransientVisualizers (think animation sequences for certain splashy actions) being associated with certain server-side model activities and being transmitted to the client where they can rendered. I’ve added support for “literal” brush keys, in which the key name represents a solid color or a linear gradient (horizontal or vertical) so that I can encode fail-safe animation colors without having to have mapped brushes defined (in Ikosa packages) for the models.

I’ve also added a storage area in the map for holding transient visualizations for the current tick. When the map time changes the transient visualizations are cleared (hence: transient). This storage area is accessed by an operation contract in the visualization service contract. Well enough to have a place to store and retrieve visualizations, but I also added bits to the power definitions and (by extension) the spell definitions for supporting animation types based on targets and animation style. Turns out that not too many spells (in the 0th to 2nd level range) require flashy animations, as some of them are buffs, divinations, “invisible” effects, or create persistent (not transient) objects such as dancing lights.

I did add one new type of animation over my previous set: namely a flying orb that moves a sphere from point to point. I already had a flying “bolt” (ray bolt), but there are some low level orb-spells that are necessary. I bound animations to the spells that needed it, and fixed a few power and spell issues I noticed along the way.

Finally, the past week or so has been fixing some client-side items (and server-issues that led to them) related to icon imagery, which I never implemented in the client (despite being the reason for doing all my flat XAML icons), but now have.

My next bits of effort are in surfacing wand and spell action selection and targeting in the client (they are defined and should be “working” server-side) so that I can test and fix the animations that should be bound to them.


Spirit of Atlanta

Last weekend I drove my daughter to Atlanta for a drum corps audition camp.  I spent Saturday recovering from the drive (which was repeated in the reverse direction Sunday), getting an oil change (the reminder went off somewhere in the Carolinas), and fixing up the client-side contract changes to match up with the server-side changes made previously.

I finally got to test and fix the code this weekend, and ended up finishing some resource transfer code I had been delaying, as well as removing some client-server transfer classes by marking the original classes with DataContract attributes.

I can now run a host and client, with the ability to render the terrain and presentable objects.  Before I move on to implementing icon visualization on the client-side, and building more animation support for actions, there is still some work to make sure the “Ikosa” services are working, since in my test, I couldn’t get my character to move…

I’ll be heading back to Atlanta this next weekend, so I want to avoid spending the time on Saturday fixing my refactoring.


Renegotiating Contracts

Spent a lot of time this past weekend refactoring the code-base to isolate the DataContracts into their own assemblies.  The idea is to get the services and proxies to understand each other without having to export meta-data through the Mex endpoint.  I had to “invert” a lot of code so that the game-state model classes created their service info instances.  All done now (server-side at least), still have to do the proxy/client changes, then the dreaded distributed testing.

While this was on the agenda for awhile, the immediate impetus was the pending addition of DataContracts for animation support, which would be cumbersome to add using the meta-data exchange (Mex) mechanism.

The proxy/client changes won’t be without challenges, as I originally defined partial class additions to the imported WSDL; and these will have to find a new way to get involved in the proxy (MVVM anyone?).  I wrote a previous post many moons ago on my proxy-side shift to MVVM style WPF UI, so should be “fun”!


Flat XAML Icons

all the icons for items (so far)

all the icons for items (so far)

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.


Greatsword Miniature

Greatsword Miniature

This is the source miniature (from my family gaming group) that I’ve been using to guide me while creating the greatsword wielder.