Making games takes a lot of time and effort - but with the tools available in 2015, it’s never been easier. DANIEL HINDES tells you everything you need to know to start thinking about games not as a player, but as a creator.
Interested in making a PC game? That’s cool. So am I! In fact, I started doing so a little over a year ago, with absolutely no experience whatsoever. If you’re in the same position and have no idea where to start, this is the guide for you. But don’t raise your expectations just yet: reading this won’t give you the power to make an entire game right away. It is a long, arduous and often tedious process. But you can do it. I believe in you.
What can you expect to do after reading this, then? You’ll have a starting point. You’ll be set up and ready to go with all the tools you need to begin. You’ll understand on a conceptual level all the elements that make up a basic game, and how they interact with one another. And you’ll get to this point without even having to write a single line of code.
NARROWING YOUR OPTIONS
The most incredible thing about game development in 2015 is that most of the creation tools you need are free. Everything from the game engines themselves to thirdparty image and audio editors can be used without spending a cent. However, with so many options available, the first thing you need to do is decide what kind of game you want to make, and thus, what tools would be most appropriate to make it with.
The first thing you need to decide is the engine you’re going to use. As your first project, I strongly discourage you from making a 3D game. Working with 3D adds quite literally a whole other dimension of complexity over 2D, which ripples out to make every other aspect of game development more time-consuming. It’s much harder to prototype a game in 3D; you’ll spend far more time tracking down bugs; compiling and testing takes longer and requires far better hardware.
For this reason, I recommend picking an engine that focuses on the creation of 2D games. Though engines such as Unity 5 do let you make things in 2D, they kind of fake it by making a 3D room and showing it from a 2D perspective.
You’ll also want to use something that’s incredibly friendly for beginners. Twine, for example, is incredibly easy to learn, though it focuses entirely on the creation of choose-your-own-adventure-style text-based games. Fun fact: the story for Telltale’s The Walking Dead was prototyped in Twine!
But if you want to make something that’s more akin to other traditional genres, such as a platformer or a top-down shooter, I recommend starting with GameMaker: Studio. It’s perfect for both the creation of simple 2D games, as well as for teaching you the fundamentals of how games themselves are actually made.
IT’S WHAT’S INSIDE THAT COUNTS
One of the first things you’ll need to come to terms with is the fact that your game is going to look awful for a long time. This is because you’ll be building a prototype, not a finished product - and you’ll be building it as quickly as possible. You’re going to be using different coloured squares, circles and triangles to stand in for enemies, walls, weapons - basically everything in the game.
You’ll be doing this because changing and removing things that don’t work from an abstract masterpiece is far easier to do than from something that has actual polish and graphical fidelity thrown into it. You won’t be as attached to what you’ve created, and will be more willing to delete entire sections of game logic - which is something you definitely will be doing.
The idea is that you want to implement the roughest yet most complete version of any new design idea as quickly as possible so that you can test it to see if it’s fun. Very rarely does something only become fun after its final graphics and “gamefeel” tuning has been applied. You’ll at least sense a glimmer of fun with a mechanic, even when you’re working with squares and circles.
Once you have implemented something rough, don’t be afraid to adjust its associated values to outlandish proportions, just to see what happens. If you’re making a platformer, and the jumping doesn’t feel good - what does it feel like if it were five times faster? Or if you jumped twice as high? Perhaps enemies need to move half as quickly, while your running speed would feel better at 300%. It takes seconds to tweak these values, and the chance that you’ll stumble upon a combination that feels great is higher than you’d suspect.
THINKING OBJECTIVELY
Now that your expectations are set, it’s time to learn about how games actually work. I’m not talking about the actual code itself - rather, I’m talking on a more abstract, conceptual level. George Broussard, the creator of Duke Nukem, once boiled this down by saying that games are about creating an Object, moving that Object, and then destroying that Object.
Take a moment to think about that. Pac-Man is created, moves around the board, and is eventually destroyed by a ghost. When you fire a gun in a game, a bullet is created, it moves along a trajectory, and is then destroyed when it hits a wall or an enemy. You create a Marine in StarCraft by building it in a Barracks then moving it to the enemy base, where it’s eventually destroyed by a swarm of Zerglings.
The key word here is “Object”; it’s the most basic building block of any game. Think of Objects like the bricks in a Lego set. But in game terms, what is an Object? It can be anything - a character, a weapon that character holds, the bullet that weapon fires, the wall that bullet impacts, the shards of debris which fly out of that wall when it’s hit. If a “thing” exists in a game, that thing is likely an Object.
Objects have a special property called Inheritance. A “parent” Object can have many “child” Objects, all of which inherit the parent’s properties. For example, if your game has different types of enemies, but you want all enemies to chase after the player once they get close enough, you would create a parent Enemy object which handles the chasing code. Then, you would create a number of child enemy objects - such as an enemy with a melee attack, and another with a ranged attack - but all would inherit the ability to chase the player.
You need to think very broadly about Object inheritance, because planning it out will save you a lot of sweat and tears in the long run - even for a prototype. It’s worth drawing a diagram, such as the one here. What you want to do is create the ultimate parent - a “super” parent, if you will. This is an Object that handles behaviours which can apply to every single other object in the game. Think about that for a bit. What does every Object in the game get affected by? The answer, as in the real world, is physics (Hey, quantum physicists, keep quiet - I don’t want to hear it). But a full, dynamic physics system like the one seen in Half-Life 2 is much too complicated for your first prototype, so let’s strip it down to one, single aspect of physics: gravity.
Without gravity, if your character jumps, they would never fall back down. Creating gravity in a game is as simple as saying “If my character is in the air, make them fall downwards until they collide with something.” This brings us to the other thing this super parent Object needs to handle: collision. A collision “event” happens every time one object touches another object. If a character who is falling with the force of gravity collides with the ground, that collision event needs to say “stop this character from falling any further down” - otherwise that character would fall through the floor. Similarly, if that character is walking left to right and they hit a wall, that character needs to stop moving, otherwise they would walk through the wall. Every time you use a “noclip” cheat in a game, you’re stopping these kinds of collision events from happening.
FOR INSTANCE
So, we have gravity, and collision. Two fundamental aspects that form a basic physics system, and all of these are being handled by a super parent Object Let’s called that object “Entity” - because it serves as a general template. Now, it’s time for Entity to have some children.
The first child we want to bring into the world is the Player. This is the Object which you will be controlling. It will inherit Entity’s properties, so it will fall with gravity, and stop moving when it touches the ground or a wall. For most games, you will only ever control one player character at a time - and there will only ever be one version of that player character that exists in the world. In development terms, this means there will only ever be one “Instance” of the Player.
However, games usually feature multiple enemies to overcome. But you don’t want to have to create a new Object, and remake all of its behaviours, for every new enemy in a level. Thankfully, you don’t have to! An Object is essentially a template with which you use to create Instances of that Object.
Think of an Object like a star-shaped cookie cutter. Every time you press that cookie cutter into the cookie dough, you are creating an Instance of a star-shaped cookie. And you can use that cookie cutter as many times as you want to create as many star-shaped cookie Instances as you want.
This means that the next Object we want to create is an Enemy. This Enemy will also be a child of Entity, because we want that Enemy to inherit our gravity and collision behaviours. And we will use this Enemy to fill the level with multiple Instances of itself.
WIBBLY WOBBLY
In this conceptual game which we are building in our minds, we now have a level which features a Player, multiple Enemies, and all of them are affected by gravity, and understand that they should stop moving when colliding with a wall or floor. Now we need to talk about how games handle another universal phenomenon: time.
Without time, the Player and the Enemies would remain frozen in place, unable to move. Gravity wouldn’t even come into effect without time. But how does the game measure time? In much the same way we trick ourselves into measuring time in real life.
Let me explain. In real life, time is constantly flowing forward. We divide a day into hours, hours into minutes, minutes into seconds, and so on, because that makes time easier to measure. But you can keep going smaller: seconds become milliseconds, then microseconds, than nanoseconds - too small to be useful in daily life.
In games, time does flow forward, but at a very real, constant, and measurable rate. You know how games run at a certain frames-persecond value - usually 60, if it’s running well? Each one of those 60 frames is a distinct unit of time for a game. This is why games with a higher frame rate feel more responsive. Each unit of time is a chance for an action in the game to take effect. For example, if you quickly stop moving to the right and start moving left, the game has 60 opportunities each second to process that and reflect it in the Player Object’s movement. In GameMaker, this unit of time is called a “Step”.
This is also why some games restrict themselves to running at 30 frames-persecond - because they only need to process half as much information every second. If you think about how many complex things can happen in a single second of an open world game like Grand Theft Auto V, and then realise the system needs to compute that 60 times every single second, you can start to understand why some games are so hardwareintensive.
What does this mean in practical terms? Well, remember those maths problems you had to solve in school - “A train leaves the station at 12:40pm, travelling at 20 kilometres an hour...” et cetera. Everything you do in a game that involves time feels like solving one of these puzzles. Let’s pretend our Player is moving at a speed of 4. The “4” measures pixels - which means that for every Step, the Player moves 4 pixels across the screen. If there are 60 steps every second, how long will it take the player to move an entire screen resolution’s width of 1920 pixels? Spoiler alert: 8 seconds.
THE NEXT LEVEL
Let’s go over what we’ve learned so far. We know that any “thing” in a game is called an Object. We know that Objects can Inherit properties from other parent Objects. Because of this, we can start building a lineage of Objects, in which the force of gravity affects all of them, and where upon colliding with a solid wall or floor, they stop moving. We know that Objects are just templates with which many Instances of that Object can be created. And we know that time in this game is measured in very discreet Steps - 60 of them for every realworld second.
These are all the basics you need to understand to start making a game. They are aspects which you need to take into account every time you design a new system. For example, when you make a new Object, think about how it fits into your Inheritance. What should its parent be? Should every weapon that you can pick up have a parent Object, like “Pickuppable”? Should every different type of projectile – bullets, arrows, fireballs – all inherit the properties of a generic “Projectile” Object? Generally, yes. And when you’re designing the behaviour of the way those projectiles move, keep in mind how the game measures time, and how the arc of those projectiles is going to be affected 60 times a second.
Where do you go from here? It’s a simple path, really. Start working through the “Basic” level tutorials included in GameMaker itself. What I’ve taught you here are the conceptual fundamentals; those tutorials will teach you how to implement them in a practical sense. Once you’re done with them, I highly recommend making a small and basic sidescrolling platformer. This will teach you much stronger fundamentals than the included GameMaker tutorials will. Luckily, YouTuber Shaun Spalding has created a YouTube tutorial series which walks you gently through everything you need to do.
With that, you’re ready to go! Chances are, as you're working on these tutorials, you'll come up with ideas for things you'll want to imploment in your own prototype. Write these down and store them away, come back to once you're feeling competent enough. And don't be afraid to put your own little spins on the tutorials' instructions, too - deviating from the norm and conning up with something creative is what this is all about. Good luck!
A BIG LIST OF ENGINES
UNITY 5
Free, great for 3D games, moderate 2D game support. A big feature is the Marketplace, where you can buy assets and plug them straight into your game.
UNREAL ENGINE 4
Free, but you need to pay a licensing fee if you release something. Mainly 3D games. Amazing graphics out of the box.
TWINE
A simple-to-use tool for creating text-based multiple-choice adventures. You’d be surprised what you can do with just words.
CONSTRUCT 2
Allows you to create simple 2D games with minimal experience. The only limitation, however, is the size - the games are quite small.
GAMEMAKER: STUDIO
GameMaker also allows you to create 2D games, but they can be much larger. Hotline Miami and Gunpoint were made with this.