Structured Game Programming. Self-reliance over abstraction.
Learn Game Programming, Free →
Joined November 2022
- Tweets1.5K
- Following337
- Followers2.9K
- Likes6.2K
Dylan Falconer retweeted
Systems don't go just anywhere--they go in order.
For example:
Layer 0: Utils, Memory, OS
Layer 1: Entities, Physics, Renderer
Layer 2: Player, AI, Scenes
Layer 3: Stats, Combat, Inventory
Layer 4: Dialogue, Quests
Systems below don't know about systems above them (usually--some are hard coupled, that's okay. This is a roadmap, not a blueprint)
Unidirectional dependency preferred. Like an assembly line.
Systems don't go just anywhere--they go in order.
For example:
Layer 0: Utils, Memory, OS
Layer 1: Entities, Physics, Renderer
Layer 2: Player, AI, Scenes
Layer 3: Stats, Combat, Inventory
Layer 4: Dialogue, Quests
Systems below don't know about systems above them (usually--some are hard coupled, that's okay. This is a roadmap, not a blueprint)
Unidirectional dependency preferred. Like an assembly line.
The full method with diagrams:
bytesbeneath.com/p/how-to-ar…
If you are trying to scope your game, try this:
Take one of the verbs, like "Explore"
Ask, what do I need to build for this to make sense? Explore what? With what? -> Character controller, movement system, collision system
2D world? 3D world? What style? -> Scene system, asset pipeline, shaders
One verb, 6 systems.
Pull every thread until you can't ask any more questions. Then organise based on dependency.
I walk through this with a JRPG example here:
bytesbeneath.com/p/how-to-ar…
Verb extraction: Figure out what the player can do in your game before writing a piece of code.
Describe what the player does: "Explore a vast fantasy world. Battle monsters. Help people with their problems."
Explore, Battle, Help
What do you need to build for these? Now you have a starting point.
The full method, step by step:
bytesbeneath.com/p/how-to-ar…
You followed all the clean code rules, but your game just dropped to 54 FPS.
You just hit the 2-Week Wall.
You followed all the rules are were penalised:
- Dependencies: injected
- Inheritance: predictable
- Encapsulation: strict
You profile it and realise every part of the game is slow. 1.5ms here, 2ms there. It all adds up to 17ms and your frame budget is blown.
To fix this, you have to refactor your entire "clean" architecture. Not knowing where to start, you shelve the project. Again.
It wasn't your fault. You were taught a paradigm that doesn't map to reality.
Here is the first step you can take so you never abandon a game project for this reason again: bytesbeneath.com/p/725-faste…
There are no objects inside your computer.
Just deterministic circuits executing instructions sequentially. Data stored in blocks of memory. That's the reality.
If computers execute sequentially, your game shouldn't be a web of objects. It should be an assembly line.
input → update → render
This is the standard order across games for a reason. You've been fighting it.
To see this applied in more depth:
bytesbeneath.com/p/how-to-ar…
How to speed up your game loop by 725% without writing a single micro-optimisation
The Old Way (Object-Oriented):
- Virtual methods
- Single object instance mindset
- Data and code live together--objects call into each other unpredictably
The New Way (Structured):
- Unidirectional data pipelines
- Grouped lifetimes mindset
- Data pushed through an assembly line--code operates on data in-order
Structured Game Programming > Object-Oriented spaghetti
Here is the C++ benchmark proving why the new way wins, and how it's not about micro-optimisations: bytesbeneath.com/p/725-faste…
You've hit the Week 2 Wall again.
You want to add a dash ability. Should it be an object? Code in the PlayerController? What about enemies that can dash?
Every new feature breaks two old ones. You hack something together. It works.
Two weeks in. The logic is a web you can't follow. You burn out. You restart.
It's not your fault. You were taught a paradigm that doesn't map to reality.
Games are not a web of objects talking to each other
In reality they are a pipeline of data going in, processing, and an image+sounds coming out the other end (obviously this is simplified)
The point is that what is happening in reality is the real problem
If you're programming a game, remember:
99% of players don't care how hard you worked.
99% of engine developers don't care about your game.
100% of players do care about their experience with your game.
You can't fix frame hitches if you don't understand the underlying architecture.
"No Lumen. No Nanite." is a new selling point for a reason.
Own your engine: bytesbeneath.com/p/how-to-ar…
Dylan Falconer retweeted
"Why would you want to read and write code?"
because I like programming the computer, that's why I do it