Home > Articles > Programming > Games

How a Common Game Design Language Can Improve Game Design

  • Print
  • + Share This
Many video games fail at a basic design level. But if we’re going to discuss game design, the first thing we need is a vocabulary. By equipping ourselves with a language for talking about design, we are giving ourselves the ability to design. This chapter describes the need for such a game design language and explains how and why it will help improve game design.
This chapter is from the book

Signs Versus Design

New Super Mario Bros. Wii, released by Nintendo in 2009 (see Figure 1.1), is a sequel or a remake of Super Mario Bros. from 1985. Though the newer game diverges pretty quickly in design from its progenitor, the first few screens of the first level of New are arranged in deliberate mimicry of the same screens from the 1985 version. The player (or players, in the case of New Super Mario) starts on the left side of the screen; to the right, there’s an enticing, flashing block with a question mark on it, floating just above the ground. Then the game’s most basic enemy trundles toward the player to the left. After that, you see two parallel platforms made of hovering blocks, some breakable, some that contain rewards, one of which contains power-up items for the players. After that, there’s a tall obstacle that the player has to jump over to progress further: a big green pipe in the 1985 game, the side of a cliff in the 2009 one.

Figure 1.1

Figure 1.1 New Super Mario Bros. Wii starts with an arrow pointing to the right.

Super Mario Bros. was many people’s first videogame; there were almost no games similar to it at the time. New Super Mario Bros., in contrast, has almost twenty years of related games as precedent. Despite that, the 1985 game leaves one thing out that’s present in the 2009 game: a big sign with an arrow telling the player which direction to go.

What happened between 1985 and 2009 to cause game creators to lose that much trust in the player? The player of New Super Mario Bros. Wii gets off easy, in fact, as far as “tutorials” go. Lots of contemporary games feel the need to explain to the player, via game-interrupting exposition and big stupid dumps of instruction text, how they are played. Many games even keep the player from starting the game until she’s proven she knows how the buttons work, making her jump in place, in a contextless situation, like a trained pet.

This is shockingly popular. I see it not just in the big-budget commercial games that have the economic incentive to keep as few players from getting confused as possible, but also in smaller games, in freeware games, in games created by one or two people working out of their bedrooms. When I met Pietro Righi Riva, one of the creators of the downloadable game Fotonica, at the 2012 Game Developers Conference (GDC), the first thing he said to me referred to my take on New Super Mario Bros. Wii: “You were right. That game didn’t need a tutorial.” This kind of blunt instruction speaks not just to a disrespect for the player’s intelligence—and one that influences how she feels about the game, make no mistake—but also to a lack of confidence on the part of the creator.

Super Mario Bros., 1985, didn’t need a tutorial. It used design, a communicative visual vocabulary, and an understanding of player psychology—gained from watching players play the game, changing it, and watching them again—to guide the player to understanding the basics of the game. Those first screens teach everything the player needs to know: Mario starts on the left of an empty screen, facing right. The floating, shining reward object and the slow but menacing monster—set in opposition to Mario by walking in the opposite direction—give the player an incentive to jump. The platforms are a kind of jungle gym where the player can experiment with jumping, discover the properties of various kinds of blocks, and encounter her first power-up. Even if the player’s not sure whether the power-up is dangerous, it moves too quickly and in too confined a space to be avoided. When the power-up turns out to benefit Mario by making him grow, the player has learned something about how monsters and power-ups look and behave in this game. Then the final pipe barring access to the rest of the game makes sure she knows that the height of her jump is dependent on how long she holds down the button.

You can argue that coding a game in 8605 Assembly for the Nintendo Entertainment System in 1985 was much more demanding, and building a dedicated “tutorial” into the game would have been harder. People like to point to technological justifications for things in digital games because most videogame fans are sold on the idea that the history of games is a history of technology. If there were technological reasons that dissuaded the designers of Super Mario—Shigeru Miyamoto and Takashi Tezuka—from training the player through instruction text and encouraged them to use design to teach the player, then God bless the limitations of 1980s game machines. Design is not technology. The printed manual packaged with the game contained more information about how to play, but perhaps keeping in mind how often manuals go unread or get lost far before the software they accompany, Miyamoto and Tezuka made sure that the game itself could convey understanding through playing.

Someone in 2009 looked at the opening screens of the original Super Mario Bros.—someone had to, to copy these screens note for note into the first level of New Super Mario Bros. Wii—but didn’t understand what they meant or why they were so effective. Why are game creators unable to understand and learn from their own history? Why are they bumbling over problems that were solved almost 30 years ago?

Digital games have exploded commercially since 1985—in fact, Super Mario Bros. was proceeded by more than a decade of successful videogames—and we’ve consequently learned a lot of new words with which to talk about and describe videogames. Unfortunately, those words come from marketers, brand-loyalty Internet arguments, and magazines that exist as extensions of publishers’ PR departments. The language that exists to describe videogames is facile when applied to the very real problem of discussing design.

Most designers, lacking the vocabulary with which to discuss, analyze, and criticize game design, operate largely by intuition and instinct. And there’s a lot to be said for intuition and instinct: A lot of radical decisions are made by instinct and then only understood in hindsight. But what if a designer is working in a team? What if someone else is drawing the characters that will appear in a game? What do they need to convey, and what does the designer need to tell them? What if a designer is working with another designer? How will the two communicate about the needs and direction of the game?

I’m not the first person to notice this problem. Back in 1994, game designer Greg Costikyan wrote an essay all about it, called “I Have No Words & I Must Design.” At the beginning, he says, “We need a critical language. And since this is basically a new form, despite its tremendous growth and staggering diversity, we need to invent one.” He was right then, and he still is.

Consider that we’re all in a team—difficult in light of the practices of most contemporary publishers, I know—and that we all have access to this tremendous, growing resource of game design solutions: every videogame that has ever been made. By understanding those games—how they work or don’t work, what they’re doing and why—we get better at making our own games. We don’t repeat problems that were long ago solved, like how to convince the player to go right. But how can we understand those games if we don’t have a language with which to talk about them? How can we have a discussion?

Once upon a time, I studied creative writing. Someone would submit a story, everyone else would read it, and then we’d sit in a circle and people would offer their critiques, with the goal of allowing the author to improve the story and, in the process, improve her own writing ability. This was called “workshopping” a story. We would talk about things like how a story was paced, how certain passages or phrases helped—or failed—to characterize the characters of the story, which parts were weak, and which succeeded.

No game creator wants to put a tutorial into her game, to make the player press the jump button five times before being allowed to press the shoot button five times. A game creator puts a tutorial into a game because she lacks confidence in her ability to teach the player the rules of her game without explicitly stating them upfront. In a board or card game, it makes sense that the players should be aware of the rules upfront because they’re the ones keeping the rules. But the great strength of digital games is that, because the computer is performing the task of enforcing the rules and tracking the numbers, the game can withhold some of the complexities of the rules from the player. When the player discovers those complexities later, it feels like a story is developing.

How do we lead the player to those discoveries? That’s called “design.” And, frankly, I don’t think we, as designers, are doing enough of it.

What game designers need is a workshop—the means to design, have their design critiqued, and improve their craft. We need to be able to discuss design as a craft. And if we’re going to discuss game design, the first thing we need is a vocabulary.

  • + Share This
  • 🔖 Save To Your Account