Link to Game's Itch Page: https://bloodshot9001.itch.io/bulletro
Bullet Chambers is a work-in-progress FPS Roguelike currently being developed by myself. The elevator pitch is "If you know Balatro, this is 'Bulletro', where instead of a deck of cards, you modify a gun and its magazine." The game is inspired by the typical gameplay loop of similar roguelite and roguelikes, in particular Enter the Gungeon and Deadlink, but the main influence is of course Balatro. The concept initially started as "how would you convert the over-the-top naneinf builds in Balatro and convert them into ludicrous FPS weapons". The original "ridiculous" image in my head was stuffing a Pistol with Shotgun shells to fire a spread of projectiles, and then getting a sawed-off barrel attachment which also makes projectiles fire in a spread, for a multiplicative barrage of bullets from one trigger pull.
While I do intend to make the gunplay feel good, I do not intend to make this a fast-paced arena shooter like Quake or Doom. I instead want to emphasize the slow and methodical thought process that usually goes hand in hand with most roguelikes, but especially something like Balatro. I'm considering multiple difficulties, but at the moment the intended experience is the player will 2-3 "clips" of ammunition (all of these would have the same bullets that you have in your inventory, basically just 2 or 3 reloads), and for each clip you have after defeating all enemies, you'd gain some amount of money to spend on future shops. The player CAN reload after these clips are used, but each reload would hurt the player some amount. This means that while a player never runs out of ammo, if they don't have an efficient enough build, they will run out of health faster and potentially die sooner. Lower difficulties might just remove this health loss and settle for no money gained, but that's to be determined.
The game is being developed in the Godot engine, and careful planning and design is being taken into consideration at the onset, as a game like this heavily relies on its systems to interact with and compound upon each other. Below I will be providing updates on the game's progress along with my thoughts on the game's design, or any insights I've gleamed while working on it.
Dev Update 9: Demo Release
8/28/2025
A ton of stuff was developed over the past 2 days. Firstly, I got the Upgrade systems working. Then I got the Boss arenas and their debuffs up and running. With that, the demo is in its final state (at least for showing the concept off), so I prettied up the menus just a bit and now the game is available for download (link is now above, or you can go here: https://bloodshot9001.itch.io/bulletro).
This has been a great learning experience getting this concept to work, but I'm not done yet. I plan to get some feedback from people on what works and what doesn't, and from there I want to iterate on a lot of the systems I did not touch upon. Arenas and how they actually work is a big one, and of course more interesting enemies need to be added to give the game the depth it desperately needs, but as it is I'm happy with how the game feels, as all of the systems blend together to make some interesting moments (and that's with the bare minimum of upgrades).
Dev Update 8: Enhancements
8/26/2025
Bullets were a little one-note without a lot of ways to improve them, so with this update I've finally added the "Enhancements" to the game. An enhancement is an additional modifier to the bullets, granting them a variety of benefits. Some will increase the statistics of your bullet, such as adding a flat amount of damage or multiplying the damage multipliers by higher amounts. Others will cause additional effects, such as making bullets bounce one additional time, or making the bullet heal the player for 10% of the damage dealt. Or, the bullet can explode on impact (and if paired with bounciness, EVERY time it impacts).
In addition to being able to enhance the bullets in your magazine, when you pick a bullet as a reward there is a chance that it already comes with an enhancement. Not only that, but the more arenas you complete before choosing the bullets as a reward, the higher the chance the options come with an enhancement already. As I add more options and upgrades, I'll make the chances of getting the rarer/more powerful options go up with arena completion as well. Regardless, the enhancements have added an additional knob to turn for balancing which was desperately needed.
Dev Update 7: First Enemy
8/10/2025
At this point I want to get the game to look somewhat like a game with actual challenge, so I'm beginning to think about enemy designs. This first one is intended to teach the player's organically about how the Magazine system is going to work (i.e. after reloading enough times, you'll start to take damage). The enemies are not inherently dangerous (though they can damage the player with contact), but they can cause the player to hurt themselves if they aren't being patient with their shots.
The enemy was initially going to be a squirrel, a jittery enemy that sometimes stays still, but I found an otter model I really liked and since I'm not 100% sold on it being a squirrel specifically, I figure this was good enough to at least showcase the design.
Dev Update 6: Reward Selection and Arenas
7/15/2025
More or less the final big component that needed to be implemented, I have gotten a system for selecting the player's next reward and then spawning an arena for the player to fight in working. While there are no complex enemies at the moment, only the training dummies I've been using since I started, the principle itself works. The player selects a reward, and an arena spawns. When the player enters the trigger area of the arena, it spawns the required enemies. Once these are all defeated, the chosen reward screen pops up, and when something is selected or the reward is skipped, the player chooses a new reward to go after.
At the moment the menus are a little jarring since they are instant with no flourish, but I want to focus on the main gameplay itself first to get something testable in people's hands. Same goes for the arenas themselves, while these two arenas are obviously for testing, I think even something slightly more complex will also have the same entrance/exit just as these ones do. I do have ideas for these entrances to look like a giant rotating cylinder of a revolver, but that will be a future thing to iterate on.
One last thing to mention is the design of the rewards selection/arenas themselves. Currently my idea for the arenas and how progression will work is a combination of Balatro's antes/boss blinds and Deadlink's final area. In Deadlink, normally each time you cleared an arena you would be given 3 new/different rewards to choose from, but in the last area you were instead given 5 rewards along with the final boss. The boss was locked until you did one of the other arenas, but you could elect to pursue the other arenas before the boss to gain a little bit more of an edge, at the risk of potentially running into a mini-boss that would kill you anyway. Bullet Chambers will use a similar system for its rewards. Potentially the boss arena would require more than one other arena, but regardless of whether it's one or three, the boss arena would eventually open up but the player would still be allowed to go to the other rewards instead if they so desired. In addition, I want to make it so each time a player clears an arena, the future arenas get harder but the %chance of stronger rewards of that type go up. So if a player is searching for a legendary chamber, they could take on all of the bullet rewards first to then improve the chance of getting a rarer chamber.
The boss arenas would then be styled after Balatro's boss blinds. Instead of (or maybe in addition to?) bosses being bigger/stronger versions of enemies, or an enemy with some sort of gimmick, the arena itself would have a gimmick in the style of the boss blinds (like The Plant). For instance, one idea is the debuff "Trigger Linger", which would make it so when the player fires the first bullet, they keep firing the remaining bullets until they reload. This would make it so any chambers that require careful planning/waiting/positioning are harder to utilize effectively. Alternatively, there might be "Barrel Stuffer" which makes it so only shots within a certain distance deal damage, making longer range tactics useless. There's other ideas that don't necessarily completely nerf certain builds, for instance a boss arena that makes it so all bullets bounce, but ONLY bullets that bounced deal damage. It could mess up some builds, but not necessarily all of them. I basically want to emulate that feeling in Balatro where you have a Face build, only for "The Plant" to show up and suddenly it all comes crashing down.
Dev Update 5: Rewards Menu
7/10/2025
As mentioned previously, the UI systems are going to be the biggest component of the game, so I continue to work on these for now. Today, using some debug keybinds, I am able to open up a rewards menu for the player. Admittedly this one has a bit more interesting things to discuss, as I ended up developing a custom UI "SelectButton" for this menu to accommodate a player selecting two options from two different rows (i.e. overwriting their current bullets). What was VERY exciting was having the menu update depending on which reward type is given as a parameter. The implementation uses one Reward Screen for ALL of the reward types, simply taking in the options as resources. While I think my implementation can improve, this screen in particular has reinforced how important and useful Godot Resources can be for making robust interlacing systems easily.
Also, the establishment of the rewards menu means I no longer have to preset the player's current inventory, and can actually update it in game which is extremely nice for debugging and testing.
Dev Update 4: Player Inventory
7/7/2025
Most of the main gameplay is working, so at this point I decided to work on the UI systems as by necessity that is going to be a huge component of the game. While the reward screens are technically going to be more important, I decided to start simple and work on an inventory screen so that I could better show off what I have equipped for my videos when showcasing things.
Admittedly UI is my weakest skill in game development (aside from modeling, which I hesitate to say I have ANY skill in at all), but along with the previous system overhauls, this was a good opportunity to really figure out Godot's "Resources". I took about a day to really wrap my head around everything, but once I reworked the bullets/chambers to use resources more heavily than I was previously, it also made this inventory system surprisingly easy to get working. The actual design of the inventory itself is barebones, and I actually have ideas for a more 3d diagetic menu that would be the player flipping open a revolver to show the bullets and chambers they have equipped, but for now I want to get a vertical slice working and this menu will work exactly as I need.
Dev Update 3: System Overhauls and Tracking Chamber
7/1/2025
After getting the Bullets/Casings system working, I wasn't actually feeling good about the direction of the game. The fact that they both worked together to create a bullet was great, but at its core it felt like both Bullets and Casings were the exact same feature, just spread between two different types of items that the player would have to keep track of. It just felt more complex for no real depth gained. So I thought about it for awhile and came to a new, similar design.
Instead of the player combining Bullets and Casings and mix/matching them at will, I decided the two main upgrades the player would find would be Bullets and Chambers. Bullets would determine a lot of basic functions of the bullet (whether it fired fast, slow, in a spread fashion, how much damage it dealt vs. the damage multipliers, etc), while the Chambers would be responsible for more unique changes to the bullets. In addition, I decided that when players gain these as rewards, Bullets can be replaced with new ones, but CANNOT be swapped around (so if you have bullet in the first slot, but want to replace it with a better "first shot does more damage" bullet, you can replace the first slot but can't move that bullet to the second or third slot later). Chambers, on the other hand, are PERMANENT and can't even be replaced.
The design is fundamentally the same as it was with bullets and casings, but the decision to not make them swappable at any point, and in particular that Chambers are permanent, introduces a new layer of depth to the decision making process. Before, a player with good bullets and casings could just combine them in whatever slot was best (probably the first slot, but if they found a "higher damage if last shot" bonus, they could move things around to be the last shot instead). Now, players have to keep in mind that they might find a chamber that affects bullets the further away from the first shot it is, so they might want to put bullets in the later slots rather than immediately in the first.
As an example of this thought process (and to showcase another thing developed), I created a "Tracking Chamber". Bullets fired from this chamber will mark enemies hit (currently no visible mark, though that could be added in the future). If an enemy is marked, the NEXT shot fired will home in on the target, and will deal extra damage to the target based on the amount of time the projectile traveled in the air. This showcases a few of the design principles for the game. 1: Shotgun shells benefit from this weapon both because it helps overcome the inaccuracy and because each individual projectile gains its own bonus to damage, effectively multiplying the bonus by the amount fired. 2: If a player wants to benefit from this chamber, they have to plan around the shot AFTER the Tracking Chamber. If a player finds a shotgun shell/bullet, they may want to put it in the 2nd slot in case they find a Tracking Chamber later in the run. This is of course just one example, but I think it showcases the goal of the game perfectly.
Dev Update 2: Bullets and Casings
6/22/2025
I finally decided that for the purposes of a vertical slice of the game, I'd have the following features: a gun that contains 8 pieces of ammunition, each with 2 components: Bullets and Casings. The bullet will determine the type of projectile that is fired, along with the damage, damage type, and some of the more special effects. The casing will determine how the bullet/projectile is fired, so a shotgun shell would fire in a spread pattern dealing less damage per projectile, a sniper casing would be fast and have a higher headshot multiplier but deal less to the body, etc.
The example for this even showcases this in action, where I have a "Bouncy Bullet" and a "Shotgun Shell" to create a shot that fires in a spread pattern and bounces, dealing extra damage after each bounce. I think this will create interesting combinations in a similar vein to Balatro's "Chip x Mult" idea: a player will be able to find ways to increase the flat damage of their projectiles (maybe before OR after multipliers related to number of projectiles), before adding the multiplier of the weapon itself.
Dev Update 1: Bullets and Damage Numbers
6/19/2025
While I worked on this project before this, it was mostly setting up my Input System and a basic controller, which is my usual first step for any project. I'm still getting back into game development, and haven't completely solidified what the gameplay loop will be (mainly thinking in terms of bullets and how a player will go about selecting them to get ridiculous combinations). Because of this, I decided to just get a simple debug weapon that's a bit more "hard-coded" than I normally am comfortable with.
In the past I've over developed by trying to create elegant systems that can accommodate tons of future changes and additions, and while I will not be abandoning that thought process, I want to try and push myself into actually making something tangible and playable rather than focusing so much on getting the systems "perfect".
That said, I am very happy with how the debug numbers turned out. I based them loosely on how they look in Borderlands 2, and I liked how my implementation using Bezier curves and slightly random positions makes the numbers look when flying out.