Apr 24, 2024
Brigador Killers - dudeglove
There are a few things to interact with in the Secret Alpha build of Brigador Killers that generate a small amount of reactivity for the player. For this month we’ll look at the two main ones: the braintape, and the carmine suit parts. Please note that these systems are still a work in progress and what is detailed in this post is not necessarily indicative of the final product.
Both of these interactive elements have the following things in common:
** SJTiled is a fork of Tiled, a map-making tool used by several games
*** Lua is a scripting language that allows the game to execute code; a Lua function is a self-contained module of code[/expand]
To jog your memory, this is what the braintape looked like placed on its own:
This is what the data for the tape looks like in the Data editor tab of the debug panel:
The two things to note here are the resource path i.e. assets/data/pickups/kipple/pkp_braintape_01.json, and what’s contained in the on_pickup field i.e. UnlockTape. From here we go look at the same scene, but in SJTiled.
The three elements to pay attention to here are:
The asset field tells the game what asset to use for that object. Since it’s using the same asset path as the braintape in the data editor screenshot earlier, this means the game knows to use the assigned sprite for the braintape. If no asset was assigned to this object, the game would not render any sprite at all (or possibly crash in the attempt to load the map) and the player would not be able to interact with it.
The disable_if field contains the text __IS_UNLOCKED__. This field means that the object will not appear if the object has been unlocked by the player. Recall that the on_pickup field in the Data editor tab contained the text “UnlockTape”. Reversing the idea, this means the braintape will always appear in game until the player interacts with it. This begs the question: how does the game know to do this?
The bridge between SJTiled and the game engine is a Lua function called by the ITEM_PICKUP resource. Here is the relevant Lua function in Notepad++:
This function is titled UnlockTape. In case you missed it, the text that was inserted in the on_pickup field is referring to this exact function. In other words, we can insert functions into the data of ITEM_PICKUP resources in order to execute a module of code. What this module does when the player interacts with the braintape is:
So, once the braintape is picked up, it will be “unlocked” by the game engine. In SJTiled, we assigned this object to be disabled when it is unlocked. This means that when we come back to the same location…
…the tape is gone. Now that we understand how the braintape appears and disappears, we can look at the suit parts.
Unlocking the carmine suit follows the same path as the braintape but with a couple more steps. Going back to our test level, all three suit parts are laid out in a line and have the same disable_if condition as the braintape to stop them from reappearing after being interacted with. Here is what the parts look like in SJTiled:
While this is what the parts look like in the game:
And all the resource data for the carmine suit parts looks something like this:
An additional field to pay attention to here that the braintape did not have filled out is menu_unlock. When the function unlocks this resource, the intel entries on these items also become available to read. Until the pickups are interacted with, they will look like this in the game’s Intel section accessed from the main menu:
The function being called in the Data editor for all the carmine suit parts is UnlockItem. Here’s what this Lua function looks like in Notepad++:
Simply put, this function unlocks the resource that is calling it (the three carmine suit parts), and saves that state information to the gvar_data Lua file.
When this map that contains the carmine suit is being loaded, two other things are going on. The first is another function called HandleItemUnlock, which looks like this in the file called mapstates.lua:
There is also a reference script called pickup_ref.lua which contains this:
In this reference script we can see the filepaths for the three ITEM_PICKUP resources that are also placed in the map in SJTiled, and we can see the filepath for the carmine suit itself.
The reason why this script is referenced is because of something called BRIGAHACKED. This is another object layer in SJTiled that has a custom property called luaload assigned to it which contains a string called, you guessed it…
…pickup_ref.lua. Combined with HandleItemUnlock, this reference script gives the layer of this map a list to check off when it is loaded. This reference script is also meant to be copied and modified to unlock other items on other maps.
So what about the suit itself? We already know how the suit parts disappear when interacted with - how is the suit being handled?
Returning to SJTiled, the suit is just sitting there, but when we look at the custom properties for it…
…Instead of disable_if, we have the custom field enable_if with __IS_UNLOCKED__ in the field. In other words, until the three parts are acquired and trigger the UnlockItem requisites, the suit is disabled from appearing on the map. When all three suit parts are acquired and the map is revisited…
…The three suit parts are gone as we would expect, but the suit is now available for use. It should be noted that for demonstration purposes, all three suit parts and the suit itself were placed on the same test map – but they do not have to be. Since the unlocks system is being handled by these Lua functions, which are entirely separate from the maps, the unlocks can be made to appear wherever we want them.
If we look at the “Fort” map that you see when you start the Secret Alpha build, the suit is placed there in SJTiled.
However, it is only until the player ventures out and finds all three carmine suit parts that they will find this reward waiting for them back at the fort.
This unlocks system for Brigador Killers is how we are responding to some of the feedback the previous game Brigador has received over the years. While the quality of action and writing in lore entries was fine for enough players, Brigador’s unlocks system was found lacking. This doesn’t come as a surprise to us as developers, because very little time was available for that aspect of the game’s design.
Brigador Killers is in a different position and we think this new system of unlocks will address the criticism of there being “nothing to do”. Players will have reasons to return to certain locations, as opposed to the previous method of earning arbitrary sums of money to unlock pieces of text in a menu that was too many clicks away from the action.
We’re also exposing these details to give our modding community advance notice. Those who have made Brigador maps and mods in the past will likely have already thought of ways to go one step further with what’s been detailed in this post. After all, why give someone a carmine suit as a reward and have nothing to fight against? Why not place something more lethal in a map that can only appear in-game once the carmine suit itself has been unlocked? Or if entire layers of a map can be given custom properties, why not change that map entirely?
In a later post we will revisit the topic of gvars, predicates and storylets. We already talked before about how they handle dialogue, but what we weren’t able to say back then is we are also able to use those narrative systems to effect changes on gamestate in the much same way that ITEM_PICKUP resources can.
If you’d like to support our ongoing development efforts, consider making a purchase from our merchandise store where we sell minis, pins, t-shirts and many other items.
Both of these interactive elements have the following things in common:
- They are ITEM_PICKUP resources* in the game
- They have a condition assigned to them in SJTiled**
- They change state because of a Lua function***
** SJTiled is a fork of Tiled, a map-making tool used by several games
*** Lua is a scripting language that allows the game to execute code; a Lua function is a self-contained module of code[/expand]
WHY THE BRAINTAPE DISAPPEARS
To jog your memory, this is what the braintape looked like placed on its own:
This is what the data for the tape looks like in the Data editor tab of the debug panel:
The two things to note here are the resource path i.e. assets/data/pickups/kipple/pkp_braintape_01.json, and what’s contained in the on_pickup field i.e. UnlockTape. From here we go look at the same scene, but in SJTiled.
The three elements to pay attention to here are:
- The green key icon that is currently selected named “Braintape 01”, which is a scripting object
- The asset field under Custom Properties
- The disable_if field under Custom Properties
The asset field tells the game what asset to use for that object. Since it’s using the same asset path as the braintape in the data editor screenshot earlier, this means the game knows to use the assigned sprite for the braintape. If no asset was assigned to this object, the game would not render any sprite at all (or possibly crash in the attempt to load the map) and the player would not be able to interact with it.
The disable_if field contains the text __IS_UNLOCKED__. This field means that the object will not appear if the object has been unlocked by the player. Recall that the on_pickup field in the Data editor tab contained the text “UnlockTape”. Reversing the idea, this means the braintape will always appear in game until the player interacts with it. This begs the question: how does the game know to do this?
The bridge between SJTiled and the game engine is a Lua function called by the ITEM_PICKUP resource. Here is the relevant Lua function in Notepad++:
This function is titled UnlockTape. In case you missed it, the text that was inserted in the on_pickup field is referring to this exact function. In other words, we can insert functions into the data of ITEM_PICKUP resources in order to execute a module of code. What this module does when the player interacts with the braintape is:
- Increases by one the gvar labeled “tapes_delivered”*
- Executes the relevant code to change the gamestate
- Unlocks the resource according to the indicated filepath in the resource that is calling the function
- Saves that unlocked state to a local Lua file called gvar_data
So, once the braintape is picked up, it will be “unlocked” by the game engine. In SJTiled, we assigned this object to be disabled when it is unlocked. This means that when we come back to the same location…
…the tape is gone. Now that we understand how the braintape appears and disappears, we can look at the suit parts.
ONE MORE LAYER OF COMPLEXITY
Unlocking the carmine suit follows the same path as the braintape but with a couple more steps. Going back to our test level, all three suit parts are laid out in a line and have the same disable_if condition as the braintape to stop them from reappearing after being interacted with. Here is what the parts look like in SJTiled:
While this is what the parts look like in the game:
And all the resource data for the carmine suit parts looks something like this:
An additional field to pay attention to here that the braintape did not have filled out is menu_unlock. When the function unlocks this resource, the intel entries on these items also become available to read. Until the pickups are interacted with, they will look like this in the game’s Intel section accessed from the main menu:
The function being called in the Data editor for all the carmine suit parts is UnlockItem. Here’s what this Lua function looks like in Notepad++:
Simply put, this function unlocks the resource that is calling it (the three carmine suit parts), and saves that state information to the gvar_data Lua file.
When this map that contains the carmine suit is being loaded, two other things are going on. The first is another function called HandleItemUnlock, which looks like this in the file called mapstates.lua:
There is also a reference script called pickup_ref.lua which contains this:
In this reference script we can see the filepaths for the three ITEM_PICKUP resources that are also placed in the map in SJTiled, and we can see the filepath for the carmine suit itself.
The reason why this script is referenced is because of something called BRIGAHACKED. This is another object layer in SJTiled that has a custom property called luaload assigned to it which contains a string called, you guessed it…
…pickup_ref.lua. Combined with HandleItemUnlock, this reference script gives the layer of this map a list to check off when it is loaded. This reference script is also meant to be copied and modified to unlock other items on other maps.
So what about the suit itself? We already know how the suit parts disappear when interacted with - how is the suit being handled?
Returning to SJTiled, the suit is just sitting there, but when we look at the custom properties for it…
…Instead of disable_if, we have the custom field enable_if with __IS_UNLOCKED__ in the field. In other words, until the three parts are acquired and trigger the UnlockItem requisites, the suit is disabled from appearing on the map. When all three suit parts are acquired and the map is revisited…
…The three suit parts are gone as we would expect, but the suit is now available for use. It should be noted that for demonstration purposes, all three suit parts and the suit itself were placed on the same test map – but they do not have to be. Since the unlocks system is being handled by these Lua functions, which are entirely separate from the maps, the unlocks can be made to appear wherever we want them.
If we look at the “Fort” map that you see when you start the Secret Alpha build, the suit is placed there in SJTiled.
However, it is only until the player ventures out and finds all three carmine suit parts that they will find this reward waiting for them back at the fort.
WHAT’S IN IT FOR ME?
This unlocks system for Brigador Killers is how we are responding to some of the feedback the previous game Brigador has received over the years. While the quality of action and writing in lore entries was fine for enough players, Brigador’s unlocks system was found lacking. This doesn’t come as a surprise to us as developers, because very little time was available for that aspect of the game’s design.
Brigador Killers is in a different position and we think this new system of unlocks will address the criticism of there being “nothing to do”. Players will have reasons to return to certain locations, as opposed to the previous method of earning arbitrary sums of money to unlock pieces of text in a menu that was too many clicks away from the action.
We’re also exposing these details to give our modding community advance notice. Those who have made Brigador maps and mods in the past will likely have already thought of ways to go one step further with what’s been detailed in this post. After all, why give someone a carmine suit as a reward and have nothing to fight against? Why not place something more lethal in a map that can only appear in-game once the carmine suit itself has been unlocked? Or if entire layers of a map can be given custom properties, why not change that map entirely?
In a later post we will revisit the topic of gvars, predicates and storylets. We already talked before about how they handle dialogue, but what we weren’t able to say back then is we are also able to use those narrative systems to effect changes on gamestate in the much same way that ITEM_PICKUP resources can.
If you’d like to support our ongoing development efforts, consider making a purchase from our merchandise store where we sell minis, pins, t-shirts and many other items.
Share: 
