How we designed a 60+ part modular boss system

When we started Boss Lab, the idea was simple: let players build their own boss monster out of parts, then watch it fight. The hard bit was making "build your own" feel meaningful instead of cosmetic. This post is a plain look at how we approached a modular boss system with 60+ parts, what worked, and what we're still fixing.

Boss Lab is a free Android game built with Phaser. You assemble a boss, upgrade it, and watch it fight through 100 stages, plus there is an asynchronous Arena PvP mode. There are no forced ads, and the art and audio are AI-assisted.

Start from slots, not from parts

Before we drew a single part, we defined what a boss is: a set of slots (think body, limbs, weapon-like attachments, and so on). Every part belongs to a slot type, and a boss is just a collection of filled slots. This had a few benefits:

The builder UI is generic. Adding a part means adding data, not writing new screen code.
Rendering is generic too. The game draws each slot's part at an anchor point on the body.
Saving a build is tiny: a list of part identifiers and upgrade levels.

If you are making anything modular, we'd strongly suggest deciding on slots first. It is the decision that made everything else cheap.

Every part needs a job

With 60+ parts, the biggest risk is a pile of near-duplicates where one option is always strictly better. Our rule was that each part must have a clear role, a readable look and a trade-off. A heavy part might add durability but slow the boss; a flashy one might hit hard but leave a weakness elsewhere.

We kept the stat vocabulary small on purpose. If a player can't roughly guess what a part does by looking at it, the system is too complicated. We would rather have fewer stats with distinct feel than a spreadsheet of tiny numbers nobody can reason about.

Data-driven everything

Parts live in data files rather than in code: name, slot type, art reference, base stats, and upgrade curve. That let us add and rebalance parts quickly, and it keeps the code that runs a fight small. When we changed our mind about a part (which happened a lot), it was an edit to a data entry, not a refactor.

Phaser was a good fit here. We wanted a fast feedback loop in the browser and a 2D toolset that already handled sprites, tweens, particles and UI layers, so we could spend our time on the game design.

Upgrades and the build-watch-learn loop

Upgrading is where the builder becomes a long-term game. Players put resources into parts, which makes them think about which parts are worth investing in. The core loop we wanted is: build, watch the auto-battle, work out why you won or lost, then rebuild.

For that to work, battles must be readable. On a phone screen a lot happens at once, so we leaned on strong silhouettes, clear hit feedback and restrained effects. We removed a lot of visual noise that looked great in a trailer but made fights hard to follow. Ideally, after a loss you can say "my boss was weak on the left side" and go fix it.

Combining parts in ways we didn't predict

One of the best moments in development was watching testers find odd combinations we hadn't planned for. Some were fun and became things we embraced; some were clearly too strong and needed rebalancing. Balancing is ongoing, and we still tweak things as we see how people play. We don't claim the balance is perfect.

Packaging for Android

Shipping a Phaser game as an Android app brought its own chores: different screen sizes and aspect ratios, comfortable touch controls, memory on lower-end devices, reliable saves, and testing on real hardware instead of trusting a desktop browser. Plan more time for this than you think you need.

Being upfront about AI-assisted assets

The art and audio in Boss Lab are AI-assisted. We use these tools as part of our workflow and would rather say so openly. The design, systems, code and balancing are ours. Having 60+ parts with a consistent look would have been a much bigger undertaking for a small team without them, but it also means we spend a lot of time curating and fixing what the tools produce.