How to Architect Your Games so They Don't Fall Apart Two Weeks In
The System Stack Method
You start a new game project. Excited to bring your vision to life, you jump right in without thinking too much about structure.
You use the techniques that your education provided you—Object Oriented Programming and the SOLID principles.
You try to add a new feature to the game, but it’s breaking two others.
You hack something together—it works!
You continue working...
Excited, you send a build to your friend.
She doesn’t play the game how you would and runs into game breaking bugs.
You try to reproduce the bug, but you struggle to follow the logic through the web of objects. Printing out values doesn’t seem to be helping.
You rewrite that part of your object hierarchy—the bug is gone!
You continue working...
Two weeks in—you want to add a dash ability. But you can’t figure out where it goes.
Are abilities objects that run their own update methods? Should it be code in the PlayerController? What if I want enemies or NPCs to be able to dash?
You grind against the friction of these decisions, doing the best you can to keep it together.
Every time you think about adding something new, you feel resistance because you know it comes with more bugs.
You burn out. You’ve hit the Two Week Wall. Again.
Why can’t I get this right?
I know I can program... why is this not working?
The doubt turns toxic.
I’ll never be able to do this.
I’m a failure.
This isn’t the first time you’ve felt this way—a graveyard of abandoned games offer silent condemnation.
You tell yourself that next time you’ll get it right. But you don’t.
It’s not your fault. You’re capable. You’ve been taught a paradigm that doesn’t map to reality.
Individual objects talking to each other, keeping state, with no concept of shared lifetimes—it adds an almost insurmountable level of complexity to one of the most complex types of programs—a video game.
The developers who built their own games and engines weren’t geniuses (mostly).
They stopped treating game development and programming as an exercise in real-world modelling. They looked at what computers are and how they work.
Computers execute instructions sequentially from beginning to end. Data is stored in blocks of memory. That’s the reality.
There are no arbitrary “objects” inside your computer—just deterministic circuits.
If computers execute sequentially, then games shouldn’t be a web of objects, they should be more like an assembly line.
The user input is recorded, the state is updated, the result is drawn to the screen and played through the speakers.
You’ve probably seen this before: input, update, render. It’s the standard order across games for a reason.
Here’s a method you can use to map out your game’s assembly line.
The System Stack
The System Stack is a method for getting past the Two Week Wall.
It’s not a programming paradigm. It’s a planning method that will take an hour, but save you a hundred.
It will help you tease out what systems you need to build before you write a line of code. You can stop asking “where does this go?”, because you’ll have a road map.
Let’s walk through how you might structure a JRPG using this method.
The System Stack method has a flaw—it requires intuition or experience of some kind. However, this flaw can be mitigated by the use of an LLM. As such, I’ll outline the manual version and the LLM version below.
Manual Version
Verb Extraction
In a few sentences, write down what the player can do in this game. For example:
Explore a vast fantasy world. Battle a variety of monsters. Help people with their problems.
Extracting the verbs from this description gives you:
Explore
Battle
Help
Verbs to Systems
Ask yourself a question. Answer the question and ask any further questions that arise from the answer, until you have pulled all the threads.
Here’s a (very cut down) example. The real thing is long and will take some time—but it pays for itself a hundred fold.
Q: The player is going to explore the world—what’s required for that to make sense?
A: A world. A character in the world. Some way to move through the world.
At least 3 threads appear: world, character, and movement.
World
Q: What will the world look like? 2D? 3D?
A: 3D world, but like a diorama, like Octopath Traveler.
[Scene System, World System?, Asset Pipeline]
Q: For the Octopath Traveler look, how do they achieve that?
A: I don’t know—will require a technical research spike. (I do know, it’s a mostly shader work—depth of field, lighting, some volumetrics)
[Custom Shaders]
Q: Octopath has ramps, will this game have ramps?
A: Yes.
[Collision System that handles ramps]
Character
Q: What will the character look like?
A: A 2D pixel art sprite.
Q: Animated?
A: Yes.
[Sprite and Sprite Animation System]
Movement
Q: How will the character move around the scene?
A: The player will press WASD or move their left stick on the gamepad.
Q: So the game supports both KB/M and Gamepad?
A: Yes
Q: Can they jump?
A: No.
[Input System]
... and so on ... it took me about an hour to do for the JRPG.
Once you have identified as many systems or requirements as you can, you are ready to move onto the next step.
Action Extraction
You probably have a much deeper understanding of your own game idea from the exercise above. That’s important for this step.
Some systems arise from what the player can see, feel, or their expectations.
So here’s the 3-pass method:
1. Verbs to Actions to Systems
For each verb, ask “What does the player do here, and what system(s) makes that possible?”.
Fill out a table like the one below.
2. Simulation Systems
Question: “What is changing or running in the background?”
Enemy Respawns: Time System, Spawn Manager
Dialogue/Quest flags/state: Quest/State System
Time of Day: Day/Night, Time System
NPC Schedules: Time System, NPC Schedule System
3. Presentation Systems
Question: “What makes the game feel alive?”
Animated sprites: Animation System
NPCs walking around: NPC Schedule System
Talk to any NPC: Dialogue System, Input
Flickering lights?: Shaders, Lighting
Weather effects?: Shaders, Particles
Animated grass?: Shaders
Sound effects and music: Sound System
Creating the System Stack
Now that you’ve unearthed all of these systems, you’ll need to organise them by dependency so you know where to start.
1. Write Down System Dependencies
For each system, ask:
What does this system depend on?
What does this provide to other systems?
For example:Combat depends on Stats, Abilities, Inventory, UI, Entities, Scenes, ...
UI depends on Input, Combat State, Inventory State ...
Inventory depends on Item Data, Save Game State ...
Try to be exhaustive, I’ve kept it short for brevity.
2. Group by Dependencies
Group systems together based on dependencies.
The trick is unidirectional data flow: Systems may only depend on data from prior layers. They must not reach forward to systems that depend on them.
Here are my groupings (top-to-bottom):
Entities, Input, Time, Assets, Save/Load - No dependencies
Camera, Shaders, Animation, UI, Particles
Player, Collisions, AI/Pathfinding, Scenes
Stats, Combat, Inventory, Equipment, Abilities
Dialogue, Quests, NPC Schedules
Some systems may be hard coupled, such as entities and collisions. This is fine. The System Stack is a method for seeing where things go, not for encapsulation.
This is a road map you are building. Not a fully specified blueprint.
It can be modified later if things don’t work out as expected—they rarely do.
3. Review
Some systems will be hard coupled. Knowing what those may be comes from experience.
Go over each layer, make sure they are in the right order.
Now create yourself a diagram using whatever tool you like. This is your road map.
LLM Version
Use this prompt, replacing the JRPG example with your own game concept:
I want to build a JRPG with this description: Explore a vast world. Battle a wide variety of enemies. Help people with their problems.
The verbs are: Explore, Battle, Help.
Ask me questions so that I can map these verbs to systems that I will have to build in the game.Answer questions until you have exhausted all avenues or until you can’t confidently answer what remains.
Then use this prompt:
Organise these systems into a layered stack where each system only requires what's below its layer in the stack.This should give you a result similar to the manual method.
The free version of ChatGPT gave me this result:
Explore / Help / Battle
│
┌──────────┼──────────┐
│ │ │
Rewards Combat Quests
│ │ │
└──────┬───┴───┬──────┘
│ │
Party Enemy Dialogue
│ │ │
Skill Spawn NPC Schedule
│ │ │
Job Seasons Relationships
│ │ │
Character Region World State
│ │
└──┬───┘
│
Engine FoundationsDespite it being different to the manual version, it’s similar, and includes some aspects I didn’t.
The point of this exercise is to answer the question: “Where does this go?”—so you can break through the Two Week Wall.
Conclusion
Drawing the map is only the first step. If you want to stop guessing at architecture and learn how to apply this method from first principles across 4 distinct game engines: Metroidvania, JRPG, RTS, and a Roguelike, join Program Video Games today.
Stay subscribed for future articles about Structured Game Programming.
Cheers,
—Dylan