Category Archives: Programming

Generating Gladiators

Some time ago now, we made a decision on Ludus which was a particularly tough call to make. We had been working on Ludus for a while, art, code and design all along side eachother. We had made economical decisions based on our scope and our minimal budget.

I’ve been working as a technical artist for 10 or so years now, so I have come to expect that expectations tend to change over the course of a production, but I somehow didn’t quite foresee that my own would change quite so much. Nevertheless, through habit more than clairvoyance, I knew things tend to change, and I knew that the best way of dealing with this is to always try to build a system that does whatever some job is, rather than focusing on doing the job itself.


So when it came to creating the characters, I set out making a system that would instead generate characters on my behalf from a set of models that had the same topology so that they could morph into each-other and consequently be mixed in any variation.

I started by grabbing some gladiator armor meshes from TurboSquid and Rob fitted them to a model exported from MakeHuman, then I exported some more characters of different shapes from MakeHuman to serve as the morph targets. I linked the bone positions to the vertex positions in the mesh so that I could correct the rig after morphing the vertices, and computed an automatic weight for the clothing meshes to follow the underlying geometry.

Character generator v1

The results seemed promising and after a while of ironing out some vertex order and other kinks we had a system that could produce characters of lots of different shapes and sizes. As you can see from some of the in-progress images below, this process was easy peasy lemon sqeezy.

We continued working with these models and preparing new gladiator armour models for them. Time passed by, and after a while we had quite a lot of art built around this system. But something wasn’t quite right; the model we used was from an earlier version of MakeHuman, and the base model itself had some slightly peculiar proportions. All the variations consequently just looked a bit off.


We made the call to change the base mesh, and with it, all the character art had to be altered as well. A tough call to make on a minimal budget. So I made another system, this one ripped some code from the character generator to morph all the clothing meshes into a new base pose, which we made by pushing the rig into a pose similar to the new character base mesh we had, and then refining the model somewhat using standard modeling tools.

Mesh refitting

Bar a few errant vertices that needed to be cleaned up by hand, this system was able to salvage most of the data.

Adding the new character and new rig to the old system was an immediate success as made evident by the image below.


After a bit of massaging (read: near complete rewrite) the system was able to produce some  plausible looking characters of many different shapes and sizes though, and we had improved the overall quality in the process without completely killing the art budget.


In the game, we have also tied the attributes of the characters to their visual appearance, so a generated character with a high strength value will look stronger, or a character with a high constitution appear more full bodied. After a little while of playing, you get quite good at judging the abilities of an opponent.








Spherical Spline Quaternions For Dummies

or: How I Learned To Stop Worrying And Embrace The Math

My artsy illustration degree was about as useful as a chocolate teapot in setting me up for my job as technical director.  When I read white papers, I feel dyslectic when looking at the wall of math and the academic wording. Now after some years of experience, I want to share some core code bits and understandings of the stuff that makes it possible to make pretty pictures, animations and games on the computer in a wording that I hope will be a bit more understandable than many of those white papers. First up: Spherical Spline Quaternion Interpolation or SQUAD for short.

chocolate teapot

What is it?
It’s a formula that makes it possible to smoothly go between a set of rotations.

Where would I use it?
If you were making some animation code where you wanted some 3d object to go through a set of keyframes of different rotations for example, ‘tweening’ smoothly.

What do I need to understand to use it?
A basic understanding of Quaternions helps, but mainly you need to know that:
– Quaternions are rotations
– They are different to Euler angles, but they don’t suffer from gimbal lock.
– They’re not as straightforward to understand as Euler angles and have different problems to Euler angles.
– If you try to visualize them, your head explodes.

How does it work?
Do you know splines / curves from animation programs or vector drawing programs? It’s a lot like that but in crazy quaternion space. The trick is that you need to compute something sensible as the tangents so that you can go smoothly through a bunch of keyframes.

What problem does it solve?
Normally, you might reasonably interpolate between Quaternions using SLerp (Spherical Linear Interpolation) or Lerp (Linear Interpolation) but if you’re going to go between more than two key rotations, these functions are visually to the surface of a sphere what a straight line is to a sheet of paper.

Let’s take a look at it visually. Here is a vector being rotated by SLerp through several rotations:


Although it’s smoothly interpolating in time, it’s not really affected by what the next quaternion after the current two is, so it just moves in a straight line from one quaternion to the next. If you have lots of keyframes this could still appear smooth, but with just a few spaced out ones, it doesn’t look smooth. Now let’s look at what this looks like with SQUAD interpolation:


Much better!  The rotations appear to be anticipating where it’s going to go next, and we get a smooth curve occuring on the surface of the sphere. These rotations are much more visually pleasing and we need a lot fewer keyframes to achieve a smooth looking motion.

Because it’s properly interpolating over all the different axis we can now get some interesting tangents by rotating the quaternions about the twist axis:


Unity Implementation
The unity project with source code and an example of use file can be downloaded here

Unity’s Quaternion class isn’t quite enough for to implement SQUAD, so we need to expand on that a bit first. The first script in the package below ( helps us extend the Quaternion class with functions that we need to complete the SQUAD calculations. Among other things we need a version of SLerp that’s a bit different to the SLerp method in Unity in that it doesn’t flip, as well as some basic things like scaling or adding to the Quaternion directly.

The second script ( contains the implementation of SQUAD itself. Looking at the code top down, our entry point might be something like the method Spline() with a number of quaternions that make up the spline, and a value t along that curve.

SplineSegment() returns the interpolated value between the 4 quaternions it’s operating on (the part it’s working on is the “line segment” between q1 and q2, the first and final quaternion are the previous and next quaternion after this line segment).

Intermediate() is the function that produces the nice and smooth tangent values between the rotations. There’s some magic stuff going on in there and I’ll let you play with the -0.25 value yourself. I’ll cover briefly what is happening but I don’t have a very deep understanding of why this works myself.
First it transforms the first and last quaternions by the inverse of the middle quaternion putting them in world space.
It then performs the quaternion Log function on them that we added in, adds them together, scales them by a magic number and performs quaternion Exp before transforming them back into the space of the middle quaternion and normalizing the Quaternion.

SQUAD() is then called on q1 and q2 with the two tangent values we got from Intermediate().  This is where we need to use the SlerpNoInvert() method we added to the Quaternion class. If we just use the Slerp() function from Unity there will come a point where unity clamps the domain of the Quaternion which basically looks like our poor vector travels through interdimensional space and ends up in some completely different place in our puny 3 dimensional world.

Special thanks to Pekka Kytölä for helping me learn this.

Mod-ern game development

Making a game properly mod-able and data driven is something one should make a decision about early on because it impacts so much of the structure of the code and data. In our case with Ludus we decided that the mod-ability would be a  key focus both because we are interested in what players will do with it and because we want to be able to easily extend the game without having to re-work things at the core of the code-base. Keeping things easy to change is hugely important when projects grow into a larger scope. It also forces us to drive a bit of a wedge between data and the core systems that process that data in a good way.


We use a number of external tools when developing the game such as Chat mapper (A great non linear dialogue editor with Lua support) and a whole host of graphics programs. Unity’s general approach to data loading at runtime is to have ‘asset bundles’ but this would require that the asset are first opened by the modder in Unity Pro (a paid license) and then turned into asset bundles one by one. We instead wanted to use more open, easily editable file formats that can be edited by standard programs for its data type, and also be editable using only cost free software so we don’t place any extra cost on people who would want to mod the game.

Helpfully, Unity comes with a ‘StreamingAssets’ folder which doesn’t get compressed when built, so we have an easy place to put any files that we want to ship with the game, and in doing so providing a great example of how to create content for the game for the modders since that is also where we store most of our own data. We make extensive use of this folder and have made several simple file loaders in the game to deal with each type of data. The data ranges from simple things like weapon attributes and character names to more extensive data like dialogue files, scripts and graphics.

The ‘Gladius’ equipment folder containing all the information needed to load the sword in game.

The image above is a typical data folder as we have it right now. The game knows to look in the Equipment folder any time it needs to load (Surprise!) equipment data into the game, and all the file types are easily editable. The .obj file for the mesh can be edited in any 3d program, the stats/attributes and descriptions can be opened in any text editor, and the diffuse, normal and specular maps can be opened in regular image editors. The folder contains everything the game needs to know about the piece of equipment, and can be copied and renamed to make a new version of the Gladius.

The equipment stats and other small data are done as easily readable .txt files with key-value pairs.

Luckily there isn’t anyone in the executive, legal or marketing departments that have thrown a fit about us openly sharing the raw content from our game with the players, mostly because those departments don’t exist, so we will most likely share all this content under the CC by NC license.

One of the issues of making the game so mod-able is the impact it has on performance and this is a compromise we have to work with. Luckily since we made the choice to make it mod-able early on, we could have this and other pit-falls in mind from the start and do some things to mitigate this such as compiling new assets automatically and thereby loading them faster next time.


Prototypeception – A Prototype Within a Prototype

Since I joined the team we have been working hard towards a prototype that we can start showing off to people and iterate on. The plan is to have something usable by early next year. The codebase I was given was mostly made up of  concept code written by Vegard that only he could understand and use to describe what should happen in the various, cryptic scenes which showed nothing but numbers on a blue background.

One of the systems I’ve been reworking is the fighting system. Currently it is only a simple DnD D20 style system with modified rules that changes the way health and critical strikes work by using hitpoints and vitality (or as the original document calls them: vitality and wound points). In short: regular hits consume hitpoints, when all of the hitpoints are depleated you start losing vitality points, when all of the vitality points are gone, you are defeated – if a critical strike happens, damage skips hitpoints and goes directly to vitality.

The fighting system is completely independent of whatever you display on the screen, this gives us flexibility to try out different ways to present the fights to the player, without having to modify how the underlying system operates. In the beginning, the only visualization I had created for myself looked like this:


Note the intense effort I put in to change the default background color of Unity. This does not look like much but everything we needed was there, the gladiators were generated randomly and we could observe how different stats provided different advantages in fights.

A quick rundown of the interface: you don’t actually control any of the gladiators directly, the game is about managing gladiators after all, not playing as one. In the current state, the only input you have on the fight is the intensity of the fight. Basically, the gladiators go at each other for a few hits, then they stop, giving you an opportunity to shout instructions on how they should fight. If they fight with a high intensity they do more damage and the audience also gets more excited. If they take it easy the audience will find it less interesting but you also don’t risk exhausting – or even killing one of your gladiators. The gladiators are not equally good at taking instructions, it is based on both your and the gladiator’s stats. In some cases, the gladiator will even do the opposite of what you asked them.

The next step was to build a more stimulating interface for the system. I started by taking the animations that Vegard had been working on and making it possible to trigger them from code. I also grabbed the crowd agents and some colour correction from previous scenes and  with a little effort, I had something that was looking like this:


Sometime around this point I had the idea of trying to set a milestone for making a prototype that we could show off on the London Indies Pub Night in December, which was about one and a half week away. The other guys liked the idea so we decided to go for it.

Of course, just standing on a regular boring plane with the crowd just cheering normally isn’t fun enough. So I picked a random texture laying around (that had nothing to do with ground) and slapped it on there and made the crowd do a wave. Just for fun!


These strange naked manequinn men fighting in pink space was pretty interesting to view but the time had come to put some actual gladiator meshes in there. At this point I had also added the hitpoint and vitality bars instead of showing numbers:


At this point it was also less necessary to display character attributes on the screen since a lot of them show quite well in the generated character mesh. For example if they are stronger and have a higher constitution they will appear larger than weaker gladiators.

After this I added sliders for controlling intensity as well as stamina bars. Following that I put the arena in there with proper ground, changed sky color and some tweaks until we had something that was pretty displayable for the pub night:


Note that during this entire time, the underlying fight system was always the same as the pink – text on the screen – interface in the first screenshot. This type of software design can be very practical in that it lets you swap the presentation layer without changing the logic of the system it’s running underneath.

Now for us, this is far, far from what we want the final product to be. But even this got quite a good reception and got people excited about seeing the game progressing forward. Having a nice milestone like this allowed us to narrow down just the things we needed to meet our “deadline”. It helped us avoid unnecessary yak shaving and reveal what yaks needs to be shaven the most after showing off the prototype. We can also move on to other components of the game such as the roleplaying aspects, knowing that we already have a placeholder for fight resolution that we can iterate on later.

What you should take away from this article is just how useful (sluggish?) it is to set up moderately sized, achievable goals, which, as a bonus, can be used as a nice ice breaker to talk about your game and what it will be while still coming off as credible. It will hopefully keep you from over-engineering systems that you don’t yet know what they should be and make quick decisions that will do for now.

At the very least, you will hopefully experience fun moments where your game displays funny or interesting behaviour. A lot of accidentally artsy screenshots were taken during the development of this prototype . Some of them you can enjoy below.





In Ludus we are trying to make the code completely modular, so all the systems exist on their own with as few dependencies as possible. The systems fetch all their information from the world, process it, and then put the information back into the world instead of sending information around to different systems.

We don’t have too many things in the architecture that we are strict about but this part is important because we want to be able to replace and improve the systems independently without affecting too much of the code-base.  The bigger the code base becomes and the more sub-systems that are put into the simulation, the more important it becomes to be able to work on something without breaking something else. It also helps make it easier to implement and debug just one aspect of the game, and also means by serializing just one class we can save and load everything we need simply by ‘saving the world’.


In our case, the world object currently keeps track of only a handful of primary things:
-The characters in the world.
-The relationship between those characters.
-The upcoming set of gladiator games.
-The active rumours in the world.
It also has a bunch of helper methods to for example find a character with a certain profession or to get the asymmetrical relationship between two characters (I like you but you don’t necessarily like me).

Almost all the characters in our game are generated at runtime and as I mentioned are stored as data in the world object. The world object is persistent between the scenes and so when we for example need to load the slave trader into the market scene, we first use a simple proxy object to place the character visually in the level editor. The proxy object has a little replacement script on it that finds the world object and requests any character in the world that fits the description, in this case: the occupation ‘slave trader’.  The world object finds the most appropriate character or generates a new one with the required properties so the important professions will always available in the game. This is extra important because in our dynamically changing world with senators vying for position and fighting out personal vendettas, some of them have a tendency to lose their heads, both figuratively and literally. In other words, if something unfortunate has befallen Quintus the slave trader; Julia, whom just so happened to recently move here from Aegyptus, will be there to replace his function in the game. She may not be as friendly on the prices, but she’s got a keen eye for gladiator talent and you can start a brand new professional relationship with her. That’s a good thing  because Quintus had been getting on your nerves and that was why you told everyone he was sleeping with the magistrate’s wife .

Quintus gets replaced by a more favorable Julia.
Quintus position has become untenable and he gets replaced by the more favorable Julia.

As you trade and talk with this new character, the state of your relationship is updated from the conversation system to and from the world object, but the character placement system only knows that there has to be a character in this 3D position with the occupation ‘slave trader’ and the corresponding conversation trigger on it.

Now a small anecdote which originally lead to this blogpost:
Upon realizing that I needed to store all the things in the world in some way, I adapted the already existing inventory system to use as a kind of world state for the prototype. Gradually I added more things and realized I needed to store arrays of characters in there. This lead to conceptually peculiar parts of the code-base like Inventory.AddSlave() and Inventory.GetCharacter(occupation as string). The principle of idea of the world object was good though, and it’s still called Inventory in the codebase.