Do you ever feel like making games gets harder as you get better at it?

Ever open your project and think ‘I wish I could start this over’? 

Or look back at a pile of unfinished projects that all got too messy and frustrating to work on?  I definitely have a stack of them.. Long lost ideas that seemed simple to at the beginning..

That’s how it always is though, new projects are easy!  You’ve probably thought ‘I’d do this completely different if i started over’.  Or the more common one.. “This is garbage, we should delete it and start over!”

It’s usually when you go to add something ‘easy’ and it takes an entire week!  Or you get your new shop feature in and realize right before you release that it broke your login system.. (or even worse you realize after you release)

I used to think programming would just ‘get easier over time’.  And at some points in my career it felt that way.  You’d think it’d get easier over time, and in some ways it might.. BUT it’s the exact opposite.  

Every time I’d learn about a new system or a new pattern, I’d get excited!  Then shortly after, I’d often end up confused..  Wondering, was I doing it right?  Is this even the right pattern for what I want to do?  Is there a better way?

Often I’d end up over-complicating things.  Dramatically over-complicating them.  I’d pick up a new pattern, drop it in my tool-belt of design patterns, then start using it everywhere!  Or I’d take something that would work great in an array and shove it into a crazy set of structs and classes thinking I was making it ‘better’.

All the while, adding to the pain.. Making my projects harder to ship, harder to work on, and definitely harder to love.  Of course it’s possible to swing to the far opposite side of things.  And there it’s just as dark and terrifying.

I’ve seen this horror story dozens of times.  Projects built almost completely in 1 file.  That might sound extreme, but it’s real.  I can’t even count the # of times I’ve seen games where 90% of the game logic is stored in a single class…  But I can share disastrous fallout it causes!

And I can do that with great first hand knowledge, because let’s be honest.. I’ve done this myself, and most of us do.  When we first start out, we learn to write code and the computer just listens.  Things ‘work’ and there’s no need to make more files right?  (so wrong lol)

“Less files, less classes, keep compile time down!” – “More classes just makes it more complicated” – “I like to have everything on the screen here” – These are arguments I heard all the time as a new programmer.

I had no idea how wrong they were, or what the hidden costs of these bad practices were.  I didn’t even know they were bad practices.  When I learned to code I was mostly on my own.  Self taught from books and practice, with a couple little courses here and there.  But mostly, I learned by doing.. by building games and windows apps for games.

So when I started my first professional game dev job, I went in with close to no idea what I was doing. And on day one got the shock of my life. An assignment to build some new crazy tool to handle content for a live AAA mmo.

But I was thrown into the fire, still mostly unattended and with almost no architectural guidance. (we had a quick standup meeting where we talked about it for a few minutes…) So as you’d expect, my entire focus was on making things ‘work’. If they worked, everything was good, words like ‘clean’ or ‘maintainable’ weren’t even an afterthought at the time. 

As a result, I built up some bad habits. And I made some huge messes in an already confusing code base. Instead of leaving things cleaner than I found them (boyscout rule), I was adding shortcuts, breaking encapsulation, adding complexity..  And worst of all creating strange random bugs.

Early on, Sony bought our project from Microsoft. But it took a few years before I got to jump into another code base. When I switched over to the Everquest 2 team, I quickly started to find new patterns and implemented them wherever they’d fit. 

Think back to when you first discovered static or singletons. For me it was like magic, I’d found an easy way to get a reference to exactly what I needed. The same when I discovered events… I had no idea about the hidden costs of all the things I was doing.

And that’s because it usually starts out great. Everything works amazing and you’re tearing through tickets, adding features like mad. Think of day 1 on a project, just how fast you’re going and how much of a difference you see. It usually stays pretty fast paced too..  for a while.

Then it hits. Suddenly you look at a ticket and realize it’s going to take a lot longer than you’d expected. The new ‘little’ feature you were going to add… that’s going to touch 5 systems, and you’re not sure exactly how, so you need to test it all out. But first you’ve gotta figure out how to make it even work.

And it’s gonna require some refactoring. The systems want different things.. Something that seems trivial can become a dreadful nightmare to implement. Worst of all, you’re pretty sure something else is going to break. You may not be sure what, but somethings probably going to go wrong.

This is the point when technical debt hits us. When bad architecture or a pure lack of architecture makes it too expensive and difficult to add new features. For a lot of games this drop in productivity starts to hit early, just a few months in. More experienced teams are often able to push this out a bit, but still regularly fall into the same traps…

I only know of 1 way around this mess. One way to minimize technical debt.. By constantly paying it off, and constantly improving the code.

Of course that usually sounds crazy. How can you constantly make the code better? It’s all about intent… well intent and tactics. You need to have clean code and architecture as a goal. You have to understand the value and the immense payoff you get from good SOLID code. With the right intent and the tactics available, it’s definitely possible to have a code-base that gets better every day instead of one that decays into a post-apocalyptic mess.

My second big game project taught me something interesting. It was another big mmo, quite a bit bigger than the first.  I remember looking at the code the first time… I was a bit confused. I’d just assumed everyone built games like my first project…

Wow was I wrong. These games were at the same company, but were completely different. Suddenly I’m looking at events and callbacks… There’s no update loop at all. I’m totally lost on what to do.. And to top it off we don’t even have a database!

It took a while to get comfortable, but it was an amazing experience. Being force into a new architecture gave me a completely new perspective on what was possible. I learned tons of new ways to do things.

But I also missed things. Some things that were really easy in VG were extremely difficult in EQ2. I didn’t realize it at the time, but it’s clear to me now. Every game has some good parts and some bad parts to it’s design and in it’s code. What I wanted to do and strive to do now is go for as much good as possible and  start deleting the bad.

Since those first 2 projects, I’ve built about a dozen other games. And I’ve learned how to build things right. I look back to my old games and realize how many pitfalls I could have easily avoided if I’d had a clue where I was going.

Unfortunately, when I started in game development, there weren’t any game architecture resources I could find. And even to this date, I couldn’t find much of anything going beyond an intermediate level. 

Which is exactly why I put together a course covering the things I wish I’d known. The things that would have saved me years of frustration and wasted time. The things that would have got me past the one interview I flopped miserably in, and a whole lot more.

This course is the culmination of just about everything I’ve learned about game architecture and clean code. It’s a total brain dump of how to build solid, clean, maintainable games in Unity. It’s not for the faint of heart, and not really for beginners, but exactly what I wish I’d known about when I started out.

It’s the solution to all the problems I ran head first into. The answer to so many of my past self’s questions like ‘should I use some pattern here?’ ‘what would that even look like?’ ‘why did this event happen, I’m so confused..’

Or the biggest one I’ve asked time and time again ‘how do I clean this mess!?’

That’s the goal of this course, to help you clean your messes. Whether they’re existing messes in a code base you’re struggling with, or a new project you want to stay clean from the start. I’m going to guide you through the process with all the lessons I’ve learned and show you how to implement them in a realistic project.

I’ll take you through the process of building an extensible, modular, clean, well architected game. You’ll see how easy it can be to write safe testable code and unit tests to verify everything is safe when we want to refactor or add new systems.

We’ll look at ways to use scriptable objects and dive deep into prefabs and scene management. We’ve all struggled with setting up menus, huds, and levels, so we’re also gonna demystify that entire process and make it simple.

We’re gonna do this a bit different than normal. Instead of using the most common tools, we’re going to use what most real pros I know use. And instead of just going through how to build system after system, we’re going to focus on how to tie all the systems together, painlessly, and without killing performance along the way.

And we’re going to work on the techniques needed to clean up existing projects while we’re at it. By the end of the course you’ll be able to confidently clean up any project using the strategies we’ll cover. And you won’t have to wonder ever again ‘is this going to break something?’

If you’re ready to quit building up technical debt, stop worrying about bugs, quit fearing changes, or maybe just figure out what architecture is all about, now is your opportunity.

We’ll have lessons a couple times a week, but you’ll be able to get to them after, you don’t need to attend live.  In each lesson we’ll focus on a different key architectural concept, seeing how we can best use these concepts in real world scenarios. And most importantly, how they all tie together.

You’ll learn how to use things like asset bundles and addressables to reduce project size & memory usage.. And to do those all important updates. We’ll deal with gameplay systems like inventory and items in depth, with full UI’s, with a clean event driven setup. And of course we’ll build weapon and quest systems, what’s the point of items without them right?

Hopefully you get the idea now… we’re gonna go big and deep. I’m planning to do everything I can to completely transform how you make games. To show you how much easier it can be, and how you can often do much more with less code, once you know the patterns to apply and where to apply them.

FAQ

How long is the course, how much time to I have to dedicate each day?

The course is running live now and will continue to throughout the next few months.  I’m releasing new lessons each week, and after the lesson is delivered, you can go back to it any time.

To make it easier, you don’t change your schedule just to attend at a specific time.

We have weekly live calls where we discuss the topics for the current lesson and any previous lessons (and any other game development questions you may have).  These happen every Sunday, but if you can’t make it you can submit questions in advance and the calls are always recorded so you can re-watch them at your own convenience.

What’s Covered?

The key focus of the course is architecture.  More specifically architecture of big games, the kind of games you work on for years.  There’s an outline below that discusses some of the major topics, but the primary goal is being able to build large manageable projects that can be completed without becoming too hard to finish or breaking all the time.

Is the refund policy really a full year?

Yep. Any time within a year is no problem at all.

Are we going to learn in 2D or 3D?

The course is primarily focused on 3D development but we’ll be doing some advanced UI and inventory system work that applies to all kinds of games.

How much do I need to know to take this course?

You’ll definitely need a grasp of Unity. If you’ve never used it before, you’ll want to start with the Mastery Course. Luckily, it’s included free with your registration, so for the price of one course you’ll get the perfect starting point plus the advanced training that’ll let you soar ahead of everyone else.

What do I do if I have questions throughout the course?

Email me right away!  I get a ton of email every day, but student questions always go to the top of the list to make sure you’re never stuck waiting or wondering.

You’ll also be able to attend the live weekly calls where we discuss course content and general game development questions in detail.

When do I get to start?

Once you join, you’ll be able to access the released lessons within a few minutes and start getting invites to our live calls.

Have questions of your own?

If there’s anything you’re not sure about, any questions you have about the course, feel free to send me an email and I’ll get back to you asap – jason@game.courses