Jan 30, 2023
Brigador: Up-Armored Edition - dudeglove
In this article a number of words are linked to Wikipedia’s glossary of computer graphics so that you can follow along without too much interruption.
Ironically, how we even make these sprites is initially by creating 3D models, typically through the process of kitbashing (this part of the process we won't go into, and we'll ignore animation rigging too, but feel free to check out this timelapse video for the Pantry Boy vehicle from several years ago that you may not have seen before) usually in 3DS Max. The part we're concerned with comes after a 3D model has been decimated, which is a process that reduces the size of the polygon mesh. Once this happens, we can give the mesh a texture map, which is the point where the model starts to more closely resemble the final product.
Before we do that we'll need UV maps first. A quick way to explain UV mapping is to imagine an animal that has been skinned: our 3D model is the animal and the skin that has been removed from it and can be laid flat is our UV map. Or if you refer to the cube below.
The program we'll use to do this to our 3D model is called Houdini.
To give our UV maps texture information what we then do is take them from Houdini along with the 3D model that was made in 3DS Max into another powerful program called Substance Painter that allows us to detail the materials of the model (for example, how rough a stone looks or how glossy a metallic surface is). We don't have footage of us working on Substance Painter but you can get a good idea of what it's capable of just by looking at this short official video that touches on a lot of what we've just written.
At this point we have crafted the shape of our model, peeled off its skin, given it materials to make it resemble the final object, and now we have to take it into a fourth program: Blender. Why we take the textured model into Blender is to do three things. The first is lighting, which we only do a little of. Blender allows us to influence the light-matter interaction, or how 3D models are illuminated – a process that is often referred to as baking. The second thing we do in addition to this is framing the 3D model from an angle of our choosing – in other words we recreate the same view frustrum that the player will see when playing Brigador. The third and final major thing in the Blender step is we also get depth buffer information, which tells us how far away the model is with respect to the camera's perspective.
This is where things start to get complicated. In addition, the purpose of the second sprite sheet is it provides z-depth information. The XML data that's outputted for both of these sprite sheets by SJSpritePacker is "pointer data" - this is information that tells the sprites to face the correct direction but before it can do so, it's fed into a .json file, which is the file type the game engine reads for the majority of the game's data.
Let’s use another example of how we both use pointer data and slip in an optimization while we’re at it. Here’s a gif of the Arlo agrav from Brigador at twice the usual zoom seemingly turning 360 degrees on the spot. Every single angle of this shot is its own individual sprite, but it is *not* a 3D model rotating in space despite appearances.
Within the game’s own data you’ll find rotations of the Arlo, aka spc_agrav_05. However, the sprites below only point to the right. Why? Because we mirror the left-hand side to save on those frames.
Meanwhile what the XML data itself looks like is a list of coordinates that tell which parts of the images above point to where.
Fun fact: at one point early on in development all of this data had to be manually inputted. Fortunately, our artists nowadays have scripts that export the required rotation data automatically.
So Brigador's not true 3D and yet visually the game still looks impressive - so what else is going on? Recall the sprite sheets from before that look black and white. Let's look at another one that's only ever seen at one rotation - the orbital cannon (AKA battery_01 in the game data).
The first variant of the orbital cannon you can think of as the diffuse version, while the second is the z-depth information visualized as a grayscale image (where the brightness can be considered as an indication of how close the model is to the camera). The purpose of the latter is to inform the lighting of the Brigador engine against the sprite, which you can see in the final version of the game itself.
Or in motion...
What should be apparent from the above image and the gif is there is additional lighting being displayed on the sprite itself. As it turns out, the Brigador engine is doing two specific things: deferred shading and with it dynamic lighting and this is what we've been building up to this whole time.
We encourage you to read up a little on both topics, because it's a rabbit hole of its own, though we will point out here how even for the mid-2010s, applying deferred shading and dynamic lighting to 3D models was a very expensive thing to do in terms of hardware... except we are not using 3D models in the engine! Remember: the sprites are fundamentally just two-dimensional quadrilateral shapes – they are not polygons where every facet would have to be lit properly and because we are able to decouple a scene's geometry from its lighting. Also, because we have the depth information from the z-depth sprite sheet in the XML data, this allows us to put in a bunch of lights into the levels without causing major performance hits and allows the engine to apply dynamic lighting to those sprites. Or, in other words, we can do things like this such as when the effects of an EMP wear off...
Or dynamically light up the player when they fire a railgun shot with the Zeus...
*This* is where the payoff is and why so many people have asked over the years “is this 3D?”. This might also prompt the question of why other developers don’t do this nowadays if it’s so visually effective. The main culprit is the games industry’s pursuit of graphical fidelity in the early 2000s, which meant most people moved on from sprites in favor of full 3D.
So, in summary:
While this is an image of the Touro at the doubled output resolution at 1x zoom.
...And together in the same scene within an early dev build of Brigador Killers.
We realize that this article may not end requests from people asking for different camera angles, but we hope players will be able to better enjoy a new level of detail that goes into each art asset in both our sequel and our current game. Speaking of which, Brigador is currently on sale.
https://store.steampowered.com/app/274500/
Thanks for reading.
[N.B. [i]This article is based on a previous newsletter from September 2021 and a Twitter thread on the same topic from June 2022[/i].]
👨🏫A BRIEF LESSON IN COMPUTER GRAPHICS
Often we get feedback from players who wish the camera in Brigador could be moved to see different angles of the various models of the vehicles or buildings seen in the environment. We don't wish to disappoint those players but within the game engine this isn't possible because what you are seeing rendered in the game is not a 3D model that can be rotated along any axis. Instead, what you are seeing are sprites (more specifically, you are looking at 2D quadrilateral shapes, and what you are also looking at right now is a flat, two-dimensional screen upon which is a moving image that can create the illusion of depth through particular techniques).Ironically, how we even make these sprites is initially by creating 3D models, typically through the process of kitbashing (this part of the process we won't go into, and we'll ignore animation rigging too, but feel free to check out this timelapse video for the Pantry Boy vehicle from several years ago that you may not have seen before) usually in 3DS Max. The part we're concerned with comes after a 3D model has been decimated, which is a process that reduces the size of the polygon mesh. Once this happens, we can give the mesh a texture map, which is the point where the model starts to more closely resemble the final product.
Before we do that we'll need UV maps first. A quick way to explain UV mapping is to imagine an animal that has been skinned: our 3D model is the animal and the skin that has been removed from it and can be laid flat is our UV map. Or if you refer to the cube below.
The program we'll use to do this to our 3D model is called Houdini.
To give our UV maps texture information what we then do is take them from Houdini along with the 3D model that was made in 3DS Max into another powerful program called Substance Painter that allows us to detail the materials of the model (for example, how rough a stone looks or how glossy a metallic surface is). We don't have footage of us working on Substance Painter but you can get a good idea of what it's capable of just by looking at this short official video that touches on a lot of what we've just written.
🔀FROM MODELS TO SPRITES
We said at the top that in the game you were technically looking at sprites, not 3D models. The basic reason for that is because the game engine is told to display sprites, which in turn spoofs the appearance of 3D models in an apparent isometric perspective. How we get from 3D models to sprites is via open source software – a version of which comes included with the Brigador Modkit & Map Editor called SJSpritePacker. What this does is takes the original 3D model and (depending on the model's level of detail) captures up to 64 rotations of all that model's positions and animations at a particular resolution and creates not one but two sheets of sprites along with the XML data for the sheets. Below you will see the sprite sheets for the loyalist infantry NPC (AKA loy_foot_01 AKA “Dave”), which if you own a copy of the game you can find in the folder Brigador\assets\units\loyalists\foot.This is where things start to get complicated. In addition, the purpose of the second sprite sheet is it provides z-depth information. The XML data that's outputted for both of these sprite sheets by SJSpritePacker is "pointer data" - this is information that tells the sprites to face the correct direction but before it can do so, it's fed into a .json file, which is the file type the game engine reads for the majority of the game's data.
Let’s use another example of how we both use pointer data and slip in an optimization while we’re at it. Here’s a gif of the Arlo agrav from Brigador at twice the usual zoom seemingly turning 360 degrees on the spot. Every single angle of this shot is its own individual sprite, but it is *not* a 3D model rotating in space despite appearances.
Within the game’s own data you’ll find rotations of the Arlo, aka spc_agrav_05. However, the sprites below only point to the right. Why? Because we mirror the left-hand side to save on those frames.
Meanwhile what the XML data itself looks like is a list of coordinates that tell which parts of the images above point to where.
Fun fact: at one point early on in development all of this data had to be manually inputted. Fortunately, our artists nowadays have scripts that export the required rotation data automatically.
🤔WAIT, WHY DOES IT LOOK 3D THEN?
Careful readers might be asking why did we go to all the trouble of putting together 3D models, give them detailed materials for their textures, bake in some lighting and not just use those models in the game instead? This question was asked many years ago and was finally answered around the winter of 2012. While Brigador does have a 3D look, it is not 3D. Games that are true 3D are extremely complicated because once you go 3D, now you really are in a situation where the player can view a model from every conceivable angle in a game's environment. Creating such a thing is a considerable undertaking for any studio's engineers and technical artists to deal with, who essentially have to figure out a way for models that are exported in a particular format to be understood by their game engine and also be optimal (i.e. not grind to a crawl and run at single digit FPS). In other words, everything we've talked about so far took five different programs alone: 3DS Max > Houdini > Substance Painter > Blender > SJSpritePacker – and that was only for 2D sprites. So, knowing this, and with respect to the amount of time, people, money and energy it would take to make a true 3D Brigador game, hopefully it's clearer now what some of the reasoning was for Brigador's look.So Brigador's not true 3D and yet visually the game still looks impressive - so what else is going on? Recall the sprite sheets from before that look black and white. Let's look at another one that's only ever seen at one rotation - the orbital cannon (AKA battery_01 in the game data).
The first variant of the orbital cannon you can think of as the diffuse version, while the second is the z-depth information visualized as a grayscale image (where the brightness can be considered as an indication of how close the model is to the camera). The purpose of the latter is to inform the lighting of the Brigador engine against the sprite, which you can see in the final version of the game itself.
Or in motion...
What should be apparent from the above image and the gif is there is additional lighting being displayed on the sprite itself. As it turns out, the Brigador engine is doing two specific things: deferred shading and with it dynamic lighting and this is what we've been building up to this whole time.
We encourage you to read up a little on both topics, because it's a rabbit hole of its own, though we will point out here how even for the mid-2010s, applying deferred shading and dynamic lighting to 3D models was a very expensive thing to do in terms of hardware... except we are not using 3D models in the engine! Remember: the sprites are fundamentally just two-dimensional quadrilateral shapes – they are not polygons where every facet would have to be lit properly and because we are able to decouple a scene's geometry from its lighting. Also, because we have the depth information from the z-depth sprite sheet in the XML data, this allows us to put in a bunch of lights into the levels without causing major performance hits and allows the engine to apply dynamic lighting to those sprites. Or, in other words, we can do things like this such as when the effects of an EMP wear off...
Or dynamically light up the player when they fire a railgun shot with the Zeus...
*This* is where the payoff is and why so many people have asked over the years “is this 3D?”. This might also prompt the question of why other developers don’t do this nowadays if it’s so visually effective. The main culprit is the games industry’s pursuit of graphical fidelity in the early 2000s, which meant most people moved on from sprites in favor of full 3D.
So, in summary:
- Nothing is 3D in Brigador – we make spritesheets out of 3D models instead
- Brigador's custom game engine draws 2D quadrilaterals on screen which are inexpensive to light
- Sprite z-depth information informs the lighting and helps spoof a sense of 3D despite the fixed isometric view
💭WHERE DO YOU GO FROM HERE?
What you've read so far is an abridged version of what goes into what you actually see on your screen when you play Brigador and why it looks the way it does. For our next game, Brigador Killers, what we are changing about the visuals is we are doubling the output resolution of all sprites from their 3D models. In the next two images you will see the first game's masthead Touro Loyalist mech. The first image is from Brigador with the camera set to a 3x zoom...While this is an image of the Touro at the doubled output resolution at 1x zoom.
...And together in the same scene within an early dev build of Brigador Killers.
We realize that this article may not end requests from people asking for different camera angles, but we hope players will be able to better enjoy a new level of detail that goes into each art asset in both our sequel and our current game. Speaking of which, Brigador is currently on sale.
https://store.steampowered.com/app/274500/
Thanks for reading.
[N.B. [i]This article is based on a previous newsletter from September 2021 and a Twitter thread on the same topic from June 2022[/i].]
Share: 
