A few years ago, after participating in a couple of game jams and releasing an extremely early, unpolished version of Shapes of Gray on itch.io, I felt that I had attained enough authority to write a book on game development aptly titled “How to Make Games” containing sage advice like “do GameMaker’s tutorials” and “remember to eat food.”
As self-deprecating as I am about it now, the guide actually got spread around quite a bit, and people still download it to this day. A friend of mine once recommended I make it available as a series of blog posts; three years later, now that I actually have a blog, I’ll follow his suggestion. I’ve changed a few details here and there, but 99% of what you’ll read is identical to what I wrote down in 2014 (meaning some of it is out of date, a few resources may have disappeared, and I might disagree with certain points).
While I don’t expect anyone who follows me closely enough to know about this blog to get much out of this guide—the majority of the people I know personally in gamedev are far more talented than I am—if you truly are a complete beginner when it comes to game design, this can serve you as a pretty great compilation of all the advice that got me through my first year of it.
May it serve you well.
How to Make Games
I. You Can Make Games!
“What advice do you have for an aspiring game developer?”
If there’s one question that video game developers get asked the most, it’s this. Almost everyone who loves to play games has thought about making one, yet most people don’t seem to have any idea how to. And who could blame them? While creative endeavors like writing or filmmaking seem straightforward, the process of making a video game can feel mysterious and scary.
“I can’t make a game—I don’t know how to code,” they’ll say. The good news? You don’t have to.
“Well, of course I don’t need to know how to code NOW. That’s what college is for.” You don’t have to go to college either. By utilizing simple-to-learn game engines like Game Maker, you’ll learn how to code without even realizing it.
You don’t even have to be a dedicated gamer. It’s not uncommon for game developers to enjoy creating games more than they enjoy playing them. If you play more games, you’ll have more knowledge on what works, but at the same time, a lack of preconceived notions could lead you to creating something no one has seen before.
Perhaps the most intimidating hurdle of all is the notion that many people who claim to be “uncreative” struggle with: that there isn’t anything that they could create that would have any value to anyone. This fear can be paralyzing, and it’s kept many potential geniuses and artists throughout history from taking the first steps to creating something amazing. To get past it, you need only remember one thing: you are unique. Your experiences, your memories, your friends, your family, your upbringing, your culture, your gender, your ethnicity, your beliefs, your achievements, your losses; they all add up to create the giant story of your life which you tell yourself every day.
Only you can tell that story.
This isn’t to say that game development is a smooth ride. In fact, it’s one of the hardest careers there is. But if you truly love it and strive to succeed at it, there’s a chance you’ll make it work for you.
As you read this book, you’ll learn everything you need to know to make your first video games. By the time you’re done, you will have gained a basic understanding of design and will have a solid grasp on the technical knowledge required to make a game. Not to mention, you will have made several small games and will be prepared to continue your growth as a developer by making more ambitious titles.
If there’s one thing you get out of this book, it’s this, the single mantra that all game developers must follow at all times:
II. Always Start Small
Take a quick peek at Steam Greenlight or Kickstarter and you’ll be overwhelmed with plenty of impressive-sounding projects. “A procedurally-generated open-world horror game with RPG elements and local multiplayer!” “An MMO that’s bigger than World of Warcraft where you can go inside anyone’s brain like in Psychonauts!” “Minecraft but with aliens!”
Then you’ll look at the project’s page and realize that a team of two ten-year-olds put it together. So far, they’ve managed to draw a fence and write a two-paragraph design document. They’ll do everything else later.
We can’t blame them for being ambitious; game development can seem pretty nebulous to someone who’s never done it before. There’s no way for those kids to know how hard it would be to create a WoW-killing MMO. And if game development is so easy that there are chumps out there writing books about how anyone can do it, why not skip straight to making the biggest game ever?
Unfortunately, it doesn’t work like that. This is your first lesson: start small.
Have you ever wondered why it seems like every time you get excited for a game, it gets delayed just before it was about to come out? No, it’s not because the developers are lazy; making games takes time, and it usually takes more time than expected.
Starting small will help you dodge the bullet that so many aspiring developers fail to see: a lack of scope-control. Poor scope-control can spell death for a project before it even gets started.
Finishing games is especially important in these early stages of your career. Victory feels good, and the more small victories you have under your belt, the more motivated you’ll be to press on. You don’t want to burn out at the starting gate; if you master walking, running will be no problem.
With each project you tackle, your skills will grow in ways that you can’t imagine. This is why starting off by working on a wide variety of diverse games is so helpful for learning. You’ll gain a ton of experience by completing one small project at a time, and you’ll always have motivation to move on to the next one.
Not to mention, the benefit of taking less time to finish is a gift in and of itself. If you don’t have a lot of time to dedicate to game development, you can whittle away at a smaller project by working on it a little bit each day. Even if you only have fifteen minutes before bed to work on your games, use them. Every little bit of time that you spend learning counts, and it’ll all add up.
There are plenty of other reasons why starting small is important. We’ll talk about these later on–first, you have to learn how to use your tools of the trade.
Patience, young grasshopper. Your training has only just begun.
[Note: With the release of GameMaker: Studio 2 and it now being impossible to get a license for Studio 1, pretty much everything in this section is out of date. The general advice still stands, though, so grab a trial copy of Studio 2 and try to follow along with that edition.]
Downloading GameMaker: Studio
Whenever someone asks me how they can start making games, I tell them the same thing: download GameMaker and do the tutorials. By the time they’re done, they’ll know everything they need to know. You’ll be starting off this way as well. There are plenty of other great game-making tools out there, but in my personal opinion, GameMaker is the best for absolute beginners who don’t know how to code. It’s certainly the most versatile.
The first step in using GameMaker is to download it off of the YoYo Games website. If you Google “GameMaker,” the first result will take you to the download page for GameMaker: Studio, the latest version. There’s a case to be made for using the previous version, Game Maker 8, instead, but for the time being we’ll stick with Studio.
There are three versions of GameMaker Studio: Standard, Professional, and Master. Standard is free—download that one. You don’t need to worry about the Professional or Master versions, which are mainly used for porting to non-PC devices.
Once you’ve downloaded GameMaker: Studio, run the installer and follow the installation instructions. This involves a lot of clicking the “Next” button.
After you’ve installed GameMaker, run it and click on the “Tutorials” tab on the top row. Click on the second tutorial—it covers the same material as the first one and does a better job of it. Click on the “…” button at the bottom to choose where you’ll save your project (I usually save mine to the desktop for easy access) and click “Create.” GameMaker will then download the pre-made resources for the project. When they’ve finished downloading, a blank project will open and you’ll be ready to go.
(When you create a new project in GameMaker, a folder ending in the extension .gmx is created, which holds all your resources and data for the project. To re-open the project when you want to work on it, open the .gmx folder and then double-click the .project file. It’s best not to go poking around in any of those inner folders just yet.)
Now that your project is open, pay special attention to the pane on the right side of the window. This is the tutorial pane, which will only be open for these tutorial projects. Follow the instructions in this pane; they’ll explain how to complete this first tutorial. As it says at the beginning, the tutorial will take you about 30 minutes to complete. Do this tutorial right now.
Once you’ve completed the tutorial, go ahead and play your first game ever. It isn’t the greatest thing in the world, but knowing that you made it makes it all the more fun.
When you’ve had your fill, feel free to take a break before moving on to the next tutorial. As we discussed in Chapter 1, you don’t want to burn out in these early stages.
For your second and final tutorial, you’ll be doing the “Scrolling Shooters” project. Open the tutorial in the same way that you opened the “DnD” one and follow the directions. This one will take a bit longer; it goes much more in-depth and expands on what you learned in the first tutorial. By the time you’ve completed this tutorial, you will have an excellent grasp on GameMaker’s drag-and-drop interface and will be ready to create a project from the ground up.
In the section “Finishing the Game” towards the end of the tutorial, you’re invited to expand on your game. I recommend doing this—try creating some new enemies or powerups to see how they change the game. Do they make the game more fun? Do they make it more fair? Ask yourself these kinds of questions as you play your game. Being able to break a game down to see how its components work together to create a unified experience is an essential design skill.
Once you’re content with how your Scrolling Shooter project has come out, we can move on to creating a game from the ground up.
Recreating the Classics
The best way to learn to code is to tackle a challenge on your own with no tutorial. To do this, you’re going to recreate a few arcade classics so that you can practice making a game without a set of instructions next to you. This will let you train up your programming brain-muscles so that when you’re making something original, you’ll have the capacity to pull it off.
The three games I would recommend are Breakout, Pac-Man, and Tetris, in that order. If you can recreate those three games, you’ll be well-off in your quest to become a proficient GameMaker user.
This isn’t to say you can’t look online for help when you bump into a specific issue; quite the opposite. If you run into a problem that you just can’t solve, the best way to learn how to get past it is to Google the answer. Odds are, someone has run into a similar problem in the past and has already asked it online. It’s important, however, that you make sure to understand the answer to the question, instead of just implementing it in your game without knowing how or why it works.
The art for the three games you’ll be making should be simple enough to draw even if you have no artistic ability. If you’re averse to doing the art yourself, feel free to go online and get the graphics for your game straight from the original games. You won’t be releasing these games, so there’s no harm in playing around with the original graphics for the sake of learning. Whatever you choose to do, keep in mind that the art doesn’t need to be too amazing for these three specific projects.
The same goes for sound. You can either get the sound effects and music online, or record them yourself using a microphone and your voice. At this stage, it doesn’t matter.
As you create these games, remember your first lesson: start small. Don’t worry about the scoring or menus or level progression when you begin the Breakout project; see if you can get a paddle moving on-screen. When you’ve figured that out, add the ball. Make it move. Make it bounce. Is it bouncing correctly? Take these projects one step at a time, adding features little by little.
Recreating Breakout should be an easy task for you at this stage. Pac-Man and Tetris will be a bit more difficult, but should be able to pull them off. You know everything you need to complete these projects.
You can think of these projects as your final test in GameMaker boot camp. Don’t move on to the next chapter until you’re done! By the time you’ve finished them, you’ll be ahead of 95% of would-be game developers who spend their time wishing they could make games instead of sitting down and making them.
This is your mission, should you choose to accept it.
Breakout. Pac-Man. Tetris. Go get ‘em.
If you’ve made it this far, congratulations; you now have an impressive assortment of completed games under your belt. You know your way around the GameMaker interface and have proven that you know how to make things happen. You can start a project and finish it. As mentioned at the end of Chapter Two, you’re now in the top five percent of aspiring game developers. You should be proud of your accomplishments.
Now that you’re about to start making your own games, it’s time to discuss a little bit of basic game design theory. There’s a ton of information out there on game design, and every designer has their own design philosophy. In the next two chapters, we’re going to be brushing the tip of the iceberg by looking at a few ideas that will get you in the right mindset to design a respectable, simple game.
Remember: with everything you do in your game design career, start small. When it comes to creating a game, we call this “prototyping.” A prototype is a simple version of your future game without any complex art or sound; it’s a small demo that you can create quickly just to see if your idea works.
It’s important to know how your idea will translate into actual gameplay before starting on any other aspect of the game. For example, let’s say you get the idea to make a platformer controlled with the scroll wheel. You’re going to want to know that your idea works before you start designing enemies or levels. Just like when you were making your own versions of those classic arcade games, you want to start off by making a box move.
If it doesn’t work out the way you wanted it to, no harm, no foul. You didn’t invest much time in the project, and you learned from it, so there’s no shame in killing the project and moving on.
And who knows—maybe that prototype will end up having some great ideas in it that you can use in a future game. Jonathan Blow didn’t start out with the idea for a time-manipulation based platformer when he began development on Braid. The idea came from a prototype he made called Oracle Billiards, a pool game where the player could see what the results of his shot would be before taking it. The game didn’t end up being what Blow hoped for, but he was able to take that idea from the “failed” prototype and use it in Braid. The rest is history.
So, let’s assume you have a working prototype that you like, and you want to expand on it. Where do you go from there?
Begin by adding new elements to your prototype. Think of that Breakout clone you made; how would adding in certain blocks that don’t break when the ball hits them change the game? What if there were moving blocks? Blocks that get bigger when the ball hits them? Play around with new ideas and see how they interact with each other. Right now, your game is a giant sandbox that you can do whatever you want in. For a lot of designers, this early stage where anything is possible is the most fun part of designing the game. It often feels like the game is designing itself, and you as the creator are discovering its optimal form.
Observe how these new variables affect the core gameplay. Think back to your experimentation with the Scrolling Shooter game. Notice how the elements you add play off of each other. Are there two that complement each other in such a way that could lead to a cool level? Take note of these interactions. They’ll form the mental puzzles that your player will face in the moment-to-moment gameplay of your game. We’ll take a look at how to implement these puzzles in the next chapter.
V. Teaching the Player
Your ultimate goal with any skill-based game is to lead the player to a mastery of the game’s mechanics. You do this by exposing him to each new element of the game in an isolated, low-risk environment. You then combine those elements to create new challenges and ramp up the difficulty.
One of my favorite platformers, Super Meat Boy, does a wonderful job of this. Let’s take a look at the first few levels.
In the first level, 1-1, the player faces no opposition from enemies or obstacles whatsoever. There’s no way for the player to die in this level; it’s a simple arena made for the player to get the hang of the controls. To win the level, the player only needs to be good enough to move Meat Boy across the screen and jump up to Bandage Girl on the middle platform.
In the second level, the game introduces a new mechanic: wall-jumping. There is no way for the player to reach Bandage Girl without learning to wall-jump up that passage on the right side of the screen. Notice how the level’s geometry makes the path to victory appealing; a ledge juts out to Bandage Girl’s left, discouraging the player from trying to jump up that way, whereas the passage on the right is large and inviting. As movie directors discovered long ago, it’s far better to show the audience something instead of telling them, even if they don’t realize you’re doing it.
Finally, in 1-3, we reach a level where the player can fail; a simple jump across the chasm isn’t enough to make it over to the ledge on the right. The player must hold down the run button and build up momentum before jumping to clear the gap. This lets the player know, without any written explanation, that running is required to make certain jumps.
A few levels later, in 1-8, the player is tested on everything she has learned throughout the first few levels: she must hold down the run button, jump to the center block, wall jump around to the other side of the block, and then jump over to Bandage Girl. The player will only be able to complete this challenge if she has learned the game’s controls up to this point.
Something else to take note of in this level is the number of sawblades. The designer could have left them out and just had a bottomless pit. Not to mention, those two sawblades at the top of the screen that aren’t even doing anything! So why have them there to begin with?
This is another level design trick: riddling this level with sawblades makes it appear much more intimidating than it actually is. To a Super Meat Boy veteran, completing this level will pose no challenge whatsoever. For someone playing the game for her first time, using everything she’s learned to complete this menacing-looking level will feel like a huge accomplishment.
Another game which masterfully conveyed its mechanics to the player within the first few minutes of play is, the one and only, Super Mario Bros..
The following is an excerpt from Nintendo’s Iwata Asks series, where CEO Satoru Iwata interviews the developers who work on Nintendo games. Here, Iwata is discussing the design of the first level of Super Mario Bros. with the game’s legendary designer, Shigeru Miyamoto:
Iwata: The mushrooms don’t just sit there, but actually move. What gave you that idea?
Miyamoto: Well, in games you can either have objects following you that move at the same speed as you, objects that follow you but are a little slower than you, or objects following you that are a little faster than you. That speed makes all the difference in terms of how fun it is. We repeatedly did trials and saw the results, and I was adamant that something that you really want is escaping you at a bit slower speed than you would be really fun.
Iwata: You can experience the enjoyment of chasing something.
Miyamoto: Right. There was one problem, however. When you play, you encounter a Goomba right at the start and it’s shaped like a mushroom.
Iwata: It does look very similar.
Miyamoto: So when you hit a box and something that looks like a Goomba pops out…
Iwata: You run away.
Miyamoto: Right, you run away. This gave us a real headache. We needed somehow to make sure the player understood that this was something really good. That’s why we made the mushroom approach you.
Iwata: Yes, that’s right. If you play the game for the first time with no prior knowledge, you’re going to run into the first Goomba and lose a turn.
Miyamoto: Right, which is why you have to teach the player in a natural way that they need to avoid them by jumping over them.
Iwata: Then when the player tries to jump and avoid them, there are going to be times when they get it wrong and end up stamping on the Goomba. By doing that, they learn in a natural way that by stamping on them, you can defeat them.
Miyamoto: As long as you stamp on them, you have nothing to fear from Goombas.
Iwata: But if you avoid the first Goomba and then jump and hit a block above you, a mushroom will spring out and you’ll get a shock. But then you’ll see that it’s going to the right so you’ll think: “I’m safe! Something strange appeared but I’m okay!” But of course when it goes against a pipe up ahead, the mushroom will come back! (laughs)
Miyamoto: Right! (laughs)
Iwata: At that point, even if you panic and try to jump out of the way, you’ll hit the block above you. Then just at the instant where you accept that you’re done for, Mario will suddenly shake and grow bigger! You might not really know what’s just happened, but at the very least, you’ll realize that you haven’t lost the turn.
Miyamoto: But you’ll wonder why Mario suddenly got larger.
Iwata: You’ll try jumping and see that you can jump to higher places and smash through the ceiling, so it’ll be clear that you’ve become more powerful.
Miyamoto: It’s at that moment that you first realize that the mushroom is a good item.
Iwata: That’s the reason why it’s designed so that whatever you do, you’ll get the mushroom.
In a visual medium like film, showing the audience will always be better than telling the audience. With games, we can take it even further. Instead of showing something to the player, we can have them interact with the game to find out what we want to convey to them all on their own. As Iwata and Miyamoto discussed, within the first few seconds of Super Mario Bros., the player is exposed to a small playground of the game’s elements and let loose to experiment with them. In this way, the player will learn the game’s rules without ever losing control of the game.
Design your games in such a way that encourages this sort of natural discovery. Showing is better than telling, but playing is better than showing. For a great resource on conveying your game’s mechanics, I recommend Egoraptor’s YouTube video “Sequelitis – Mega Man Classic vs. Mega Man X.” It contains quite a bit of language, but it’s hands-down one of the best videos on game design you’ll find on the internet. Its explanation of the concept of conveyance is perfect.
The path which your player takes as they learn how to play your game will be similar to the path you took to design it. Have them start small, with the most high-concept mechanics possible. What’s the first thing that the creators of Super Mario Bros. probably implemented in the game? Horizontal movement. What’s the first thing that the player will learn? Horizontal movement. As the designers added in more variables and learned what the final game would be, they built a chain of levels to show these new variables off to the player.
This is, fundamentally, what a game designer does. He discovers the game’s mechanics through experimentation and then builds the game in such a way that allows the players to mirror those discoveries as they progress.
VI. Achieving Harmony
Game development is time-consuming—there’s no way around it. Something as insignificant as making a door open could take hours to program depending on the complexity of the project. This is the why we start small; if we weren’t limited to 24 hours in a day, why not lock ourselves away for decades working on prototypes that would put even the biggest-budget games to shame?
Unfortunately, we humans only have so much time and energy to devote to game development. On top of that, in anything we do, our output will be capped by our current skill level. Though these limitations can be discouraging, being aware of them allows us to create art that’s interesting in its own right. As the famous painter George Braque once said, “It is the limitation of means that determines style, gives rise to new forms and makes creativity possible.” When you don’t have infinite resources to work with, you’re forced to create something special that can’t rely on spectacle or technical prowess to impress. Instead, it must achieve harmony.
Making a game where every element fits together like clockwork is something that you can achieve no matter how much time, energy, or talent you have to work with. You just have to be aware of those limitations. This is something that people participating in Game Jams—time-restricted game development events in which teams of people work on a game non-stop for a few days—have found out as they attempt to squeeze out as much creative output as possible from every second they have to work with.
One of my favorite Game Jam games, Titan Souls, takes the idea of harmony to heart. Created in only 72 hours by three people, its development team couldn’t afford to spend too much time or energy on any one thing. The group opted for a simple pixel art style, three combat encounters, and a soundtrack consisting of a few minutes’ worth of audio. By keeping the game’s small scope in mind from the get-go, they were able to pack as much beauty as possible into its ten-minute playtime.
PUNKSNOTDEAD is another game created in a small amount of time—12 hours, in fact, and by only one person. It has a black background, pink sprites, and just a bit of green thrown in for enemies with guns. The creator, mooosh, ran with this art style and used some of the 12-hour development time to add in all sorts of crazy particle and environmental effects to make the art pop out. The gameplay is just as stripped-down as the art; you run up to enemies and punch them. All this is set to a song with the unforgettable lyrics “Walkin’ down the street to get lunch / Walkin’ down the street, I get punched,” backed by a heavily-distorted guitar loop. The game is over in three minutes, but in those three minutes it accomplishes everything that it sets out to do.
You can take these principles and apply them to your own longer-term projects as well. The first few games in the BIT.TRIP series were made by a team of three people (plus one musician who worked separately but closely with the team). They created the first game, BIT.TRIP BEAT, in only three months—a much longer development time than anything you’ll see in a game jam, but short compared to most commercial projects. As with Titan Souls and PUNKSNOTDEAD, the developers of BIT.TRIP BEAT were forced to create something cohesive with limited time and resources. They did this by creating a game with finely-tuned gameplay and a unique, simplistic style.
The opposite of harmony is dissonance. In games, the most common type you hear about is ludonarrative dissonance, or a disconnect between the game’s story and its gameplay. The term grew popular with the release of Bioshock: Infinite, a game which was criticized for having excessive violence that didn’t serve the game’s story. Whether you agree with this particular criticism of Bioshock: Infinite, or even the idea of ludonarrative dissonance as a whole (certainly, there’s room for nonsensical games like No More Heroes 2 where the protagonist can transform into a bloodthirsty tiger during gameplay for no logical reason), it’s something to keep in mind as you attempt to craft a game which blends all its components together into one cohesive experience.
Finally, there’s one more thing that you can spend a bit of time tweaking in your games to make them better, and that’s their feel. Game feel is a difficult thing to explain through text, so instead, I’ll recommend two excellent talks on the topic that you can watch for free online. The first is “Juice It or Lose It” by Martin Jonasson & Petri Purho, and the second is “The Art of Screenshake” by Jan Willem Nijman. Both talks feature playable versions of their games for you to download. Take a look at the two games and study the techniques they show off. If you can learn to apply those techniques to your own games, you’ll find that everything you create will feel just a little bit more alive.
Little stylistic touches are where you can get a leg up on the competition as an independent game developer. You don’t need hundreds of people and years of work to prove that you have a good sense for design and a good eye for editing. Though you may not have a bigger budget than the AAA studios, you probably have a better style. Take advantage of this. Draw inspiration from everything you love (and everything you hate)—not just the games you play.
Game design is an iterative process. As you build your games and add more components to them, you’ll use a process similar to the scientific method: get an idea, test it, see if it works, decide whether or not to use it. The “testing” part of this process is integral to designing your game. As we talked about in the prototyping chapter, you need to know if your game works before you invest a ton of energy into making it.
To test your game, you’re going to need more opinions than just your own. Each one of your players will perceive your game differently, and these differences will be almost impossible for you to pick up on yourself. Your players will try things you’ve never thought of and will manage to break your game in ways you couldn’t image. For this reason, it’s important that you let as many people play your game as early and as often as possible. This is called “playtesting.”
No one likes to show off their game before it’s done, but it can’t be helped. The feedback that you’ll get from playtesting is too valuable to pass up. A great playtester will tear your game to shreds—this is exactly what you want. While positive feedback will let you know what to focus on, negative feedback will help you root out all the problems in your game’s initial design. Don’t fear criticism!
Your playtester will ask questions. Don’t answer them. Your game needs to be able to speak for itself. You won’t be able to stand over your player’s shoulder and give them advice when the final game has been released to the world. It’s best to nip any obtuse elements of your game in the bud right away in this early stage. Remember, conveyance is key; let the player learn through play. It can be painful to watch your playtester flounder around in your game with no idea what to do, but, like negative feedback, this is valuable.
You should, however, ask your playtester questions. You want maximum clarification on what they did and didn’t like about your game. That said, it’s important to remember who the designer is. Your relationship with your playtester is like that of a doctor to a patient; your playtester will tell you the symptoms, and you will come up with the prescription. Ignore their medical advice, and take nothing at face value. Don’t settle for “the game is too hard” as a piece of feedback. That tells you nothing. Ask them why they feel the game is too hard. When you get a meaningful answer, think about what it means. If the playtester tells you that the enemies are too strong and that they need to be weaker, there’s probably an imbalance in your game, but the solution might not be to make the enemies weaker. Maybe it would be more in line with your game’s design to make the player character stronger, or to decrease the number of enemies? Experiment with different solutions to the problem—the solution your playtester suggests most likely won’t be the correct one.
There’s no such thing as false feedback. If your game makes your player feel a certain way, then that feeling is valid. Making your game more digestible isn’t a bad thing; don’t think of implementing feedback as “compromising your creative vision.” Think of it as allowing your vision to be the best that it can be. You don’t need to change your game’s heart, but you should at least get it a nice haircut.
Also, it goes without saying that if someone tells you that your game sucks and you should quit game development because you’re a big dumb idiot (and usually they won’t tell you that in such tame words), you should ignore that person. For some people, tearing others down is the only way they know how to feel important. Unfortunately, you’ll have to deal with these people quite often as a game designer.
No game is perfect on its first iteration. If your playtester is a game designer, they’ll understand this and will give you some excellent feedback. Non-designers might not be so understanding. Exposing your project to the world in such a raw, imperfect form is hard, and it requires a lot of confidence in your ability as a game designer. People will tell you about problems that you already know exist, they’ll give you suggestions that don’t make any sense at all, and they’ll make requests that would triple the game’s development time. Just remember: you’re doing this now to make the final game as great as possible.
Also, be sure to write everything down. You will forget it.
VII. Never Fall in Love
In 2009, Kyle Gabler kicked off the first annual Global Game Jam (a 48-hour game design event held in January) with a keynote giving the participants seven tips on how to make a game in 48 hours. These tips have stuck with me, and a few of them have found their way into this book in spirit. The most important tip he gave, though, was his final one: “Never fall in love.”
Kyle explains in the video that, the more he cares about the project he’s working on, the worse it comes out. On the flipside, when he doesn’t care at all whether he succeeds or fails, he ends up creating something awesome.
He summarized this in what he jokingly calls the 2nd Theorem of Destruction: “When love and effort increase, the probability of self-destruction approaches 1.”
If there’s one thing you’ve learned from all this talk of prototypes and playtesting and iteration, it’s this: a game designer must be comfortable with failure. With each of your glorious failures you’ll gain a myriad of wisdom as a game designer. Look failure in the eye and welcome it with open arms. As Kyle discovered, the cruel twist is that, when you learn not to fear failure, you’ll end up having far better chances of success.
Luckily, a lot of smart people have come up with ways to bring out this care-free attitude in developers by giving us excuses to make experimental games in low-risk environments. The first we’ll talk about are game jams, which we touched on a bit in Chapter 5.
Participating in game jams is a great way to gain a ton of knowledge in a short amount of time. Of course, you don’t need an excuse to spend an entire weekend making a game with only a few breaks for food and sleep, but the community aspect adds a lot. Seeing what other people have made is just as valuable as seeing what you can make yourself. Whether you work with a team or on your own, I recommend participating in as many game jams as possible. You can find a list of upcoming game jams on itch.io’s jams page. The biggest ones are Global Game Jam and Ludum Dare, but there’s no reason not to try as many as possible.
If you really want to push yourself, you can try the Game a Week challenge, conceptualized by Vlambeer’s Rami Ismail and inspired by a less intense challenge called Game a Month. Making one game a month is a wonderful minimum pace to set yourself at, but if you want to take your skills to the next level, give Game a Week a shot. The idea is simple: you have from Sunday morning to the following Saturday night to create a game. When the time is up, release it to the public on a site like itch.io and move on to the next game.
That’s over fifty games in one year, an insane amount. And since you’re only working on each one for a week, you won’t get too attached to it. Whether it ends up being amazing or unplayable, at midnight on Saturday you won’t need to worry about it anymore. As long as you keep trying new things, you’ll gain an immense knowledge of what works and what doesn’t in game design.
And that’s with extra emphasis on “trying new things.” What’s most important in doing game jams or Game a Week is that you use these opportunities to experiment! You aren’t doing yourself any favors by recreating the Game Maker Sidescrolling Shooter tutorial with the only difference being that this version is in space. Don’t be afraid to create something horrible—you just might discover the next big thing! If not, there’s always next week.
Of course, you won’t have much time to playtest or polish these projects, but that’s okay. The ultimate goal of all this rapid game-making is to dull the scariness and unfamiliarity of game design. When you take on a long-term project, you’ll have to be able to approach it with the same sort of aloof and experimental attitude that you bring to your smaller projects. Always maintain a healthy distance from your games; as Stephen King wrote in his book On Writing, “Life isn’t a support system for art. It’s the other way around.”
IX. Long-Term Projects
Short game jam-sized projects won’t keep you satisfied forever. Soon enough, you’ll stumble upon an idea so good that you want to make a full-sized game out of it, and maybe even sell it.
Committing to a long-term game project is a big decision. In doing so, you’re designating a little part of your brain in the back of your head to work on it full-time for months, if not years. You’ll always be thinking about it. The project will be there, looming over you. For some, this is exciting. For others, it’s a huge emotional burden. Odds are you’ll experience some combination of the two feelings. But if you’ve gained enough experience making games through smaller projects, you’ll be prepared.
The development of a long-term project all comes down to staying committed and avoiding burnout. The key is, like with your small projects, to maintain a healthy distance and put your happiness and health above all else. This is true even if you think of the game’s quality as more important than your own well-being—if you aren’t at maximum creative capacity, the game will suffer. Working 22 hours a day is detrimental to both you and your game.
Exercise. Eat well. Maintain personal hygiene. The healthier you feel, the better your work will be. Keeping up with good habits can be hard while working on a big project, but doing so is essential to the project’s success.
Perhaps most importantly, sleep. Everyone needs different amounts, but for most of us, eight hours a night is perfect. So many creative people believe that they work better late at night running on low amounts of sleep—THIS IS FALSE! Your brain is at maximum creative capacity after getting a full night’s sleep. Putting off your work until late in the evening will hurt both you and your game. It’s better to work for two productive hours than eight sleep-deprived hours.
Your mental health is important too. Be social! It’s easy to lock yourself away and do nothing but work on your game for weeks, but your brain needs to interact with other humans too. Take time to be so far removed from your project that you have no reason to think about it. Go for a hike, go out dancing, do anything to get yourself away from the game. It keeps you refreshed.
With your health and happiness taken care of, you must also be sure to make effective use of your time. One method of making progress over a long amount of time comes from Jim Collin’s book Great by Choice. In it, he describes the concept of the twenty-mile march. The idea comes from the race between Robert Falcon Scott and Roald Amundsen to reach the South Pole. Amundsen ended up winning—why? Because he and his men marched 20 miles, no more, no less, every single day. Scott’s team, on the other hand, marched whatever distance they felt like marching that particular day. Some days they’d march 30 miles, some days they wouldn’t march at all. The point is, committing to a solid number each day gives you a constant to hold on to and a benchmark by which you can judge yourself. At the end of each day, you’ll know for sure whether you succeeded or failed. (Neil Cicierega has a convenient tool for this.)
Where you set your benchmark is up to you and your circumstances. You might not be able to work for more than two hours a day; heck, you might only have fifteen minutes. That’s fine. Work with what you have.
Another important aspect of long-term projects is organization. With a short game jam-sized project, you can get away with writing quick and sloppy code. Do not do this on a larger project. Disorganization will snowball onto itself and make your life exponentially harder as the project goes on. Leave yourself comments and notes—you can’t trust yourself to remember everything that you did or anything that you plan on doing. A lot of software developers use Trello as a way to stay organized. I use Word documents. Do whatever works for you.
Just because this is a long-term project, that doesn’t mean you can forget the Golden Rule of Game Development: start small. Less than three months is a reasonable development time for your first long term project. Build a prototype, expand on it, and playtest everything. If you commit to the project and do everything you can to make it the best it can be, you will finish it.
X. Where to Go from Here
I hope you feel that, in reading this book and applying its advice, you know everything you need to know in order to start making games. However, this is only the beginning. As you go off make games on your own, you’ll have to be self-sufficient enough to solve development problems when they come up.
The best way to solve non-Googleable problems is to ask for help from other developers, and one of the best ways to find them is to make use of the Game Developer Help List, a massive Google Doc created by Zoe Quinn to allow developers to reach out to each other when they need help.
The document is a spreadsheet, with each developer’s name, contact info, and specialties listed. Feel free to reach out to anyone on the list whenever you have a question—that’s what it’s there for.
When contacting a developer, it’s important that your email be concise, well-written, and specific. These developers are busy, and you don’t want to waste their time when they’re doing you the favor of helping you out. Ron Carmel gave a talk at Conferencias Videojuegos 2013 where he showed examples of what an email should and shouldn’t look like. Here was a negative example:
“i think you’re great at promoting your games, can you give me some tips?”
It’s definitely short, so we can give the author credit for that, but it’s unspecific. The grammar isn’t the best either. I think you’ll find that most developers aren’t huge sticklers when it comes to grammar, but the least you can do is ask a good question, even if you can’t write it well.
Here was a positive example:
“I’m a fellow indie developer, trying to learn how to best promote my game. I noticed you release weekly gameplay videos on your blog, can you give me an idea of how effective these are in generating pre-orders?”
Now that’s a good email! Short, well-written, friendly, and to the point. It’s a specific question that the receiving developer will be able to answer. Also notice how short the first sentence is as an introduction. The developer that you’re emailing doesn’t need to know your life story, or even the name of the game you’re working on. Spend as little time talking about yourself as possible.
Twitter is another great way to stay in touch with developers. Unfortunately, due to its 140 character message limit, it’s difficult to have any sort of meaningful conversation. At best, you can get in contact with a developer on Twitter and try to initiate an email exchange from there. Most developers will be happy to take the conversation to email if you demonstrate that it would be worth their time.
There are plenty of development forums on the web as well if you’d like a more community-oriented support system. TIGSource, the gamedev subreddit, StackExchange, and Braingale are all great places for developers to talk about their games.
Be sure to get in touch with local developers in real life too! And if there isn’t already a development scene in your area, help start one up. Paying it forward and helping other aspiring developers achieve their dreams is one of the best parts of game development. It’s a great thing to do, and in doing so you just might meet your next development partner or best friend. Just as established developers will help you, it’s important that you help the developers who come next.
Sometimes, it might feel like you don’t have what it takes. You’ll feel like everyone around you is just waiting for you to slip up and expose yourself as the fraud that you really are. The truth is, a lot of people feel this way. It’s called “impostor syndrome.” But remember: you’re unique, you’re skilled, and you have a whole world of developers standing behind you who want to see you succeed.
We’re standing on the shoulders of giants—take advantage of that. Learn all that you can, help everyone you meet, and go your own way.
Not to mention, the more awesome developers we have, the more awesome games we have. And we all want more awesome games.