Game Design Workshop Wednesday Exercise 7.9: Creating a Prototype #GDWW

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 game design


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.


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.

Dragon Tail prototype

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.

Dragon Tail prototype

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.

Dragon Tail prototype

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.


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.

Dragon Tail prototype

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.

Dragon Tail prototype

Dragon Tail prototype

Dragon Tail prototype

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.

Dragon Tail prototype

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?

Dragon Tail prototype

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.

Dragon Tail prototype

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.

Dragon Tail prototype

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.

Dragon Tail prototype

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.

Dragon Tail prototype

Dragon Tail prototype

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.

Dragon Tail prototype

Dragon Tail prototype

Dragon Tail prototype

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.


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!

Game Design Workshop Wednesday Exercise 2.9: Applying the Lessons #GDWW

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.

This week, I’ll be applying what we’ve learned so far by playing a simple game and then identifying the major elements of it.


The exercise first asks us to play a game of 3-dot Sprouts.

I’ve never played it, but it reminded me of a game I used to play in school, which was apparently called Dots and Boxes. It felt like a more challenging Tic-Tac-Toe in that there was always an expectation that I could figure out the trick to winning consistently.

In Sprouts, you connect dots with lines, taking care that no dot has more than three connections coming out of it and that no lines cross each other.

So, my first attempt at playing the game was a failure because I didn’t realize I had four lines connecting to a dot. Whoops.

My second time, I created a loop, connecting dots with a line that circled another dot. I found that even though I had a dot with only one connection outside of that circle, I couldn’t connect it to any other dots due to the limitation on connections and the inability to create crossing lines.

My third session, I started with a triangle, and then I started bisecting the triangle. Eventually, I found I had one point within the triangle that couldn’t connect to any other points, and one point outside of the triangle in a network of arcs I had to create to try to match up free points.


Applying the Lessons Learned

Ok, so I’ve played Sprouts, a game created by John Conway of Game of Life fame and Mike Paterson, one of the people who recognized computer science as a science. The exercise now asks me to identify the formal elements and the dramatic elements of the game.

First, let’s look at the formal elements.

  • Players: There are two players. Each needs access to a pen or pencil and the ability to count.
  • Objective: To be the last player to make a valid move.
  • Procedures: One player needs to be designated as first, and three initial dots need to be drawn on the paper. After that, each player takes turns drawing a line and then putting a new dot in the middle of that line.
  • Rules: The actual rules are described as part of the game. Players cannot connect lines involving a dot that has three existing connections, which limits the potential lines that can be drawn. A new dot can only be placed on a newly drawn line. A player can only take his or her turn when the previous player has finished a turn. The rules must be followed; otherwise, the players aren’t playing the game anymore. Similarly, if players drew their lines and dots whenever they felt like it, or added more than one dot on a line, it would be a different game.
  • Conflict: The act of drawing the lines between dots reduces the number of potential lines that can be drawn. Any new dots drawn already have two connections, which means they only allow one more connection.
  • Boundaries: While the exercise mentions a piece of paper, the play area is fairly abstract in that it consists of wherever the dots and lines are. The assumption is that the dots and lines are on a single plane. That is, if the game was three dimensional, it would be trivial to draw arcs from one dot to another without crossing previous lines.
  • Outcome: Either the first player or the second player will win. There can be no draw.

Now, let’s look at the dramatic elements.

  • Challenge: Sprouts is a solved game. That is, it is possible to play a perfect game, resulting in a win for the first player or for the second player depending on the number of initial dots. With three dots, the first player can always win. There is no challenge once you know how to solve it, similar to Tic-Tac-Toe. In that absence of such knowledge and pattern recognition, the challenge could come from the limiting of choices as turns are taken.
  • Play: As turns are taken and dots are eliminated from consideration, it can get quite limiting. There might be some choice at the beginning, but a given turn will eventually eliminate two dots at once while adding only one back, and so eventually there is only one choice to make. There isn’t much room for play.
  • Premise/Character/Story: There isn’t anything inherent in the rules that provide a story. It’s a fairly abstract game. The name itself might imply something that is up to interpretation by the players.

Now the exercise asks me to identify types of dramatic elements that might add to the experience.

I’ll take them in turn.

  • Premise: instead of connecting dots with lines, you could be engineers tasked with building roads between settlements, or you are plumbers laying pipes between houses, or miners digging tunnels between veins of gold. Maybe you’re digging trenches to try to capture the opposing mole in a garden. I’m sure ideas can be spitballed indefinitely here.
  • Character: Each of the premises had some characters associated with them, but what if we started with the players as dinosaurs? They could be competing for scarce food resources. Thieves? You can only rob a bank so many times before it becomes too risky. As above, more ideas can always be generated here. Names and biographies could be created for characters, and even though there are only two players, perhaps giving the players a choice of more than two characters to play might provide some flavor, even if the choice doesn’t impact the game in any more meaningful way. For instance, one of my nieces likes the color pink, and I’m sure she would be very happy to play this game as a character who dresses in pink who has the same name as a favorite cartoon character. Each character might have a uniquely colored pen, allowing each turn to alternate colors. Princess Fiona provides a pink pen, Prince Bob gets a green pen, and Sir Erdrick gets a purple pen.
  • Story: I can see coming up with a traditional story involving the characters above, but what if each turn required the player to give a line of dialogue explaining the turn? Suddenly it can be a party game, in which wackier explanations are better. “I drove this herd of meerkats to the Statue of Liberty, avoiding the Pit of Despair on the way.” “Well, I drove a meerkat from the Statue of Liberty to Chicago in a taxi, dropping off a hitchhiker at the Outhouse of Tomorrow.” “And now I shut down the Statue of Liberty and forced everyone to go to Florida, and I launched a space station.”


Wow, this story-based one gets ridiculous pretty quickly.

Exercise Complete

I learned quite a bit about Sprouts, and I had some fun with thinking about the dramatic elements that could be applied to what is otherwise an abstract math game. It makes me wonder how much I underappreciate a good theme and story in games.

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.

Next week, I’ll skip ahead to Chapter 7 and work on a prototype.

GOG Galaxy: The DRM-Free Online Gaming Platform

I haven’t been following much of the news, but apparently GOG has an optional client to use that will automatically update your games and allow you to play online with friends.

They call it GOG Galaxy:

I found out about it because I just got an email offering me a free copy of Alien vs Predator Classic in exchange for joining their beta-test program. Oddly, for such a huge service, I am surprised I only just learned about it from them.

I’ve been a big fan of GOG’s DRM-free approach. I know Steam is now available for GNU/Linux, but I haven’t found myself too compelled to run it regularly. Most of the games I have purchased online came from the Humble Bundle or GOG, partly because they are DRM-free offerings I can play on my preferred system.

I know people like the convenience of Steam, but the concept of DRM, the idea that what I can do with the games I purchased is restricted in arbitrary ways, still bothers me. Single player games which require you to be online to play, or games that complain that I’ve installed them one too many times or on too many of my own systems? No thanks.

I’m interested in what GOG is offering, if only because it is optional and still allows me to play my games no matter what. I just wish that Alien vs Predator was available for GNU/Linux. As it is, I apparently signed up for the beta-test of the Windows version.

Game Design Workshop Wednesday Exercise 2.8: Gripping Stories #GDWW

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.

This week’s exercise asks me to explain why any specific games might have moved me emotionally.


I’ve written about the importance of stories years ago, arguing that games don’t need to dictate the story the way a book or a movie would. Games are interactive and allow for a variety of responses and developments, so I’m sometimes disappointed by games that can be reduced down to “Press the button to advance to the next page” because they don’t live up to the potential of the medium.

That said, story can be quite engaging. Like premise, it can give you context for what you do in a game, and discovering what happens next can be a motivating factor. I want to know how the Prince of Persia managed to stop the Sands of Time from spreading everywhere and consuming everything. I want to know if the Terran or the Protoss dominate. I want to know if this is finally the castle that Bowser has locked away the princess of the Mushroom Kingdom.

The exercise this week asks me if any stories within a game ever gripped me, moved me emotionally, or sparked my imagination.

In the past, I’ve written about great gaming moments, such as the Illusion of Gaia raft scene and the time I sent 30 pilots to their horrific deaths in Homeworld: Cataclysm. The second one is one of my favorite stories, which is a mixture of the story the game was telling and the story I created by playing it.

Throughout the war with The Beast, I never forgot those 30 ships. Technically, they weren’t more than digital bits running through memory on my computer, but the screams were terrible. The drama was real. The details of the names or types of ships involved in the above story might be remembered incorrectly, but the feeling of dread when I realized that I had just caused the deaths of 30 good people will stay with me. It wasn’t a cut-scene or a FMV movie to watch passively. I participated in it. Logically, it wasn’t my fault. I couldn’t have known what was going to happen without cheating. Technically I could have restarted the mission and tried again. I normally prefer the challenge in similar situations, but the reason for not restarting this time was different. I didn’t want to dishonor the memory of the loss. Oddly, those 30 fighters were identical clones of each other. It wasn’t like you normally would have a tie to any one of them.

Still, I had made a bad decision, and the consequences were very real to me. My fight wasn’t just to play a game anymore. It was for honor. It was for redemption. Neither of these ideals were communicated directly by the game. There was no “Honor Meter”, for instance. I simply had a strong desire to make things right again.

Ok, Past Self, you’re a little dramatic, but the point remains that the story in the game was a very engaging aspect of it. I internalized the story so that it was my own, and playing the game had new meaning for me.

Exercise Complete

Now I want to go back and play through all of the Homeworld games. I never did finish them. How does the fight with the Beast end in Cataclysm? And how do the original game and the sequel work out?

And how did I just find out that Gearbox Software has had the rights to the franchise and is working on Homeworld Remastered? I hope it is ported to Linux-based systems.

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.

Next week, I’ll wrap up chapter 2 by playing a simple game, then analyzing its formal and dramatic elements.

Game Design Workshop Wednesday Exercise 2.7: Premise #GDWW

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.

This week, I’ll be identifying the premise of a handful of games.


This section of the book continues identifying ways to engage the player. Premise provides the context for the other elements in the game.

You can touch or avoid arbitrary positions in an area, or you can eat all the pellets while chasing or evading ghosts in a maze.

No one says, “I almost fulfilled the victory condition before I triggered the loss condition.” They say, “I almost ate all of the dots, but then the ghosts killed me.”

As games involve submitting yourself to constraints and trying to achieve some goal, the premise gives you the reason why.

This week’s exercise tasks us with identifying the premise of a few popular games.

  • Risk: each player is in charge of an army and fighting for world conquest.
  • Clue: each player is suspected of a murder and trying to identify who really did it.
  • Pit: it’s all about cornering the market in commodities
  • Guitar Hero: you’re struggling to become the next big rock star

Exercise Complete

You can see how a premise could make for a good starting point when trying to create a game, as it gives you a focus in terms of the player experience. The premise also lets your players know what to expect.

If you’re making a golf simulation, you want to mimic it as best as you can with wind speed and silence, but if you want to make a strange fighting golf game, you might have zany music and fast-paced action, with golf carts used as a means to quickly close in on opponents to strike them with your unrealistic and mechanized clubs in order to get the ball in the hole first. A fan of the first could be disappointed with the second.

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.

Next week, I’ll talk about games with gripping stories.

Follow GBGames on Google Plus and Facebook!

Association of Software Professionals

Twitter: GBGames