Working with Unreal Engine 4

Between 2014 and 2015 I was the only programmer in a small group of friends who worked on games in their spare time. Previously, we worked on Zeitgeist (I also made a post about it here), but after that didn’t work out, our plan was to make a medieval-swordfighting multiplayer game in Unreal Engine 4. Unfortunately, this game also went nowhere, but what can you expect when you have zero funding and no way to make game development your full-time job. Anyways, during the development of this game I became quite familiar with UE4, so I’m just going to present some more or less interesting things here.

Sword mechanics prototype

To nobody’s surprise, a medieval multiplayer game about melee fighting needed some sword mechanics. We didn’t think the Chivalry style or any other old left-click-your-opponents would work; instead, some fresh air was needed, although that would make game design much more challenging. In our prototype, you could do stabs and swings with swords. Thanks to animation blending, swings could be executed from any angle on the full 360° circle, and stabs could be performed in any direction in the field of view. Opponents had to block stabs and swings within a small time window. On a sucessful block, a small window for a counter attack opened.

We wanted to handle hit detection not by some approximation, but by actual contact between the sword and other players, so I wrote a robust collision detection system for swords. It kind of worked in a sweeping-a-bunch-of-raycasts manner plus some extra 3D math, to put it briefly.

I made some sort of blend between the classic FPS camera and a free cursor, as you can see in the videos below. It created a new and uncommon input scheme for this genre, which opened up some cool gameplay possibilities. Tuned correctly, it actually works fairly well, although it might feel weird at first. I’ve never seen this done before in any other game.

For networking, the back and forth attack-defending loop had to be carefully timed out with minimal overhead so that players would have enough time to react to attacks even with higher RTTs to the server. A successful defend could be predicted client-side for a quicker feedback but an attacker had to wait for the server response on the success of the opponends defend action; our strategy was to hold the exaggerated wind-up animation on the attackers client side until the response arrived and then play the respective animations.

None of this was ever completely fleshed out, but in our gameplay testing sessions the gameplay loop looked promising, and some fun was had. But of course, more iteration would’ve been needed for sure.

Sword collisions

I used my collision detection system in combination with inverse kinematics (IK) to have swords actually be stopped by collisions with other objects, characters and swords.

For the most part, this could’ve been used for creating more believable sword fights where the proper defense animations are selected and swords actually collided, but we never got this far. The largest challenge would’ve been to ensure swords actually connect regardless of the 3 degrees of freedom: swing angle, enemy distance and height difference (assuming during an attack both characters would always be oriented to face each other). It seemed ambitious at the time and still seems ambitious today. I wonder if this would’ve added much value to the game or if this would’ve just been overly technical and nothing more.

More technical art

I wrote a global snow shader, with a (probably typical) “steepness limit” for the surface normal and the ability to use vertex painting for manually editing snow density. As it turns out, making good looking snow is hard. I didn’t quite manage to get the results I wanted, but on the other hand I’m usually not an artist, so yeah. In the video clip below, you can also see a river, which is an experiment where I used the neat flow-maps technique introduced in Portal 2 and Left 4 Dead 2. Although I guess the clips I found don’t show anything but a constant flow map.