Hi. I'm Mark Brown and I am making my own video game. And so to start, I need to learn how to make video games.
Which is quite a big endeavour and quite a big challenge. So believe me when I say that this whole game making challenge… well, it almost ended before it ever really began. Let me tell you what happened.
♫ Music ♫ First though, let's back up a step. Because the first thing I had to do was to pick a game engine. Now, a game engine (at least in this instance) is a piece of software that helps you make a game by, essentially, taking care of the stuff that's hard and boring about game development.
Things like getting graphics to render onto the screen, interfacing with a controller, doing physics calculations, and more. Plus, they have loads of really handy tools that are specifically designed for the things that you'd want to do in a game: like animation and UI. Now there's loads of game engines out there.
I mean the most popular ones are Unity, Unreal Engine, Godot, Pico-8, Game Maker, Construct. Plus, there are game engines for specific types of game, like Twine, RPG Maker, and Adventure Game Studio. There are even game engines for specific ecosystems like Game Builder Garage on Switch, Drams on PlayStation 4, and Roblox in… the Roblox-iverse.
Each one has pros and cons, lovers and haters. But ultimately I had to just pick one. And so, in the end, I decided to go with… Unity.
There's loads of reasons why I chose Unity. It seems to strike a pretty good balance between being very powerful and relatively easy to learn. It's good for both 2D and 3D, which is good because while I plan to make my first game in 2D, I might want to do 3D down the line and this means I won't have to learn a new engine.
Plus, Unity supports pretty much every platform under the sun so if I want to take my dumb game and put it on PlayStation 5 that is technically possible, if not financially sensible. But, really, the most compelling argument for using Unity is its sheer popularity. Unity is the game engine behind Hollow Knight and Cuphead and Fall Guys and Overcooked and Cities: Skylines and Hearthstone.
It is the most popular game engine on Steam at the moment and when we ran the most recent GMTK Game Jam more people used Unity to make their game than every other game engine combined. And that popularity is really important, for me, because it means there's more people to help me learn it. More tutorials, more resources, more assets, more plugins, more people I can turn to when I get stuck.
For example, there's loads of people in the GMTK Discord who know how to use Unity. Plus, I know very seasoned Unity users like Noa from BlackthornProd and Andre from Mix and Jam, who can certainly help me get out of a jam. That was really bad.
Okay, and so that's my decision. Sorry Godot bros, it's all about Unity. That's step one done: pick a game engine.
Tick. Now, step two: learn how to use it. That's the hard bit!
And so as I said, there's lots of tutorials for Unity out there. And that is exactly what I tried to use when I first started learning it. I went onto YouTube, I typed in ‘Unity tutorials’, and found a bunch of, like, Swedish men who could teach me how to use the software.
And so they showed me how to make a game, and I followed along diligently. Every time they clicked a box I clicked that box on my screen. And every time they typed out a line of code I type out the same line of code.
And before long I had a working game on my computer, which was like… super exciting. But then, many weeks later, I decided to open up a blank Unity project to kind of see what I had learned. And the answer was… nothing.
Like, literally nothing. Like, everything they had said had gone in one ear and out the other. Like, I couldn't even make a character appear on the screen and move around.
It was terrible! And ultimately it was my own fault: you remember that video I made about tutorials where I talked about how in strategy games they have those arrows that say ‘click here’, ‘click there’, and they're not effective at teaching people at all? Well I had done exactly that for Unity!
I had played myself. I had done myself dirty. Agh!
But, to be honest, this was really demoralising. Like I truly felt like an idiot. Like I had wasted weeks of my life and I didn't know if I was even cut out for game development at all.
Like, if I can't even watch a tutorial and have any of it sink in then maybe I'm not cut out to do this. Maybe I should stick to what I know. And I mean this was like months ago and I was planning on doing this series that I'm doing right now and at the time I thought maybe I should just cancel it.
Like, maybe I should just never announce it and just pretend it never happened. It was… it sucked. It was horrible.
But then I thought about Adobe Premiere. This is the software that I use to make all the videos on this channel and it's a pretty complex piece of software and yet I know how to use it, and I know how to use it pretty well. So how did I learn Premiere?
Well, when I was working at Pocket Gamer we had to do these very basic video reviews. And so a colleague taught me the basics of Adobe Premiere: like just the absolute baseline knowledge you need to make a video. How to import clips, put them on the timeline, apply really basic transitions, and export them to YouTube.
Then I had to make dozens of these video reviews myself. And so I had to repeat those basic steps over and over again, as they slowly wormed their way into my brain. Then I made Game Maker's Toolkit.
And at that point I wanted to do more interesting stuff with video. I wanted to do masks and colour and text and transitions and motion graphics and all that fun stuff. And, really, that should have been very difficult to learn.
But I had two things on my side: one is that I don't need to learn everything all in one go. As long as I'm always trying at least one new thing in each video I make, I can slowly build up a repertoire of effects and knowledge. And, two: because I had done those video reviews I had become really familiar with Premiere.
I was comfortable with the software and so whenever I wanted to try something new I felt I could experiment and play around. Or, at the very least, I knew what I should go and type into Google to get the answers I needed. And so ultimately I ended up following a pretty nifty three-step formula in order to learn Premiere: step 1, learn the absolute basics and nothing more.
Step 2, familiarise myself with those basics through repetition and simple projects. And then 3, slowly, over time, build a repertoire of tools in Premiere as I build and build and build my knowledge base of the software. And this has obviously worked pretty well for me.
I know how to use Premiere now. I can make pretty much whatever I want in the software. And I think I understand why this worked.
You see, making videos is often about coming up with some idea: like ‘wouldn't it be cool if I had a VHS-style pause effect right now? ’. And then I need to figure out how to realise that idea.
Like how am I gonna make it so that the frame pauses? And then what effects should I use to really sell this effect? And then how do I get that wibbly line to scroll down the screen?
And if you think about it, there is an infinite number of ideas I could have so it is physically impossible to learn how to solve all of them at the beginning. But what I can learn is familiarity with my tools, so that when one of these ideas crops up I have both the confidence and comfort with the software to experiment for myself and figure things out. And I have the context for how the software works, so I kind of know where the problem is and I know what terms to use when Googling it.
Or I know how to ask someone for help. And boy if that doesn't sound a lot like game development, right? You have an infinite number of ideas that could possibly crop up, and it's impossible to learn all of them.
So all you can really do is build familiarity with your tools, so you'll have some solutions when those problems arise. So perhaps I can take my three-step structure - basics, familiarise, experiment - and apply it to Unity. Sounds like a plan.
Let's give it a go. Okay, so luckily I'm not starting completely from zero when it comes to game development. I am familiar with the fundamentals of programming, or at least that's what it said on my Tinder profile.
So I know about if statements and for loops and functions and stuff like that. And I have dabbled in Game Maker, so I kind of get how game engines work… sort of. But I do need to understand how Unity itself works.
So that starts with just the real basics of, like, what is this UI, and what should I click on, and what are the keyboard shortcuts, and stuff like that. I also kind of need to understand conceptually how Unity works. Like, for example, Unity is all about GameObjects.
Everything in Unity is a GameObject. And until you fundamentally understand what that is you can't go forward. And if you're curious, a GameObject is basically like an invisible container with a position, rotation, and scale, which you can then fill with components to make it do stuff.
That includes a sprite renderer to give it an image, a rigidbody to give it physics, a collider to make it hit into things, and most importantly a script to let you write programming code for it. Once I had that in my brain I put together a list of things that I would really need to know in order to make games: things like how do I make one GameObject talk to another GameObject? How do I spawn in new GameObjects and then how do I delete them again?
How do I make something happen when two GameObjects collide into each other? How do I do UI and sound effects and animation? How do I deal with levels and game over and things like that?
So then I used tutorials and Google and talking to people to kind of answer those questions and figure out the basics of Unity. And, sure, there are probably plenty of Unity people watching this right now who think that is not a very comprehensive list. That is not going to get you very far.
And there are probably, no - definitely, better ways to do all of the things that you have just learned how to do. And, yeah, that's true. But it's enough to get me started.
I can make stuff appear on the screen, make it move around, make collisions happen, spawn things in, delete them again - these are things that are fundamental to how games work and they are these kind of genre agnostic things that I will need to know no matter what I make going forward. It is the baseline, bedrock that I can use to start building from. And so with that I'm on to step two: to really prove that I understand those things and to really familiarise myself with them, by repeating myself and making simple projects.
And I found in game development the best way to do this is through the ancient art of plagiarism. What I mean by that is by copying really simple games, things like arcade games, mobile games, web games, mini games… anything with really basic gameplay and rules. By copying them I can prove to myself that I understand how Unity works.
And I think this is a really good training tool because you don't have to worry about art or design or rules or anything like. That that's already done for you. All you need to care about is code.
And you get this really clear objective: can I take this game and recreate it, in Unity, by myself? And so the first game I did this with was Flappy Bird: the really simple iPhone time waster about a big fat bird fighting with gravity. And, yes, sure, there are tutorials out there for how to make Flappy Bird in Unity.
There's about 10,000 of them. But I didn't want to use them. I wanted to do it by myself.
So I started by playing the game and figuring out how it worked, and then making a game plan for how I was going to recreate it. It was really important to make the steps as small as humanly possible: like, step one, make a bird appear on screen. Step two, make it drop.
Step three, make it flap. Just one thing after another, nothing too crazy. And then I just went about making it.
I made a GameObject and gave it a sprite renderer for the bird, an animation controller for the flapping, a rigidbody so it falls, a box collider so it hits into the pipes, and a script so that whenever I hit the space bar it applies some velocity to the bottom of the rigidbody and makes the bird flap into the air. Nice! I then made the pipes and turned them into a prefabricated GameObject, or a prefab, that allows me to spawn in an infinite number of them at different heights.
And it was here that I discovered a game development cheat code! You see, the intuitive thing to do would be to make the bird fly through a field of pipes but that's quite hard to do. What's a lot easier is to make the bird just stay still and have the pipes move across the screen and then delete when they go off the screen.
Trust me, I felt like a genius when I figured that one out. I also had to sort out collisions so when the bird hits the pipe that's a game over, but if the bird goes between two pipes that hits a trigger and adds a score to my UI. And so that involved sending information from one GameObject to another: that fundamental lesson I had learned was being put to use.
And then I finished it off with some sound effects and some basic stuff like clouds flying by in a parallax effect. And this felt… amazing! I know it looks dreadfully unimpressive: like, well done jackass, you stole the most simple game ever made, I hope you're proud of yourself.
But I am! I am, I was, I am, I'm proud of myself. I took this game that exists, I broke it down, and I remade it myself in Unity.
I had proven that I knew how Unity worked I got it working all by myself. It felt great and it felt a lot better than that demoralising feeling I had when I first tried to learn Unity. And in fact it was such a good feeling that I did it again, this time for the game Pop the Lock which is about a line that rotates around a circle and you have to collect other circles… again it's pretty simple, but it's very addictive.
The process was pretty much the same: play the game and kind of reverse engineer it to get a sort of quasi-design document. Break it down into the smallest steps possible, like just have a thing rotate around the screen, and build it step by step. This one did cause some pretty big problems because it's based around rotations, and rotations in Unity kind of use this thing called ‘quaternions’ which are like a four dimensional, rotational, axis.
And my brain just kind of leaks out my ears when I try to read about them, so that was quite difficult. But I did discover this cool built-in function in Unity called ‘. RotateAround’ that allows you to rotate one GameObject around a point, and that solved so many problems.
And now that's in my memory banks for the future. I also figured out this cool thing about parent and child GameObjects and that solved a lot of problems too. And so then, again, I had this game working on my computer and it just felt really cool at the time!
I i can't really explain it, but it was just like: I did it! I had this goal: make this game. And I did it.
And the most important thing was that I was proving that I knew how to use Unity and I was also building my familiarity with the tools. The things that I had to solve when I was making that game, I couldn't have done when I started but I can now because I kind of know where to click, I know where to look, I know what to type into Google. And so at this point I feel pretty good about Unity.
Like, I'm definitely not an expert… but I've got somewhere to start. And I think right now I should move on to step three: to start building my own games and start experimenting. And, sure, I'm gonna run into problems.
There are things I don't know how to do. There are problems I will face. But I've got that confidence and that comfort with the tools now.
I understand Unity on a conceptual level. I understand the basic things I need to know how to do, and so from this point when I run into a problem I can probably solve it, maybe. I can at least play around and at the very least I know what to type into Google.
Or I know how to construct a question for someone who is much smarter than me. Now I can't guarantee that this style of learning will work for you. Everyone learns in a different way, and maybe you do just like having someone explain things to you in a Swedish accent.
But for me, someone who gets very easily bored by tutorials… I possibly have ADHD, I don't know. Someone who needs to experiment and play around with things and fail to really get things to go into their brain, this approach worked for me. Learn the basics, familiarise myself with them, and then slowly build up a repertoire over time.
And I guess we'll really see if this works in the next episode of this series because I am going to start making my own game and start making a prototype. I do hope that you will join me. For now though, I know that this isn't a tutorial series but if you watch this and you're thinking boy I would really like it if you could teach me the basics of Unity, Mark… well, let me know if that would be useful in the comments down below and if I have time I might be able to squeeze in a quick tutorial video to go along with this series.
For now though, thank you so much for watching. And I'll see you next time. This light is gonna run out of battery very soon.
But… you’ve done me proud.
