Brigador Killers News

By summer of 2025 we expect to have a demo ready in preparation for the next Steam Next Fest. That Next Fest will begin on June 9th, or about three months from the time of this post. As a result a few things are going to happen, though not all at once.

First, the storepage - which was set up in haste after Rock Paper Shotgun covered our appearance at BitSummit in 2019 - will finally get its long-due overhaul. That means those images and gifs will be replaced so that it’s clear what Brigador Killers actually looks and plays like, instead of things from the build that did the rounds at PAX in 2019 and 2020. All those “old” images from that version of BK can be seen in this dev archive album.

Next, we intend to put the demo up before the June Next Fest starts so that we’re eligible for the press preview event that occurs before each one. Developers only get one go at this event per game so we want to make the most out of it. What this means for you the public is that you will probably be able to access the demo not long before the festival begins. We do not intend to take the demo down after the Next Fest ends either.

Another piece of news is that the next audiobook will become available soon. One reason it has taken a while is we needed a good illustration for it. The work is almost done and here’s a peek at one part of the overall image (click here for a bigger version).



In case you missed the prologue post from before, the book is titled Brigador Killers: Pilgrim, written by Brad Buckmaster and read by Ryan Cooper. It is a direct sequel to the events of the first novel and it takes place between the first and second game. The first half of the new novel will be put up on our YouTube channel, one chapter at a time. The ebook version will follow at some point after since it is also waiting for the cover.

We realize this is a short post for this month but they aren’t the only things that are going on behind the scenes at Stellar Jockeys - this is just what to expect in your immediate future.

[previewyoutube][/previewyoutube]

The video above is about a new debug tool added to Brigador Killers called “Ghost Lights”. The rest of this article repeats the content of the video in text form with some additional details.

[h2]A brief note about map making[/h2]

Like in Brigador: Up-Armored Edition, the Brigador Killers engine uses a combination of global illumination and small destructible props called “minis” to light its levels. Global illumination is where we model the position of a “sun” inside the game, while minis are things like lamp posts, traffic lights, neon signs etc. When these minis are destroyed, the lights attached to them are also removed, as one might expect.

The levels are made in SJTiled - a fork of an open source program called Tiled - and it works like a WYSIWYG (What You See Is What You Get) editor. In other words, where you place a building prop or an NPC spawn in the editor corresponds to the same position inside the game when you load that map. SJTiled, however, cannot have the same lighting conditions as the game as can be seen at the 34 second mark.

Regardless, SJTiled is great at making levels. When we export a file from SJTiled, it creates a .json file for the game to read. This .json file tells the game what to load for that map and where. We demonstrate this in the footage by placing a blue barrel in the map, exporting the map, switching over to the game that is currently still running, and reloading the map with a developer command to show that same blue barrel in the game. Dave promptly kicks the barrel to show it’s not some sort of trick.

Although placing mini lights to illuminate a scene in the right way is still something we’ll do, constantly having to go back and forth between SJTiled to adjust the position of a lamp post, exporting the map, reloading the map over and over can become tedious.

[h2]What are ghost lights?[/h2]

Ghost lights allow us to dynamically place lights anywhere in-game via the debug panel, instead of placing minis via SJTiled. They are neither props nor minis and can exist entirely on their own if needed.

In the footage we start by placing a simple electrical light via a sub menu in the Rendering control tab, which in its default state is a bright white sphere that initially has green, blue and red lines sticking out of it when selected. We then use the debug panel’s Data editor to change the width of its cone to create a small spotlight and give it a sodium lamp-like color.

After navigating back to the ghost lights sub menu, we change the direction of this spotlight via the X, Y and Z direction where X corresponds to the red axis, Y corresponds to the blue and Z corresponds to the green. This spotlight is then categorized by giving it the category name “spot” before it is duplicated to create a second light in the list.

This duplicate light uses the same data values as the first but we can change its position and direction independent of the original ghost light as seen at the 2:37 mark in the video. Also, since both lights are in the same category, this lets us bulk select and move them together as a group, so we move them over to spotlight the barrel that was placed via SJTiled earlier.

When we save our ghost lights via the “Save ghost lights for this map” button in this sub menu, this creates a “meta” .json file for that map specifically for the ghost lights. Once the lights have been saved, if we mess up the position, we can reload that meta file to reset their position.

[h2]Where things get interesting[/h2]

The sneaky part comes at the four minute mark: ghost lights can be linked to a prop or mini. In the video we link our two ghost lights to the barrel, then have Dave destroy the barrel, at which point the ghost lights disappear just like when Dave kicked over the lampposts earlier.

We can also make the ghost lights flicker by checking the "flickering" checkbox in the ghost lights sub menu. Once enabled, we can choose from one of many preset patterns available in the Data editor depending on what sort of effect we want, be it a fluorescent light with a faulty capacitor, or the gentle whispering of candlelight.

Since Brigador Killers is more zoomed in than the first game, the player’s attention is much more likely to be drawn to environmental details, so it’s important that we have the capability to fine tune those things.



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

A short post this month for the end of 2024, this time again from our lead artist who previously wrote about the Lobo, the Mar Nosso SWAT vehicle and the spacer redesign. This post is about a few new vehicles assets recently added to the game.

Earlier this year we put out an alpha of Brigador Killers over on Itch. We learned a lot of good lessons—one lesson being that the game world felt empty between playable vehicles. It was time to add a lot more civilian vehicles to Brigador Killers, starting with smaller ones.

Many of the fan favorites in Brigador were small, so we knew the Tuk Tuk had to come back, and we already had a motorcycle. What else fits into that category? I wanted an electric scooter, and some kind of goofy small commuter car.

[h2]Teddy Boy[/h2]

A freely-styled, loud, sort of 80s/90s scooter which I named Teddy Boy, partly because I think the jokingly Italian scooter names in games are tired, partly as a nod to the underground fashion style in the UK of the mid 20th century, and partly as an echo of the fan-christened Pantry Boy from Brigador: Up-Armored Edition. Here’s how it looks in-engine.



[h2]Liliputter[/h2]

For a small commuter, I looked no further than the deeply charming and goofy Comuta-Car of the late 70s/early 80s, one of the first widely available electric cars. Exaggerating its small scale, I turned it from a two seater into a single seat vehicle. Below is the Liliputter in action in GIF form.



[h2]An aside on the process[/h2]
Sometime last year I moved all of my hard surface modeling to a program called Plasticity, and it was an incredible gain in speed. Now it was time to revamp our rendering pipeline—not for the sprites, but some new way to show off items and vehicles in the game with close-up beauty renders. Blender and image-based rendering came to the rescue, as per this tutorial:

[previewyoutube][/previewyoutube]
Following this tutorial I had my new template for beauty renders. The added bonus is that once the game is out, we will include this render scene for modders. This means that any gun or vehicle you add to the game can use exactly the same rendering!

[h2]The Tuk Tuk[/h2]
As mentioned earlier, here’s the return of the Tuk Tuk, which now comes in multiple configurations:

Like with the other new additions, here is the lineup within Brigador Killers.


Remember that over on the Brigador: Up-Armored Edition news section we announced four new pewter minis available on our merch store, as well as a 20% holiday discount until the end of 2024. A rundown of the new models can be read here.

https://store.steampowered.com/news/app/274500/view/4488495001178736877

Alternatively, head straight to the store by clicking here, and don’t forget to enter HOLIDAYS2024 at checkout.

Happy Holidays!

Restitution - Physics. the return to an original physical condition, especially after elastic deformation.

Video games are not bound by what we understand to be the laws of the universe. Objects can be given ridiculous values for their acceleration or mass and they won’t suddenly create shock waves or distort space time around them if the engine running that game doesn’t have systems trying to simulate those things. Generally speaking, games trend towards simplification when recreating the underlying chaos of nature. Note that this doesn’t mean work isn’t involved - the math for things like real time fluid simulation are very complicated and resource intensive, so to get the thing running at a steady framerate concessions must be (literally) made. At the same time, this simplification process is where things that might be referred to as “jank” can appear.

Entities in the Brigador engine love to spin

Jank isn’t necessarily bad - in the above case it’s just an example of the Lobo inflicting pure impulse on the car with both set to deal no damage - but it looks “off”. Within the game data, impulse is the value that decides how much “push” another entity has. In this instance the Lobo is applying impulse with its arm swing, while the car is applying its own pushing force by driving into the Lobo, but it’s not quite right because the Lobo is being shunted slightly while the car bumps off it and spins nearly 270 degrees. In isolation this might look fun, but in the heat of gameplay a vehicle wildly clipping into the player might get old fast.

[Tangential: one in-game distance unit is equivalent to just over 8 ft (or 2.44 meters). A “tile” in-game is two units by two units. Mass correlates to kilograms 1:1. For example, “Dave” who has featured in previous posts has a mass of 70 kg.]

Dave standing on a tile

To keep things simple in the Brigador engine, only NPCs are affected by impulse. Props (static objects like lampposts or office buildings) are not affected by it - though that is not to say props do not have an effect as was discussed in this previous post. So how do we go about reducing janky moments like the one above? It sounds crude but in truth we just start smashing things into one another and keep changing the values until it’s right. In other words, a crash test.


Two identical Lobos at one end, with two cars going at full speed towards them. The car on the left can go faster than the other one, though in this next gif the “slower” one arrives first in frame.


In this demonstration the slower car (with all its doors) has a mass of 615 kg, the faster one (no doors) has a mass of 750 kg. The Lobos are both 1000 kg.

There is a name for the phenomenon when two bodies collide with one another: Coefficient of Restitution. To directly quote the wikipedia article:

…the Coefficient of Restitution (or COR) is a dimensionless parameter defined as the ratio of the relative velocity of separation after a two-body collision to the relative velocity of approach before collision. In most real-word collisions, the COR lies somewhere between 0 and 1, where 1 represents a perfectly elastic collision (in which the objects rebound with no loss of speed but in the opposite directions) and 0 a perfectly inelastic collision (in which the objects do not rebound at all, and end up touching).

For our purposes, we need the COR for the bodies involved to be neither too close to 0, nor too close to 1. In the example above the COR is about 0.35.

In this next example, the Lobos have a higher COR of about 0.75 meaning they will spring back more than in the previous GIF - notice how the Lobo on the bottom being hit by the slower car doesn’t get knocked over until the second impact.


If we keep these same parameters but decide to increase the mass of the Lobos up to 1500 kg from 1000 kg, then the impact will look like this.



Neither Lobo is knocked over on the first hit and both cars bounce back pretty hard. Since there’s a greater disparity in mass between the two entities, the resulting bounce is harder.

Because restitution is basically how much inertia is preserved after an impact, this ties into another system that we’ve mentioned before - reverse trample (short version: both rapid acceleration and deceleration can be deadly). So if cars end up having a default COR of 0.35, and that at full speed that deals about 50% of their HP on impact (such as from hitting a wall, or hitting another NPC of equal or greater mass with a COR of 0.35 or lower), then hitting a unit that is both bigger (like the Lobo, or a mech, or a tank) and has a higher COR means the impact will be more destructive.

Whether that destruction is fun, however, is a different question. We expect players will want to gun the engine, but we might not want to make every impact potentially lethal to the player.

Something else discovered during these crash tests is that reverse trample damage does carry over into what’s called overkill damage. In plain terms this is what happens if you drive a 2000 kg cop cruiser into four Daves.


In other words, if you have a heavy enough vehicle moving fast enough, you will insta-gib infantry.



Over on the Brigador: Up-Armored Edition news section we’ve just announced four new pewter minis are coming to our merch store, as well as a 20% holiday discount. Full details can be seen here.

https://store.steampowered.com/news/app/274500/view/4488495001178736877

Alternatively, if you want to go straight to the store, click here and don’t forget to enter HOLIDAYS2024 at checkout.

[previewyoutube][/previewyoutube]
The video above shows off a basic implementation of two major mechanics for Brigador Killers. The first is weapon pick up and drop, and the second is the vehicle bay. Caveat as before that what you see in this footage is subject to change, both in function and especially in terms of appearance. Since the UI is very simplistic, the rest of this post is an explainer for this footage.



This demonstration takes place in a simple shooting range level. At the timestamp of 0:06-0:20, the player-controlled Dave moves next to a weapon on the ground that lights up to indicate it can be interacted with. When Dave is in range of it and the player mouses over the glowing weapon, a text box appears showing what the weapon is, how much ammo it has, what “slot” it goes into, along with the prompt of “Press E to equip, hold to place in backpack”.



For the purposes of this footage, the player presses the interact button to immediately equip the shotgun, fires off a few rounds, and then presses another keybind to drop it back on the ground.

At the timestamp of 0:26-0:52, Dave instead stores the weapon in his backpack by holding down the interact button. The player then presses the inventory keybind, which brings up a basic inventory screen that lists what the player has. From here, the weapon can either be equipped or dropped from the inventory.


The player equips it, closes the inventory screen, and shoots off some rounds before dropping the shotgun on the ground.

Moving on to the timestamp of 0:58-2:10, the player moves Dave towards a set of briefcases which lights up like the weapons do. This is a weapon “chest”. By pressing the interact button when in range of the chest, the chest’s inventory appears. Listed on the left are what the player has, while on the right shows the list of items contained within this chest.


The player takes the Heino9! SMG to add to the Rhino Stopper shotgun they picked up earlier. The player closes the chest inventory, opens their own inventory and drops both weapons on the ground. Those watching carefully will notice that the shotgun occupies “slot 0” while the SMG occupies “slot 1”.



[What “slots” means for the player is that, unlike in Brigador: Up-Armored Edition, weapons are no longer assigned to LMB and RMB on your mouse, but to slots. Depending on what the player is controlling, the number of weapon slots available will dictate how many weapon slots they can use. For the time being, Dave has only two slots available.]

The player picks up both weapons from the ground to immediately equip them like in the first example. Pressing 1 on the keyboard selects the shotgun, while pressing 2 selects the SMG, visualized by the change in ammo count in the top left of the screen. After swapping to the SMG, the player opens fire on the dummy Daves, then drops the gun to the ground, showing that it was the correct weapon, as well as showing off the reduced ammo count of the dropped weapon.



Now for the second major mechanic – vehicle bays.




This demonstration takes place in a small, screen-sized square. At the timestamp of 2:15-2:56, a Fork mech is seen parked in the top corner, while some weapons and a brain tape are scattered on the ground. Our focus is on the terminal of TVs next to a green rectangle. Like with the weapon chest in the previous section, the terminal lights up as the player approaches it, and pressing the interact button shows three options:

• Store/Retrieve
  
• Summon vehicle
  
• Store Vehicle
  

For the purposes of this footage, the second option is chosen, and the player selects the Forverkhuhn mech from the list since there is one available. The menu then shows a Groups option, which is intended to serve as a “choose loadout” option but is non-functional at time of recording. Upon clicking Summon, a confirmation window appears asking us whether we want to call in the vehicle…


…and it does. Dave gets in, drives the mech around, and stops it back on the same green rectangle, which changes color when the mech is parked on it. When interacting with the terminal again, the third option of Store Vehicle is available. Upon clicking this and a subsequent confirmation window…


…the Fork mech is returned to its bay.

At the timestamp of 2:57-4:10, Dave instead gets into the Fork parked in the top corner, and drives the Fork straight into the vehicle bay. Dave gets out, hits the store button on the terminal and the Fork disappears. When Dave accesses the vehicle terminal again, two Fork mechs are listed as available, so Dave retrieves both of them one after another. Dave drives both mechs around and then parks them back in the bay one at a time.





Both of these features are part of a major user interface overhaul that has taken several months to come together. We mentioned a while ago that Lua scripting had been added to the engine and this video is an example of just some of the things we can now do.

As a quick example, the chests are relatively simple. Maps that have chests need to have a file called luaload.lua which is referenced on level load. The chest itself is a simple object that references a file called rangechest_01.lua. Functionally, rangechest_01.lua is not that much different to a .json file, in that it will list out what files it’s referring to, how many can be found, and what “chance” there is of that item spawning within that chest.



However there are still limitations: Lua files cannot be live-edited like .json data - this is instead done externally in an application like Visual Studio Code, Notepad++ or Sublime Text. Lua files also require a full restart of the game in order to see the changes, but it’s worth the trade off. We no longer have to worry about levels feeling “static” like they were in Brigador: Up-Armored Edition, since we can now do things like add weapons and vehicles for the player to acquire. Lua is also what’s behind the narrative system, map connections and unlocks and now this vehicle bay and weapon pick up system.



In summary:

• Players can pick up weapons found on the ground
  
• Weapons and vehicles can be stored to be retrieved for later use
  

Regarding the first point, it’s expected that enemies won’t always drop weapons but some will. In addition, you might have noticed something in the text about the Heino9! SMG…



Even though this is placeholder, the functionality referred to is something called weapon stability, which was once mentioned in an older newsletter all the way from March 2022 that predates when we started posting these updates to Steam.

Weapon stability is a combination of two new things: a unit's "stability" and… a weapon's "chaos". As the names imply, units like infantry, vehicles, or tanks will have different stability values, while weapons like shotguns, rifles, or heavy machine guns will differ in how "chaotic" they are to fire.

In development terms, "stability" and "chaos" both have a rating between +5 and -5. Depending on the difference between the two values on those "stability" and "chaos" ranges, the game engine modifies the weapon's accuracy bloom. "Bloom" here is the rate at which bullets fired start to spread outwards from the intended point of impact.

In simple terms, if the stability rating is the same as chaos, then the weapon's accuracy bloom will act as it does in Brigador. If stability is greater than chaos, then the bloom cone will be narrower and stay accurate for longer. And if stability is less than chaos, then the bloom will grow quickly [and] start at a higher spread.

In other words, if Dave were suited up in a carmine, they’d be able to fire the SMG with better accuracy.

Meanwhile, the player’s weapon inventory and vehicle storage still needs a lot of work on the visual front, but the main point is: it works. It’s difficult to stress how much of an accomplishment this is for an engine that was never designed to accommodate something like this in the first place, and veterans of the first game are all too aware of how limited that game’s menus were.

More importantly, this system ties into what was mentioned back in our August 2024 post under the section titled “Refining the core loop”. The storage of vehicles is not just a simple garage but also meant to be part of the development tree for making more specialized vehicle variants.



If you haven’t yet wishlisted our game, please consider doing so.

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