Direct Line

Posted: 2014-01-30 | Author: | Filed under: Coding, General | Leave a comment

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

Posted: 2014-01-16 | Author: | Filed under: Coding, Debugging, Guildsmanship, WPF | Leave a comment

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.