Brigador Killers News

For this month we’re going to explain how the Brigador Killers engine handles the emission of gib sprites from entities during gameplay. In other words, this.


We’ve established in previous news posts that all you’re looking at on screen are flat 2D sprites and that BK’s systems can overlap in interesting ways to create unexpected outcomes, but we haven’t touched on the data end of these things.

First off, to save on space, both the Brigador and the BK engine store all assets in a large collection of compressed data called a pack file which has the exciting name of assets.pack. By using the game’s debug panel, we can look up these assets via the Pack file tab. At time of writing there are roughly 19 thousand assets categorized into 60+ different “resources”. Sometimes these assets are .png image files (such as the various sprite sheets for all the building props and characters) but a large portion of them are JSON files which allow us to specify the values of all sorts of various things in a human readable manner. Most of the screenshots in this post are of the game’s debug panel, which is a version of Dear Imgui that among other things allows us to look up and iterate on data values during a game’s runtime without having to make a new build of the game.


The JSON for a specific unit can be made up of several JSONs itself. For instance, let’s look at foot_loy_bd_01.json, which is the JSON file for a typical enemy infantry unit, and which turns out to be made out of a lot of JSONs.


The keen of eye will notice that, yes, infantry in Brigador Killers are all technically mechs behind the scenes - anything in assets/data/vics/units is a mech, be it the player in a carmine suit or an NPC-controlled forklift truck. This is just how the game data is organized. From this list of JSONs, we want to inspect the unit’s salvage, which is a file called salvage_foot_01.json.


Here you can see not only even more JSONs attached to this one, but also the types of values that can be assigned to its salvage “hulk”. A unit’s “hulk” is what is left over after its health has been fully depleted. Vehicles that have been destroyed will leave a wreck, which is usually just the top part of the same model but desaturated to give the appearance of burned out armor. From the above menu most of the values are set to zero, as the hulk left over is for a body instead of a chunk of metal, but for purposes of player reactivity, hulks will still have some amount of health. Tangentially, infantry units as seen from the opening GIF will go through a series of animations as they are being attacked, which is not handled in this menu - that’s part of what’s called Flinch, Suppression, Flop and Weapon Stability, which looks like this:


Getting back to the gib sprites, we look at what’s assigned for the on_damage_pyro, which is pyro_blood_mist_01.json, which is emitted by infantry-type NPCs and is a pyro-type resource.


Within that JSON we look for the gibs assigned to that pyro, which leads us to gibs_blood_mist_01.json. Explosion layers and lights are for “bigger” pyro effects. For instance, a gas station blowing up will need a fireball attached. Three layers down we have arrived at the resource that handles the attributes of blood sprites that an infantry NPC will emit on receiving damage: gibs_blood_mist_01.json


Here we can see what type of sprite has been assigned and how the animation for that sprite is set to play. We also get to decide how many blood mist sprays shoot out from the unit and at what speed, height, angle etc. These numbers are kept low for infantry gibs but, if we want to get silly, we can crank the numbers up and end up with something like this.


Again, the use case for more flamboyant gibs would be the destruction of a bigger entity like a heavy vehicle or a building prop that will have their own pyro and gib effects. Note again like in the first GIF at the top of the post an entity will do more than just shoot out a blood mist spray - just like a practical effect in movies, a “squib” also plays out to leave a blood stain on the ground. But unlike movie FX, we have to account for more situations than a carefully staged scene. Therefore one of the many other things to bear in mind with making these gib effects is that they have to have different “spreads” depending on what caused the hit. Here for instance is what happens if we put a bunch of infantry NPCs in a straight line and attempt to drive a heavy caliber round through them.


On top of the fireball explosion sprite and the bloom of light for the explosive bullet, you’ll notice that there’s some uniformity to the ground spatter. This is because the sprites will only shoot out from an entity a limited number of ways. It would be too expensive (and a waste of time) to have our artists render out every single possible angle. Instead, the hope is that the gibs are done in just enough ways that the player fantasy is maintained.

Thanks for reading, and happy halloween!

We’ve mentioned that one of the criticisms the original Brigador frequently received is along the lines of “Cool mechs, but what else is there to do?” If you haven’t been following our development updates since they began, part of what we’re doing as a response to this is adding elements of progression like acquiring unlocks within a map, rather than the previous system of spending money in a menu outside of the action. What we haven’t talked about yet is how Brigador Killers is presenting the narrative - and yes, modders will have access to these tools.

(By the way, whoever is responsible for looking after the TVTropes page for Brigador - your efforts have not gone unnoticed and we appreciate those of you who spent the time piecing together that game’s story.)



Brigador Killers will have narrative systems, including dialogue. They are heavily inspired by Emily Short’s article “Storylets, You Want Them” and Elan Ruskin’s article “Dialog” in Procedural Storytelling in Game Design (eds. Tanya X. Short, Tarn Adams), which describes the contextual dialogue systems in Left 4 Dead. The overarching system is made up of four overlapping narrative systems: storylets, predicates, the gvar (or "global variable") editor and a library of Lua functions. Note well: what we’re showing off is a work in progress, and both the systems and UI elements will change, particularly the debug panel.

[h2]WHY THESE SYSTEMS?[/h2]

As Emily Short describes in her blog, there are three attributes that make up a storylet:

1. A piece of content
   
2. A set of conditions that determine when the storylet can play
   
3. A set of changes that happen to the world state after the storylet is completed.
   

Why do this, and not just a “normal” dialogue system? For one thing, we didn’t just want a dialogue system. This system of storylets and qualities gives us far more flexibility to describe a changing world and react to the player’s actions. On Brigador, we freed the player from some level design constraints by implementing completely destructible environments; on Brigador Killers, we want to do the same thing with our storytelling.

Storylets enable us to write reactive “chunks” that respond to the player’s decisions and behaviour. Let’s say that you have intel on a Betushka that you want to steal. In a traditional model, we’d simply set a flag saying that you unlocked the Betka and dialogue trees would have variations to account for that flag. Using a storylet model not only allows us to track whether you steal it, but also how you steal it. Rather than accounting for flags within complex trees, we can (following from Left 4 Dead’s contextual systems) write reactions for various NPCs based on the “stolen Betushka” quality assigned to the player. Qualities are like a flag, but with more semantic information. Where Left 4 Dead's characters react to the world around you in an FPS, Brigador Killers’ characters will react to the story-world of the player’s actions.

Not only that, storylets and qualities can be used to affect the game state on a local, per-map level, as well as on a global, game-wide level. They are not just a means to make NPCs interactive on a map, though we can do precisely that. Let’s say we set down two NPCs that when we interact with them, a text box will appear.


If we interact with the NPC on the left, their text box is a simple introduction. If we interact with the NPC on the right instead, we can have them ask the player if they spoke to the first person.


And as a part of that chain of dialog we can have the first NPC chime in on the conversation


And if we wanted to do the same thing for both NPCs, we can do exactly that.


A system like this is appropriate for the needs of BK because we have player reactivity in mind for the design of the game. Put another way, if presented with a choice of left or right, we want the player to be able to select either one and still be able to advance, and not be required to speak to the “correct” NPC. Indeed, the player could just as easily choose to not speak to any of these NPCs. They might ignore them entirely, or the NPCs might have been spooked into running away because of a gunfight across the map, or an explosion might have killed them before giving the player the chance to talk to them. We can factor all of this in with such a narrative system. Better still, we can continuously add new content to this system without breaking existing “chunks”.

Here’s how a basic dialogue box is created in the game. In the game’s debug panel we click the Show Dialogue Editor button in the Main tab.


This opens up another window called the node editor, which looks like this. Node graph editors have been seen elsewhere, like Unreal Engine’s visual scripting system. We use the imnodes extension to Omar Cornut’s excellent Dear IMGUI library.


When we click Add dialogue storylet, a box containing several fields appears on the node graph for us to fill out. A functional storylet would look like this:


Interacting with the NPC will prompt a text box to display “Hi I am Tester 1”. If we want an interaction to display a sequence of text boxes, the node graph editor would look like this.


So if we want the text boxes to go “Hi I am Tester 1” and then “Did you speak to Tester 2 yet?”, we add the name of that second storylet to the response field of the first one. When we do that, the interaction will produce two text boxes in sequence on screen.

Lastly, in order to assign these speakers, we need to use Tiled - the open source program we use to make maps - to give these NPCs names in their properties, because this is how the storylets system knows who is a speaker, even if multiple versions of the same NPC are populating a map.


But it’s trivial to display text on screen after hitting an interact key next to an entity. How do we make things more interesting?

[h2]COMPLEXITY THROUGH CONDITIONS[/h2]

The three other narrative systems are predicates, the gvar editor and Lua functions. You might have spied the Show Predicates Window button in an earlier screenshot. Clicking it shows us the window.

What is a predicate, you ask? A predicate is just an expression that evaluates to true or false.


What appears is a list of all existing predicates currently in the game. This window also serves as the predicate editor. Predicates can be considered the conditions that can be applied to a dialogue storylet in order for the dialog storylet to “play”. For example, if the player has done a specific action, like having talked to another NPC or completed an objective, this can be queried through a predicate.

Let’s say one NPC can have two storylets with the same predicate but with two forms: one of those forms says gvar.rescued_norman == true and the other says gvar.rescued_norman == false. This “gvar” part is a global variable which is a thing tracking the overall state or “world quality” of the game. If the player has rescued Norman, then the first storylet will play because the predicate has determined based on the gvar that Norman was rescued. If the player left Norman to his fate, then the second storylet will play.


Before you ask, yes, predicates can be nested within other predicates and we can make the Norman example more complicated. Maybe we have a gvar like gvar.alive_norman which is tracking whether Norman is alive or dead, not just whether the player rescued Norman or not. In this case we can have four potential predicate outcomes.


These gvars can be a simple true/false statement, or take on the form of a number or a string. The gvar editor within the game lets us decide what form these things take. It’s also not limited to NPCs either. This system lets us express complex situations by responding to simple tests. It’s easier to keep track of, for designers, and easier to reason about, for programmers and modders.

[h2]ONE MAP, MANY OUTCOMES[/h2]

When a level loads up, the game engine checks the gvars and mvars (or map variables) for what to load within that level. When we make maps in Tiled, we can populate that map with whatever we want it to display according to the current quality state of the game (instead of having to make multiple versions of the same map to accommodate different outcomes which would be extremely tedious for our level designers). Any entity, like a building prop or an armored vehicle containing a full squad of tac-suited mercenaries, could appear, so long as they have been placed in Tiled and have been given the necessary labeling.

Last of the four narrative systems are Lua functions. Lua functions either modify the game state or are bound to game code. They can be applied to storylets to generate an outcome of some kind. For example, when a certain enemy spawns and initiates dialogue, we can use Lua callbacks to play a particular music track or sound cue. They can pause or unpause the game, spawn units, set or complete objectives… and eventually, much more.

Note that this is not full on scripting in the sense that we’re not putting a programming language into the game. Doing that would open the door for all kinds of malicious activity. While Lua is a programming language, what we’re putting in the game is more like a lesser version of Papyrus, Bethesda’s in-house scripting language. It’s a set of predefined functions that we make available to designers and modders. We’ll go into more depth on that later.

Combined, these systems massively expand our options as designers; we’re no longer limited to hard-coded objectives and mech spawns, and we gain a huge amount of flexibility and iteration speed. The tradeoff, well—we spent most of this year on these systems. What we’re hoping, though, is that we can pass on that flexibility and massively expanded set of options to the player. Players who come in to Brigador Killers expecting the limited-by-comparison playspace of Brigador are in for a pleasant surprise. Thanks for reading.

[h2]WIN SOME MINIATURES BY PAINTING MINIATURES[/h2]

We are currently holding the Olive Drab Everything painting contest on our discord server. The theme is “Brigador” - do with that what you will - all we ask is that submitted minis be painted. Painted minis do not need to be official Stellar Jockeys pewter figurines – if you have kitbashed a Brigador vehicle of your own, or 3D printed a Touro you are eligible. Winners will get to choose one of the new sets of minis that are coming to our merch store later next month. The contest will be taking submissions until approximately 23:00 PST on Monday October 9 2023. Check the pinned message in the #olive-drab-everything channel for the full details

Lastly, our first game Brigador is currently on sale as part of the Steam SHMUP Fest. If you’d like to support our development for BK, tell a friend?

https://store.steampowered.com/app/274500/Brigador_UpArmored_Edition/

Courtesy of our lead artist, August's post is a look into the design of an armored vehicle belonging to NOSPOL, which is one of the enemy factions you'll be facing off against in Brigador Killers. Without further ado...



Brigador Killers deals in part with the question of militarized police and police violence. How to approach this in the design and presentation of the world of Mar Nosso and its inhabitants? It is not enough to present to the player an MRAP [Editor's note: Mine-Resistant Ambush Protected vehicle] with police badging. While obscene, absurd, it is also perfectly ordinary to Americans. We are inured to it.

So, the initial point of departure for the SWAT vehicle was to go back to the source: the Los Angeles Police Department and their SWAT Team. This department’s escalation of weapons, tactics, and equipment would I believe set the template for militarized police presence in America for years to come.

Which brought me to the Cadillac Gauge V100/Commando:


While iconic and fitting for the technical restrictions of our engine (wheeled vehicles can only have four wheels), we run into a similar problem as the MRAP: too many associations, many of them positive. The player can’t “see it with new eyes,” which to us is one of the crucial aspects of good science fiction.

So we’ll shift to an older, and much more loaded point of departure: German wartime armored cars.

British soldiers inspecting a captured Sd.Kfz. 222, North Africa, 1941 (Wikipedia)

While the associations vary, the baggage is unquestionable. WW2 German hardware should be unambiguous enough of a reference. Not so simple! German wartime hardware is the background radiation of popular cultural designs in film and videogames for decades, everything from Star Wars to Killzone. These design elements are powerful, but so much so they can easily overwhelm your own design intention and muddy your intended comment.

Another particular difficulty with referencing German wartime designs is that one can end up on footing to that of say, Jin Roh – where the loving depiction of German wartime arms and armor could be read as uncritical devotion. This is not what we mean to suggest with NOSPOL, the corrupt and gang-ridden police force you face in Brigador Killers.

Early on, I switched from the Cadillac Gauge basis to this idea of roughly approximating the Sd.Kfz 222. I wanted to echo the angular hull shapes, but the overall design shouldn’t map too closely to any original wartime design. Rather, I wanted to design my own vehicle to invoke, rather than recreate a wartime vehicle explicitly that might distract or muddy the player’s read for the vehicle.

Again, let’s have the player see it “with fresh eyes”. There are myriad other pitfalls with fascist police force design. Travel too far in a given direction and you retread others’ work, like Viktor Antonov’s brilliant Combine APC design for example was something I wanted to avoid.

The best way to do this was to design the vehicle in a way that made sense to how NOSPOL might commission the vehicle in the setting: a retrofit from an existing truck chassis.

I had this Russian tanker truck model on hand. Perfect!


“But it’s Russian, not German, how is that helping your association?” Good question. Just as with the Loyalist military gear was largely but not exclusively Russian in origin, we don’t want any one single source. When the viewer sees a design that is by turns subtly heterogenous in character it’s my theory that it aids in, to introduce a metaphor, slower digestion.

An obvious design is like a piece of candy–it can be very sweet, but it’s gone and eaten quickly without a second thought and without a lasting impression. We want this design to be somewhat… chewier. More complex flavor notes. We want the taster to think about what flavors strike the palate.

So we begin from a Russian truck chassis to execute a German influenced armored hull design to talk about American militarized police. Simple enough, right?

Let’s chop off the back wheels and introduce a magenta box to remind us of the package space required by the engine. Whatever else goes on in the design, we’re going to need ample clearance to house the engine.

While we’re at it, I quite like those big, high clearance front fenders. Let’s turn them around and put them over the rear wheels.


Now we’re getting somewhere. We haven’t really had to design anything yet, actually–but by using a real world truck, notice how confident and realistic the scale read is. Provided we keep it consistent with our chassis here, the scale read will be more or less an automatic bonus, and will keep our work from getting too outlandish.

[Side note: one such problem that science fiction designs from scratch will run into is that when designing a ground car the designer fails to take into account the legal width limits for road legal vehicles. While military machines can be bigger, they are also still expected to travel on the confines of established road infrastructure. Get those dimensions dialed in first and you’ll get a lot “for free”.]

All we need to do now is start fitting an angular hull on top of this chassis, while still keeping in mind our other core requirements. How many people can it hold? Where does the driver sit? Does the armored car actually have a front and back driver, as some armored cars did? What engine limitations for a sprite-based and isometric game do we need to cater to?


In the interest of time we’re not going to walk through the rest of the design in detail, but with the major hull shape established, much of the rest would be about adding the hull detailing consistent with armored vehicles, stowage, searchlights, etc. Once we’ve got our goal in mind for this design there’s not a lot of quibbling over different shapes and thumbnailing different looks–one of the great pleasures of independent game development is that we can dispense with a lot of tiresome Art Director behavior most of the time.

Here’s the finished render of the armored car, in two flavors. First we see it as it will first appear to the player:


Beyond the police colors, something that always distinguishes overenthusiastic purchase of surplus military equipment by police departments in America and the former military service these vehicles saw is plainly their role. In the military, an armored vehicle is maintained but often subject to a lot of wear and tear. Once an MRAP is back home in America, emblazoned in SWAT livery, it seldom has to “work”. Its purpose is intimidation and peacocking for the department by and large. This is the initial guise I wanted to see the SWAT armored car deploy in BK as. A little “underdressed” compared to its military companions, seen elsewhere in the game.

Then, as the game progresses, and the player’s fight against the Concerns and their attendant police and mercenary forces intensify, updates and changes are made. Even a SWAT vehicle is forced to “work” under something more akin to active combat conditions. It needs to keep ammunition and fuel and spare tires with it.


It might even need to get semi-improvised slat armor for the wheels, a repeated weak point for ambush attacks from the player character (or other parties?). We highlight for the player that the slat armor is definitely newer by giving it fresh, dark paint compared to the more sunfaded exterior of the main hull.

Hopefully you’ll agree that at least some of the above is more than bluster and the design principles as established are borne out in the final design, and that the up-armored variant makes it clear to the player that the fight is escalating. See you, killer.


Stay appraised of news about Brigador Killers development by wishlisting and following the game.

https://store.steampowered.com/app/903930/Brigador_Killers/

A while ago we revealed that one of the big visual differences between Brigador Killers and the previous game is the increased output resolution of sprites. This increase in fidelity means you the player will get a closer look at exported models in-game. If you'd like a longer read on the topic of how these models become sprites then consider reading this other article from Brigador's news hub.

Getting a closer look means we get to focus on the infantry scale of things. In that spirit, we're going to run you through how an all-new spacer suit for Brigador Killers goes from concept to final sprite render.


The first step is what's called the mood board. This is the conceptual framework where the artist references the mood, texture and detailing that we want to evoke with the spacer power suit.



Step two is the adapt or "kitbash" stage. Seeing as we've already developed a powersuit for Clade Vocc (not pictured), in 3DSMax, we extrapolate a suit design to help suggest how mainline spacers are still related, though considerably drifted away from in both culture and military doctrine.



The third step is the paintover in photoshop. With a basic suit layout in hand, we think about how we are going to change and treat the design. Returning briefly to the mood board's astronaut references, we decide on a cloth-covered suit. At this stage the helmet is unsatisfactory, but that will get revised later.



Once we have arrived at a satisfactory model of the suit, the finished design is then broken down into components for baking down and then texturing in Substance Painter. The final sprite render shown in the bottom right corner of the above image is done in Blender. Here is the finished suit as a render (click here to open a full size version in your browser).



As a bonus, a scene was composed using the model of this new spacer powersuit, which was used as the header image for this article. You can get a wallpaper sized version by clicking here, with deference to American digital painter Craig Mullins for this piece.



This post was based on one of our monthly newsletters that was sent out back in March 2022. Click here if you’d like to check out our newsletter archive.

For June 2023 we are (very briefly) showing off one of the major new features for Brigador Killers, which we're calling map connections.

[previewyoutube][/previewyoutube][h2]❓WHAT ARE MAP CONNECTIONS?[/h2]
Map connections are a means for the player to transition to different areas without resorting to overmaps menus. If you are familiar with Brigador: Up-Armored Edition's Freelance mode, those used overmaps menus to handle the different map choices within a run of maps. For BK, we’re building a contiguous set of spaces that you can travel back and forth between, giving the game's world a clear sense of structure that you navigate and explore.

In the video above you can see a very basic implementation of this in action. The player gets into a vehicle and drives towards the edge of the first map, hitting the first map connection volume that will advance both the infantry character and the car they're driving to the next area. The player then drives all the way through the second map still in the same car, hitting the next connection. They then get out of the car in the third and final test map, shoot away some props and hop onto a gurney.

[h2]🛒BRIGADOR PEWTER MINIS NOW ON SALE[/h2]

The latest addition to our merchandise store is three pewter minis of vehicles from Brigador: Up-Armored Edition. They are the Canmore, the Broadsword and the signature Touro at 1:144 scale. We've already put up a post detailing the creation process over on Brigador's page.

https://steamcommunity.com/games/274500/announcements/detail/3680051300625264980

Please note that due to higher-than-expected demand, any orders made for these miniatures will be delayed by at least a week.