Laser Beast is now officially shipped. My favorite game development tournament, GDKO (Game Dev Knock Out), kicks off at the start of next year. That leaves me with a small window before I really have something major to work on.
Rather than start a new project, I plan to spend December building something that’s been on my mind for a while: a reusable game dev system library I’m calling BF Tools (Brainfart Tools).
My goal is to centralize all my systems and tools into one reusable place. I feel like I do well at creating independent systems with minimal dependencies. The problem is those systems are spread out across multiple projects rather than centralized in one place. I want as much of the reusable pieces in one place, and as independent as possible, so it can be used across any game jam or project with minimal work.
This article covers what I want BF Tools to contain and why. I need to list everything out as much as possible before building, to identify any potential dependency issues. It doesn’t discuss how I’m going to build it yet. That will be a separate article once I better outline the organization and structure.
Core vs. Genre Specific
My main focus is the systems used across all different genres. The ones that show up in nearly every project I build. These are what I’m calling my core systems.
However, I want a system flexible enough to handle genre-specific systems as well. I find myself building in certain genres regularly enough that each has its own repeating systems. Rather than importing systems from game to game, I want those in the library too. But they need to stay separate from core.
I’m keeping this in mind as I brainstorm and plan BF Tools.
Core Systems
Event Bus
The event bus is arguably the most important system in this whole list.
If I want everything else to be truly independent, systems need to communicate properly without holding direct references to each other. That only works if the event bus is solid from the start.
Scene Management
Nearly every game has scene transitions. Mine usually just fade in and fade out. With the short deadlines of game jams, I’ve never done others.
I want an expandable system. New transitions (like a wipe) should be added, implemented, and selected without having to adjust the scene management system itself.
Object Pooling
I always try to stay aware of performance issues. Object pooling is something I use in games where a large number of objects spawn or get destroyed rapidly.
The problem is I keep adjusting the pooling system per game. I want a version that just works without rebuilding each game.
Game Feel and Feedback
Haptics, screen shake, screen flash, and hit stop connect visual and physical feedback directly to player input. The game feels significantly better to play as a result.
I already have a decent version of each of these. What I want to fix is how tightly they’re coupled to other systems. Specifically how each one would connect to the event bus and get triggered by other systems.
Settings Menu
Right now, I build whatever a particular project needs and move on. It works, but it’s not reusable.
A universal settings menu that handles as many of the most common options as possible (audio, controls, accessibility toggles) without a rebuild each time would save a lot of time.
Genre Specific Systems
2D Platformers – Player Movement
Since focusing more on 2D platformers and metroidvanias, good player movement has become something I obsess over.
I’ve built a solid player movement system for Laser Beast. It makes a great starting point. But right now, it isn’t flexible enough to support a completely different move set or new abilities. That’s the hard part. I’ll need to figure out how to make it flexible but also reusable.
Top Down Shooters – Player Movement
Same problem in a different genre. I tend to reuse the same base movement logic across projects.
I want this version to be tweakable and expandable. If a future project needs a dash, the system should support adding that without a rewrite.
Roguelikes – Selection Systems
I love making roguelikes. Short deadlines make them quite challenging, though.
If I could streamline the selection system, that would free up more time for adding upgrade content. Though now that I’m writing this and thinking about it, there’s a lot of potential dependency issues in making a reusable roguelike system. I might have to table this one temporarily.
Why List This All Out
Repetition is a signal. If I’m rebuilding the same system across multiple projects, that’s usually a sign there’s a better way to handle it.
Writing all of this down does two things. It shows me what comes up most often, and it shows me where the biggest technical challenges are going to be before I start writing code.
From here, I can start mapping out dependencies and figuring out what order things need to be built in (such as the event bus).
What’s Next
December is focused on building the base of BF Tools, and I’ll be documenting the process here as I do.
GDKO starts in January. The immediate goal of BF Tools is to speed up actual development time during that tournament. I want to go all out this year. The more I can speed up the core systems specifically, the more time I can focus on better gameplay and more content. If something breaks or doesn’t work under jam conditions, I’ll have the break between rounds to fix it.
The next article covers the organization and structure of BF Tools. That includes the repository structure, individual packages, submodules, and how the asmdef and package.json setup tie things together.
0 Comments