Common pitfalls

We can get to a well-architected state with less stress if we keep an eye on some common pitfalls. You’ll notice as you read this book that it’s not so much a step-by-step tutorial as it is a reference for when you need to implement a design pattern. Half the skill is learning if, and when, to use one at all.

Let’s summarize:

• Don’t use a design pattern just for the sake of using it. Impressing a review team or someone on GitHub isn’t worth it. If a part of your game needs some abstraction and decoupling, absolutely do it.
• Only add complexity where it’s needed. If you find that your project is overly architected, ask yourself if your codebase wouldn’t be cleaner and easier to read without it.
• Good software architecture is never free. Abstracting code takes time to learn, write, and maintain, and you may take runtime hits to performance and speed.

So why do any of this design pattern nonsense in the first place? Because complexity isn’t a bad word, performance can be improved later on, and the efficiency bump in your development process is well worth the up-front investment. You won’t get it right the first time, so enjoy the iteration. It’s all part of the process. And if you’re like me, using design patterns is like a puzzle, and when that code runs, it’s like finding that last pesky piece your cat hid under the couch – it’s magic.