GeekGirlCon ’15 Recap: You Can Make a Game (Yes, You)
This one-hour panel, given by Elizabeth Sampat and Zoe Quinn, was a crash course in how—and why—to make your own game. Between them, the two designers have made video games, tabletop games, board games, and other entertainments, and they brought their breadth of knowledge and experience to GeekGirlCon attendees. Each half of the panel could really have been an entire talk of its own, being condensed versions of talks and workshops that Sampat and Quinn have given elsewhere. If you’re interested in more in-depth information on these topics, check out Elizabeth’s and Zoe’s websites.
Zoe Quinn and Elizabeth Sampat at GeekGirlCon ’15. Image source: GeekGirlCon Flickr
Elizabeth Sampat went first, with a talk called The Systems of Autobiography, about making games that are personal and emotional.
A pivotal moment in Sampat’s personal history was the death of her older brother, Doug, when she was eleven. She sometimes wonders who she, and her family, would have been if he had lived. For many years, she didn’t allow herself to grieve for Doug, but is now making a game to help process those experiences.
Before digging into the process of designing this game, she did offer one warning: if you make a game about the worst thing that ever happened to you, you have to relive it over and over.
Any biography, however, must be purely background; the story is a pared down version of history. Get to the heart of the story, she said, and put the player there.
The heart of the story of Doug’s death, for her, is a feeling of suspended progress. Sampat’s inability to grieve blocked her from progressing for many years, and Doug’s progress through life was suspended—permanently—by his death.
How do you make a game about that?
Well, she could make a platformer. Jump through the levels, collect grief points, fight the protagonist’s zombie brother.
Sure, that would create sympathy for the protagonist, but the point of making a personal game is to get the player to feel empathy, not sympathy, which distances them from the emotions and the stakes. She emphasized that empathy in games is not new or edgy—creating a world from scratch is playing god, after all.
Instead of the platformer, she decided to start creating Lifted. There are just two characters, the player and an AI character. At certain points in the story, the AI turns gray and can only move if the player picks it up. The game doesn’t mention grief directly, just takes the idea of suspended progress and contrasts it with the idea of lifting up.
Cover image for Deadbolt. Image source: Emily Short’s Interactive Storytelling
Another design dealing with her suspended process is Deadbolt, an example of what she calls a ‘correctional’ game. She dug into aspects of herself that she doesn’t like, or wants to change, in this case her difficulty with social situations. The goal is for the players to experience social connection, and to chip away at the things that block that goal.
She made it a tabletop game to create direct connection between the players, and the players must tell each other stories that make them vulnerable, in a highly ritualized fashion in order to do away with small talk.
Since the game was designed to correct her personal flaws, she has the only copy. Every time the game has been played, she’s been there.
These two examples illustrated her two approaches to designing a personal, emotional game:
- Emulating the way things are
- Exploring how you wish things would be
Making a correctional game is very emotionally difficult. As a designer, you must ask yourself What do I regret? What would I change? Am I prepared to face those changes?
She left us with a few notes on playtesting your personal games. In order to give the best feedback, the playtesters must be people who know games, and who know you. As playtesting progresses, add testers who have not been there for the whole process, so the first iteration they see is the current one, and they come to it with fewer expectations.
Remember that you’re not the only one who’s putting themselves out there emotionally; players are also vulnerable when they play. “Making them feel something is basically like mind control,” she said.
Zoe Quinn’s half of the panel was much more of a practical guide to game design options, being a condensed version of a course of practical workshops, available online at Sortingh.at. The workshops are presented in Twine, so it’s a game about making games in a game engine—very meta!
One pitfall common for beginners is the idea that they need to find the perfect tool, but Quinn emphasized that having a finished game that isn’t perfect is far preferable to hunting for the perfect tool and never finishing anything.
She recommends picking either 2D or 3D, choosing from the available tools for that medium, and getting started.
For 2D, some good options are RPG Maker, Game Maker: Studio, and Adventure Game Studio, all of which have GUIs, which makes things much easier.
For 3D, Unity is by far the best for novice designers, and has the best community support.
She also mentioned a few tools ideal for specific game genres: Ren’Py for dating sims, Inform for text parser games, and Twine for point and click.
If you want to make an MMO, she said… your idea is too big. As a solo, novice game designer, don’t do that! You’d be setting yourself up for failure.
All these tools come with pre-made levels and tutorials. Don’t skip the tutorial, she says. Take a pre-made level and modify it until it’s unrecognizable. When you show your first game to someone else, do it in person if you can—the feeling of watching someone play through your creation is awesome!
For your first original game, take your idea and throw out 99% of it. Your scope is too big, guaranteed. It’s something that happens to every designer, no matter how experienced.
She quoted Antoine de Saint Exupéry: “Perfection is attained not when there is nothing left to add, but when there is nothing left to take away.”
Ask yourself, what is fundamental? What is the thesis statement of the game—start with one core thing and make it work; if it doesn’t work, throw it out. Once that core statement works, wrap other game elements around it.
At all stages, but especially when starting out, lean on forums. Everyone felt like they knew nothing at the beginning, and they have a lot of advice to give.
Screenshot from Depression Quest. Source: Depression Quest website
She talked about her game Depression Quest. Her experience was that people don’t understand how depression works, that they don’t get that it’s more about not being able to do things necessary to daily life. The core statement of the game was to show people with depression that they are not alone, and to do this she used art and photos to show that it’s a real life illness.
However, even when the game is about you (ie. personal and emotional), remember that it isn’t about you. It’s not enough for you to like the game—you have to speak to other people, and take the player into account.
In order to get your game in front of players as soon as possible (so you can course-correct if it isn’t working as you intend it to), use open source art and code to make a prototype as soon as possible. If you intend to work with artists or programmers, having a prototype proves that your game could really work, and helps get other people on board.
If you want your game to speak to a wider group of people, you need to reevaluate at every step, playtesting with people who don’t know you, with people’s parents, with people who don’t have the vocabulary and expectations of games, or that game genre.
Anything you put in there “because that’s how video games are” needs to go, because it alienates people who aren’t steeped in video game tradition and convention. If the game drives you in a particular direction, even if you didn’t expect it, roll with that and see where it takes you. And always remember—it’s OK to make short games.
The audience Q&A covered a lot of ground, from how to get honest feedback (don’t let people self-report. Watch how they play, and where they get stuck. In tabletop games, note how many times they look at their phone, and at what point) to why cheat codes exist (they were originally used by developers for testing, but now people like putting in fun easter eggs for players).
One young kid got up to ask, “Are games meant to be a certain way?” To which our panelists gave the heartfelt response: “If you say it’s a game, it’s a game.”
Have you ever revisited old ideas? one questioner wanted to know.
The panelists explained that they have what they think of as a mental ‘shelf.’ Sometimes they didn’t have the tech skills at the time they came up with the idea, and later, when their skills have developed, they take the idea down and dust it off. (Relatedly, they said, if your first project is too large, you may find that your skills improve so fast that you’ll have to throw out your earlier stuff.)
The final question was about originality—how do you make a game without copying other people?
Don’t worry about it, said the panelists. Reverse-engineering is good for practice. Don’t put in something just because you see it in other games, but if you make a game from your brain and your gut, even if it uses some of the same features, it won’t feel like other people’s games.
