Back to main page

Development Update #14

Posted on June 23, 2016 by Kelso


I spent this update period working on getting the Surgeon skill-swapping mechanic working. The idea is that player’s can toggle the Surgeon between two different states – a heal state where he looks for injured squad mates, runs to them, and heals them; and an attack state where he acts like a regular unit and looks for enemies to attack.

To do this I had to provide a framework mechanism to override specific states on a unit-by-unit basis. We already had some of this concept in place when we did custom targeting behaviors for some units (like how the Ancient Fist will pick targets with other enemies in-line so that his projectile can deal maximum damage). To that end, a customBehaviour node can be added to a unit’s markup to override default unit states. The Surgeon’s looks like this:

When the framework sees that a unit contains custom behavior it uses a special factory object to build the custom state via some reflection and a required “initialization package” that allows for some commonality among custom state constructors. The result of this reflective process is wrapped up into a Func object that is “compiled” so that subsequent requests for the same type of state can be executed much faster.

In the case of the Surgeon these custom states are actually fairly involved compound states; but the end result is a self-contained solution that should also allow modders to easily create totally customized behavior for any unit.

A note: the British spelling of behavior in the XML markup is to remain consistent with the Unity engine’s spelling of behavior. I, however, am not British and thus there is a discrepancy in the spelling in this post 🙂


So since the hospital is done I have moved onto the units that are tied to it. The first being the Laperian Surgeon. The Laperian Empire has a somewhat limited appreciation for soldiers who can’t shoot things in the face in at least some form, so even their medical support soldiers are expected to do said face shooting. The Surgeon is thus able to toggle between a healing and attacking state. This means you will need to balance priorities depending on the engagement (and remember to switch them back to healing if they are idle perhaps). The heal is single target and the medic will run between members of his squad who are injured. His attack is a limited damage AoE that applies a healing received debuff to units it hits.

As for ingame images I only have T posed model screenshots, but the textures are all done. The first pair are at the standard camera zoom.

You will likely never see them much closer up aside from some elevation shifted buildings (the hospital coincidentally) and perhaps if they get blown or thrown sky high (this will be a thing, and it always makes me giggle…whatever that says about me).

I kept the skill icons simple and hopefully the toggle is standard enough that players will intuit the click to switch nature of it.

I make the icons much larger than they appear in game. Mostly because it is easier for me and I can let Photoshop sort out the reduction in scale, but also because it allows us to display them in other places if need be. This is especially handy for the unit icons:


One of the things I glossed over when talking about animation is skinning. I kind of mentioned the effects it can have on a model and how good animations look because of it. So Let’s talk about Skinning..

See, characters are generally (and by generally I mean 99% of the time) are animated by making ‘bones’ that work much like our bones do. They give our muscles something to latch onto. Why, we would be just wobbly messes of mush without the bones. So animators put these bones in to gives guidance to the mesh, by giving vertices a place to pull their direction from.

An Example: An Arm is made of 2(technically 3 but Im simplifying here because 2 of them work in tandem) bones, the bone near our biceps, and the bone at the forearm. They are connected at one point, the elbow. Now this elbow is a joint that allows the 2 separate sections to move based on a common point. When you flex your bicep, your forearm muscles don’t move. And vice versa. But when you move the elbow, the place where they connect, both areas move.

One vertex can be told, “Ok, you move when bone A moves. Only listen to this bone.” Another vertex could be told to move with bone B. The interactions get more complex when a vertex is told to follow bone A AND bone B. It gets even more interesting the more bones affect a single vertex or when many vertices are packed into a dense area affected by multiple bones. Or the vertices are required to take a certain shape. In this case, cloth. A lot of our characters have draping clothing.

Here is a picture that shows just some of those interactions between a vertex and the particular rig I use:

And just to show you the difference between a decent skin:

versus a skin where the vertices were not carefully manipulated to follow the bones they were meant to.

Back to main page