Category: Game Design

Note: this post was originally published in the August 2014 issue of ASPects, the official newsletter of the Association of Software Professionals.

This is the final post for Game Design Workshop Wednesday. You can see the #GDWW introduction for a list of the exercises I published.

As Chair of the Interactive Media & Games Division at the USC School of Cinematic Arts, Tracy Fullerton teaches game design with a “playcentric approach”. What is a playcentric approach?

She describes it as an iterative design process with player experience goals. Her book, Game Design Workshop: A Playcentric Approach to Creating Innovative Games, Third Edition, teaches the reader how games work, demonstrates how to design a new game through prototypes and playtesting, and finally explains how the game designer role fits into the larger industry. By the time you’ve read the book, you should not only be able to create new games that are compelling and enjoyable to play, but you should also be able to make a living at it.

Except, just reading a book about game design won’t make you a game designer any more than reading a book about how to draw will make you an artist. Saying that “the only way to really become a game designer is to make games, not just play them or read about them,” Fullerton fills the book with plenty of exercises to reinforce lessons as well as provide ways to practice. In fact, she recommends seeing the book as a tool that guides the reader through the design process to get the most out of it.

The first part of the book focuses on the basic components of games, providing a common vocabulary to prepare the reader for the rest of the lessons. Fullerton’s definition of a game? A closed, formal system that engages players in structured conflict and resolves its uncertainty in an unequal outcome. She makes a point of claiming no ultimate definitions of games, however, stating that what she has provided is a starting point.

An entire chapter is dedicated to the formal elements of a game. For some elements, a list of examples is given, such as the various player interaction patterns or the general types of objectives one might encounter. With a good understanding of mechanics and the rules that make up a game, the reader can critically analyze existing games and is capable of putting together unique game designs.

The chapter on dramatic elements starts with a discussion of the roles of challenge and play before explaining how traditional dramatic elements, such as premise and the dramatic arc, manifest in games. The idea is that a game designer using these elements can more effectively create powerful emotions for the player.

The mechanics and dramatic elements are static, but games are also made of systems. The system dynamics chapter breaks down a few games, contrasting tic-tac-toe with chess and Mastermind with Clue. Concepts such as resource exchange, emergent systems, and feedback cycles are touched upon, and it is easy to see how challenging it can be to identify the key relationships between the properties of different elements in the game.

The second part of the book takes the reader through the actual game design process, starting with idea generation and ending with an eye towards ensuring the game is accessible, enjoyable, and complete. It is this part of the book that really emphasizes player experience goals of the playcentric approach.

While having a lot of ideas helps you identify the good ones, you need to start with one, and Fullerton provides a number of ways to help you narrow it down.

She splits prototyping into two chapters, one focused on physical prototypes and the other on the unique challenges and benefits of digital prototypes. While one might think that digital prototypes would be ideal for computer games, physical prototypes are quick ways to work with basic mechanics without worrying about the scaffolding of creating a full application, including the need to design the right control scheme and aesthetics. I particularly enjoyed Richard Garfield’s explanation of how the design of Magic: The Gathering evolved.

I wish the digital prototyping chapter explained more about how to create the actual prototypes and not just what kinds of prototypes to make. In the most technical section, it felt like it was too much theory and left the reader figuring out how to proceed without too much guidance besides getting informed about game engines and level editors.

Playtesting is incredibly important, as without it you are designing games in a vacuum. An entire chapter is dedicated to recruiting testers and organizing the sessions that will allow them to tell you how your game could be improved, complete with multiple articles with insight into how various game companies have conducted playtesting sessions to greatly benefit the game they were working on.

Part three provides an overview of the experience of working as a game designer. My first impression wasn’t positive, as I wondered why a book about learning how to design games would give so much attention to the jobs you might get. But then I realized that this chapter wasn’t about finding a job but about the practical realities of being a game designer.

It’s rare for a game designer to also be a competent artist, programmer, and composer, which means that a good game designer needs to be able to work with a team. Being able to communicate a design decision is critical to getting everyone aligned with your vision, and you need to be able to take feedback. Everyone has something to contribute to the design of a game, as game development is a collaborative art. What’s more, understanding the business end of game development and publishing can only help your designs.

While the book features interviews with prominent independent game designers such as Jenova Chen and Asher Vollmer, a big focus of the third part was working within a larger company and major publishers. I wish more was dedicated to independent game development than a single page.

Between the exercises and the main text, the book features many game designers such as Brenda Romero and Will Wright offering their insights through articles and interviews. In my own experience as a game designer, I know there have been plenty of times when I wondered how other people would approach a particular problem, and this book provides 30 quick interviews with designers getting asked the questions I would ask.

Each chapter also provided at least one article explaining a particular topic in detail. For instance, in the chapter on system dynamics, there is an article that critically analyzes the card game Set. It provides a good example of the kind of rigor needed to break down the seemingly-simple rules and components to fully understand a game, and it prepares you to start making changes to see what impact they would have on the experience of playing it. You could look at a game of solitaire and imagine how much more complexity would be introduced by adding a new suit, for example.

I appreciated Fullerton’s emphasis on innovation. Her focus was on providing tools and skills to create more than mere knock-offs of existing games, and she sprinkled the text with her positive outlook on the possibilities of what games can and will be. I could tell that one of her goals is for her students and her readers to be the kind of game designers who transform the industry.

People without programming or artistic skills need not worry too much, as the game design lessons are non-technical in nature and are quite accessible, although the digital prototyping chapter did encourage readers to learn at least one programming language. That said, the book is the next best thing to being in an actual game design workshop with Fullerton as it combines hands-on exercises, anecdotes and interviews with existing designers, and practical lessons.

Each week, I’ll go through an exercise from Tracy Fullerton’s Game Design Workshop: A Playcentric Approach to Creating Innovative Games, Third Edition. Fullerton suggests treating the book less like a piece of text and more like a tool to guide you through the game design process, which is why the book is filled with so many exercises.

You can see the #GDWW introduction for a list of previous exercises.

For this week, I’ll be working on a prototype.

Prototyping

Prototyping is a very important tool for a game designer. It allows you to test a game’s mechanics without worrying about the perfection of the details. Paper prototypes are great because you can get a sense of how well your concept works without code or graphics being needed, allowing you to iterate over a number of ideas very rapidly and inexpensively.

Fullerton offers the following four-step process to make a paper prototype efficiently:

1. Foundation: build a representation of the core game play.
2. Structure: identify the key rules of the game.
3. Formal Details: flesh out the needed rules and procedures to make it a complete game.
4. Refinement: polish up the play experience to make it flow.

The Initial Concept for Dragon Tail

I’ve been toying around with programming a simulation about segmented creatures recently, and so what easily came to mind is the idea of a segmented tail whipping back and forth to attack the unwary. I eventually came up with the idea of a game about stealing treasure from a dragon.

The goal of Dragon Tail is to steal more treasure than your opponent.

The core activities that can be performed by the player including:

• moving
• picking up and dropping off treasure
• poking and avoiding the dragon’s tail

Ultimately, I would like this to be a real-time mobile game. I’m not sure how the lack of a keyboard will impact the controls of such a game, but let’s not get ahead of ourselves. I want to work on the initial game design before I worry about implementation details of the finished and polished version.

Foundation

I admit that I struggled with this part. Did I err on the side of not having enough detail, or was I adding rules when I didn’t need them yet?

I used some components from my game design prototype toolbox and some graph paper to create an initial scene.

There are two players at one end of the play area, each with their own barrel to signify retrieved treasure. The treasure is at the other end. Also extending from the far end is the dragon tail, implying a dragon protecting treasure but facing the other way.

Right now, as this is a paper prototype, the game will be turn-based. A player can run by moving between adjacent spots.

If the player is next to a treasure, he or she can pick up a single piece of treasure and carry it. While carrying treasure, movement is slowed. The player can then attempt to bring the treasure back to the barrel.

So far, it isn’t much, but it’s a start. There are a lot of questions. How far can a player move in a single turn? How much slower is the player made to move when carrying treasure? How much is treasure worth? What about the dragon tail?

But it isn’t a small thing I’ve done. Retrieving treasure is the main activity, and I’ve established that treasure can only be taken one piece at a time. Or am I being premature in making that a rule at this point?

If players can’t collect all the treasure at once, treasure-stealing is a drawn out affair. On the other hand, if the player is allowed to collect multiple pieces of treasure at once, perhaps the encumbrance increases and movement is slowed progressively. Steal one piece, and you can move relatively faster than if you steal five pieces.

Perhaps these are questions best left for the Structure step, and for now the idea of multiple pieces of treasure and the idea of running and collecting them is enough to identify the core game play.

Already I am thinking about how the players will interact with each other and the dragon tail. Poking the dragon’s tail forces it to swing in the other direction.

In this shot, one player is returning with treasure, but the other player has poked the tail, which has started whipping slowly toward the first player.

How the tail moves sounds like a Structure issue as well, but the idea that there is a tail that moves away from the player who poked it and can eventually hit the opponent might be enough here.

Does the tail merely knock him or her over temporarily? Does it kill the player and force a respawn? What happens to the treasure if it was being carried?

As I said, I struggled here with trying to keep the prototype in the Foundation step. Fullerton asks you to try to play your core game play on your own in order to see if the basic concept is worth pursuing while avoiding the temptation to add rules unless they are absolutely necessary. But how do I play this game without putting some rules in place to dictate how I can play it in the first place?

So far, I know I have some number of treasure pieces, a whipping tail, and competing players who can move, carry treasure, and poke the tail. The players can also be hit by the tail with some currently unknown consequences.

It’s probably time for some structure.

Structure

Where do I start? I think the movement of the players is a good place, as moving is going to be a key part of the game play. It allows you to make progress towards collecting treasure and dodge the swinging dragon tail.

I divided the play area into a grid of squares. A player can move between adjacent squares and is allowed to move up to three squares each turn. When carrying treasure, a player is encumbered and can move only one square.

Treasure can be collected one piece at a time. There. Now it feels OK to make this rule. How many pieces are there? Maybe specifying it now is too early. There are multiple pieces available to both players. Maybe that’s enough for now.

How does a player obtain a piece of treasure? Instead of moving, a turn can be used to pick up a piece. Dropping off the piece in the barrel, however, is automatic and does not require more than being adjacent to it.

And the tail? It’s segmented, represented by the wooden heart pieces. As you get further down the tail, each segment attaches to the end of the previous. Each segment can turn 90 degrees left or right, which affects the positioning of the remainder of the tail segments.

For example, if a segment is turned to the right, the rest of the tail moves to attach to the new position of the end of that segment. Each turn, the next segment down the line will also turn 90 degrees, until all are rotated 90 degrees. Then the segment furthest up the tail rotates back to the original orientation, and the later segments likewise take turns rotating back into place.

What causes the first segment to rotate? A player can be adjacent to the tail segment and use the turn to poke it.

At the poke site, the segment will turn 90 degrees away from the player.

In this way, each turn the tail will get closer and closer to the opponent, potentially blocking movement depending on how far up the tail it was poked.

A poke at the far end of the tail will result in only one segment rotating 90 degrees for one turn, but a poke at the treasure end will have the entire tail curling, making it almost impossible to avoid.

And when the tail hits a player, I want it to cause problems. It will knock over the player for a turn and smack the treasure back to the pile. The player can use the next turn to get back up.

Right away, I can see an issue with the interaction with the tail. What happens when a player gets knocked over near the poked segment? The tail will extend through the same square for multiple turns, so getting up the next turn means standing on the tail. How does that work? I suppose I didn’t specify that the players can’t walk through spaces that the tail segments are on, but now I need a way for the player to get up ON a tail segment? Something needs to change here.

Also, since it takes multiple turns for the dragon tail to whip around, it can effectively trap one player for a very long time. Getting trapped is potentially devastating.

So now I have more questions: can you poke a tail segment when the tail is in the process of whipping, or can you only poke a tail at rest? Can a player carrying treasure poke a tail?

Let’s assume one can poke a tail while holding treasure and if the tail is already whipping. Here, the player that was trapped can poke an earlier segment and cause the tail to come dangerously close to the opponent.

And now the revenge! The treasure is returned as the original player is knocked over by the tail.

With this interaction, I worry that it will be impossible to collect treasure as each player tries to poke the tail in turn and cause problems for each other. Even when progress is made, it can be taken away too easily.

I think that the movement and treasure-collecting parts are workable, but the tail interaction is in need of some help.

If both players ignored the tail and simply collected the treasure, there would be no challenge. Whoever went first would be guaranteed to win.

I have a tendency to try to make games that don’t have any random elements in them, but then it is very hard to make something that cannot be easily solved.

I imagine that there should be a way to avoid getting hit by the tail. If you are carrying treasure, you can drop it, and the treasure acts as an obstacle that the tail can wrap around. Maybe. I’ll keep that thought for later.

Perhaps this game needs the tail to move on its own? Rolling a die can indicate if the tail should move, which part should move, and in which direction. Maybe the tail should be only six segments long to match the six sides of a die.

Maybe I should explore the idea of the tail being a pain to navigate around. Instead of having it rotate segments each turn, it could stay in place until the next time the die roll changes it.

After both players have made a move, the die is rolled to indicate which tail segment will be rotated next. Roll the die again to determine which direction it should rotate. Rolling a 3 or less should rotate it clockwise, and 4 or more should rotate it counter-clockwise.

Hmm, the tail shouldn’t kink, since a later tail segment is supposed to attach to the end of the first, and a kink means that the segments are on top of each other. But maybe I’ll let it happen and see how it plays out. Perhaps the tail will curl around itself at times?

If a segment rotates, do the later segments rotate with it, or do they stay in their orientation and merely attach at the new end? I think the latter ends up being easier to manage.

Well, this tail really did curl in on itself. Will it constantly get that way? I need to playtest some more to know, but at least on the next die roll I see that it successfully uncurled a little.

The next die roll after that even did what I hoped it would do: cause the tail to block access to the treasure.

Even though the players have been able to move through unscathed so far this play session, I think I can see the tail movement has added a sense of fear to the game. What if it swings out and hits me? What if I can’t get to the treasure I was aiming for and now have to go around the tail, losing precious time? Oh, phew! I have some relief that the tail curled in on itself, although I’d rather it smack the other player.

OK, so kinks in the tail aren’t a terrible problem. What I also like is that a single rotation near the beginning of the tail can cause it to swing drastically. The only real issue I’ve seen is that I have hard time telling which segment is which when it starts kinking. Maybe labeling them with numbers would make it easier?

Hmm, am I no longer thinking of Structure and jumping ahead to Formal Details?

Formal Details

After playtesting with someone else, I found that the kinks in the tail manifest as a confusing mess that make it hard to understand what is happening. Rather than seeing it as something that can potentially swing out at any moment and so can be anticipated, the entire concept is chunked as a random event that will be dealt with if anything happens, but otherwise can be ignored. I’m not happy with how unimportant this aspect seems to a player’s turn.

I numbered the tail segments to make it easier to understand which was which, but I also found that the tail segments were hard to align, partly because the wooden pieces I was using didn’t fit nicely on the grid. So I made them fit.

I spread out the tail segment so that each segment straddled four different grid squares. Not only does this help make it easier to move the segments around when one of them rotates, but it also clarifies where a segment is. Before this change, some segments seemed to be in one space, but when rotated, they bumped up against other segments and seemed to be in a completely different space or to cross two spaces. It was difficult to tell if a player had been hit by the tail or if the player could poke the tail.

I tried testing the poking mechanic. What if you can poke at the end of your movement, but you can’t poke if you are carrying treasure? Well, during one session, one player got hit twice and was trapped while carrying treasure and was forced to wait until the tail moved, which might not happen for many turns. Frustrating, but not fun.

Also, can you poke when getting up after being knocked down? I decided that when you are knocked down, you are pushed to the nearest free space of your choice. After that, however, your opponent might be running off with treasure, and if all you can do is get up on your turn, it feels quite futile.

In light of both of these situations I decided that poking at the end of any turn was valid. If you get knocked down, on your next turn you can poke the tail to try to hit your opponent to prevent him or her from getting too far ahead. I think it will help with the balance. Only playtesting will tell, of course.

Refinement

This step can last many iterations, and I am going to run out of time before I can consider this game done enough. It is here that any features and rules that aren’t core to the game can be experimented with to see if it creates a compelling experience.

What follows are some of the concerns I identified.

How big should the play area be? I had graph paper and tried to center the grid of 3×3 squares, but what if the paper was smaller or bigger, and in any one dimension to boot? If it is too small, the tail will impact the play area a lot more, but if it is too big, then players can choose to hug the walls at the expense of using up more moves and taking longer to avoid the tail.

I noticed that whenever the sixth segment needs to rotate that it is inconsequential. Is this situation similar to the dragon tail losing a turn, so to speak, or should there be a seventh piece? Which is better for the enjoyment of the game, added risk or the equivalent of Monopoly’s Free Parking?

The interaction with the tail also feels like it isn’t as finished as it could be. Instead of being a significant piece of the game, at times it feels like it is nothing more than a completely random event. That is, players are running after treasure and usually can forget that there is a tail in the game at all, and suddenly a tail hits one.

And when one does get knocked down, where does he or she get moved? Letting the player choose the nearest open space is ok, but if it was a video game, I feel like it should be deterministic and handled automatically by the game. So, what’s the simple and easy rule for displacement by the tail?

I learned during playtesting that the game is slow. Well, how do I solve this issue? It takes 16 moves to get to the treasure, pick it up, and bring it back to the barrel. Moving three spaces at a time might be fine, although now that the tail segments take up a 2×2 area it could be tweaked. Perhaps moving two spaces at a time instead of only one when carrying treasure might help? Then it would only take about 10 moves, especially if I allow the player to pick up the treasure at the end of a turn instead of making it a separate turn on its own.

Instead of bringing the treasure back to the barrel, just bring it back to the other end of the play area. So whenever treasure crosses the last set of squares it’s considered collected by that player. In this way, there isn’t a faster treasure to collect, and so if you find yourself on the other side of the dragon tail due to necessity, it won’t slow you down as much. You just have to move back to the left, not left and down to a specific spot.

There could also be less treasure. I placed 16 pieces because they fit, but having less can improve the time to play the game. Also, an uneven number guarantees that there will be a contention. One player will get to the last piece first, and so the other player then wants to manipulate the tail in order to try to prevent the first player from winning. But how many pieces of treasure should there be in the game? I can do some playthroughs and time it, or see how long it takes for a single treasure to be collected and multiply it by how long I want the game to take.

Hmm, the ending is quite unsatisfying. The player without the last treasure piece can’t do much to interfere with the other player other than poke the dragon tail, which might be far enough away that by the time he or she gets close enough to do so, the player with the treasure is too far out of reach.

That sense of despair is a symptom of the lack of meaningful player interaction, which I think is a big concern. How much of a change do I need to make to address it?

An example of a minor change is changing the effect of poking the tail. What if it doesn’t just turn the segment 90 degrees but allows the player to choose the new orientation? Would doing so make it a lot easier to have an impact on the game?

A bigger but related change might be if poking the tail allows the player to move the tail segment one space adjacent. Of course, if segment is moved, it has to be a valid connection to the parent tail segment, so how will it be resolved without being too complicated for the player to figure out?

A major change would be the introduction of obstacles. What if you could push boulders around, which not only act as obstacles for the players but also for the tail, which can wrap around them? Sounds good, but now there are number of questions to answer. How do boulders get added to the play area? When are they added? Can they be destroyed? Are they permanent obstacles, or can a player move one? If so, how far? Can multiple boulders in a row be pushed at once, or do they prevent the player from pushing them in that case? If the latter, is it possible to get stuck permanently between multiple boulders? What happens when you push the boulders in front of the treasure and block access to it? What happens if you push the boulders across the starting area?

Maybe treasure isn’t carried but is pushed and acts the same as the boulders described above?

Can there be fool’s gold? That is, sometimes you collect treasure only to find that it doesn’t count towards your score. Maybe it’s a random chance, such as rolling a die for each treasure you captured and trying not to roll a 1.

Or each treasure you collect has you draw a card from a deck. At the end of the game, even though you collected more treasure, there’s a chance your opponent might win because you discover your treasure is fool’s gold when everyone is asked to reveal their treasure cards. It might make it a way for people to catch up at the end. So, how many cards are there? How many fool’s gold cards are in the full treasure card deck? Is it constant between games, or is it like Saboteur in which the number of potential saboteurs is different from one session to the next?

As you can imagine, exploring the playspace here is a very big job. Testing a single rule change at a time can get tedious, but how else will you know what works? I’m reminded of the development of Steambirds: Survival, which Daniel Cook described as finding the Goldilocks Zone of games, the playspace in which the game is enjoyable.

Many attempted ideas will fail, but if you explore enough variations, you can find what works much more quickly.

Exercise Complete

This post is about 4,000 words long, and I tried to capture how the process went. And of course, I still have a lot of work to do.

I didn’t do a very good job of working on this prototype in these four separate stages. I sometimes found myself thinking about details when I was supposed to be working on fundamentals, or refining some structure instead of refining the details.

So while the above might show a somewhat organized thought process, the reality of it was that there was a bit of messiness to it. That said, the four steps did help me think about the nature of the change I was making at any given point, which helped me restrain from thinking about features when I should be focusing on rules. I think the attempt at following these steps helped me create this game much more rapidly than I might have otherwise.

If you participated in this exercise on your own, please comment below to let me know, and if you wrote your own blog post or discuss it online, make sure to use the hashtag #GDWW.

This post concludes my GDWW exercise posts. I’ll be publishing a book review next week. Thank you for following along, and I look forward to seeing your prototypes!