Making Games

Let me start by saying that I’m no expert. Not in game creation, anyway.

So take the following advice with a grain of salt. Also, I’ll likely refine my opinions and practices as I develop more games. Also also, this isn’t going to be about game theory, business, marketing, or anything like that. This really going to be about the technical side of game making. Okay, with that out of the way… Let’s proceed.

Unity is my preferred game engine for a variety of reasons. Not the least of which is the underlying software language used for writing code.

So my first tip is very simple: Use C# (types are your friend).

Some other lessons I’ve learned making my first two games in Unity:

1. Less Code is Better Code: Leverage as much of the engine as you can.
2. SOLID/YAGNI/KISS methodologies apply to software for games too. Small laser-focused behaviours are better than large sprawling ones. But don’t go crazy.
3. Use custom events for triggering changes in state and game logic.
4. Relatedly, keep all your event definitions in a central place. Here’s an example from Drumpf Flinger 9000.
5. The physics engine is your friend.
6. The physics engine is your enemy.
7. Treat every behaviour¹/script as transient. (Everything that gets set up needs to be torn down). This is helpful when changing/reloading scenes.
8. If you’re using unit tests, never test engine code. Only test your own algorithms.
9. Save optimization for the last step. Make it work, then make it faster.
10. Unity has a lot of features (I haven’t come close to discovering them all), keep reading and keep exploring.
11. It’s a great thing to get pre-release feedback. It’s even greater to let their feedback shape and improve your game. I got some terrific feedback from my alpha testers (thanks guys!) that really improved Drump Flinger 9000.