There was a time when making a game as simple as the Atari 2600 classic Combat required 6 months of constant work not simply by professionals, but by the people who developed the hardware that the game was running on. We could not have come further from that point today, and right now anybody with a computer, a little bit of time and enough dedication can make a fully playable game that far surpasses the complexity of anything made before 1983. Even better, they can often do it in less than a day. In this post, and a few after, I want to give you the tools to do so.
Before I get into it, I want to be clear that I HATE math and will do anything to avoid it. I am also not a computer science student: I’m in the fourth year of a Philosophy degree, which is as liberal arts as you can get. Until early last year, the only programming that I had any experience with was a very poor Java class in high school. Fortunately a designer from Telltale encouraged me to become familiar with Gamemaker, and on my own time, with a minimum of math, I was able to learn these skills and start experimenting with game ideas that had lived in my head for years. I just want to make it clear that anybody can do this, and many rumours about the skills needed are greatly exaggerated.
So where do I start?
Well, there are lots of ways that you could start. You could start by making mods for other games, or just make new levels and models for them. Those things are completely valid ways to start, but I’m going to assume that you, like me, want to focus on developing actual game mechanics. This means learning a game development toolset. There are many options out there, and depending on your prior experience with code you might want to go somewhere else. What I’m going to talk about here is the free 2D development software Gamemaker.
What is that?
GM is a shareware level editor, code editor, art editor, and 2D engine (it has 3D in the paid versions, but that’s not really its forte and we won’t talk about it here). It is powerful, flexible, and the recently released (and rather expensive) studio version supports development for many mobile platforms along with Windows and Mac. It has its own proprietary programming language called GML that is conceptually similar to, but not easily translated into, Java and C#.
Why are we using GM if its language is proprietary?
It certainly has many things to recommend it, but most important for our purpose is that it is a fantastic learning tool. This is because you can make a complete game for it without writing a single line of code. It features a drag and drop (D&D) system that allows you to give things in the world (objects) behaviours using an entirely graphical interface. This allows you to quickly build a reasonably complex game of your own design without having to worry about code structure or anything.
That’s all well and good, but there’s a second part to the learning process. At some point you’ll be working on your creation and realize that there is no simple way to do something using D&D. Since you love this idea to death and it would kill you not to have it, you will steel yourself and add an “attach code box” to one of your objects. It is likely that your first code will be full of bugs, and that you’ll have your eyes on the Gamemaker code reference site most of the time, but that’s ok. You’re learning. This is what learning feels like...
Well anyway, that’s what happened to me. Basically, this is a way to learn the theory behind programming without having to learn an actual language first, and to do it in an environment where the really complex work (such as collision detection) is already done. If you stay on with game making you will eventually want to learn something like C# so that you can use a more robust engine like Unity, but doing this first will give you the basics. And hey, Spelunky was originally developed for Gamemaker. In fact, the code for that game is freely available so if you want to see what is possible with these relatively straightforward tools, you can take a look at that.
That’s great, but I don’t even know where to start with this program. SO MANY BUTTONS!
Unlike most guides, I’m not going to tell you exactly where to click and what to type. I’m assuming that you are smart enough to figure out or Google that stuff. I find that I get frustrated by tutorials that explain in too much detail and start to miss things. This may not work for you, in which case there are many other very good guides out there and I certainly recommend that you check them out.
To begin with, you’re going to want to start a new project instead of using the example one that comes up when you do a fresh install of GM. Once you’ve done that, you’ll also need to create a new room. Every game must have a room (read: level) in it to run. In fact, if you press the green triangle on the toolbar you will be able to run this game! Of course it won’t do anything because it’s missing, you know, stuff.
The next thing that you’ll want (in 99% of cases) is an object for the player to control, so make a new object and call it “playerObject”. Almost everything that happens in the game will be done by and to objects. This is analogous to the way that we think about real physical space, and this type of programming is called “Object Oriented Programming,” or OOP.
Now that you’ve created an object, you’ll need to give it a sprite. You can use any image you like, and GM will adjust its in-built collision detection to transparencies so feel free to use a shaped image. Now go back to your room and (using the room editor’s objects tab) place an “instance” of playerObject into it. At this point we should note that “objects” and “instances of objects” are different from each other. I should hope that difference is intuitive, but if it isn’t you can think about the object as being the blueprint for a car, while an instance is the car itself. You can have many cars built from the same blueprint, and if you have an accident in one car it won’t have any effect on the others.
Now if you run the program (the green triangle again) an instance of your object will show up wherever you put it in the room. Of course it won’t do anything, because it needs some “behaviours” attached to “events.”
Close the game and go back to playerObject. See that “add event” button? Press it and create a keyboard event for whatever button you want to use to move the object up. Now add one of the “move fixed” boxes from the menu on the right (it’s the red one with all the arrows in it). It will ask you for a direction and some values. We’ve already decided that’s it’s moving up, and you can pick a speed. I’d recommend something small like 2 or 5, because if it’s too big your object will just run off the screen.
Now if you run your program, you can make your instance of playerObject go up. Woooo! Now, what exactly did we just do?
Time in GM is measured in frames. By default it runs games at 30 frames per second, so your object is checking the keyboard 30 times and performing its behaviour every time it find that you are pressing you’re up key. Learning what order code is being run at will be very important later, but for now this basic understanding of framerate is all that you need.
Ok, what now?
You’ve probably seen many exciting buttons and functions while doing this, so my suggestion is that you think of a type of game that you want to make (something relatively simple) and start experimenting with what kinds of events should trigger what kinds of behaviours. You’ll probably want object collision events, and you may want to mess with the room settings like size or resolution. Or not, the sky is the limit!
Wait, don’t leave me!
Relax; I’ll happily answer anybody’s questions in the comments or by PM. At some point soon I plan to write a guide exploring some more advanced features and concepts that I didn’t discover till later, and then after that I want to look at some ways to stay organized and write code (yes, code!) in ways that would have made my life much easier if somebody had shown them to me when I started out.
Go forth and make games!
(To inspire you, here is a prototype that I made from scratch for my “game design and development” class over the weekend. While there is certainly much that needs to be done with this particular project, it shows you how quickly you can build a game if you take a small amount of time to learn some tools!)