A mate pinged me recently because a student friend of theirs had a specific question: how do you actually get into game engine development?
Not just games programming in general, but proper engine work. It's a brilliant question and one I don't get asked often enough, probably because most people assume you need some sort of dark magic ritual involving assembly code and linear algebra.
TLDR: Want to work on game engines? Don't waste time building your own from scratch. Get stuck into Godot and start fixing real issues. Join the community, pick up small bugs tagged as good first issue, and learn by doing. Real experience trumps theory every time.
Also read some foundational books like Game Engine Architecture by Jason Gregory or Game Engine Black Book series by Fabien Sanglard (Wolfenstein 3D and Doom)
Also I want to highlight I see no real difference between engine and game development it is all just arbitary lines we draw around things for professional reasons to help us find jobs or categorise books ect... You should just learn to solve problems and expand your knowledge deep and wide. The old axiom code is data and keep it simple stupid help you solve most things.
Build a Game Without an Engine
Right, before you dive into Godot, here's something that'll teach you more about engines than any tutorial: build a small game without one.
I'm not saying build a massive 3D engine from scratch - that way lies madness and you'll never finish the bloody thing. I'm talking about something small and tightly constrained. Pick up old hardware like a Game Boy emulator, or use something modern but limited like Pico-8. Or grab SDL or Raylib and just get something on screen.
The key is: build ONLY WHAT YOU NEED. Nothing generic. No grand architecture. Just solve the problem in front of you. Need to draw a sprite? Write that code. Need collision? Write that code. You'll learn fast because every system you build is directly connected to making your game work.
This approach was made famous by Casey Muratori's Handmade Hero series, though I'd say aim smaller. You don't need to build Doom - a simple platformer or top-down shooter will teach you loads about game loops, rendering, input handling, and all the fundamental systems that engines abstract away.
Once you've done this, when you dive into Godot's codebase, you'll actually understand what problems it's solving and why it's structured the way it is. You'll see the abstractions and go "oh right, that's handling the same problem I had, but in a generic way." That's when the lightbulb really goes off.
Real Experience Trumps Theory
After you've built something small, get stuck into Godot and start contributing. Why Godot? It's open source, actively developed, the community is generally welcoming to newcomers, and it's small enough that you can actually understand the architecture without needing a PhD. Unity and Unreal are brilliant engines, but good luck making sense of their massive codebases as a junior developer.
Here's the actual on-ramp:
First, join the Godot Dev chat. This is where engine developers hang out, discuss issues, and coordinate work. You'll learn more from reading the discussions than from any tutorial.
Second, read the Introduction to Engine Contributions guide. Actually read it, don't just skim it. Understanding how the engine is structured and how contributions work is half the battle.
Third, start fixing things. Find something small that's broken and have a go at fixing it. The Godot repo has issues tagged as good first issue specifically for this purpose. These are real bugs that real developers are hitting, but they're scoped small enough that you won't drown in complexity.
What makes this approach brilliant is the feedback loop. You submit a fix, experienced engine developers review it, they tell you what you've done wrong, you learn from that, and you improve. You'll learn more from having your first PR torn apart in code review than you will from months of solo development.
On Being a Good Contributor
Open source contribution is hard because consensus is hard, but it's a bloody useful skill to learn. Here's the thing though - you need to understand the community dynamics or you'll just end up frustrated.
A good contributor maximises their contribution while putting minimal strain on the community. What does that mean in practice? It means your PRs are well-tested, clearly documented, and don't create extra work for maintainers. It means you've read the contribution guidelines and followed them. It means you're solving real problems, not just scratching your own itch in ways that'll break everyone else's workflow.
People genuinely want to help, but you need to prove yourself and earn trust first. Don't take it personally when your first few PRs get rejected or heavily critiqued - that's just how it works. Show up consistently, fix the small stuff well, listen to feedback, and eventually you'll build up enough trust to tackle bigger problems.
Having strong engineering opinions is good - in fact, it's essential. But don't expect everyone to agree with you, especially not straight away. The maintainers have seen dozens of "revolutionary" approaches that turned out to create more problems than they solved. If you've got a cool new way of doing things, prove it works in a solo project first. Show why the wheel needed reinventing before you try to convince everyone to use your square one.
HUGE WARNING: AI-Generated Code
Do not submit code written by AI. Seriously. Hand-check everything and never submit code you don't understand. Your first job as a contributor is to understand the code and its side effects. You need to be ready to answer questions about why you made specific decisions, what edge cases you've considered, and how your changes interact with the rest of the codebase.
If you can't explain your own code in detail, you're not ready to submit it. Maintainers can tell when someone's just copied AI output without understanding it, and it tanks your credibility instantly.
But Also Read Some Books
Course, you need foundational knowledge to make sense of what you're looking at. Here are the books that keep coming up when experienced engine developers are asked what to read:
Game Engine Architecture by Jason Gregory is the big one. It's comprehensive, practical, and covers pretty much everything you need to know about how modern engines are structured. If you only read one book, make it this one.
The Game Engine Black Book series by Fabien Sanglard (Wolfenstein 3D and Doom) are fantastic for understanding how classic engines worked and why certain decisions were made. They're a bit historical now, but the principles are timeless.
Real-Time Collision Detection by Christer Ericson is essential if you're going anywhere near physics or collision systems. It's dense and technical, but it's the definitive reference.
And then there are the old Game Programming Gems books, most of which you can find online for free now. They're dated in places but packed with practical techniques.
The Bigger Picture
Godot isn't the only option, of course. Have a look and you'll see loads of engines you could contribute to. But Godot is popular and probably the most approachable and has a large community around it.
The key is to work on something that's actually used in production. Contributing to a hobby engine that three people use isn't going to teach you about the real challenges of engine development. You want something where performance matters, where backwards compatibility is a concern, where your design decisions affect real developers.
So There You Have It
It's not some magic secret or hidden knowledge. Build something small without an engine to understand the fundamentals. Then show up to an open source project, be part of the community, and fix the small stuff. Prove you can be trusted with the simple problems before you tackle the complex ones. That's how you build the skills engine teams actually want.
Now stop reading and go fix something.
Useful Links:
- Godot Dev Chat
- Godot Contributor Guide
- Good First Issues on GitHub
- Handmade Hero
- Pico-8
- SDL
- Raylib