This talk was delivered at the NYC Games Forum on February 18th, 2014.
I. Introduction
Hi I'm Michael Hansen. I work full time as a web-developer, but I am also a member of Brooklyn Game Ensemble, where I am working part time on a roguelike with Naomi Clark, Josh DeBonis and Eric Zimmerman.
In 2011, I decided (for the second time in my life) that I wanted to make games. Here are some facts that were true when I decided this:
- Games are awesome I love games and I want to make them.
- Game design ain't easy Good games are hard to make.
- I am a novice I play games, but I don't really know anything about game design.
- NYU has a new game design MFA However, NYU is prohibitively expensive and I don't feel like putting my life on hold.
Me now is the product of three years of muddling through and putting off quitting my job and going to grad school, and eventually realizing I didn't need to.
For me, this was a process of developing myself in a few different ways. I needed to learn how to think about games critically, practice game design (actually design games), and also work my way into New York's tight-knit community. These are the things I'm going to talk about tonight.
I think I was able to do this because I really wanted it. I didn't like the idea of me being a game designer and working in the game industry. I enjoy game design and learning about game design.
Three years ago, I would have told you that muddling through didn't seem like a good idea. I think that, looking back on it now, it was a great idea. I may not be on the same level as game designers who went through a masters program or who work in the industry and I might be missing something crucial with this talk, but my hope is that if you are just starting out I can save you some time.
II. Thinking critically about games
0. Go out and buy a notebook.
Or if you're crafty, make one.
Here's mine. It has, clearly, seen some things.
This is your game design notebook. Write all of your game design notes in it. When you go to talks like this one, take notes in it. Keep it with you at all times.
Don't tear pages out of it. Don't write stuff in it that isn't related to game design. Don't write stuff that is related to game design anywhere else. Transcribe your notes into it if you have to.
In a year, you'll thank me when you have a full tome of your own creation filled with ideas. It has all your good ideas. It has all your bad ideas. It has all the ideas that came to your mind while you were watching someone speak about their game.
I had a dream about playing a card game where you hang out with wild horses on the beach. I woke up at 4am and wrote down everything about it that I remembered. The next day I was able to turn it into a prototype.
When you have an idea, write in your notebook as soon as possible. I usually do a "high concept" title for example "Horse Beach Island" and then a bullet point list of features. Write down the special things that make your game idea unique, and write down the mechanics or features that you pulled from other games. The main idea here is that you can look at this writeup in a year and recreate the vision in your mind.
1. Read more
You need to put yourself on a diet of real games thinking. Everything else in this talk is about the practice of being a game designer. This is the one part where theory sneaks in. To understand games, you need to study them.
When I started, I read a ton of books on game design. This was probably really good for me, but in hindsight there was a lot of overlap and I could have been a lot more efficient.
To make this easier for all of you, I made a spreadsheet of every game design book I bought and read. Each of these has a one-sentence blurb on what they're about, as well as highlights to check out if you're looking at it in a Barnes & Noble.
To prevent you from wasting your money by getting a bunch of textbooks that are all rehashing the same thing, I also categorized these books based on what they cover. I'm not going to go over all the books, but I am going to explain how I categorized them.
Game design books are going to talk about definitions of what a game is and its component parts. These books are important to give you a baseline vocabulary for communicating you ideas about games, but they're also usually pretty dry.
Some books are going to talk about what games do in the world around them. This means looking at play and players, "games culture" and also culture as a whole. If you are interested in making things that express a message through the medium of games or that have an effect on your player's view of the world, you will want to read books that focus on these topics.
Books are also going to talk about the practice of game design. These are my personal favorite because they talk about game mechanics and also how to do work as a game designer: prototyping, designing, balancing, playtesting. They include case studies and tell you what works and what doesn't work.
And finally, game design books are often geared towards certain types of games. I've separated these out into three categories:
- Ambient games - I'm using the definition of "ambient" as it applies to "ambient music" meaning games and gamelike experiences with light mechanics that use videogame tropes to frame an idea
- Formal games - by this I mean games like Chess or Settlers of Catan which emphasize mechanics and systems but are often light on theme. Chess is a game with symbols that call back to the middle ages, but I don't imagine heavily armored men duking it out in a bloodstained field in England when I play it
- "Videogames" - by which I mean realtime interactive experiences involving a computer, sometimes in 3D, usually with some sort of physics simulation. usually with a human or anthropomorphic avatar that you control
2. Play a ton of games
I cannot stress this enough. Nothing is more influential on your work as a game designer than the games you play. Reading the material is important because it helps you to understand the forces at work in a game. It gives you the vocabulary you need to describe games.
However, I think that knowing how to talk about games will only get you halfway there, and to truly "get it" you need to play them so you can understand the systems they model, in your own mind.
There's a joke about game designers who can play a game for 10 or 15 minutes, understand it and move past it. I am that kind of person. It's helpful as a game designer but it means that I don't finish a lot of games (especially not console games). That's ok!
Having knowledge about a wide breadth of games is important if you want to make them. 9 times out of 10 when I open my mouth in a design meeting with an idea it's to say "this game does this thing this way, maybe we can think about it in a similar way".
Also I don't just mean video games. You should play board games! I play a lot of board games, and I made a list of my favorites for a talk I gave to my coworkers.
10 board games you should play
III. Practicing game design
3. Choose a tool
I have a programming background which puts me at an advantage here, but the tool I gravitated towards when I wanted to make my first game was Processing (which also happens to be the first tool I used creatively when I was in college).
Processing is very easy to understand and you can get stuff on the screen and moving around in a few minutes. It's incredibly well documented, every method has code samples that you can run yourself. There are examples for how to do everything from mouse and keyboard input to image processing to rudimentary physics simulations. The tutorials range from "learn to program" to "learn graphics shaders and 3d" and there's even one for how to expand into using the Processing library in a Java application.
In the long term, learning Processing is a good introduction to object-oriented programming in a C-like language. Here are some other tools which are based on concepts that are very similar to Processing:
- Java, which Processing is a subset of
- C#, which is what Unity uses
- openFrameworks library, which is a C++ implementation of most of Processing's methods
4. For your first game, follow a tutorial
When I started, I found this "How to Write a Roguelike in 15 Steps" tutorial on the RogueBasin wiki and followed that. It's actually a great framework for building any kind of game. These are the first few steps:
How to Write a Roguelike in 15 Steps
1. Decide to build a roguelike (or any other game)
I'm assuming you've all already done this, because here you all are.
2. Choose a programming environment
Hopefully I swayed you in the direction of Processing. I still use it for prototyping.
3. Screen output and keyboard input
Here we go. They suggest you do the standard "@ walking around on the screen" demo. If you've read "Rise of the Videogame Zinesters" which I recommended in the Material Matrix, this is actually the first thing you do in Anna's tutorial as well. You "introduce a character" and then "teach your character to do something".
4. The Map
Introduce another character, the world! Give your main character some more nouns (for example walls or fireballs) for it to verb on (for example: bump or avoid).
5.-15. Continue!
5. Min-max your time
Learn how to work
Not to sound cheesy, the most important tool you have is your own brain, and you need to learn how to get the most out of it.
I have a ritual that I do when I need to find the energy to work after I've already been working for 8 hours. Here it is:
RITUAL FOR A PRODUCTIVE EVENING AT HOME
- Turn off lights, but open blinds and windows (weather permitting).
- Drink a large glass of water.
- Lie on the couch for 45 minutes. As soon as you doze off the first time and wake up, get up. Don't continue sleeping.
- Order food, or heat leftovers. Boil water for tea.
- By now, it should be between 8:30 and 9 PM. You have roughly 3 hours of productivity ahead of you.
Use the best tool for the job
I fall into this trap very often. Programming is my HAMMER and every problem looks like a nail. Don't do it!
Building a new game? Make a prototype first to work the initial kinks out.
Are you mocking up an interface? Use a sharpie and paper. You can do 10 ideas very quickly in the time it would take you to layout stuff in code. This sketch took me about 15 minutes. These mockups took me several hours, and this actual working prototype is the product of a few weeks.
When I'm trying to design a "game economy", meaning the internal systems the describe how resources are exchanged (like gold or hit points), this can get very mathy so it's tempting to just program it. However I've switched to using this tool, Machinations, which is a free program that helps you model these kinds of things. Connecting boxes and arrows is way faster than actual programming
Make a habit of asking yourself "What am I doing?"
You need to develop a sense of self-awareness. Your time is limited, and so regularly taking a minute to examine what the difference is between what you need to be doing and what you're actually doing will save you time and sanity.
"Eat your own dog food"
If you play most of your games during your commute, make a game you can play while riding the subway. You will need to playtest your own games for hours and hours, so it's a good idea to pick a format that's compatible with how you consume games already.
6. Don't get lost
I want to point out the most common traps you might fall into.
Signs you are lost:
1. You picked an open-world 3D first person shooter or JRPG for your first game
You have no idea how to build one of these. Start small and add onto it.
I suggested a roguelike because building turn based games is way easier. With turn based games, particularly turn based games ON A GRID, everything is discrete:
- Wait for input
- Do player move
- Do "world" move (move enemies, update environment)
Complicated 3D, realtime games are also turn-based games on a grid, but the grid size is very small compared to the player, and you are taking 60 turns a second. You will get there one day.
2. You have a million ideas for your game and no idea where to start
Write these in your design notebook and get back to work. You'll get to them later (if they're still fresh).
3. You are building a general case for something that you MAY need in the future
Hard code it for now, and make a note of how it could change if you decide to add onto it in the future.
Signs you are on the path:
1. You are reading code and documentation more than you are writing it
Welcome to programming! This is what it is. You've got to learn to read before you can learn to write. This concept might seem familiar: you have to play games in order to learn how to design them.
2. You are intimidated by a tool
There are a million reasons why tools can be good or bad. A lot of very powerful tools have major downsides, and as a beginner, you might not be able to understand what they are. That's fine, and it's not your fault.
For example, I think Unity has bad documentation and a terrible API. They use the UK spelling for "Behaviour" but the US spelling for "Color". I think that if I didn't have experience with Java, and if I didn't work with someone experienced in Unity already, that there would be no way I could have ever learned how to use it.
3. You are bored with your game and you want to work on something else
Everyone has periods of doubt. Try to understand where this feeling is coming from and address that before you give up.
Is your game no fun? Take it in a new direction.
Is your vision too big? Pare down your idea until it's manageable.
This is where I break out the Oblique Strategies deck, which is a deck of aphorisms to help artists get over creative blocks by making you think about the answers to questions like "What would your closest friend do?" or "Work at a different speed."
IV. Getting into the scene
Now that you know how to talk about games, and you have something that you've worked on that you can show to people, the last piece of the puzzle is interacting with the games community.
7. Get involved
You must be on Twitter
This is where the conversation is happening!
Find someone who's work you admire and follow them on Twitter. They will retweet people who's work they admire. Follow THEM on Twitter too.
PROTIP: do it after the Game Developers Conference happens, because watching people be at GDC on Twitter if you're not also there is maddening.
Get to know people in the scene
1. Find game designers you like
If you follow a game designer on Twitter, you'll very quickly get a sense of what's important to them. You can see where they're coming from and how their experience informs their design.
2. Be interested in other people's work
The best way to get to know a game designer is to play the games they make or the games they love the most.
3. Show them your work
Bring something to the table when you talk to someone. Game designers love playing and critiquing games, and it'll give you something to talk about.
I went to IndieCade in the fall and I brought an prototype of my game on my phone. Bringing your work to show to people is great because not only do you get feedback on how they play and where they're confused, but also having people tell you that "it's fun" or "they'd buy it when it comes out" is the the kind of positive feedback you need to keep going on a project.
4. Be cool
Game designers are generally approachable people, and you should tell people when you like their work.
When you don't like something, or when other people love something but you are lukewarm about it, you should take the time to try to understand what they like about it before you write it off entirely.
In the interest of developing that sense of self-awareness: when something turns you off, try to understand what that is. It may be obvious. But all of these things that I've laid out in this talk--what people play and read and who they follow on Twitter--these apply to every other game designer out there.
Go to a conference or event
I don't have to tell you to go to events, because you're all at one.
New York has probably the best independent games scene in the US. There's a serious academic bent here thanks to Parsons, SVA and NYU--these schools and the people in them love getting together.
IndieCade East was this past weekend.
Different Games is in mid-April.
No Quarter is in May.
PRACTICE is my all time favorite, in November.
Offer to help
Finally, the last thing I want to say about getting involved is that you should think about your own talents and find out what you can contribute to it. Even if you are still honing your artist skills or learning to program, events always need volunteers to help run them. This is a great way to meet people, and you'll usually be granted free admission as well.
8. Do something else
I didn't learn about why minimalism in game design was a good idea because I made a bunch of games with overwhelming designs. I learned about minimalism at the salad bar at Whole Foods, when I put too many things in the same carton together and it ended up being $15 and terrible. It's important to get away from games occasionally because there are a lot of lessons that are more easily learned elsewhere.
A friend of mine is making a game based on the Lewis & Clark expedition. In his free-time, he hikes, camps, hunts and fishes. He says that "getting away to have all these other hobbies outside the city is really difficult", he has to be purposeful and plan ahead, but he does it and when you look at his work you can get a sense of his reverence for nature. That is the kind of connection with the subject that shines through in your designs.
This is a picture of Khumjung, which is a town at the base of Mount Everest. This is a screenshot of the "Nepalese Village" in Uncharted 2.
I think we can all agree how ridiculous this screenshot is. Once you get over the fact that he's shooting a handgun at a Russian (and not Chinese) tank--also, this particular model, the T-62, was last produced in 1975, 7 years before Nathan Drake was even born--once you get past that, and if you can put out of your mind how maneuverable this death machine probably isn't, and how Drake could "just, you know, run away?", you might ask how this tank found its way up the mountain and into this tiny Nepalese village in the first place.
I think that if you had actually ever been to Nepal, at some point in your visit it might have been impressed upon you that it's a.) beautiful and b.) not a place for tanks.
I'm picking on Naughty Dog right now for setting out to and succeeding in making a game that feels like a blockbuster action movie, and I want to point out that Richard Lemarchand, who designed Uncharted, is on the board of advisors for IndieCade. The point I'm trying to make is that people play independent games (and listen to independent music or watch independent films) because they're drawn to their authenticity and raw, weird humanity. So if you're going to make independent games, you're not going to be making something like this, which, like blockbuster action movies, is catering to the "core gaming audience", namely men between the ages of 18-35 who have power fantasies and the disposable income to exercise them.
You're going to be making something different, and it will be a projection of the world through your own personal lens. This doesn't mean you can't make a game where people shoot eachother. I'm just suggesting that instead of being inspired by World War II or Star Wars, maybe it should be inspired by Japanese psychedelic rock or a weird children's book from the 70s or a really thoughtful science fiction novel you enjoy.
Thanks!