Archive for category Game Design

Choosing a Tag Line

On the eve of my Kickstarter for Supertall (live now), I’ve been sitting here working with Buttonshy trying to find the perfect tagline for the campaign. It was very similar to some of the work I had been doing making game summary sheets (i.e. sell sheets) in the last few weeks. The goal of a tag line is to give you a quick impression of the game. People will decide to investigate further based purely on that 10 second reading, so it’s important to make a good impression. With a summary sheet, you have a little more room, because the person is already looking over the whole sheet. But you really want to keep words to a minimum and show the game rather than spend a paragraph explaining it. I thought it might be interesting and helpful to talk briefly about the process we went through in developing that tag line and how it relates to getting the most out of every word.

You might start with something like “Supertall is a 2-3 player game where you use different types of plans to building skyscrapers”. Simply saying a player count and some mechanics is a good start, but doesn’t do much to relate the experience of playing. Plus in this case, the price point ($10) is a big selling point. Lets try again. “Supertall is a 2-3 player game about building skyscrapers from a mix of plans. Only $10 for a fast and highly interactive tower building game.”

We’re headed in the right direction. First, we simplified language, instead of saying “where you use”, we made the information about plans a clause on building skyscrapers. We added the price and description “fast and highly interactive” and call it a tower building game. The second sentence is sort of awkward and we’d rather leave the reader with $10 as a point of interest. We’re also still wasting words at the beginning, by saying “Supertall is a game where…” We don’t need to clarify that we’re talking about Supertall.

In its place, we want a word that will excite players right off the bat. Tell players what they are doing in the game. “Build skyscrapers” is Ok, but build is a little boring. “Plan skyscrapers” is even worse. But “Design” is a more interesting behavior, because it’s active instead of passive, and suggests a level of skill is involved. Also, we aren’t just building skyscrapers, lets add some wording to show that these are special. “Design the next world-class skyscraper. A fast and highly interactive tower building game for 2-3 players. Only $10!”

OK, now we’re getting closer. The first part is active and interesting. The second part is descriptive, but is still a bit clunky. And rather than say that it’s fast and interactive, lets tell players why. Plus we’re just calling players “players”. So that gets us to the final iteration.   “Design world-class skyscrapers. 2-3 architects compete and collaborate in this fast and highly interactive game for only $10.”   Most of the words are now descriptive of the theme and player actions. “design” “world-class” “architects”. “Compete and collaborate” tells you it’s competitive but still strategic. The whole thing flows much better.

When you describe your game, value the reader’s time. Make the most out of your space. Get rid of all the extra connector words and be as direct as possible whether you’re describing the mechanics, theme, or experience. Don’t just say “this is what happens”. Take all the potential in the game and make it kinetic. Describe what is happening, as if players are active right now. Because you’re not just trying to get players interested to hear about the game, you’re trying to get the players interested in playing the game.

As usual, there’s not a road map, but this hopefully gives you some strategies to apply when you’re working on writing your game up, whether it’s for marketing, making a sell sheet, planning your pitch, or even explaining the rules. Try to get to the experience as quickly as possible.

Advertisements

Leave a comment

Breaking the Wallet Game Code, Part 2

Last time, in Part 1, I looked at some of the lessons I learned from a pile of failures, and how my upcoming games Garnet, MT and Supertall avoid the same problems.

I’ve also found common ground in a number of Buttonshy’s most successful games that I think really embodies what makes Buttonshy Wallet games feel like bigger games. I wasn’t really able to put this into words until after developing most of Garnet and Supertall, but it’s something I’m now starting to look for to make sure my games have, too. Read the rest of this entry »

2 Comments

Breaking the Wallet Game Code, Part 1

I’ve been trying to make a wallet game for Buttonshy for about 3 years, and I’m finally about to have my first one. I’d like to say it was an academic effort to understand what makes a good wallet game and using that information to carefully design one. But I must admit that it was mostly accomplished through brute force, and a lot of failures.

Wallet games are difficult to design. The entire game must fit on 18 cards and a plastic wallet with (until recently) no tokens, which is hard enough. But wallet games should also feel like much bigger games than those 18 cards, which adds another level of challenge to the design process. On my journey to meet that challenge, I’ve definitely learned some things that are necessary, some things that help, and some things that don’t, and I’m going to share that journey and the secrets I’ve uncovered.

I’ve discussed part of this journey before, in Learning New Ways to Fail. The very first game I tried to design as a wallet was Shapeshift, a game about monsters. That gradually morphed into Iceburgh, and has since outgrown the wallet. And that was the first game I felt really could succeed as a wallet game. But then came a string of failures.

  1. Space Race 1969: my 2016 Wallet Game contest entry.
    • 2 players simultaneously play two cards to choose actions, trying to perform 3 successful rocket launches
    • Theme was a muddled combination of cold war sabotage and space race inspiration that felt detached from the mechanics
    • This might be salvageable.
  2. Dossier: the second version of Space Race
    • Draft then play your spies to hand off documents, get the right documents in your dossier.
    • Thematically way better, with more variety, but mechanically not tight enough. Space Race had a clear mental game that this version was missing.
  3. Mills of Jajce: Based around a town full of tiny water mills in Bosnia and Herzegovina
    • Grinding grain in tiny mills by rotating cards.
    • This was a bare mechanic, functional with no interesting gameplay. The game lacked any real arc.
  4. Brandywine: Inspired by Carcassonne’s River expansion
    • Place a card down to form the Brandywine river and to put your mills near the appropriate resources.
    • A waste of a much more thematically rich idea.
    • I overbalanced it worrying about the 4 player game. And once you put a card down, you basically forgot about it until scoring.
  5. Fairgrounds: Build carnival attractions
    • Build a small tableau that also makes resources for your neighbors to build.
    • I couldn’t find the right balance point, so players rarely had decisions about what to play or build.
    • And it took too many cards just to make the base mechanic work. This was probably just too big to work in 18 cards.
  6. Thousand Year Rose: Growing a rose bush for 1000 years.
    • Played sort of like Kodama, growing the rose, but with events that made parts of it die
    • This game was literally unendable. If your game is about something that grows over time, make it harder to destroy than to create.
    • Probably wanted to be a cooperative game instead of competitive.
  7. Twining Vines: Winemaking game
    • Run a vineyard, plant and age vines, sell the grapes or turn them into wine.
    • This one nearly worked, but money both felt tacked on and was a component hog.
    • It could probably work as a slightly larger game.
  8. Boundary Issues: Shift the national border between US and Canada.
    • Shift the boarder back and forth to get points for what’s on your side at the end, while granting abilities to your opponent.
    • Neat mechanic, but I had no idea what to do about the end/win condition.
    • This one might also be fixable if I can give an arc to it
  9. Surviving Everest: Climb Mountains in the 1950s.
    • Solo/Co-op with elements of memory, push your luck, and deck manipulation. Sounds great on paper
    • Successful as an artistic representation of the mental challenges of high altitude climbing.
    • But nobody liked it because the first round had no guidance.
    • Still potentially salvageable.

There are a lot of trends to pick up from here.

First, I kept bumping into the size limit. It’s really difficult to make something that needs 12 of the cards on the table at all times. Fairgrounds, Twining Vines, Space Race and Dossier needed a lot of cards in play at one time, which doesn’t leave you much room to actually play with. And putting enough variety within the game and between games is a challenge for every one of these.

Along with the size concern, don’t worry too much about making it a 4-player game. That often requires a lot more cards to work. Accommodating 4 players is almost standard for larger games, but 2 and 3 player games do well for Buttonshy. And there is always the option of adding a 4th player later through a 6-card expansion. Get the core design down first, then worry about adding players.

Next, a lot of these games were missing a clear goal. Figure out what makes the game have a beginning, middle, and end, and how they differ. Again, variety within the game is a challenge. Jajce Mills, Thousand Year Rose, Fairgrounds, Twining Vines, Boundary Issues, and to a lesser extent Brandywine, all had good mechanisms with no real long term gameplay. Just repeat until some arbitrary end.

And may of these games failed to give players choices for a substantial portion. Brandywine was often an obvious choice, Surviving Everest didn’t give the player enough information early on (although that is totally thematic), and Fairgrounds often left the player able to perform no actions. Decisions are the lifeblood of an engaging game, so it’s not enough to rely on end scoring, or theme, or clever distribution to make them occur.

After all of these failures, I finally made a game that I was happy with. I had worked on the idea in my head for quite a while before getting on the table, but it needed tokens to work for tracking resources. So when the Wallet+ option was announced, I was ready. Garnet, MT is right out of my standard playbook. Develop a 1900’s Mining town before it burns down. Historical setting, action drafting, resource management, tableau building with permanent effects. It’s totally my type of game as a designer and a player. The main concept worked, and I’ve been working on improving the balance, making the decisions more challenging, and bringing in more strategic elements, and it is scheduled to appear later this year. So that’s 1 in 10 attempts.

But wait! Next month, Buttonshy will be Kickstarting my game Supertall, about planning skyscrapers. But instead of 2 years of development Supertall took shape over a few months. It started as a nanogame inspired by Buttonshy’s Sprawlopolis. But when playtesters said “this would work a lot better if it was on cards”, I expanded the game from 1 card and 15 tokens into 18 cards.

Both of these games avoid the problems I addressed above. Garnet was designed so the 15 cards represent the 15 years the town was in its prime and contain the 13 saloons and 13 basic buildings that are central to the history. Supertall started with a limit of 15 tokens, so easily fit in the 18 card limit. I actually had more trouble figuring out which 3 cards to add. Garnet was designed as a 2 to 3 player game from the outset. Supertall was likewise designed for 2 to 3, and the first 6 card expansion will accommodate a 4th player.

Garnet also had the hard time limit from the start, and as a tableau building game, naturally has a progression. Plus there’s a great end-game twist I’m really proud of. Supertall has a natural direction as you build taller and taller. The end was a little challenging, because you can return cards to a draw pile, but I included a simple rule that cleans up the ending. Finally, Garnet loads all of the available actions onto each card, so there are always options for everyone. And Supertall gives 3 ways to use each card, plus makes any player’s skyscraper a possible placement option, so there are choices on every turn.

So after all those failures, does that mean I have finally revealed the secret for making a wallet game?

Nope.

I’ve been working with Buttonshy for over 2 years, so I had a good idea of what they look for in a game, and I knew that Garnet and Supertall would definitely fit in their lineup, but that only helps for the pitch, and doesn’t mean you’ll have a good game. The lessons from above are all absolutely necessary if you’re interested in designing a wallet game [or really any game] worth making. But these just make your game playable. Buttonshy wallet games always feel like bigger games, and I think I’ve finally figured out the element that makes the difference.

Which I will look at in part 2.

2 Comments

Which one was it? Identify Your Game

In college, I entered an essay contest trying to win some scholarship money. But by coincidence, I happened to know one of the judges, who was a professor at my school. I remember having a conversation with her, after the judging but before the announcement. Knowing that the judging was anonymous, I made a passing joke, “Oh, did you read my essay?” Without missing a beat she responded seriously, “Oh, which one was it?”

I replied “oh, it was the good one” to a still stony demeanor. It would be easy to misinterpret this this as a failed joke and let it go, but I continued that I had written it months before and didn’t remember the details, which was true. But this speaks to a larger point. If I can’t remember my own essay, and I can’t give a description of it that would make it easily identifiable, how is it ever going to stand out to a judge? Those words, “which one was it?” have really stuck with me.

Of course this is directly applicable to submitting games to design awards and competitions. But it applies to any kind of submission to a publisher and, by extension, to creating a game that will be successful and popular when it reaches the market. The things that help it stand out to a potential publisher are the same things that publisher will rely on when marketing the game. With thousands of games released a year, and an even larger number competing for limited publishing slots, you need to be able to point to something in the game that makes it memorable and unique.

This is probably considered conventional wisdom among game designers. But it’s far from automatic, and it takes a lot of effort to see your game with outside eyes. A great way to get around this is to think about how you’d identify your game without a title or art. Commonly used categories, themes, and mechanics are a great way of putting someone in the right reference frame. But these things can’t–by definition–uniquely identify your game. I recently set aside a pirate game with simultaneous card play, where you’re trying to take gold from ships and hire better crew. The mechanics weren’t working as well as I wanted, but that’s something that I could continue to fix. The larger problem is that it just wasn’t doing anything to have an identity. That description could fit a number of different games.

So this is something I am still working on with my designs, especially when I have so many designs in progress at once. I’m trying to filter out the games that don’t have an identifying feature, and focus on the designs that do. And it’s slowly making me a better designer because I’m starting to consider that aspect throughout the design stage. It also makes me a happier designer because the same factors that make a game stand out make a game fun to work on. There’s some new problem, some new topic to cover, some new way of doing things that is enjoyable to figure out.

It’s not easy to get someone to remember your game. With so many games coming out, just being “the good one” or “the fun one” doesn’t tell you anything about what game it was 2 days later, let alone weeks or months. And it’s not something you can rely on adding at a later stage. Titles and box art are also easy to forget when so many games look and sound the same. Step back and think about what made the last game you played memorable.Then picture yourself talking to a judge from a contest, or following up with a publisher after a month, or even in a game store trying to tell someone about your new game. If you can’t identify your game from the 30 second interaction, it’s probably not ready. Having a unique identity is what will keep it in players minds, the next time they ask “Do you remember that fun game we played?” the answer is yours.

 

Leave a comment

The Value of a Bad Playtest

I recently attended all 3 days of the inaugural PAX Unplugged in my home town of Philadelphia. It was great showing off my home city to people (especially Reading Terminal Market). It was also way bigger than I expected, and there were people I never even ran into all weekend. Possibly because I spent a lot of my time Friday and Saturday in the Unpub/Alpha Build room, working on prototypes. It was a good weekend for prototypes, if not for the players. Read the rest of this entry »

1 Comment

Questions to Ask Before Making a Game

Deus Ex is right at the top of my greatest games of all time list. It’s a crowning achievement in game design that I still use as s point of reference for other games. A recent article on Gamasutra covers some remarks that the designer of Deus Ex, Warren Spector gave at GDC earlier this year, looking back at Deus Ex after 17 years.

The article includes a list of questions that he always asks before making a game. It really leapt out at me because I’ve been struggling to figure out what games I want to make recently, and these were some of the same questions I was asking myself about my games. So I wanted to look at the list of questions in detail to figure out whether I was making the games I really wanted to make.

First, there are 6 questions about the game you’re making.

  • What’s the core idea? Can you describe the core of the game in 2-3 sentences?

A straightforward, but deceptively difficult question to answer, because you need to narrow your focus to give the game shape. You can fill in details as you go, but it’s really important to have that structure to build the entire game around.

  • Why do this game?

“Because I can make it” isn’t good enough. I’ve made plenty of games because I was capable of it. Every single one was bad. “Because I can get it published” is almost the same thing, but even worse because it’s usually wrong, too. Find the reasons you’re excited to make the game, in order to be motivated to make it great. As a bonus, those will usually translate directly to the reasons someone is excited to play the game.

  • What are the development challenges?

This is probably less of an issue because boardgame design is so rarely held to a release schedule or budget, but it is still an important part of the development process. From the very start, you should figure out what is going to be hard. It could be on the design side, such as scaling, balance, or manufacturing, or it could be on the play side, such as down time, or ease of learning. Know these things early and you can design around them without getting stuck.

  • How well-suited to games is the idea?

This looks liks a sort of pointless question, because your idea for a game is sort of by definition suited to games. But the subtle issue it raises is whether it is something that ought to be represented in the form of a game. Boardgames, even more than video games, still carry the connotation of being an object of “play”, and not every subject matter can be carried as well. Some ideas would also benefit from elements that are infeasible in cardboard, leaving you stuck with a hobbled implementation or an overcomplex mess.

  • What’s the player fantasy? (If the fantasy and goals aren’t there, it’s probably a bad idea)

This is something I’m trying to consider more often, because it a applies at two different levels. On the first level, it asks about the role the player takes on internal to the game. That tells you something about what players will want to accomplish in the game. And on the second level, it asks about player goals. What do players want to get out of the experience of play? Spending half an hour chatting and laughing with friends can be that “fantasy” the player wants just as much as leading a civilization through history, running a 17th century farm, or defeating an army of monsters to claim some loot.

  • What does the player do? (What are the “verbs” of the game?)

I have always loved the idea of games as a collection of verbs. It can be very challenging to translate a lot of ideas about a player’s experience in the game to paper. But the verbs you choose give you a more direct route for defining that experience. They act as building blocks that give you a framework for how players interact with the game.

Then there are two more questions about the game as a product.

  • Has anyone done this before?

This requires both honesty and research. You can’t know about every single game ever created, but there are resources, especially BoardGameGeek, that make this easier. And it’s just generally a good idea to go out and play a variety of games that might do similar things, to learn about how they work and make your game better.  It’s tempting to think that your idea is original and to lie to yourself to preserve that feeling, especially if you’ve already put in a lot of work. But to do so is to waste time that you could be using to do something new.

  • What’s the one new thing? (“You can always find one thing that hasn’t been done before [in games], even if you’re making a My Little Pony game.”)

And it’s not enough to just not be duplicating something. Different is good. New is better. Seek out those new twists and original ideas that make your game stand out. Yes, it’s a marketing tool and a way to make sure it’s different, and a reason to make the game. But it’s also a part of what makes being a designer fun, creating something entirely new. It is the spark of life that keeps games moving forward.

And finally, there is an existential question.

  • Do you have something to say? (“In Deus Ex I wanted to explore all sorts of big issues,” said Spector. “And I wanted players to explore those things in ways that only games could do.”)

Of all of these questions, this is the hardest, because everything else is sort of tangled up in this one issue. At the risk of sounding cheesy, you bring a unique perspective to the world. Games are a way to share that perspective. It doesn’t always have to be some profound statement, or something you can make into a slogan. But remember that as a form of art, games inherently carry a message, so pay attention to what you want to say and what the game is actually saying. I know that my own games are better when I knowing what I want to say.

As I organize my designs, now, the answers to a lot of these questions are already part of the data I’m entering from the start. I think they really help define what you want from your design. I always want players to have meaningful choices in a game, and it’s probably no coincidence that that was one of the main goals for  Deus Ex. I played it at a very formative time in my life, and it has no doubt shaped my game design choices since then. I think it’s a real testament to Deus Ex that the design lessons remain so universally relevant.

2 Comments

Literary Game Design 2: Designing Conflict

Sometimes, you can be working on the same idea from two different angles, and it takes you a while to realize it. The previous article, Games as Stories, was one angle. I’m also starting a new game design, and was getting a bit overwhelmed with everything that I was trying to do at once. I started looking at some of the basic ways I was trying to make the game interesting. And I noticed the parallels between the classes of conflict and the ways to make decisions interesting. But I called them by slightly different names. Player versus player conflict is competition. Player versus randomness conflict is just another way of saying luck. Player versus rules sets boundaries. Internal conflict of player versus self is what I call struggle. Finally, player versus feedback is difficult to name, but I think challenge is a good term for it.

Some definitions of what makes a game focus on the idea that a game is characterized by creating artificial obstacles. These forms of conflict are the obstacles. Players get frustrated by obstacles that are too hard to pass and get annoyed by obstacles that have too little resistance. So by considering these forms of conflict individually, we can be better at deciding how to use them.
Read the rest of this entry »

Leave a comment