Input Manager, pt1

The Input Manager is working. I take incoming input data and then interpret that into human readable directions. This then is fed into the HUD system that draws the appropriate input icon.

You may notice that some of these icons change color. I am tracking how long each input is held, and then updating that icon color to indicate charge level.



Camera work. Engine Update. Stuff Broke.

I quickly banged together a camera system and spawned in a 2nd player. Works ok. Well and good enough for now, though obviously it could be smarter about how much of each character needs to remain on screen in the vertical.

It’s very rough, but I just needed something workable to get started. The camera actor gets the horizontal distance between characters and does a little math to pull the camera back far enough so each player is in view. There’s probably some fancy equations that take into account FOV, character velocity and all sorts of other factors, but math is hard and so this will do for now. There is a bit of a buffer to keep them in frame at the outer extreme, and a simple collider system is in place to keep the players from getting too far apart. There’s also a limit on how far the camera will tighten up on the characters when close together. This is a number I have tweaked about 9000 times already. I would like nice, big closeups, but at some point the low res voxel style gets difficult to read when too large on screen.

I had not upgraded UE4 versions for some time, so this project started in 4.16. When I updated to 4.19 earlier in the week, stuff broke. It happened to look like this:

If you know which axis UE4 considers “forward” (hint: it’s +X, ) it’s fairly obvious what was going on here, fortunately. The issue was that once I upgraded to 4.19, the camera was spawning before the fighters, so it didn’t know what to look at. As a result the camera was coming in at 0,0,0, looking forward down the X Axis. For some reason, in the earlier 4.16 build of the engine, the camera spawned in after the pawns in a 100% consistent manner, and all was good in the world, so I did not bother dummy proofing it. No idea why an engine update would have cause this, but going to 4.19 exposed a spot of sloppy coding blueprinting on my part. BUSTED.

PROTIP: There is no guarantee in what order anything in a level is going to spawn in. Account for this.

The fix was pretty simple. I was already spawning my players in via the Game Mode in a specific order. I just removed the camera actor from the level and spawned it in on demand via the Game Mode after the players were in the scene.

Spawn order is a thing that sometimes bites newish UE4 developers. I almost wonder if the engine might benefit from some sort of spawn list that says: “Yo: spawn this, then this, then this, then I don’t really care about the rest; bring it whenever.”

Loads of successful games have been built, shipped, and sold without this functionality, so perhaps this is something of a non issue. IDK.

You may notice that the two characters not only feature different color schemes, but different costumes than previously shown. More on this in another post. (Admittedly, I am somewhat proud of this feature.)

Subscribe for best life.

FX Work

Took a break from character related stuff and relaxed with a quick stab at some effects work.

Switching gears allowed me to work on another type of mesh swapping animation component I have been meaning to build. This new one is a bit more lightweight than the character specific version as it is intended for animated environmental props and as we see here, some types of effects.

This effect consists of a two frame mesh swap animation, point light, simple particle effect, and a moderately sized material. The material features a bit of refraction, a 32×32 texture, a 32×32 normal map, some world position offset vertex animation, plenty of emissive, and a whole lot of panning UVs.
Of course everything is parameterized, so this should serve as a good parent class for more effects down the road.

This is a quick color change to make a fireball:

There’s still a lot I can add to really flesh this effect out, and I have yet to work on associated spawn in and a hit/dissipate transitions. At the moment I have the projectile blinking on and off to mimic old school techniques for simulating transparency on hardware that did not have such rendering features. I am not quite sold on it just yet. I cannot decide whether or not it looks better with or without the blink. The variable frame rate at which the gif up top was captured isn’t doing me any favors;  All of the fancy vertex position offset work I did gets lost. Oh well. I put the flicker on a parameter so I can come back to it later.

I am also a bit unsure of the refractive glass tile look. I am afraid it makes the effect feel like a physical object rather than an ethereal manifestation of force. But it does look pretty cool, so the eye candy wow factor wins for now.

Maximum visual overload is my motto.

Now that I have the framework of the special effect in place, pretty soon I am going to need to work on capturing and deciphering the input stream, looking for valid special moves. I suppose I’ll have to do another character animation in order to tie it all together as well.

Subscribe for best results.

Animation System, pt2

In the previous post on the subject of the animation system, we looked at the struct that serves as the animation asset and the data table based on that format that is then filled out with to create a character’s moveset.

Now we’ll look at how that data is applied in game.

As I am not using a skeletal mesh, I cannot take advantage of UE4’s awesome animation system. As a result, no access to the super useful state machine tools found there.  I had to come up with a way to resolve which animation I wanted to play when.

In a previous implementation, I was attempting to keep clean distinctions between the input, movement, and animation functions. Input would come in from the Player Controller, which was passed to a component that then resolved those inputs into readable directions, (up, down, forward, back.) Those directions were next passed to the character and checked against the current movement state, (standing, in air, walking, etc,) from which a suitable animation name was derived. This name then went on to another component that then played the requested motion.

Attempting to maintain borders between those systems quickly became tedious, so I aborted that route and went quick and dirty. Input, movement, and animation now all happens in one location. It is a bit ugly, and there are already a number of special cases for things, but I did manage to separate these elements out into an event graph dedicated to just movement and animation away from other stuff, such as collision, hit point management, and so on. This is still WIP, so I haven’t done much in the way of cleaning the graph up or thorough commenting: 

Running left to right, input comes in (red nodes,) some stuff happens, (facing is determined, states are checked, etc,) and then movement occurs, followed by animation calls, which are denoted by the aqua colored comment boxes.

Here is a simple anim call, the Jump:

Two big functions here. First one is fUpdateAnimData. Any guesses as to what it does?

This function takes the name of the requested animation, passes it through an enum switch which then routes down the appropriate path so that the desired animation data can be pulled from the anim data table. There’s probably a smarter way to do this without all of the excessive pathing, but whatevs… it works. The player won’t know or care. This animation data is stored in the a variable which is returned at the end.

The variable holding the anim data then goes off to the SwapMesh function found on a custom component in the character class.

The SwapMesh function is the workhorse of the operation. It basically gets the first mesh, loads it into the static mesh component of the character, applies any location offsets needed, updates collision volumes as needed, keeps everything there for a duration as specified, and then repeats with the next model in the array of static meshes of the anim data. When SwapMesh gets to the end of the list, it checks to see if this particular animation is looping and either starts over if true, or plays the next animation as defined.

Easy as cake!

Of course, what I really would like is a new mesh swap animation asset type and associated final pose node that worked in the standard UE4 anim blueprint system, but ain’t nobody got time fo’ that. (Well not me at least.)

Subscribe. etc.

Animation System, pt1

(Lots of text to follow, so here’s a gif as an aperitif.)

Since I started posting gifs of the voxel fighting game tests in action couple weeks ago, I have had a couple of animators contact me, interested in getting involved and helping out.


While I am capable of throwing down a keyframe here and there when the need arises,  I do not consider myself an animator. Having real animation talent on board will free me up to do the things I find more enjoyable, such as game design, lookdev, and implementation. We’re still ironing out the details, but I am excited about the possibility of collaborating.

During the course of one discussion, I showed an animator the anim system running in game. His surprised reaction made me realize it might be worth a blogpost, so here we go…

UE4‘s animation system truly is a marvel of engineering. Its feature set is deep and wide. It has state machines, complex motion blending, hooks to drive joints procedurally, physics  based features, and more. In the hands of a skilled animator, it is capable of incredible feats of realtime motion…

IF you are doing skeletal animation! Of course, why wouldn’t Unreal‘s anim system be driven by a skeletal paradigm? That’s just how things are done in gamedev today. No madman would think of stepping back in time to some some sort of archaic, static frame based system, right? RIGHT!?!

Wrong. As I am typically wont to do, I chose the dumb hard thing. I had decided to emulate the old school style of animation with a brute force approach, and shoe horn it into a modern game engine. (Funny how some development approaches that were once easy, become difficult over time.)

Without skeletally driven animation,  all of those fancy, new fangled animation features mentioned above wouldn’t be of much use to me. No statemachines, no blends, no anim notifies, etc. I couldn’t even use the standard animation asset type. I had to make my own. It looks like this:

It’s a big ole struct. I based this off of my prior experience working on 2D fighters back in the day. Variables are seen on the left, and their type is down the right. I expect the format will continue to grow; there are already a couple of fields I need to add in, even at this early stage.

This struct is the basis for a data table that defines a character’s suite of motions. This is the current library for Mr. Voxel Karateman.

This is what a typical animation then looks like:

As previously stated, each animation is an array of static meshes and other data, as you see above. A suite of functions loads in the anim data from the table on demand, then cycles through each static mesh, holding for the specified amount of time.

(This was the point in the conversation where the animator I was showing this to said, “WHAAAAAAAAAAAAAT?”)


In addition to the relatively easy bit of swapping in and out meshes, this means I had to write a system to handle state switching, transitions, collisions, and other stuff. It’s all kind of working at the moment, and the core of it all may be worthy of being labelled a system, but there are a TON of edge cases headed my way that need handling.

But perhaps that’s just the way it is. Thinking back to those early days in my career, we hacked and applied whatever band-aids were necessary to make it work.

The plan for now is to just make it all work. Prove it out. Who knows, perhaps some programmers will want to pitch in and help out too. 😉

Subscribe and save!

Basic Movement

I went and processed a few more animations for a basic locomotion moveset and hooked it up to WASD. The voxel fighting game is playable! (in the narrowest terms possible.)

Thus far I have:

  • Stance
  • Walk Forward
  • Walk Back (reversed forward)
  • Crouch
  • Jump

There are actually slots for 3 different jumps, but I have yet to animate variations for forward and back. I might do front and back flips for those.

The walk back speed is slightly slower than the walk forward speed. Similarly, jumping away is more shallow than jumping forward. The idea is that this will make the game a bit more aggressive, as a retreating player will get caught by an advancing player. The values for the retreating velocities are adjustable, of course.

I am not sure how I feel about the static crouch and jump frames. They look a bit lifeless compared to the way the stance and walk animation swim through the voxel field. I may experiment with adding a few frames of animation to loop through in order to bring a little dynamism to those moves.

Also on display is a bit of triplanar worldspace uv mapping, giving the ground and polygonal blocks in the background a voxelized look via a normal map. I took care to make sure that the normal map tiles at 5cm of world space, and objects all snap to that gridsize. No partial voxels!

Thanks, and please remember to subscribe!

Voxel Animation Test: Walk Cycle

Here’s another animation test, this time the forward walk cycle. At the moment, the backward walk cycle is the same, just reversed, so no point in showing it now. Eventually I’ll animate a unique walk backwards with the character leaning away from the direction of travel.

So how does this work?

The high level view is that as previously mentioned, these are preprocessed frames of geometry, imported into UE4 as static meshes. The frames are stored in an array, and then a function loops through, swapping each mesh in and out with a bit of a delay in between.

Aesthetically, there’s still a bit of work to do here. For instance, as seen in the belt area there’s a bit of noise that needs touching up.

I am also not sure how I feel about the character’s proportions. I typically prefer a bit of a beefier style character, and to me his torso looks a little slim here.

As you can tell by the stationary floor pattern, the character isn’t actually going anywhere here; he’s just animating in place. Hooking this up as a controllable a character is a job and blog post for another day.

Comments on the blog are disabled, so probably best to direct feedback and questions to me over on the Twitter thread.

Thanks, and don’t forget to subscribe!

Voxel Animation Test

Well then.

This tweet seems to have blown up a bit, as did its counterpart on the Unreal Engine Developers Community over on Facebook.

The positive reception is quite nice to see, taking my misgivings regarding voxel graphics into account, not to mention the work that went into it.

I am very appreciative for all the interest and kind words, thank you.

There were a number of questions and a bit of speculation as to what we’re looking at here. I will go into more detail as to how I did it at a later date, but as stated in the original post, this is an early work in progress test of the frame based, voxel animation system I am working on in Unreal Engine.

And what does that mean exactly?

These are preprocessed, 3D frames of animation which were imported into UE4, where they were animated via a custom animation feature.

What this isn’t:

  • A post process material effect
  • Realtime voxelization
  • A Skinned and rigged mesh
  • Animated in MagicaVoxel

Good guesses though! And please: If anyone comes up with a performant realtime voxelization solution that does all the things I need, let me know immediately. The pipeline I have going right now is rough. The less work I have to do manually, the better. 😉

Thanks for reading, and please be sure to subscribe for notifications of new content!


I knew pretty early on in life that all I really ever wanted to do was make games. In fact, I distinctly recall the moment the idea cemented itself in my mind. The first time I saw Pitfall Harry jump on that vine and swing over those alligators, that was it: I wanted to design my own characters and bring them to life. I wanted to craft adventures for those characters to go on and make creatures for them to fight. Oh and they would need weapons too. Lots of weapons. Most likely swords. But some guns as well…

Through a lot of hard work, and no small measure of dumb luck, I eventually found myself employed as a game developer.

While I am incredibly fortunate to have been gainfully employed all these years, and I really do enjoy my day job, I somehow got off track. I’m not really doing what I set out to do. I find myself in need of a creative outlet.

I need to make games.

My games.

There are game mechanics I want build. There are cool and unique visual styles to explore, badass characters to create, and wild new worlds I want to share. This blog will serve as a chronicle of these experiments.

after regular business hours of course! I’m strictly talking about working on personal projects, yo. Bills still have to be paid and mouths still have to be fed, after all. I won’t be giving up the regular paycheck any time soon.

(I did that once already. But that’s a story for another post.)

So watch this space, and please subscribe for updates!