My game development process is structured and logical. That’s not an accident. I’m a professional programmer by trade, and I tend to approach game planning the same way I approach software architecture: understand all the pieces first, then figure out how they fit together.
This isn’t the only way to plan a game. It’s probably overkill for most people. But it works for me and my brain. And honestly, I’ve come to love the process itself.
Note: this is my full planning process for entire projects, not daily dev sessions.
Scope Starts With the Player
Before I think about levels, enemies, or systems, I ask one question: what can the player actually do?
Run and jump? Attack? Dash? Wall climb? Equip items? All of those can make for a great game. But as a smaller developer, I operate by one rule: the shorter the project timeline, the fewer things the player should be able to do.
- Weekend game jam: one player action. Maximum.
- Two-week jam: maybe two.
- Multi-month project: now you can start expanding.
The goal isn’t to limit fun. The goal is to do fewer things incredibly well, rather than many things poorly. Every system, obstacle, and mechanic should exist to challenge or expand that core action. Nothing in the game should exist outside of that scope.
In my current project, Laser Beast, the entire game is built around one thing: making running and jumping feel as good as possible. That’s the foundation. The movement controller came first, and everything else had to earn its place.
The lasers, checkpoints, moving platforms, collectibles: none of them change how the player moves. They exist to create interesting situations around that movement. The fun isn’t in adding complexity to the controls. It’s in finding new ways to challenge the thing the player already knows how to do.
See more of Laser Beast here.
Build the Smallest Possible Loop First
Once I know what the player can do, I think about the smallest thing that still technically qualifies as a game.
For a platformer, that looks like this:
- A title screen
- A gameplay scene
- A player that can run and jump
- One obstacle (even a single box collider works)
- A way to end the level and return to the title screen
Admittedly, not a very fun game. But it’s a complete loop. And building it forces me to think through the systems that matter most: player movement, input handling, scene loading, basic progression, and a menu. Nothing else gets added until that loop works.
I don’t add enemies here unless the game is literally impossible without them. Mario is playable with just a gap and a flag. You don’t need pipes or Goombas to jump over something. Get the loop running first.
Technical Design Documents
This is where my programmer brain takes over completely.
I spend time writing a Technical Design Document, or TDD. It’s a standard document in professional software development. These documents cover what all the major systems are, how they connect, and what other systems they depend on.
It is not really a Game Design Document because it doesn’t touch art direction, narrative, or level themes. More on that in a minute.
My TDD process looks like this:
Systems First
I list out every major system the game needs. Player controller, input manager, enemy AI, save system, UI manager, scene loader, and so on. For each system, I note:
- What other systems depend on it
- What events it likely triggers or listens for
- Whether it is essential to the core loop (vs optional expansion and polish)
Separating core from optional matters. It drives development order. Core systems get built first. Everything else waits.
Event-driven architecture is important to me because I want systems I can reuse in the future. That means keeping them decoupled. Systems should communicate through events, not direct references. Each system has one job, one place to trigger, and one place to listen. Clean boundaries mean I can lift a system out and drop it into the next project without rewriting half of it.
Classes Second
Start with the systems the player will feel directly. Player movement, input handling, anything that touches the controls. These deserve the most attention at the class level because the player experiences them on every single frame. Getting the structure right here pays off immediately.
Complicated systems are a close second. A boss system for a Metroidvania sounds manageable until you actually map it out. Hierarchical state machine for phases, another for individual moves, the moves themselves, hitboxes, animations, audio triggers. It’s an entire sub-system hiding behind one bullet point in your systems list. (Especially if you want it to be reusable.)
Not everything needs this level of detail. Haptic feedback, for example, is usually simple enough to figure out as you build it. Use your judgment. If a system has a lot of moving parts or sits at the center of everything else, break it down. If it doesn’t, move on.
The “Good Enough” Rule
I do not wait until everything is figured out. I aim for roughly 75-80% coverage. Enough to understand the major systems and where the gaps are. Then I stop and start building.
The gaps don’t disappear. They just move to the background. And in my experience, my brain keeps working on them without me forcing it. By the time I hit that system in development, I usually have a clearer idea of what to do than I would have if I’d tried to force it during planning.
Waiting for 100% means never starting.
Scope Looks Different for Different Projects
The TDD process scales with project size.
For a game jam, I still list out the systems, the events, and how things connect. That part doesn’t change. What I skip is the class diagrams. I’m not breaking down every class for a 48-hour build. I keep it at the system level and move fast.
For longer projects, I go a lot deeper. And I start early. Right now, while actively developing Laser Beast, I already have the high-level plan for my next game running in parallel. Laser Beast is essentially the foundation. Most of the core systems carry over. The planning for the next project focuses on what’s new or different, the systems a Metroidvania needs that a precision platformer doesn’t. Laser Beast is the stepping stone. The next game builds on top of what I already know works.
What This System Doesn’t Cover
This process doesn’t account for art, music, or narrative. No asset lists, no audio direction, no visual style guidance. And honestly, that’s fine. It isn’t meant to. It’s a technical document built around me doing programmer work.
But here’s what I like about it: the framework is flexible. There’s nothing stopping me from expanding it. I could add an art pipeline, a music direction section, an asset checklist for a composer. At that point it starts to look more like a full Game Design Document. And from there, I could extract role-specific documents: one for the artist, one for the composer, each with exactly what they need and nothing they don’t.
It isn’t there yet. Right now it’s a solo programmer’s tool. But the foundation is solid enough to grow into something bigger when the team does.
A Note on Skill Level
Thinking at this level of abstraction is not easy. I’m still learning it myself.
It’s a skill that comes from years of writing production software, not from reading a tutorial. If you’re newer to development, a simplified version of this approach is still worth trying. But don’t be discouraged if it doesn’t click immediately. Even the smallest games have more moving parts than they appear to. That surprises almost everyone the first time.
The best way to practice this is to write the TDD without ever building a game. Next time a game jam theme drops, treat it as a planning exercise. Scope the player verbs, list the systems, map the events, and stop there. No code. Just the document.
You get the planning practice without the time commitment. I do this regularly and I’ll cover it in detail in a future article.
0 Comments