Building, Bit By Bit

New items, new rooms, new visuals, new noises. This month, my work on Bit Crusher was all about a whole lotta new. But not too much new. I took my time to build a system that makes sure I could keep making new, so that new new is easier to make new.

Modularity In Practice

The big push this phase was getting the foundation to a place where adding new content doesn't feel like a chore. When I get an idea for a new item, or room, or whatever, I want the speed at which I can develop that new feature to be fast enough to where I don’t run out of steam halfway through. Additionally, since this is a roguelike, I will soon be developing a system that allows a player to boost or modify the numbers within this system as they progress through a run. Risk of Rain 2 does this with items, Hades does this with boons, Slay The Spire does this with artifacts. They all have a core system, and ways to augment stats and behavior within that system. In addition to what I’ve already mentioned, this foundation that I’m building also needs to serve this kind of mutable system.

This was important for me developing Bit Crusher, but also for someone playing it. As a player, when items and rooms share similar structure, you can dependably rely on how items or mechanics that tweak the system will do so. It opens up a reward track for players who LEARN the system and can figure out how to GAME the system. Going back to Risk of Rain 2, you can always depend on the Lens Maker’s Glasses to increase your critical rate, which requires a system in place that allows that item to target the same stat on each character. Additionally, this item means very different things between someone playing the ranged and high-rate of fire Commando and someone playing the hard hitting melee character Loader. A reliable, learnable, and MUTABLE system like this is a really great way to implement depth and complexity within a game. For Bit Crusher, I am hoping to accomplish something similar: a player might think “maybe instead of increasing damage for my gun, I want to decrease its cooldown.” or “this item isn’t really my style because its damage is so low, but maybe I can keep an eye out for effects or items that remedy that.” The same applies to rooms: “my health is low, and I am close to beating this zone…I’ll go with a 1-bit room with less enemies and play it safe.” 

In order for me to create ways for the player to game the system, though…the system needs to exist. So, I built out shared base classes for player equipment and rooms so that everything follows the same skeleton. New items this phase: freeze ray, bubble, ram, and gun. (Ram not shown in the demo viD below)

Offensive items are built off a shared class that consists of variables such as cooldown and damage. Defensive items are similar, but have a variable that measures their effect and a similar cooldown variable. New rooms: 1-bit, 2-bit, and 3-bit. The rooms are only differentiated by the number of waves of enemies per room, and I’m planning on making more unique encounters for certain rooms. And while there aren’t any features in place yet that take advantage of the system I’m setting up, I have confidence now that the system is somewhat prepared for me to introduce those features. For now, this is a good baseline.

SWAG (SENSORY WORK ASSISTED GAMEPLAY)

Speaking of a unified system: a really easy way to make everything feel more cohesive is with visual and audio cues. While I intend to tell the player how the system works, it will certainly be easier to do if I am also SHOWING the player the effects of the system through audio and visuals. So I also decided to work on more SWAG — Sensory Work Assisted Gameplay. Patent pending.

The idea is the game should be communicating through what the player sees and hears, not just through a health bar in the corner. So I pushed on two things: make what's already there feel better, and add what was missing.

In regards to what was already there, I added some spice to the ‘bits’ the player has so far (which is basically your ‘score’) as well as revamping how the background looks. A lot cleaner looking, while still maintaining the low pixel style. I want the background to look interesting just because it gives Bit Crusher some more whimsy, but the score looking cool was a bit more important to me. The indicator of your current progress needs to be as flashy as possible. “Number go up” is a good start, but that reward cycle needs to be as satisfying as I can make it. This will certainly not be the last pass on this idea.

The background now reacts to hits and deaths. Under the hood, I actually completely changed how the background is displayed, so that everything felt a bit more cohesive. The bit value of the room you’re about to enter is displayed when you hover over it with your mouse. And the game has sound now. Firstly, I have hit sounds and “fake” hit sounds for when an enemy gets hit during their i-frames. When a player engages with the system in a way that might reduce an enemy’s i-frames, these audio cues will be a lot more meaningful. I also worked on a death sound, which is a necessity. 

I also have music, but I’ll be honest and admit that it is kind of hard to bring myself to showcase any of it. That stuff feels like much more of an art, whereas all the stuff I am usually talking about here is much more so system design and stuff. Due to that, I’m inclined to a “when it's ready” approach to showcasing music in these dev logs, just with how much more of a form of personal expression it feels like.

One thing I’m really proud of is how I show enemy health, which is also now visible…in the form of dice. You see the health values when they spawn, but you won’t know who is who until they start dying. I play a lot of Dungeons and Dragons, and I actually like the idea of the player not knowing exactly what an enemy’s health may be. I feel like this is a good middle ground. This might all seem like small stuff, but it makes a real difference in how it feels to play.

Conclusion

Happy with where things are heading. Adding content is actually starting to feel like adding content, which hasn't always been the case. It usually felt more like having to learn how best to implement a feature in a way that is Godot friendly, then having to figure out how to code it, but also what not to code since the editor provides so much abstraction that isn't always directly visible, and then I try implementing it and it doesn't work, then I get mad, then I want to do something else, then I go play Kenshi and my skeleton character gets knocked out for the 40th time and since he's a robot fixing him is insanely expensive so now I'm double mad and everything sucks.

Anyways, I'm still a little uneasy that Godot probably has built-in solutions for some of what I've been doing manually — nothing catastrophic yet, but it's in the back of my head. I have a side project that I recently started working on as a way to pivot away from Bit Crusher, so I can come back to it with some more tools in my tool kit, so to speak.

But until then, I am finally ready to move towards the part of Bit Crusher's development where its personality will truly start developing. It is time for phase four.

Card game.