Gaming Game Design

by Seth Kenlon

Every year there’s at least one appealing game jam or game-related hackathon tempting hobbyist programmers to contribute code. There’s something appealing about the idea of blocking out a long weekend for literal days of immersing yourself in code. But frustratingly, there’s a phenomenon that happens with programmers that I’ll call a peak reversal: your once-fledgling coding skills have escalated so you’re no longer blocked by programming skills, but somehow along the way you’ve lost touch with all the great ideas you thought you had about what you ought to spend time coding. The time to address this problem is now, before you sit down to code, and like most things worth doing, you can solve this one by gaming the system.

Reductionistism

One problem of coming up with a great game idea is that you know that anything, theoretically, is possible. Before you start writing code, you have an embarrassment of wealth. Anything is possible. You know how to make each element happen on screen, and you can even visualize the code now.

That’s a natural mistake to make, and it’s actually a good thing, because it’s the same impulse that drives brainstorms. Instead of becoming overwhelmed with ideas, let it turn into a brainstorm. Write everything down: no idea left behind.

Once you’ve done that, you have a word cloud consisting of mostly unconnected and seemingly incompatible ideas. Take note of the elements you enjoy in games. Reduce and distill your ideas down to a few key concepts.

For instance, say you’ve written down ideas for a driving game, an RPG, and a Tomb Raider clone. At first glance, these are three separate ideas. But if you treat them as ingredients instead of goals, then you suddenly have several possibilities. For instance, a game in which a player drives through puzzles to find new and better parts for their car. Or a car repair shop sim in which players discover hidden treasures by repairing cars. Or a platformer in which the player is a car that can’t drop below 50 MPH until the car levels down to slower speeds, thereby unlocking greater precision during increasingly more nuanced puzzles.

The possibilities are a lot clearer, and instead of being overwhelmed, you’re empowered.

Brute Force Mechanics

Sometimes the details of a game play can have a domino effect on your mechanics. Things you thought would be bonuses for a player turn into burdens. Fun little challenges you threw in to take your players by surprise turn out to be annoying distractions. It’s impossible to anticipate which mechanic is your real hook until the game has been play-tested, at which point your players will tell you what your game’s hook is.

If you have the time to rework how your game plays, then you may be able to fine-tune your creation until a broken mechanic works the way you want it to work. If you don’t have unlimited time, however, you might consider the brute force technique.

When you brute force your game mechanics, you let the mechanics form themselves, usually in relation to one another. There’s a way to practice this principle in real life: go buy a Magic: The Gathering starter deck, throw out the rulebook, and use the cards to invent a game. Of course, if you’ve ever read a Magic card, you know that they’re filled with data, including integers, symbols, rules, names, and flavour text. Each card is highly specific to not only the rules as written but also to the current iteration of Magic itself. And yet, a new rule system can be imposed, you just have to throw out or modify the meanings of the parts that exist but don’t work for the game you’re inventing.

In video games, you can do this by changing your code. Bonus items can be changed into cursed items, annoying challenges can become set dressing, win conditions can become triggers for a new challenge. Everything can change, and the mechanics around it will either adjust to fit, or they’ll get changed too.

When something’s not working in your game concept, try inverting or reversing it. See what effect that has on your game. After you’ve adjusted enough mechanics, your game will find you.

Prototype Early, Prototype Often

There are enough simple interpreted languages and game frameworks now that it’s trivial to prototype an idea. You don’t have to use anything fancy; as long as the language you choose can do math, you can emulate at least some of your game.

My choice for prototyping is Lua, a scripting front-end to C that happens to be used for the truly exciting (and cross platform) LÖVE game engine (among many others). You can prototype the basic math of your game in either a script or an interactive Lua shell, and then continue development all the way to completion. From battle card games to dungeon crawls to platformers, Lua and LÖVE is a fast, efficient, and friendly way to get your game ideas from a frantic brainstorm using Magic cards and Monopoly meeples to a video game for Linux, Windows, and Mac.

Gaming

Gaming is meant to be fun, and game design has the unique quality of being, itself, a game. Have fun with your game design, but don’t try to force it into existence. Sneak up on it by gaming game design.

About the Author

Seth Kenlon is a teacher, artist, D&D dungeon master, free software and free culture advocate, and UNIX geek. He has worked in the VFX (The Hobbit, Deadpool, Valerian) and computing industry (IBM, Red Hat), often at the same time. He is one of the maintainers of the Slackware-based multimedia production project.

This article was contributed by Seth Kenlon, author of Developing Games on the Raspberry Pi.