Category Archives: Art

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.








Composing the music for Ludus

In the first instance, it was suggested to attempt to write traditionally authentic historical music but the lack of bona fide material from the time coupled with my concern for its relevance to today’s audience encouraged me to explore a different route. The decision was made to combine authenticity with a more accessible ‘contemporary Hollywood sound’. I started by referencing historical musical sources to help define my instrumental palette and inform my musical decisions. I wanted to focus on writing strong melodies using instrumentation and musical language associated with the genre and time period I was writing in. I combined this methodology with contemporary stylistic decisions to create a traditional yet cinematic crossover.


We decided to write music that was culturally inspired by different geographical areas of the far reaching Roman Empire. From Hispania in the west, we went through Celtic Gaul to Britannia and Germania in the north. We then followed along the Macedonian province and the Greek Isles east through Thrace and Cilicia all the way to the Parthian border and then back along Aegyptus and Numidia. We decided to title the tracks in such a way that if someone looks up the titles, they will find some interesting piece of history from the region they are inspired by.


Whilst I was given a healthy amount of creative freedom I was also instructed for each genre to cover the 3 main themes of general tasking, action based and intrigue/plotting. Writing in so many different genres with which I had little experience, was a daunting yet fun challenge.

The other requirement for this prototype was to ensure that all of the music written for the game could interweave and loop at random. I made the decision to write everything in the same tempo and complimentary key signatures, keeping the development relatively linear yet at the same time ensuring there was enough variation in content, style and melody, to keep the listener interested.

Production wise, I used a combination of digitally sampled instruments and real live performances to make sure the recordings had enough realism. String sections were the most predominant instruments throughout most of the compositions and due to their nature it was vital the majority of them were recorded for real.

I have now spent over a year composing music for this project on and off. It has been a unique and interesting challenge and I like how it has encouraged me to explore and write in styles and genres I wouldn’t have necessarily written in otherwise.


As we mentioned in the previous blog-post we want to make Ludus very easily mod-able, and because we are a small team we need to make sure that the tools we create help us fill in the world as quickly and easily as possible. We decided that the most efficient way of making the world was to generate a part of it procedurally whenever practical. At the same time we want to maintain control over the design and make it as easy as possible to design new areas of the world, both for us and the modders. The system we came up with was kind of interesting so we wanted to share the thinking behind it in this blog-post.


This picture is all that’s needed to design the terrain for one of the levels in Ludus. but how does it work? Let’s break it down.


The red channel indicates the area where the buildings will be. We want to make sure that the ground here is relatively level, and we also artistically decided to slightly raise the ground just beyond where the buildings make contact with the ground. This channel is currently derived from the 3d placement of the buildings rather than the other way around, and only affects the terrain.


The green channel dictates the playable area, this is what should be accessible to the player, the system should make sure that this area looks and acts like a walkable terrain and that it doesn’t contain any overly steep inclines etc. It also helps indicate where to use most of the vertices of the terrain itself.


Finally the blue channel is used in the texturing process, it instructs the material to say that this area should be using a second blended material (specifically in the current case, this makes it a paved area, while the rest is sand, but this is set up in the material settings)


The image we had before is the final output of the ‘design’ image, All the modder/designer needs to define is there. This is then processed and combined in a procedural material from substance designer to output the image we see above. You can recognize some parts but others have come from procedural noise and various processes the image goes through to create a heightmap that is usable in the terrain generation in substance designer. The playable and building area is leveled out and raised, and a bit of height is added just around the buildings.


Each pixel in the procedural texture is scored by neighboring height difference and whether it’s in the playable area, and we create a vertex on each ‘important’ pixel. This makes sure that the vertex budget we have for the terrain is used in an optimized way. In the image above you can see the resulting mesh. Note that it uses fewer vertices on the flat areas and that the area defined as non-playable has a natural in-accessibility because of the steep inclide.
Lastly, similar to the Mosaic effect, we use Delaunay triangulation of these vertices to combine it into a mesh.

Although the coding and procedural material process to achieve this takes more time than making one or two terrain models, the ease with which we can add new areas, using a very broad-strokes method, to the game means we can make a much more interesting and expansive world. We intend to take the system further and add set dressing like barrels etc automatically based on the original image input as well.

Gladiart or Process

This is a short summary of the art process used in creating the armour sets in Ludus.

Beginning with some research into Roman style art and props, I took a trip to the British Museum. I was looking mainly at Roman relics and weapons/armour that were on display to get into the mood of that era.



To help aid with the visual background, Vegard had gone to a one day event organised by Britannia Gladiators and had taken many photos of the re-enactments of gladiator combat along with reference images for the armour. These got the ball rolling and I began to design some of the shields based on the photos.


The re-enactment team done an amazing job of re-creating designs of the era, so we piggy-backed on their hard work and based a lot of our designs on their physical armor sets. Here are a few of the 3d models for the shields created and textured based on those reference images.



The modelling process for the Gladiators started with high poly geometry done along with some digital sculpting in preparation for extracting a low-poly or game friendly version.


I worked by sculpting directly onto the basemesh and extracting the various parts for texturing on a per-part basis, which enabled more control of the final UV area of the complete armour set.

Part of the workflow was to divide the UV area into 4 areas that would enable the meshes to be recombined in the game at runtime to reduce draw calls.


After each part was sculpted and retopologised, they were given quick UVs to get started with the painting and texture generation. Here is an example of one of the arm padding unwraps that would later have its UVs moved and rebaked into the correct UV area.


As you can see the same normal map could then be rebaked to a new location by cloning the original mesh and moving its UVs. I used 3d Coat’s texture baking tool for the rebaking, assigning the original mesh to the scene with the original normal map and assigning the target mesh (the one with the new UVs). This process would prove useful if ever we had to alter the UV layout in the future for any particular reason.


So the Process was as follows: Sculpt the Highpoly mesh, create the Lowpoly geometry from the high poly and bake out a normal map using Xnormal, from here I took the low poly mesh and the normal map into Substance Designer/Knald to extract more useful texture maps such as AO, Cavity and Curvature maps.

In Ludus we are using Physically Based Rendering which requires us to create Diffuse, Specular Colour Maps and Roughness Maps. We chose the Specular and Roughness map approach over the Metalness/Roughness workflow, as we found it more straight forward and easy to read visually in Photoshop. We are using the Lux shaders for Unity that support this visual approach well.

Now that I have 2k textures for each part, I can go ahead and texture each part using Quixel suite:


Quixel suite allows for full control of edge wear, dirt trapped in occluded areas and most importantly the mega scan based materials.

I also created a few custom materials based on photos of various cloths and metals to aid in the process.


I created ID maps for all the different parts so the materials could easily be assigned in Quixel Suite and we could make easy adjustments to the final textures.

The ID map defines different materials on this wrist guard
One of my custom Brass metal materials

The greatest part of this process is messing around with various materials based of the ID’s, instant texturing has arrived!


With everything created and rebaked using this process we end up with the final texture maps and a new ID map based on the new UVs which is used on the final model.



Finally here is the full textured version of the Hoplomachus Armourset.



Ahhhhhhh Lalalalalalalala!


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.




Rendering crowd agents in Ludus


The trouble with rendering a lot of different looking characters is that they tend to require a lot of drawcalls. Normally when making a crowd, the way to do this is to combine several skinned meshes together into a single skinned mesh and then send this to the GPU as one mesh. For Ludus I wanted to draw a huge amount of characters in the crowd, with sufficient visual variety that they looked like a crowd of individuals as opposed to multiple copies. I also wanted to control their animation independently to display things like a mexican wave, and different other ‘multiple people doing the same thing’ type of motions.

I was thinking a bit about the kind of motions that the chinese olympic opening ceremony showed so well with lots of people doing something with a slight delay to eachother, but almost completely in synch. For example everyone holding up a card at the same time, or doing some arbitrary motion. There’s something very appealing with those motions because as synched up as they are, they are also subtly offset because however trained they are, there are always some minor differences in reaction time etc.


In order to do this I figured I needed to be able to control the animations of the characters individually, but still send it to the GPU in as few draw calls as possible.

Unity will try to dynamically batch any unskinned mesh together that is less than 900 vectors of complexity, including UV coordinates and normals. That leaves us with a budget of around 300 vertices + 300 uv coordinates + 300 normals. To achieve this while keeping the overall shape I first cut the body up into the major parts that I wanted to animate, used an automatic polygon reduction tool to hit the target vertex amount while maintaining the shape as much as possible.

Crowd mesh
Each major movable area is cut into it’s own model

Now animating the mesh only using these major areas instead of a skinned mesh, I can get enough animation fidelity for the crowd agents without using bones at all. Since the crowd is far away, there’s no way of seeing the bad interesctions etc, so even though the model parts are completely rigid, we don’t really percieve it as wrong from the distance we see them at.

Up close of course, the mesh is not sufficient, but as soon as it goes somewhat into the distance we stop paying attention to a lot of the details and start seeing the agents as a crowd.


When we look at a large crowd, the thing that affects us the most in terms of perceiving the characters as a group of individuals as opposed to a group of copies is colour.  Shape and animation are both secondary to this. We can easily see how big an impact this has on our perception by comparing the two images below.


In order for dynamic batching to work in a complex scene we have to make the rendering instruction as simple as possible. This means excluding the crowd from shadow computation, and basically using vertex colours as much as possible. I wrote a simple unlit vertex colored shader, and then computed on the CPU the shading of the characters per vertex at spawn time. This way we don’t need to compute anything substantial on the GPU. not even a dot product. So each character is vertex coloured using a random skin tone and their rest value normal dot product to the light forward direction.
This might seem strange as the characters move around their lighting is effectively baked in, but because of the distance and the multitude of characters, we don’t really perceive the ‘error’. In the end we save a huge amount of drawcalls using the dynamic batching method and can still maintain individual agents for animation purposes, and have about as many of them as our CPU can handle.

And here’s the final test from unity, 1200 individual crowd agents running in the editor on an Intel HD 4000 integrated graphics card.

And there you have it, dynamic draw call batching for use in crowds.


Procedural mosaic using Voronoi diagrams


I’m a big fan of procedurally created or assisted artwork. It’s something that’s both kind of complicated to do and makes for some unique and interesting variations in a game. In Ludus I wanted to be able to produce a procedural mosaic and then link this to the Player’s story. The idea was that after a particularly exciting match, a local artist NPC might come to the Player and ask if the Player would like to commission a special mosaic to commemorate the fight. This kind of decoration can then be used to impress people that come to visit the Ludus and is visible in game.

Now of course, this could have been just represented by some pre-made picture of two gladiators fighting, but I thought it would be much more interesting if it captured a real moment from the fight. So to do that, I decided the best way forward was to actually capture a frame from the 3d scene and see if I could get this to look like a mosaic.

First up, some inspiration:Gladiators-from-the-Zliten-mosaic-400

First I started by rendering just the characters and ignoring all the background layers with a special camera that is attached to the main camera into a texture.  Since most of the mosaic backgrounds I found are just a single colour with some random variation, we don’t need any of that information.


Then I tried doing a normal Voronoi diagram over this image. Just placing random points all over the size of the 2d texture, computing the Delaunay triangulation and drawing lines between each center point of the triangles.

After the lines were in place I sampled the rendered texture we had from earlier at the vertex where the random point in the voronoi diagram was, and performed a flood fill from there. If there was no alpha value in the rendered image, I instead picked a random colour.

Flood fill algorithm

This left a few areas unfilled because they happened to overlap with a  vertex that had also been shaded as a line, but otherwise gave the impression I was looking for, so I just pre-filled the computed pixels with one of the same colours as I was using for the background.


The effect wasn’t quite good enough, in particular I felt that the shape of the outline was a bit too blotchy compared with the real mosaics which usually have quite a strong outline, often re-inforced by an extra black line. I decided that I needed to draw an outline of the characters, so this would always be clearer. To do this I sampled the alpha values of the rendered image, and whenever it changed from its neighbours, it would draw a black outline on this pixel.


The second thing I noticed was that  I needed more ’tiles’ in the internal shape of the characters but this was wasted if distributed evenly everywhere on the image. I decided to change the algorithm for the initial random points of the Voronoi diagram so that instead of being completely random, each pixel was scored randomly but the score would increase if the alpha value was over 0.5, which meant that there would be more random points inside of the character, and thus more tiles used.  Mosaic2

So there you have it, prodecural mosaic, or at least as far as I got with it before having to move on to something else. One of the things I think is interesting here to link it further to gameplay, is that for example if you decide to commission the artist to make the mosaic, but give him less money than necessary, he can produce a mosaic with fewer tiles, giving less visual fidelity to the action.