Building Gameplay Systems Designers Can Control
How data-driven gameplay systems, designer tooling, and clear ownership boundaries reduce dependencies between designers and engineers, enabling faster iteration and more scalable game development.
One of the biggest bottlenecks in game development isn't rendering performance or complex gameplay systems.
It's waiting.
Waiting for an engineer to become available.
Waiting for a small balance change.
Waiting for a code review.
Waiting to find out whether an idea is actually fun.
On smaller projects this isn't usually a problem. The engineer makes the change, everyone moves on, and the project keeps going. As projects become larger and more iterative, however, this workflow starts breaking down. Designers depend on engineers for every adjustment, while engineers spend their day making small changes instead of solving bigger production problems.
Eventually, engineering becomes the bottleneck without anyone intending it to.
Over the years I've come to believe that one of the most valuable things a gameplay engineer can build isn't another gameplay feature.
It's reducing dependencies between people.
Recognizing the Real Problem
Early in my career, I exposed very little to designers.
That wasn't because I wanted to keep control of the systems. It was simply how we worked. Designers created documents, programmers implemented them, and every change, no matter how small, had to go through engineering.
At first, that seemed completely normal.
Around my second year, I started realizing this workflow wasn't going to scale. Every balance adjustment, every gameplay tweak, every iteration depended on whether an engineer had time to make the change.
The issue wasn't that designers had bad ideas.
The issue was that every idea had to wait.
That realization changed how I thought about gameplay engineering.
During one of our internal game jams, I wanted to test a different approach. We built a first-person narrative game set inside the cockpit of a robot, and for the first time I invested time in creating tooling specifically for designers.
The tools weren't particularly sophisticated.
Looking back, they were pretty rough.
But they proved something important.
Programming wasn't just about implementing gameplay anymore. It could also remove friction from the people making the game.
I've looked at gameplay systems differently ever since.
Building Systems Designers Can Control
When I say "designer-controlled," I don't mean giving designers access to the codebase.
I mean giving them control over the parts of the game they naturally iterate on.
Damage.
Cooldowns.
Spawn rates.
Animation references.
Audio.
Visual effects.
Progression values.
The engineer still owns the systems behind those values.
Our responsibility is deciding how those values interact, validating unexpected input, and making sure the game continues to behave correctly.
The designer owns the content.
The engineer owns the rules.
That separation creates healthy boundaries without creating unnecessary dependencies.
Separating Data From Logic
One principle that has consistently improved the way I build gameplay systems is separating data from logic.
Not because it's academically cleaner.
Because it reflects how teams actually work.
The moment I realized I was changing the same damage values every other day, it became obvious the problem wasn't the balance.
The problem was that designers couldn't change those values themselves.
Gameplay data naturally changes throughout development.
Damage values.
Enemy stats.
Progression tables.
Spawn probabilities.
These belong somewhere designers can iterate quickly.
On one of our projects, progression balancing was managed through spreadsheets instead of Unity inspectors.
That wasn't because Unity couldn't store the data.
It absolutely could.
The designers already lived inside spreadsheets. They could compare values, use formulas, visualize progression, and iterate much faster than they could inside the editor.
Instead of asking them to adopt my preferred workflow, engineering supported theirs by allowing validated spreadsheet imports.
The opposite is also true.
Not everything should become data.
Systems like save management, networking, gameplay state transitions, and validation are better kept inside code. They're responsible for maintaining consistency across the game, and exposing them would create more problems than it solves.
There's no universal rule for deciding where that boundary should be.
Every project is different.
The important question isn't "Can this become data?"
It's "Who benefits from changing this?"
(A bit about who's writing this: 10+ years shipping gameplay systems on PC, Switch, and mobile →)
Designing for Iteration
One thing that's changed over the years is how I start implementing new features.
Earlier in my career, someone would ask for a feature and I'd start thinking about implementation.
Now I spend more time asking questions first.
What are they actually trying to accomplish?
What parts are likely to change during playtesting?
How many times will this feature realistically be revisited?
Those conversations often uncover a much better solution than the original request.
Instead of implementing exactly what was asked, I can build something that allows designers to continue experimenting without coming back to engineering every time.
That collaboration happens earlier.
The iteration happens later.
Everyone spends their time where they're most valuable.
Engineering Is Always a Tradeoff
Building flexible systems isn't free.
It usually means spending more engineering time before the feature is even playable.
Validation needs to be added.
Editor tooling needs to make sense.
Unexpected input needs to be handled safely.
You're no longer writing software only for engineers.
You're building tools for designers, QA, producers, and sometimes people who have never looked at the code.
That changes what "good engineering" looks like.
It's more work upfront, but after the third or fourth balancing session the investment starts paying for itself.
At that point, engineering stops being the department that changes numbers and starts enabling everyone else to move faster.
A Production Example
One project where this paid off was Heist Hunters.
Character and vehicle progression were driven by level-up tables maintained by the design team.
Originally, progression relied on static stat increases, making balancing difficult and limiting the team's ability to fine-tune the game's economy.
Instead, every level contained its own configurable values.
Designers made changes in spreadsheets, imported the data into Unity, and immediately validated the results in-game.
Engineering wasn't responsible for every balance change anymore.
Engineering was responsible for making balancing easy.
That distinction made a much bigger difference than the implementation itself.
Making Good Tools Is Its Own Skill
One mistake I made early on was assuming that exposing data was enough.
It wasn't.
Sometimes the data existed.
The designers just couldn't find it.
Sometimes the naming didn't make sense.
Sometimes the ScriptableObject lived three folders deeper than anyone expected.
Sometimes people simply didn't know the feature existed.
We documented our systems in ClickUp and on our project server, but documentation alone wasn't always enough.
That experience changed how I think about tooling.
Making tools accessible is just as important as making them functional.
Good naming.
Clear organization.
Helpful validation.
Discoverability.
Those things don't sound exciting, but they're often the difference between a tool people actually use and one they forget exists.
Avoiding Overengineering
I've also learned that not every system deserves this treatment.
Sometimes exposing a variable saves everyone time.
Sometimes it creates unnecessary complexity.
The difficult part is knowing which is which.
That decision depends on the project, the production schedule, the people using the system, and how often it's expected to change.
Trying to predict every future requirement usually isn't worth the effort.
Supporting the next hundred iterations often is.
Looking Back
If I could go back and teach one lesson to my younger self, it wouldn't be another design pattern or architecture principle.
It would be this.
Gameplay engineering isn't just about building systems.
It's about enabling other people to build with those systems.
That shift in perspective changed how I collaborate with designers, how I approach tooling, and how I think about production as a whole.
Final Thoughts
These days, I judge gameplay systems with a simple question.
If I go on a holiday to the beach next week, can the designers still build content?
If the answer is yes, I probably designed the system well.
To me, that's what good gameplay architecture looks like.
Not removing engineers from the process.
Removing unnecessary dependencies so everyone can spend more time building better games.
What's Next?
If this way of thinking about tooling and team collaboration resonates, feel free to look into my background and what I've shipped.
Based in Japan • Available for technical gameplay implementation and cross-disciplinary development.