We turned the weakest part of Pecking Order into the best part

The Social Game is a social deduction game, so we are developing it in a highly collaborative way. I had some core ideas nailed down, but was struggling to realize those ideas in a prototype. I brought in a group of friends who are a mix of experienced designers/testers, and game fans who have zero design experience. 

Here’s how it works:

• Nearly all of the designers of Pecking Order play in every test game, so we are all effectively super-testers of the game. And we play constantly.

• The game will eventually be managed by a Bot. But until we build the bot, the game is managed by one of us. The bot is effectively a dungeon master for the game. We intentionally give the person in this role leeway to design their own challenges, make judgment calls when there’s ambiguity about rules, come up with a theme, and to run the game as they see fit (within the parameters of the rules we agreed on beforehand).

• At the end of each game, we have a comprehensive retrospective where we review how things went, what new rules we were testing, and what changes we want to make next. We invite everyone to this retro. Pretty much all design decisions are made by majority consensus, and I can say with some honesty that’s it’s been a pretty consistently ego-less, creative discussion every time.

By playing the game a lot and taking turns serving as the bot, we have learned a ton, really fast. Each bot has brought their own flavor to the game, and has introduced new ideas. This structure has also helped us to embrace the best ideas, because every single one of us has had great ideas and horrible ideas — and the merits of each idea are pretty obvious when you’re testing and reviewing as a group. Here’s a case study of how this structure very quickly turned a weak idea into a great idea.

---

The game mechanism: Pecking Order takes a week to play, and we wanted to have a daily Challenge so that players have short term daily goals and ways to get ahead outside of the big picture victory condition at the end of the week. Winning the Challenge gives you a token, which can be used to buy yourself advantages later in the game.

Version 0: At a random time of day, the bot will post some random Sudoku or Crossword puzzle, and the first player to respond with a correct answer wins a token.

• Version 0 bot observation: there is a lot of information in the game that could be used to quiz players such as, “who has the most tokens right now?” It’s much more interesting to make the challenge questions integrate with what’s going on in the game, and to reward players for paying close attention to gameplay.

Version 1: At a random time of day, the bot will post a question about the current state of the game, and the first player to respond with a correct answer wins a token.

• Version 1 player observation: there are very few tokens in the game, but tokens and advantages are the most fun part of the game. We wish there were significantly more tokens in play.

• Version 1 bot observation: A lot of players are submitting correct answers after another player already won the challenge. This creates a ton of urgency and then bad feelings for players who had the correct answer, but 2 minutes late.

Version 2: At a random time of day, the bot will post a question about the current state of the game, and all players who respond with a correct answer win a token.

• Version 2 player observation: this “at a random time of day” structure creates a ton of stress and frustration. Players with kids or demanding jobs or weird life schedules are at an automatic disadvantage on all Challenges. It would be better to leave the challenge open all day, and let players answer on their own time.

• Side note: this crucial realization led us to do an overhaul of a whole bunch of other rules to make it so that players never have the experience of urgently needing to take action at any unexpected time of day. Ironically, this improvement is a complete reversal of the original design of the daily challenges.

Version 3: At the beginning of each round, the bot will post a question about the current state of the game, and all players who respond with a correct answer any time this round win a token.

• Bot observation: asking questions about the future state of the game would be significantly more interesting than asking questions about the current state of the game. For example, a challenge might say, “who will be in first place tomorrow?” Now players are empowered to affect the future and manipulate the challenge answer by coordinating others to upvote one player and downvote another. Suddenly, a much more interesting layer of strategy emerges for how you will vote, how you talk to your alliances, and how you approach the Challenge. Now challenges reward your amount of knowledge and your ability to control outcomes round to round.

Version 4: At the beginning of each round, the bot will post a question about the future state of the game, and all players who respond with a correct answer any time this round win a token.

---

Challenges started as arbitrary puzzles that were disconnected from gameplay, and frustrating to players who were not able to check their phones throughout the day. Challenges ended up as questions that drive the core gameplay of voting, and reward players with the best deduction skills and the best ability to coordinate with others to control outcomes round to round. Now, Challenges are probably the most universally beloved part of Pecking Order.

We were able to efficiently diagnose problems and develop this mechanism because we were all super-testers, and all had a chance to manage the game and observe player behavior as the bot. I’ll probably write up some more examples of how this kind of collaborative design helped us move fast and embrace the best ideas in the future. Hyper-collaborative, consensus-driven design is probably not the right path for most projects, but it has worked wonders for Pecking Order.

How we start projects: Spine and Constraints

We have spent 3+ years developing our first board game Beast Master. Part of the reason it has taken so long is that we fumbled around in the dark for the first couple years designing without any constraints or any particular goal in mind. A cool, divergent idea would come up and we had no grounds to say, “no, that’s too far fetched,” or, “that’s simply not what we’re aiming for here.” We ended up accidentally re-designing it into a completely different game more than once. We eventually landed on a game that both of us are proud of, but we spent lots of unnecessary time banging our heads against the wall. 

Since then, we’ve started explicitly writing up two things that shape the development of our games: Spine and Constraints. These crucially important concepts provide a huge amount of clarity and focus for us, and give shape to our projects before we even start prototyping them. 

Spine

Twyla Tharp is a choreographer who has been creating and directing wildly successful dance productions for decades. I know little to nothing about the art of dance, but I know that she wrote a brilliant little book called The Creative Habit. It is chock full of practical ideas for how to lead a creative life and how to do creative work. 

One of her stickiest ideas is that a great creative work needs to have a spine that holds it up. She describes a Spine as “private guidance” that can drive the theme and structure of the entire work. “The spine is the statement you make to yourself outlining your intentions for the work... The audience may infer it or not, but if you stick to your spine the piece will work.” The spine is pre-eminent, and it informs every single creative decision you make. You can create something without a Spine, but it will very likely lack coherence, conviction, and confidence. 

Constraints

At GDC in 2019 Matthew Davis detailed how he and his team designed the game Into the Breach. I aspire to one day make something as deeply elegant, fresh, thoroughly explored as Into the Breach.

Their development was driven by the constraints that they put on themselves. Davis describes a “hierarchy of constraints” that they implemented as they developed the game. Their design process is a process of narrowing their own options. They’d lock one constraining idea into place (such as: players have perfect information about what the enemies will do next), then survey what was still possible in the game, and implement further constraints from there. They continued narrowing down the mechanisms in the game until the game was an immaculate, clear, and perfect piece of game design. This is similar to the concept we love of “soft vs. steel.” Once we find something that feels great, we throw out other soft ideas that fail to serve the ideas that are working. Once you have a few steely things working together, it becomes obvious what you need to cut, and the game almost begins to design itself. 

Certainly there is a time for broad and unconstrained brainstorming. When I’m deciding what kind of project to take on next, it is worthwhile to be extremely open-minded and uncritically explore new and wildly divergent ideas. But once I’ve decided on a project that has a spine, it’s crucial that I set up some basic guardrails for myself to focus my creative thinking onto how to make the most of the confined little idea that I’m trying to develop. Without guardrails to guide brainstorms, the space of possibilities is simply too large to be manageable. This kind of focus makes mere concepts blossom into fully realized games.

Here’s a glance at what this looks like with the two most recent games we’re working on.

Rampage

• Spine: you must build hands and manage your deck to win battles in a way that also prepares you for all contingencies, and preserves your best cards for future battles.

• Constraints: less than 5 minutes to learn, both players have identical decks, the entire game consists of 54-108 cards, and game play must have enough variance to be extremely re-playable without adding more cards.

With Spine and Constraints in place, I was able to rapidly generate dozens of ideas for cards. Some worked and some didn’t. Some were interesting, but felt misaligned from the Spine I wanted. I was suddenly free to confidently shelve cool ideas and say, “no” because I had guardrails. I was able to really deeply explore this little idea of building multiple contingent hands, and the result is a focused and fun game that represents the best game design I’ve ever done. 

Pecking Order

The Spine and Constraints of Pecking Order were borne of necessity. When Covid-19 hit, we were suddenly not able to test games in person, but we wanted to make a cut-throat social game that we could play together remotely.

• Spine: All game play, sharing of asymmetric information, deduction, cooperation, and betrayal is handled through text communication, and players can communicate as much or as little as they want.

• Constraints: less than 3 minutes to learn the rules, includes no components other than Discord or Slack, players don’t get eliminated, and game play should vary majorly depending on who is playing and how experienced the players are. 

Designing a game with no components and few rules was extremely restricting. It forced us to think very differently about design and throw out loads of cool ideas that are simply too complex for this medium. What we were left with was a hyper-focused, and truly addictive game we can’t stop playing. 

How we make beautiful cards fast with Figma + Google Sheets

We’ve been trying out different ways to prototype cards for years, and I wanted to quickly share the best thing we’ve found. When we prototype and test, we need to create and print components in a way that is:

1. Fast

2. Cheap

3. Presentable (if not beautiful)

4. Easy to update

Sample cards from Contingency Plan

There are obvious tradeoffs between these four requirements. Scribbling on note cards is fast and cheap, but it looks terrible and updating cards is tedious and time-consuming. Printing text on printer paper and taping it to old business cards looks slightly better, but it’s still amateurish and takes too long to update. The key to a great process is that we need to be able to make small changes to existing cards, and create wholly new cards very rapidly without sacrificing presentation or spending a lot of money.

The process in the video below is the best thing we’ve found for the following reasons:

1. Fast: Figma is extremely user-friendly and easy to use.

2. Cheap: This whole process uses free tools. Printing on cardstock can be pricey, but you can trim down costs by not using color, and using cheaper paper.

3. Presentable: Figma makes it easy to make beautiful cards at scale. You don’t have to be a designer to make things look good there. Walter (Product Desginer at DropBox) and I (Product Manager at Binti) use it constantly for work. It works for designing software, it works for designing card games. It’s an amazing tool.

4. Easy to update: The workflow with Google Sheets allows me to update the entire deck and create a new print file in seconds.

Here’s how it works:

You can see the detailed process in the video above, but the key steps are:

1. Put all of your card information into a Google Sheet. Use the first row to name the different text fields on the cards (such as Title, Body, and Power). Make sure that your sharing settings on the sheet are set to “Anyone on the internet with this link can view.”

2. Install Google Sheets Sync on your Figma account.

3. Design a card in Figma, and name the different text fields using a # for the name of the column you want to reference in your Google Sheet.

4. Create a Component by right-clicking on the card and selecting “Create Component”

5. Create a Frame, and name it “// “ followed by the name of the tab in your Google Sheet

6. Click on “Assets” in the top left of Figma, and drag and drop copies of your card component into your Frame.

7. Right click on the frame, click Plug-ins, and run the Google Sheets Sync. Paste the link to your Google Sheet, and run.

8. You can either download using “Export” in the bottom right of Figma. Depending what you want to do with the cards, you could either download individual cards and upload to something like Tabletop Simulator, or put them onto a 8 1/2” x 11” PDF to send to print on cardstock.

Our game design syntax

In the first half of 2018, we went from index card cutouts to a fully fledged v1 of Odra (a working title that we quickly dismissed as wannabe sci-fi). We knew that there were problems with the game, but we lacked a systematic way to diagnose those problems. One big issue we ran into was that we were fine tuning every part of the game simultaneously. Games are finicky systems. Each part of it is hydraulically linked to all the other parts of it. Small adjustments to the rules can result in huge changes in player experience. On a few occasions we changed 3 or 4 little things at once and managed to completely break the game.

This blog post is about the syntax we used to audit our game systematically, evaluate each part of the game independently, identify what needed work, and ultimately allow us to rebuild the game around its best parts.

Rule vs Component vs Loop

First, we triaged each part of the game into 3 broad categories: rules, components, and gameplay loops. Rules are rules, and there are rules that apply to just about everything. Components are the stuff that players interact with to play the game. Loops are sets of activities that players perform repeatedly in pursuit of victory.

Core vs Ancillary

By testing over and over and over, we discovered a small handful of ideas that hung together particularly well, and were a consistent source of fun. Specifically, we fell in love with:

Attempting to define the “Core” parts of the player experience

• Exploration of a dynamic map of hexagonal tiles with hidden information

• Interesting movement between each hexagon that includes chained, cascading effects

• Big, exciting events that you can play at any time, and affect everyone

• Some sort of punctuating, repeating attack from an automated villain who prowls around the map and kills players between turns

That’s our 30 seconds of fun. That’s the core. All of that stuff is essential to the player experience we’re creating. Sometimes you don’t get to decide whether something is core. The board is what players will be staring at for most of the game. The gameplay loop of a “turn” is the set of activities that players will do over and over for the whole game. Those types of things are core whether we want them to be or not.

But we definitely didn’t care about all the other parts of the game that much as we cared about the core stuff. For example, we had many long discussions about how best to implement the currency system. We tested lots of ideas, and came up with some fun ones. But when we audited the game after testing v1 a lot, the currency itself wasn’t a source of fun. It had an important role to play — currency governed how much a player could do on a given turn, and presented an interesting trade system. But it wasn’t the main show. It served a necessary support role to make the current rule set work, but it was not primary to the player experience. We call these kinds of components and rules ancillary. Our opinion is that ancillary components and rules should be quiet and reliable, and fold seamlessly into the player experience without drawing attention to themselves. Here are the guiding principles for our ancillary components and rules:

• Purposeful: It must achieve a goal or solve a problem that nothing else in the game solves. The total number of ancillary elements should be minimized, so elements which address multiple goals / problems simultaneously are preferable.

• Minimal: It must be ruthlessly efficient in getting the player to their desired outcome. In the words of John Roderick, ancillary elements should keep players moving and get out of the way.

• Integral: It must enhance the experience of performing the core activities of the game and inform the player about who they are and what they are doing. It must be integral to the whole of the game.

It’s not always this straightforwad, but we declared everything in the game to be either ancillary or core. Now we could begin to assess every part of the game in light of how well it served the core player experience. For example, we loved the player experience of exploring tiles while avoiding an automated villain. However, the components and rules we used to implement that in v1 were clunky and confusing. This was no major problem. There are 10,000 ways to pose danger to players and shift tiles randomly. The components and rules that will evoke that player experience are ancillary, and therefore replaceable.

Steel vs Soft

Finally, we categorized everything according to the old adage, “If you meet steel, then stop. If you meet mush, then push.” We found that it was really important to put our pencils down on things that felt like steel so that we could focus on the stuff that still felt soft.

Putting all the pieces together, we could summarize the whole game using this syntax. The board shape is good, but it might be better with smaller spaces and more spaces: core component (soft). The rules for dealing with currency are a fair way to manage player turns, but they are clunky in practice: ancillary component (soft). Hexagonal Tiles are great as they are: core component (steel). The victory condition is extremely important, but it’s kind of anticlimactic right now: core rule (soft).

v2

Finishing v2

We started locking some pieces into place, and that made subsequent decisions even easier. Each time we locked something in as steel, the scope of possibilities for all the remaining soft components and rules around it would shrink. Using this method to develop a v2, we ended up recreating the game into something quite different once again. In fact, we may have been too liberal with our changes. We ditched all the soft ancillary stuff, and built a fresh game around the core stuff that we loved. Here’s what we changed:

• Simplified tiles to just a few different broad categories to make it easier for players to quickly understand what they were looking at. 

• Shrunk the size of tiles, and added 10 spaces to the board. 

• Replaced the villain with 4 payloads that could be worth different points, based on player bidding. 

• Shortened the player’s turn so the gameplay is much faster and simpler. Feels less like a strategy game and more like a sport. 

• Players now started in different corners of the board instead of moving linearly across the board together.

It was a fairly fun game, but it felt nothing like the v1 that we loved so much. Mildly discouraged, we put v2 on the shelf for a couple months while working on other games. Then in November 2018 we suddenly realized that we could incorporate our learnings from v2 to solve the problems of v1 while preserving that original player experience that we lost in v2. Now we are neck deep developing v3, which combines the best features of the first two versions, and feels significantly better than both of them. But that’s a blog post for another day.

30 Seconds of Fun

Walter and I have been “designing games” in our mind palace for years. We thought up a puzzle-based competitive iOS game, a Jackbox-esque multi-screen heist game, and an epic superhero role-based strategy board game. We talked on Skype and imagined exciting, novel games that had beginnings, middles, and ends. They were sort of like un-playable, puffed up thought experiments. And because they weren’t real yet, they sounded elegant, fair, and perfectly balanced.

We had misplaced confidence in the quality of our ideas, because no player had yet given us that blank stare that says, “this rule makes no sense and there’s a typo on the card… and by the way this isn’t fun.” They needed rigorous editing and brutal feedback and fresh eyes. They needed to be tested.

Walter’s floor after our first day. We used lots of components from other games for things like currency and people.

Moving from the mind palace to the real

In January 2018, we decided to change our approach and get serious. And by “get serious,” I mean, “Buy index cards and sharpies.” Our strongest, simplest idea was a game where players bid different amounts of resources to commission space ships and send them on a dangerous journey (the mechanisms for competitively bidding on multiple risky entities mimics venture capital investing, which was my day job). Without any sense of how the game worked, we started cutting little ships and pushing them around Walter’s carpet back and forth between an origin planet and a destination planet. Extremely basic stuff.

At first, we just wanted to stress-test the basic engineering of the game. These crummy index cards exposed some obvious initial questions with much deeper questions behind them:

• Obvious questions: how far can ships move from a given location? are there spaces between them?

  • Looming questions: where are we, what are these locations, why are we motivated to move between them?

• Obvious questions: how do players move about the board? do they have turns with limited movement?

  • Looming questions: who is the player, what are they doing here, what does a turn feel like, and why?

Immediately, the tactile experience of pushing index cards around sharpened the game. By the end of the day, we had basic, fair rules about movement, and it felt good. The game was resolutely un-fun, but we had our first few rules. Then we played it with Walter’s unbelievably patient wife Toria, who exposed a bunch of other blind spots. We made more progress on that Saturday than we had made in the last three years. Since then, we have had a major design sessions or play tests almost every week. We repeated this process for months, the best features of the game percolated to the top, and the half-baked filler ideas started to look weak and bland.

Once we had a game that more or less hung together, we began looking for something much more mysterious: fun.

30 Seconds of Fun

These play tests were in pursuit of some great, repeatable experiences within the constraints of the prototype. By tinkering with the components of the game, interesting little movement mechanics or a satisfying progression cycle or a set of dynamic problems would emerge. We wanted to find the best features, and focus the entire game around them. We needed some activity or decision at the center of the game that you could do 1000 times before getting bored. 

We refer to this hook as the “30 seconds of fun.” That’s how Jaime Griesemer described the design process of the player experience in Halo.

“In Halo 1, there was maybe 30 seconds of fun that happened over and over and over again, so if you can get 30 seconds of fun, you can pretty much stretch that out to be an entire game… but if you don’t nail that 30 seconds, you’re not gonna have a great game.”

We didn’t yet know what our 30 seconds are, but we know the fastest way to find it is by playing the game. A lot.

v0.1 consisted of a 25 space board, hexagons with crazy encounters, specialized ships, a currency (fuel for ship movement), and a villain who prowled around the map autonomously between turns.

Finishing v1

Many ideas worked elegantly in the mind palace, but created friction and confusion for players in practice. Physically moving cardboard and plastic on a table and watching the reactions of friends and family forced all of our design decisions to be practical, understandable, and integral with the other components in the game. We mercilessly chopped everything that didn’t work, and the game evolved quickly into something pretty different. We tested this way for months, sharpening the good, purging the bad, and always keeping the game intact and ready to play each week. In July, we landed on v0.1 of the game

We played v1 throughout June and July. Since then, we developed and shelved a v2, refining our design process along the way. And now we are testing v3 at board game shops! Our design process is still based on rapid iterations and ongoing tests, but includes a system for tracking and categorizing all the components and rules. That’s a blog post for another day.