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.


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.