Before You Start Learning Design Patterns
If you’re just starting out, come back later.
This is something I realized while studying game development. I’m not particularly skilled even now, but when I first started programming, I was overly ambitious. I tried to learn every bit of C# syntax and every feature in Unity, and that included topics like algorithms and design patterns.
For beginners, trying to study design patterns and apply them right away is difficult. Not only is it hard, but it leaves you with one persistent question: “I get what it is, but why would I ever need this?” That’s because you’re studying it simply because it looks like something you should know — not because you’ve actually felt the frustration or inconvenience it was meant to solve.
As you study, you’ll often come across advice like this from people sharing their knowledge:
“There will be times when you want to do something like this — that’s when you use this.”
As a beginner, I came across this kind of advice constantly, and my first question was always: “When exactly is that moment going to come?” If you’ve felt the same confusion, there’s a good chance that knowledge simply isn’t something you need right now.
Study what you actually need.
If you’re a beginner reading this, I’d like to ask you something. What do you think you need to study for game development? Is it C#, C++, data structures, algorithms, design patterns, CS fundamentals, game engines? Do you need to master all of them?
Let’s say you just want to make a character move. To implement that, do you need to start with math and physics, pick the right data structure, choose the right design pattern, and understand what’s happening in the CPU, GPU, and RAM while it runs?
A deep understanding is absolutely an advantage in development. But having deep theoretical knowledge doesn’t automatically mean you can make a fun game.
Just implement it first. If questions come up, or you want to understand things more deeply, looking it up then is perfectly fine.
Write messy code. Break things on purpose.
Design patterns aren’t something you study — they’re something you experience. Writing code freely and letting it fall apart is the fastest way to truly learn them. As your code gets messy and harder to manage, you’ll naturally start feeling frustrated and uncomfortable. That’s when you try to clean it up yourself. If you manage to tidy it up, you may have already used a design pattern without even realizing it.
Design patterns are not rules you’re required to follow. And no one sat down, declared “This is what a design pattern is!”, and then invented one. They’re simply approaches that developers who came before us discovered through practice — patterns they named and shared because they felt “writing it this way is just easier to manage.”
This applies not just to design patterns, but to most areas of development knowledge. Why do you want to make games? Probably because you want to create something fun and share that experience with others.
The YouTube video above is a code review of the popular indie game Hollow Knight: Silksong.
Watching it, you can see that this game’s logic doesn’t follow the SOLID principles — the five core principles of object-oriented programming (OOP) — at all. The original Hollow Knight has even lower code quality. So let me ask you: is Hollow Knight a failed game?
The Essence
Gamers are the ones who decide ‘Is this game fun?’ They don’t look at your code and admire its beauty. Of course, architecture, SOLID principles, and other development knowledge all matter — but please don’t get obsessed with perfect design or beautiful code.
I think what matters most is never losing sight of the core truth: ‘A game has to be fun.’
Put the studying aside for a moment, and go write some messy code.