Brigador Killers News

[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/

We asked one of our artists for an explainer on what they’ve been working on. This time it’s Igor again, who previously helped us write this post, and has decided to drill down on his favorite building prop.

This is me playing on Manyson. The map cs_manyson.
- Anonymous youth, circa 2000s

McMansions, which are called "subhouses" in the game files, are one of my favorite prop sets in Brigador: Up-Armored Edition. The moment I blasted through one of them with a Banshee MG and saw it immediately collapse, I thought to myself "Oh, they're flimsy, that makes sense!". Working on the upgraded version of the McMansion for Brigador Killers was a challenging and occasionally painful quest that asked me to reconsider what constitutes good architecture.
[h2]New design, new problems[/h2]
The subhouse as it appears in Brigador: Up-Armored Edition, divided into its constituent tiles

Subhouses, as good as they are, needed a lot of reworking to fit into BK’s design requirements. With the increased fidelity and visual scale, as well as a greater focus on infantry combat, I had to show the collision boxes a lot more respect than the previous game, effectively blocking myself from using some of the modelling techniques deployed in Brigador. Significant deviations from the tile grid had to go for a while, returning only when the code team pushed an update that allowed us to put down what are called “qprops” (as the name suggests, it’s a prop that takes up one-quarter of a standard tile in the engine).

The modularity issue also needed to be tackled. The original game's subhouses were modelled from the top down, in that they were a complete house model divided into tiles. This approach allowed for the greater utilization of half-destroyed states, where destroying one of the building tiles reveals the ruins and debris "inside" of adjacent tiles as in the image above. However, this approach significantly limited the ways tiles could be combined together.

Last, but not least, the visual scale had to be more realistic. If our player character is standing next to a building, it would be better if they could visually "fit" inside it, at least when it comes to something as spacious as the houses of the wannabe ruling elite.
[h2]Italian inspiration[/h2]
The Villa La Rotonda, just outside Vicenza in Northern Italy, designed by Italian Renaissance architect Andrea Palladio

Since ordinary McMansions – with their seemingly nonsensical combinations of volumes – were too hard to work with from the get-go, I had to pick something simpler I could start tinkering with. The Villa La Rotonda immediately checked many boxes. A Renaissance masterpiece, I saw it has all the essential elements I could easily cut into tiles: entrance groups, corners, internals, dome... With this the basic combinatorics were born: tiles can be facade or corner, one or two storeys high, all with a front-facing sloping roof, meant to be assembled around core internal tiles.

An initial mockup of possible combinatorics

Importantly, the Villa La Rotonda also provided a general style guide. McMansions come in many different shapes and styles, but understanding that all those variations won't seamlessly click together, I had to narrow it down to just one. Italian quickly became the choice for good reason: it was thematically appropriate for Miami-inspired Mar Nosso and also worked better with more gentle roof slopes. This meant I could model my two-story pieces without occupying too much screen real estate with the jarring roof tiling.

With all the prep work done there was only one question: how do I turn a UNESCO World Heritage Site into complete shit?
[h2]Rules, or lack thereof[/h2]
First iteration of the new McMansion in BK

There were a few hard constraints left to set due to the modularity requirement mentioned earlier. The primary color has to be uniform to call less attention to the tile grid. In addition, all sets (I made three, which are differentiated by the wall and foundation design) have to share the same floor and roof heights.

As for the rest, well… one thing I noticed while looking at IRL examples of McMansions is that there is not a single architectural rule left unsullied. Rhythm, composition, using your classical references correctly – you name it, it’s disrespected. This was the paradigm I had to adopt. If a particular set corner had plain rectangular windows, its corresponding facade tiles should use ornate phallus-shaped ones instead. If one particular element had to, by all the rules of good taste, align with another – misalign them, but only slightly, lest someone think it was intentional. If the set you're making looks medieval, add one (just one) Neoclassical tile for good measure. If the tile you've made screams "entrance group" at you, conveniently forget to add a door.

And after you’ve broken everything, make a couple of tiles that actually look normal for once, just to subvert the meta rule you've set for yourself. But even then, remember: it’s "tacky", not "classy". After all, we're making a mass-produced steel-frame property investment, not some aristocratic manor. This approach came in handy when I was working on side wall greebles. Sure, I want them to have pipes and AC units just like in the original subhouses, but what's the proper nouveau riche way to do this? It's by ignoring the back-alley aesthetic and painting all of it with the primary wall color, of course.

Final iteration of the McMansion in Brigador Killers, divided into its constituent tiles

This brief article on McMansions omits many aspects of what could be a much longer story. There are other tales such as my work on actual wall and floor constructions, or the accompanying topiaries set inspired by the album cover of Supertramps’ Breakfast in America, or how I discovered some of the mappers were combining unfinished McMansion assets with office buildings behind my back. Regardless, I hope you enjoyed reading this as much as I did working on them, albeit without the minor existential crisis where you question how your education led you to this point.



P.S. We are running a very short survey about the exact make and model of controller you use to play on your computer. We particularly want to hear from those who played Brigador on controller. Participation in this survey is anonymous, but at the end you can submit your email address to be entered into a raffle to win something from our merchandise store. You will only be emailed if you win. This survey will run until October 31st 2024.