How did we get here?

I tried Unity for the first time back in 2012, that was a year before I went to school for game development. Like many, I mostly learned by consuming online tutorials. I had some practical experience from school projects. I even did some freelance. Long story short, I used it a lot for 4 years straight since the first time I touched it.

During my last year of university, however, I wanted to make my own game. It had a lot of dialogue, some cutscenes and…I had to confront a sudden realization that I’m sure you had to confront as well: I had no idea how to scale my features to build anything larger than a prototype.
I knew it, too. I asked anyone I could, and a common answer I got was “you’ll get better at it once you start working with Unity full-time”…and I really disliked that.

So I had to do this the only way I can. I’m generally bad at tracking things. At first, excel sheets were helping me out. But then I took a 3-months break as I was finishing my final year project. Looking at all the mess I made prior was a lot like trying to read Danish. I don’t speak Danish.

A while later, I got my first full-time job. During my first year, I learned more about writing scalable features in Unity than perhaps the prior 5 years combined. And it was all due to my luck of working with many talented developers who knew how to write good production code, and had the patience to teach me.

Why did we get here?

I really like teaching. In the past few years, I tutored here and there in my free time, wrote a couple of tutorials, and tried to share what I learned with anyone I could help.

During that time, I grew really bothered by the fact that just like me back in university, new developers have no idea how to write scalable features in Unity, and just like me back then as well, they have no idea how to ask.

Given that Unity is designed with a set of philosophies that enables it to be easy to learn and build features quickly with, most tutorials out there don’t teach you scalability. And while you can power through prototype code and workflows until you’re done with your project if you’re persistent enough, it’s just unnecessary.

I actually had a couple of discussions recently with other professional Unity developers about this subject. It seems that a common opinion that many have is that the only way to learn how to write architecture, is by professionally working with other people who know how.

I completely disagree.

Another common opinion seems to be that interest in learning building scalable applications won’t be there in the first place.

I also completely disagree.

The game plan

Although some people can read a software architecture book and apply it to Unity, this is the exception, and not the rule. A big blocker for transferring this knowledge exists: sometimes you need to specifically learn how to apply this knowledge to Unity.

Here’s the interesting part: I’ve seen myself how a new developer can maintain scalability in a growing Unity project by following a few simple rules. Rules that aren’t very complicated and don’t require obscure knowledge of software engineering. You’ll see me tackling this very concept and related examples throughout the book to illustrate why it scales.

Regarding interest, I don’t think that’s a fair assumption. Unity’s used to produce over 50% of the games that come out every year. Many people who try out game development and stick with it start with online tutorials. Many university students learn Unity and want to learn more.

But regardless of interest, I couldn’t find anything similar when I was starting out. It’s not easy to find out there. And I’m sure many are in the same boat.

Let’s change that.