I Only Wrote One Weapon for My RPG… But Thousands Exist
That title is technically true.
If you opened the Monster Mercs codebase and searched for weapon classes, you’d only find one.
Not one for swords.
Not one for axes.
Not one for magical monstrosities or cursed relics.
Just one weapon class.
And yet the game contains thousands of possible weapons.
So how does that work?
The short answer is that the weapons themselves aren’t defined by code.
They’re defined by data.
Rethinking “Build Small Games”
One of the most common pieces of advice in indie game development is:
Build small games.
It’s good advice. Most indie projects fail because they try to do too much before they have the structure or experience needed to support it.
Too many mechanics.
Too many systems.
Too much content.
Eventually the complexity collapses under its own weight.
But when I started building Monster Mercs, I found myself pushing on that idea a little.
Part of that comes from my background. I’ve spent over twenty years building large software systems, and that experience strongly shaped how I approached the architecture of this game.
Not because I wanted to ignore scope discipline, but because I wanted to redefine what “small” meant.
Instead of building a small game, I focused on something slightly different:
Build small systems that scale.
That philosophy has shaped almost every technical decision behind the project.
One Weapon, Thousands of Possibilities
Weapons are a convenient example, but they’re not the only thing defined this way.
In Monster Mercs, most gameplay elements are defined through data rather than custom code. That includes things like:
weapons
abilities
enemies
affixes and modifiers
item restrictions
interactions between systems
The game code defines the framework of behaviors these things can participate in.
The data defines what actually exists in the game.
Weapons just happen to be a very clear example of how this works.
At the code level, there is essentially one class that represents a weapon. That class doesn’t contain the unique gameplay logic for every weapon in the game. Instead, it acts as a container that reads structured data describing how a specific weapon should behave.
That data defines things like:
the weapon type
tags and restrictions
ability triggers
modifiers and affixes
how the weapon interacts with other gameplay systems
Because of that, creating a new weapon rarely requires writing new code.
Instead, it usually means defining a new configuration that combines existing behaviors in different ways.
For example, a weapon might simply be defined as data that says:
Weapon Type: Halberd
Base Damage: 42
Tags: Heavy, Two-Handed
On Hit Effect: 20% chance to trigger Lightning Chain
Affix Pool: Shock, Brutal, Stormcaller
None of that requires writing a new class.
It’s simply a configuration that tells the system how this particular weapon behaves.
In other words:
The code defines the rules of the system.
The data defines the content inside that system.
The long-term goal is something closer to a meta-engine built on top of Unreal.
Not replacing Unreal — Unreal still handles rendering, networking, physics, and animation.
But above that sits a gameplay layer where new items, mechanics, and even entities can be created simply by defining structured data.
The dream is simple:
Add rows of data, get new gameplay.
Separating Design From Implementation
One of the biggest benefits of this approach is that it separates design from implementation.
In many projects those two things are tightly coupled.
If a designer wants to try a new mechanic, someone has to implement it first. That means writing code, wiring systems together, and testing edge cases before you even know if the idea works.
That creates friction.
When implementation is expensive, experimentation becomes rare. Designers start playing it safe because every new idea carries a technical cost.
A data-driven system changes that dynamic.
Because most gameplay behaviors are defined through configuration instead of bespoke code, it becomes much easier to experiment.
I can try things like:
new item behaviors
different ability triggers
unusual interactions between systems
new combinations of existing mechanics
Without needing to build entirely new infrastructure every time.
That lets me spend far more time wearing my design hat, experimenting and iterating quickly.
Game design is inherently experimental. Many ideas that sound great on paper simply don’t survive first contact with players.
The faster you can test ideas, the faster you discover what’s actually fun.
This Approach Isn’t for Every Indie
It’s also worth saying something clearly:
This approach won’t make sense for every indie developer.
The advice to build small games exists for a reason. Many projects run into trouble when developers attempt to build highly abstract systems too early.
Without enough experience, that kind of architecture can easily turn into over-engineering.
You can spend months building infrastructure instead of building a game.
For many developers, the fastest path to finishing something is simply implementing the features they need directly and moving on.
That’s perfectly valid.
The reason I’m comfortable leaning into a more system-heavy approach for Monster Mercs is largely because of experience.
I’ve spent more than twenty years working as a software engineer, building systems that need to grow and evolve over time. Patterns like data-driven design, behavioral composition, and separating systems from configuration show up constantly in large-scale software systems.
Those ideas translate surprisingly well to games — but they’re also easy to misuse if you don’t know where the complexity hides.
In my case, leaning into that experience felt like the right bet.
Instead of simplifying the game down to something tiny, I focused on simplifying the framework that builds the game.
The Real Goal
There’s a lot of good advice in indie development that says:
Build small games.
For Monster Mercs, I took that idea and shifted it slightly.
Instead of building a small game, I tried to build small systems that scale.
Systems where new items, mechanics, and behaviors can be defined through data instead of custom implementation. Systems where design and experimentation move faster because they aren’t blocked by engineering work every time a new idea appears.
But the real goal isn’t scalability.
The real goal is building something fun for players.
My hope is that by investing in systems that reduce implementation overhead, I can spend more time designing, experimenting, and improving the parts of the game players actually experience — and less time rewriting plumbing every time a new idea appears.
So the bet behind Monster Mercs is simple:
Build small systems that scale, so more time can be spent solving the only problem that really matters — making the game fun.
