Brigador Killers cover
Brigador Killers screenshot
PC Steam
Genre: Indie

Brigador Killers

LET'S LEARN ABOUT STORYLETS

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.

WHY THESE SYSTEMS?



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?

COMPLEXITY THROUGH CONDITIONS



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.

[table equalcells="1"]
[tr]
[th]gvar[/th]
[th]NPC storylet text[/th]
[/tr]
[tr]
[td]Rescued[/td]
[td]"Thanks for rescuing Norman”[/td]
[/tr]
[tr]
[td]Not Rescued[/td]
[td]“You didn’t rescue Norman?”[/td]
[/tr]
[/table]
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.

[table equalcells="1"]
[tr]
[th]gvar[/th]
[th]Alive[/th]
[th]Not Alive[/th]
[/tr]
[tr]
[td]Rescued[/td]
[td]"Thanks for rescuing Norman”[/td]
[td]"At least you tried”[/td]
[/tr]
[tr]
[td]Not Rescued[/td]
[td]“You didn’t rescue Norman?”[/td]
[td]"You didn't even bother”[/td]
[/tr]
[/table]
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.

ONE MAP, MANY OUTCOMES



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.

WIN SOME MINIATURES BY PAINTING MINIATURES



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/


Designing a SWAT Vehicle From The Wheels Up
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/

REIMAGINING THE SPACERS
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.

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

❓WHAT ARE MAP CONNECTIONS?


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.

🛒BRIGADOR PEWTER MINIS NOW ON SALE



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.

A LOOK AT SOME OF THE NEW LEVEL-MAKING FEATURES FOR BRIGADOR KILLERS
For May’s update on Brigador Killers we’ve decided to talk about something many of Brigador’s modders will be familiar with: the debug panel.

For those not familiar, if you press F1 at any time in Brigador: Up-Armored Edition an overlay window appears that looks something like this.


In BK, the debug panel has had some work done to it…


…so we’re going to highlight three of its new features.

[For those wondering, yes, this is Dear ImGui by Omar “ocornut” Cornut, which is used by a lot of other game developers in their games though it’s typically not made accessible in the public versions of those games.]

Our usual caveat as ever: what you see is still a work in progress and not everything in this article’s screenshots are necessarily representative of the final product. If you're having trouble viewing the screenshots, try right clicking the image and opening it in a new tab (click here to view this post in your browser).

🔍Tile contents tooltip


Let’s say for instance we’ve laid out a level and need to edit the features of a particular structure (or “prop”) like this fenced-off enclosure in a Brigador Killers test map.


If this were our previous game and we didn’t know what the prop’s .json file was, we would typically refer to the version of the same level in Tiled, which is the editor we use to make levels in both Brigador and Brigador Killers. Over there we click the prop and it’ll show us its file path…


…And from there it’s just a matter of alt-tabbing back into the game to look up the same file path in the pack file tab, and then inspecting it via the data editor tab and we can set about configuring the prop to our needs.


Simple enough, but it can be a bit clunky, particularly if you have to work with multiple rotations of the same prop in order to, say, make sure the strength of a structure is unified across all variants of that asset. This could get a bit complicated when it came to what we call “prop stacking”, which is placing two props in the same tile but using different layers in the editor.

[Sidenote: this hasn’t historically been a huge problem for us, though it is one of those time wasters in game development that might seem tiny, but adds up as more and more assets get added to the game.]

The Tile contents tooltip provides a solution. By enabling it, a small tooltip window will appear whenever our mouse cursor moves over any prop in a level.


This window tells us what props are occupying that tile, what the prop path is and allows us to immediately look up the asset in the data editor by hitting End on our keyboard, which cuts out all that of alt-tabbing and manual typing mentioned above.

In addition, if we in fact have stacked two props on the same tile, the tooltip will still tell us! Let’s direct our tooltip’s attention to this set of light poles inside a topiary…


Mousing over with our tooltip and using the arrow keys will let us toggle between the props on that tile, showing us the details for both the topiary and the light pole.



From a development standpoint, this will save a huge amount of time because of the increased volume of props that we’re making for BK. Keen-eyed modders might also have noticed the green text that appears in the top right of the screenshot, which informs the user whether the moused-over tile is walkable or not.

🚓Patrol routes



In the Mech debug tab, two new radio buttons have been added:

  • Select patrol origin
  • Select patrol endpoint
In order to make use of it we select a mech (“mech” here means any NPC that has some kind of active AI state unlike a vehicle like a panel van), indicated by the green triangle underneath the placeholder Dave-with-a-cophead. If units are currently moving about we can pause the action with devmode enabled. With time frozen we can click the desired patrol origin and end point for the chosen mech within the game.


Inside the game we are limited to just a start and end point. Outside of the game we can set more complicated patrol routes via Tiled. If we click Force patrol AI state and unpause the game, our newly assigned mech will dutifully bounce between both points in the level, visualized here by the orange debug lines.


Unfortunately we can’t force this new patrol information permanently within the game. It has to be done outside of the game in Tiled, where we have to manually specify the patrol behavior for a placed unit. However, having the patrol feature immediately testable within the game let’s us:

  1. See whether the mech can patrol to and from that point or not
  2. Get the coordinates for those two points that we can take over to the Tiled version
As you might expect, this is going to allow us to create more interesting combat encounters, particularly in light of the third feature.

🚶‍♀️Civilian socializing


This one’s complicated, and this screenshot is probably not going to help either, but bear with us.


What you’re looking at is the debug draw of the social paths. Put simply, civilians have new socialize AI states. In the case of the above, the green hemispheres indicate areas of “socializing”, while the white lines indicate civilians searching for such areas and the path they’re taking to get to one.

When a mech enters the social state, it will randomly pick another mech, internally called its "friend". The friend's current position will be chosen as a meeting point (or green hemisphere) and it too will enter the socialization state. Futher mechs that enter a socialization state and choose either of the currently "socializing" mechs as a "friend" will converge to that meeting point. After an amount of time passes, these civilians will search for another place to socialize. In the process of writing out this post, we had left the level running a bit too long in the background and 99% of the test level civilians ended up all grouped together.


Civilians dynamically moving around in such a manner goes a long way to making levels seem more alive but it’s not the only thing. Not featured here is the ability to make props that are “socially interesting” and not just to civilians. Other on-foot NPCs like cops are also capable of the social AI state.

What does this potentially mean from a gameplay design standpoint? One possibility is it means we can place entities in levels that will draw the attention of NPCs and cause them to gather in particular spots. Maybe it’s a fast food restaurant, maybe it’s a police checkpoint, or maybe it’s something the player can use to create a diversion within a level…

Whatever form it ends up taking, we know we’re excited to see what our community of established modders gets up to with these features alone.

Did you know that Stellar Jockeys has a merchandise store? If you’d like to help fund our development, consider purchasing a pin, t-shirt or even an SNC Skull & Laurel Zippo™ lighter.

WHAT’S IN A GIF?
This month’s post looks like a GIF explainer but it’s secretly a ruse to explain how systems can overlap in Brigador Killers. Here’s the GIF in question, taken from a recent debug build:



We’ve slowed this GIF down considerably because at “normal” speed, it would look something like this…



Also we’ll post the first GIF a bunch of times throughout this article so you’re not constantly scrolling up and down.

The GIF shows several entities in its short clip. An entity is an object that interacts with the game and responds to player input or other entities. These entities are:

  • 1 x Carmine suit
  • 1 x police cruiser
  • 2 x Dave
  • 1 x destructible object or “prop” in the form of yellow buckets filled with water
The Carmine suit is player-controlled. The police cruiser has no driver and is empty. The two Daves are non-player characters that either have no AI or are set to not to react to player actions. The yellow bucket props are in-universe impact attenuators.



We also have some debug visualizations on screen, which are:

  • A label called Max speed
  • A label called Decay
  • Green HP bars above the police cruiser and the two Daves
  • A red and orange ring that briefly appears beneath the Carmine suit
Max speed and Decay aren’t important to this specific scene, but we’ll try to explain them regardless. Max speed is, as the name suggests, that unit’s maximum speed. The Carmine suit has a greater motive power than the two Daves. Decay is the “bleed off” of bonus velocity that an entity would get from boosting or charging. In the previous game Brigador, after you stop boosting your vehicle, your max speed immediately goes back down to its original value. We smooth this transition out now for Brigador Killers, but because of how these bonuses work, we have to keep track of how much "bonus" there is which we then gradually subtract from. So, the decay value represents the remaining bonus we're still subtracting from - but the decay value in the GIF is zero because no entities have boosted or charged.

The green HP bars are an abstraction of how many hit points that entity has left after taking damage. A green bar that has turned completely transparent will disappear because the remaining HP has hit zero. Not all entities on screen have HP bars visible. Player-controlled entities like the Carmine suit have their HP displayed elsewhere. Props do not tend to display HP bars either, sometimes because their HP pools are so small and because we express damage to props in other ways.

The red and orange ring underneath the Carmine suit are visualizations of the damage radii of the “kick”. You might remember something similar from a previous post about systemic building collapse.

Third, let’s go over the visual effects going on in this GIF.



The visual effects that we can see are:

  • A kicking up of dust from the Carmine suit’s “kick”
  • A darkening effect on the Carmine suit, police cruiser, two Daves and prop
  • The Daves changing animation states
  • The inertia of the police cruiser after colliding with the prop
Technically the Carmine suit’s “kick” here is actually a reused mech stomp. More specifically, it’s not a stomp at all, but an explosion. This is also the reason why the suit briefly darkens.

The darkening effect is to visualize to the player that an entity has taken damage in some way. As a result, every entity that appears in the GIF takes damage in some manner, including the prop.

The two Daves change animation states because they have entered what’s called a pain state (sometimes referred to as “flinching”), with both being pushed aside by the hitbox of the police cruiser. One of the Daves that’s still visible dies as they fall over backwards, losing the HP bar in the process.

The car’s inertia after impacting the prop carries it forward a small distance more before eventually rolling to a stop.

Now for the fun and penultimate part - here’s what’s going on in terms of behind-the-scenes systems.



Some of these systems are holdovers from our first game, some of them are new to Brigador Killers. In action in this GIF are:

  • Impulse
  • Wheeled vehicles
  • Trample
  • Reverse trample
Impulse is how the police cruiser gains velocity and is pushed sideways into the Daves. The impulse comes from the explosive “stomp” kick of the Carmine suit.

Due to Brigador Killers’ new wheeled vehicles implementation, cars can better act like four-wheeled vehicles. We spoofed wheeled vehicle movement in Brigador for vehicles like the Pantry Boy treadbike or the Varlet tuk tuk by taking the tank movement and making the treads very “narrow” to give the sense of a bike/trike-style movement. Currently in BK, wheeled vehicles don’t have the handbrake on, meaning they can be pushed around easily just from NPCs bumping into them. The Carmine suit’s kick delivers more than enough impulse to send the cruiser sideways into the Daves.

Trample is a means of causing damage that already exists in Brigador - it’s how mechs are able to stomp through buildings like with the Touro or ramming through enemy vehicles with your Killdozer.

Reverse trample is different. Reverse trample is a system new to Brigador Killers in which trample damage can be self-inflicted. A simple way to think of it is how you can get hurt because you went very fast into something solid. However, in BK, reverse trample can kick in from both rapid deceleration and rapid acceleration.

So finally with all of the above in mind, here’s the detailed play-by-play of the GIF



  1. The player in the Carmine suit hits the police cruiser with an explosive “kick” that gives the car impulse.
  2. The police cruiser immediately takes damage from the kick and the impulse sends it in a direction away from the source of the impulse.
  3. Almost instantly the first Dave takes reverse trample damage due to the rapid acceleration it inherits from the police cruiser. The police cruiser may also be inflicting a small amount of trample damage on the Dave.
  4. A frame later the second Dave takes damage for the same reasons as the first (reverse trample and trample).
  5. The police cruiser continues towards the yellow impact attenuator prop, inflicting trample damage on it.
  6. The Dave on the right exits off screen and survives, but the Dave on the left, after rapidly accelerating and taking both damage from reverse trample and trample, takes a second bout of reverse trample damage because it catches the corner of the prop and rapidly decelerates. This makes the total interaction lethal to the Dave on the left.
  7. Leftmost Dave’s HP is fully reduced, its death animation plays out, and the NPC flops backwards onto the ground.
  8. The police cruiser still has inertia and continues to roll forwards before stopping.
All of what you just read is about 1000 words explaining what happens in roughly a second of gameplay.



Why we bothered to write that all out is because at the time of capturing this GIF we didn’t even expect the second Dave to have been killed by the interaction - we would have been content enough with the police cruiser shunting into the NPCs and inflicting some reverse trample damage, which it did.

Instead, we’ve found ourselves in a much more exciting place, because we now know that such player actions have the potential to be “messy” in ways that means players won’t see the exact same thing over and over if they replay certain combat scenarios. The reason this has happened is because it’s a combination of multiple overlapping systems that, in some cases, have taken several years to develop, and can now be expressed in Brigador Killers.

If you enjoyed this post, you can find quite a few more in-development GIFs on our discord server’s #brigador_killers_chat channel.

BRIGADOR KILLERS IS A BLOODY MESS
One of the major advances that we made the past month was changing how the aiming works in the game’s engine for Brigador Killers along with some new animations. We’ve recorded some footage of the new aiming system in action and put together this post as an explainer for what you’re about to watch. A reminder as always: what you see below is not indicative of the final product, and there’s plenty still left to do… but it’s starting to get much closer to the game we want to make.

Combat Glide (0:00)


We briefly talked about an earlier version of this system in November's post. By holding down right mouse button, which is the current bind for “Ready Weapon” and moving with WASD we can see the player-controlled Dave do a Combat Glide. The yellow dot at Dave’s feet indicates his current orientation, while the green dot is where the mouse cursor is in screen space that the player has line of sight to. While Dave can spin around in a circle while stood up, crouched down his “upper” can only rotate so far in either direction until he reaches a maximum turning radius.

Dave moves over to a white panel van to then demonstrate what happens if something gets in the way of the player’s free aiming. As the aim sweeps across the van, the green point changes position and a second red dot appears. This red dot is to indicate where the mouse cursor is, but that the player does not have direct LOS to that point and is instead getting “caught” on the van’s hitbox.

The player then shoots the white van with a gun that’s slightly overtuned.

Lock Target (0:56)


When not aiming like in Combat Glide, the purple dot on screen is currently an indicator of where the player’s cursor is. Lock Target is a new form of aim that automatically locks on to the hitbox of an NPC that is closest to the player’s cursor when the player presses whatever Lock Target is bound to. In this case it’s bound to the side button of a mouse.

Once locked on, the player can freely move around the targeted NPC and maintain aim until the NPC is either destroyed in some manner or the player decides to aim at something else. The player practices on some dummy NPC units that also shoot out some new blood squibs when shot. The NPCs don’t fall to the ground like the enemy Daves will later because animations have not yet been set up for them. The player-controlled Dave, who is currently invisible to enemy NPCs, shows off the tracking of this new form of aiming by locking on to a few wandering Daves and following them around before unloading a shotgun a few times.

The ability to lock the aim is an important addition to the Brigador aim scheme for a couple of reasons: for some Brigador players, the combination of manual aiming with maneuvering and tactical awareness required too high a cognitive load. Being able to slow the game down alleviated that, but could still be frustrating as a single-stop solution. Lock Target provides another option for players while making both controller play far more viable and adding a major accessibility option for impaired players. Returning Brigador players may choose to eschew aim locking entirely, and that's fine. The idea isn't to require a certain style of play, but rather to open the door to as wide an array of playstyles as possible.

Level Aim (2:52)


Some context is required before explaining the footage of this section: one of the biggest things that we wanted to have with infantry-scale combat was the ability to crouch behind walls and shoot over them, but there were problems with doing this. The main one was due to the legacy of Brigador’s own method of aiming, in that the player’s arc of fire usually shot downwards into the ground from the position of a vehicle’s weapon mount point. That meant that crouching a unit also lowered the position of a vehicle’s weapon and thus the height at which the fire would emanate. This meant that weapon fire could easily “catch” on the top of environmental props, but it wasn’t really a problem in Brigador because of the general scale of things and most props being easy to destroy. However, in BK the props are sturdier and we’re trying to do infantry-scale combat.

That’s why this footage starts with the player Dave crouching by a barrier and appearing to shoot at the red sports car, but doing no damage to it even though the green aim dot is clearly over the car. When Dave stands up to take a shot, the shots connect because the rifle bursts are no longer “catching” on the top of the barrier and can connect with the vehicle.

At the 3:24 mark, the area is refreshed and the player crouches down to shoot at the same car... except now the shots connect. The sharp eyed will notice the aim lines have changed ever so slightly – this is what happens when the Level Aim button is held down, and in this footage is bound to a second side button on the mouse. When used in conjunction with Ready Weapon with right mouse button, it allows the player to shoot at a flat angle, parallel to the ground. So even while crouched, the player can shoot over and make their hits land.

Player Dave also returns to the group of standing NPCs we saw earlier to show off Level Aim while crouched, and shoots at a couple of wandering Daves from behind a barrier.

Flop, Drop & Prone (4:45)


In addition to new aiming, several new behaviors have been added to make enemy infantry more “alive” and animations to go with them. The first is “Prone”, which is when an NPC Dave drops to a chest-down position in response to a frag grenade being thrown nearby. The main effect of this prone behavior is to give the enemy infantry a defense bonus as well as the player a sense of agency. After taking enough damage, one of the Daves flees, before being dealt enough damage to enter a “bleed out” state that eventually kills the NPC after a specific amount of time.

Player Dave then proceeds to show off other Daves flopping over on their back or dropping to their front due to small arms fire. It’s something that needs to be fine tuned, but what we want to do with this system is similar to the pain state of monsters in Doom, wherein the player is able to briefly stun mobs of enemies by doing enough damage.

Death Animations & Gibs (6:29)


We also decided the past month that the Daves needed to better demonstrate when they’re incapacitated. In addition to blood squibs from being shot at, enemy Daves now fall over dead in various positions. Also, corpses can be gibbed by the player with explosives like grenades and generally make a mess of things.

The graphic content of BK is something we are able to configure. For instance, corpses can be made to immediately fadeout on death. So, if screens full of blood and limbs is a bit much then you’ll be able to turn such things off.

If you enjoyed this post, please consider wishlisting and following Brigador Killers on Steam to get the latest news in your Steam library feed.

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

LET'S TALK ABOUT RELEASE DATES
Back in July 2022 we wrote that we wanted to put some form of Brigador Killers out in 2023. We have recently decided that the game will come out first as a build on Itch.io in the coming months. Assuming that period on Itch goes well, BK will then come to Early Access on Steam in 2024, and then eventually 1.0 with post-release support.

The Itch page is up though there are no builds of the game to get your hands on just yet. You can take a look at it here. Price is still TBD.

🤔WHY WE’RE DOING THIS


We’ll limit the list of reasons to four broad points. First, expectations. As indie developers go, we’re old and remember what Early Access on Steam used to be like and what the public accepted as early access. If we were to repeat with BK on this storefront now what we did with Brigador back in 2015, we’re confident a lot of people on here would be disappointed because the game simply won’t be at the expected quality level of an “early access game” in 2023.

Second, risk. When a game is released on Steam, the platform puts your game in front of a lot of customers every second – but only for a limited time. Also, Steam is still the most widely used platform for PC gaming. We want to make sure we can make the biggest splash possible.

Third, scale. When BK is released to the public, dull yet highly important things like bug reports will shoot up. We already know that keeping Brigador functional on current operating systems like Windows 10 has been bumpy, and with Windows 11 we expect more of the same for both Brigador and BK. By exposing BK to a smaller pool of players first, the hope is that we can prevent ourselves from being overwhelmed by the number of people with technical issues, as well as the occasional player that is somehow able to run our game on a government-issue laptop from the early 2000s running Windows 8.1.

Fourth, burnout. We appreciate the hype from a lot of you for BK but please also understand that we don’t want to destroy ourselves in the process of making it. Brigador already went through that process in 2016 with its initial release, and it’s not an exaggeration that it took years to undo the damage that it caused.

Brigador Killers is not only meant to be a sequel to Brigador but also internally is the end result of a lot of lessons learned – and what we learned with the first game was we enjoyed the community feedback, which Itch will help us with.

We realize Itch isn’t going to be for everyone, and that’s okay. It’ll still come to Steam and GOG regardless.

🙋‍♂️ANSWERING THE QUESTION OF “IF I BUY IT ON ITCH FIRST, WILL YOU GIVE ME A STEAM KEY FOR IT LATER?”


Yes. Itch even has that functionality built in. When the game is ready for Steam, Itch owners will get their Steam key.

📰WHAT’S BEEN HAPPENING WITH BK


On the programming end of things, lua scripting has been added into the engine. This is going to significantly increase what we’ll be able to do with the overall gameplay of BK. If you’re familiar with Brigador, everything about the in-level maps in that game is decided the moment a level loads. That means a level will always have the same layout of buildings, the same spawns in set locations, the same music, and so on. We now have the ability to change a lot of that, though we’ll save an explainer post on this topic for later.

Design wise, with the new systems like morale and infantry movement, the amount of game data that needs to be audited is substantial. To give you an idea, here’s a glimpse at the current list of values that can be configured just for the morale system, and that these are things that can be set per AI-controlled unit.



Because there’s so much data to deal with, things like the armor & pierce system mentioned in the August 2022 post are going to be pared down from eight tiers. As much fun as it is to have a broad range of numbers to play with, BK is ultimately not going to be a hyper-detailed MilSim like the Arma series.

In terms of visuals, our lead artist Jack recently put up a twitter thread explaining how to signal to the player which wheeled vehicles are going to be drivable and which ones are not. Consider these two as an example:



Which one do you think you can drive as the player? If you chose the one on the left but not the right, congratulations – but pause for a moment and consider why. The obvious go-to is that the roof has been taken off, but also note that where the driver would usually sit is now occupied by an optical array, meaning there’s no space for a human to sit. The intention is that this wordlessly tells the player that, although this is identifiable as a vehicle, it is not intended for you. In addition, it serves as a tease for the loreheads out there to speculate as to the function of the vehicle on the right and what implications that has for the Brigador universe.

🏃‍♂️BEFORE WE GO…


We are surveying our userbase to see what kinds of computer hardware and software they are using to play Brigador with. Participation in the survey is anonymous. The information gathered isn’t very exciting but it will be incredibly helpful to us as it will tell us what benchmark to aim for with BK. Click here to take the survey and get your response in before March 31st 2023.

MORE MAVS FOR YOUR EARS

🎧NEW MAKEUP AND VANITY SET TRACK


Considering people enjoyed the Makeup and Vanity Set tracks from November’s all props tour video, here’s the extended version of Strange Bedfellows from the Brigador Killers OST as its own upload on our YouTube channel. More tracks to come.

📅OUR PLANS FOR 2023


Our intention remains the same as what we said back in July 2022: BK will come out in some form of early access this year, and we’ll have more details on the specifics next month.

Between then and now we’re currently settling on the minimum feature list for that early access build. The biggest task for the programmers is overhauling the menu interface. Rewriting how the engine handles the menus is a complicated affair, but it will be necessary to make the game we want to eventually release.

📝OTHER THINGS OF NOTE


In other news, animations for enemy infantry flopping over were completed. Here’s a group of Daves falling over to demonstrate.

People who have played a lot of the original Doom will be familiar with the term Pain state. Our intention with the flops above is largely the same, in that it is both visual reactivity for the player’s actions, and is a means of controlling enemy NPCs.

Why we have this is part of what we talked about before with “finding the fun”. With a vehicle-only game like Brigador, we didn’t have to worry about the enemies having pain states, because their vehicles weren’t “alive” and it was enough to make them go boom and end up as hulks on the ground. Doing the same with human NPCs won’t work, because players will want to see human-like behavior.

Our hope is that combining flops with death animations and the new gibs system we have in the works will lead to satisfying gameplay.

🥶STAY WRAPPED UP TIL NEXT MONTH


If you’ve missed any of our previous dev streams or other dev-related videos over the past seven months, you can find them as their own playlist on YouTube.

BRIGADOR KILLERS: PILGRIM AUDIOBOOK PROLOGUE
As a parting gift for 2022, here is the first chapter of the next audiobook written by Brad Buckmaster and read by Ryan Cooper. Titled Brigador Killers: Pilgrim, it is a direct sequel to the events of the first book and will serve as a companion novel for the game Brigador Killers. We are thrilled to have worked with both Brad and Ryan again on this project. As we state in the novel’s foreword:

Be ready: this is no mere "tie-in" novel. We gave Brad the go-ahead to run, and he ran all the way into the dark.

As for Brad's own blurb:

Solo Nobre fell in one night.

Those loyal to Great Leader were pushed to the edge of oblivion, yet remained unbroken, and now they turn their gaze skyward towards a new world, jewel of the corporate oppressors that now reign over them.

It is there on the rich colony of Mar Nosso that the hated Brigador mercenaries enjoy the spoils of war, basking in newfound celebrity status, lionised as heroes to the ignorant masses.

They think the fight is over.

For the members of Kill Team Pilgrim, they haven’t even started.

Pilgrim will take the fight to the enemy, on their home turf, where they think they are safe and protected.

It’s time for the Brigadors to die.

We’re looking forward to you learning more about both Zhe and Kill Team Pilgrim when the novel is released in full in 2023.

P.S. Our merchandise store is still running its sale all December long. You can get 20% off your next merch order by entering promotional code HOLIDAYS2022 at checkout, or clicking here.

P.P.S. Like the splash art? An album of all our splashes to date for Brigador and BK can be seen over on this IMGUR album.
Newer posts Older posts