Once my vehicle racing prototype was acceptably polished, I turned back to Catalan, my 3D humanoid move-and-animate prototype, which had been thrown into unflatteringly sharp relief. The movement controls were a joke, and the boxman him(or her)self, though a heady achievement at the time, was looking increasingly limited. I had recently discovered the humanoid animation options within Unity, and had made some brief forays into working with the animation state machine systems provided, but I hadn’t been able to get the various pieces to cohere properly.
As luck would have it, around this time I was put in contact with a team working on some new projects in Unreal Engine 4. I had downloaded it when it went free, but apart from some perfunctory pokings-around it had sat un-launched on my hard drive since. I took the opportunity to crash-course it, and found myself really enjoying it in various intangible, quality-of-life type aspects. I wondered idly if it might mot be worth trying to re-create Catalan in Unreal, just to get a sense of the workflow, and to see whether some problems I was having with character animations in Unity might not clear up if I could get a different perspective on them. Soon enough I had Blender on one monitor and Unreal on another, and was re-making Boxman’s skeleton for what had to be the eighth or ninth time.
The above image shows the differences between my Unity skeleton (left) and my Unreal skeleton (right). One (arguable) improvement visible above is that for the Unreal remake I made discrete mesh boxes for the shoulders, elbows, ankles and knees, so that I could assign those vertices to the appropriate joints and hopefully get better deformation than I would without: these sophisticated animation tools are expecting to transform the topography of mesh surfaces with hundreds or thousands of reference points, and they can get a little stumped when presented with only a cube’s worth. The Unreal version of the skeleton also has an extra spine bone, which I initially didn’t find significant until I tried to do without, unexpectedly generating this spider-like creature with the legs above the arms:
The process of re-rigging involved a lot of staring intently at the UE4 Mannequin’s bones, then returning to Blender and tweaking my own version, then back again to compare. This was difficult enough in practice, but would have been impossible without a tool made freely and publicly available by an utter SAINT and BEAST named Lluis Garcia, who provides at the link a python Blender add-on that can (among other things) spawn a fully UE4 compliant reference skeleton along with a vertex-weighted reference mesh within Blender. This made the whole skeleton-conversion process immeasurably easier, as the Garcia armature lines up perfectly with the UE4 Mannequin, even including a suite of IK references that I haven’t begun to explore.
Getting the vertex groups for the new joints right also took a bit of trouble, for instance each forearm’s group had to include the upper half of the wrist box and the lower half of the elbow box, so the twisting and bending could map correctly to the skeletal joints. Without those mesh joint boxes being shared across two vertex groups, the mesh would try its best to figure out where I wanted it to bend but would end up splaying itself out like a slinky:
In the meantime I got my mind sorted on Blend Spaces, which use a very similar interface to Unity’s Blend Tree system. You have a 2D representation of two movement axes, you plant the animations you want at each intersection and it blends in real time as the values change. Below is Unity on the left, Unreal on the right, and it’s a good bet 90% of your proprietary in-house implementations are basically the same, because why re-invent the wheel? If it was good enough for Lara Croft and Marcus Fenix, then by gum it’s good enough for the Boxman.
Of course, these weren’t animations I cooked up myself, instead I used the walks and runs provided in various Unreal starter packages, using a process called Animation Retargeting. You first make sure the original mesh (in this case the UE4 Mannequin) is using one of the rigs that Unreal knows about (in this case the humanoid rig, with the extra spine bone). Then you just make sure your own skeleton is using the same rig, if necessary mapping the 1:1 equivalences from one skeleton to the other by hand, in the “Retarget Manager” window. As long as all your bones are more or less in the right place, you’ll get a more or less acceptable result. In this case, I was able to map some “military” animations onto my updated Unreal-friendly skeleton. I also learned how to create bone sockets, which allowed me to equip the player character with this charming Mauser:
Boy if there’s anything you can find plenty of on the internet, it’s 3D models of guns. I think we’re good on that score for a while.
Even though the gun can’t be fired yet, this is inarguably better than the version I was able to wring out of Unity… although to be fair I’ve been over the Blender pipeline many more times since then, and I could potentially have an easier time with the new engine regardless of which direction I was moving in. I’m going to stick with UE4 for at least a few weeks, I expect it shouldn’t take long to recreate the various other elements: terrain, ui, health/damage, etc., at which time I’ll switch the site version over from Unity to Unreal.
I’m not saying goodbye to Unity completely, I have a lot of fondness for it and attachment to it, and I hope to spend some time in a future post talking about both engines and my experiences learning each. I will throw a few general observations in here in advance of that: I’d say that generally Unreal is more invested in making sure you do things the “right way” in terms of OOP best practices, encapsulation, that sort of thing, although it doesn’t make it super obvious why it wants you to do certain things in its own way. If you’ve studied any OOP languages you’ll have a sense of what’s going on under the hood and adapt faster, but I wouldn’t want to get into it as my first experience in a game engine. Unity by contrast feels to me more like a big box of legos where you can just stick anything on wherever and it will just work most of the time. This is liberating in a lot of ways, but, like in so many other aspects of life, one may find that total freedom has hidden costs. I’ve made bad, sloppy organizational and hierarchical decisions in Unity projects that I’m now realizing wouldn’t even have been possible in Unreal, due to the tighter implicit structural control of the Unreal “way”. More on all this later, including too many words about Blueprints vs C# scripts.
For now, I’m going to try and get Unreal Catalan up to the low bar of Unity Catalan, provided I don’t get distracted in the meantime by the thousand shiny game new ideas these new workflows are conjuring forth from my fevered brow.