P4: Git $#!? Done

Motivated by a fun playtesting session during the development of version one, our P1 group reconvened for P4 to take Git $#!? Done to the next level.

For our in-class playtest, we wanted to see if a different board mechanic might make gameplay smoother — so we built a geoboard.

Playtest with Geoboard: a wooden board with a grid of nails and colored rubber bands to represent the player.

We soon realized in the first few rounds of playtesting that the geoboard had affordances that allowed players to circumvent the (intended) imaginary obstacles of the game.

So instead, this iteration of Git $#!? Done focuses on polishing gameplay with a simpler set of rules, more pleasing and accessible cards, and prettier custom game pieces.

Some changes we’ve made since the final P1 playtest include:

Language:

• Rewrote rules and cards to use consistent terms like action tokens, resolve bugs, etc.
• Added a visual and rule distinction between bug and feature branches.
• Rewrote card flavor text to fit the audience of the game (removing acronyms and proper nouns such as SWE, Sequoia Capital)
• Restructured rules to have clearer actions and a simpler response to edge cases (bugs related

Instruction Cards:

• We came up with a revamped instruction card that each player would get. Originally, the instruction cards only included the type of actions that could be done, as well as the price of each action (action tokens). However, the new instruction card includes step-by-step instructions of proceeding through a turn, as well as caveats (notes on roll-over tokens, explanations of the context of the actions that could be taken).

Graphic Design:

• Revamped the visual identity of the game (logos, fonts, color schemes) to better reflect the actual ‘Github’ vibe, as well as the modern ambiance of the tech industry. Incorporate the newly designed logo to many parts of our game, including but not limited to the back of the action deck/feature card/project cards, but also the instruction sheet/cards.
• Standardized the design and the size of the cards. We made the conscious choice to make the project cards bigger than the rest of the deck, given that the project card is to be shared among the team. Other cards were designed in a way that would both be easy for us to produce (print) and would be nice for the players to hold in their hands.
• Italicized all flavor texts (across all cards). Set all ‘action texts’ (i.e. draw 4 action tokens) to bold, with added colors, so that users can easily understand what actions to take.
• For the project cards which featured well-known tech companies, we introduced a higher-quality logo (with an obvious twist) to make the story more convincing.
• For the packaging, we took cues from the actual GitHub user experience, introducing the element of a browser window and the ‘code development tree’ as the main design elements of the package.
• The colors that represent each of the 4 players was chosen after careful research on color accessibility. The four colors would even be distinguishable for those who have protanopia (unable to perceive red light) and deuteranopia (unable to perceive green light). The game’s board design, dry-erase markers, and painted player tokens were chosen in line with the color selection.

Physical Board:

• For easy production, we standardized the size of the board to be comprised of 6 letter-sized papers. The pages were then laminated to withstand dry-erase markers.
• As people sometimes experienced difficulties on how to start the game (how to draw the initial line of branching, coding, pushing and committing), we introduced a lightly-colored guiding line on the board.
• Instead of having a tracker for the progression of the turns (8 turns), we updated the rules so that players would start with n number of cards, where n is the product of 8 and the number of players. That way, when they run out of cards in the action deck, they will see a “game over” icon that is printed on the board.
• The physical board retained most of the prominent elements of the original design, including but not limited to the ‘master’ branch, the grid design, and prescribed spaces to put the deck of cards on the board.

Old vs. New: Mockups of game board and and game pieces in setup orientation for P1 and P4.

After making these changes, we did two remote playtests with:

1. Close to our target audience, college seniors with very little (but some!) git experience. We are very grateful for playtesters Kai, Kelsie, and Ismail.

Playtesters after Ismail rolled a 4 on a new bug

2. Board Game Hobbyists, with a mix of expert git experience and no git experience at all. We are very grateful for Devin, Amanda, Brian, and Sicheng.

Playtesters reading a funny “$#!? Tips” card

Playtest recordings can be found in the following Google Drive. You must be a member of the Stanford community to view (for the privacy of our playtesters).

Meet Google Drive - One place for all your files

Surprisingly, our two playtest groups had very different experiences. We learned a ton from both groups. If we had the time (and the lab resources) to do another iteration, some ideas we could consider include:

1. Shrink the cards. Players in the first playtest struggled to shuffle the oversized cards.
2. Add action text to every action card. Players in the second playtest were unsure if they were supposed to discard bonuses, since some cards said nothing and some cards said to be kept.
3. Discuss the bug dice on the bug card and indicate the triangle in the rules. It took players in the first playtest a few turns to figure out how to track the bug progress.
4. Instruction cards one-sided OR indicate two-sided. Players in the first playtest wrote the action options on the board because they didn’t discover the backs of the instruction cards.
5. Explicitly allow collaborating on features. Players in the first playtest had no issue, but players in the second playtest did not know they could collaborate to complete a feature.
6. A bug interaction better than shuffling into deck: Players in the second playtest didn’t see any bugs, and players in the first playtest saw several bugs in a row.
7. (Code+Commit+Push) conveyed clearly as one action. Possibly by changing language to fit “coding action” and having code/commit/push be in flavor or helper text. We’ve been resisting this change since our first playtest because it goes against our learning goals.
8. A more climactic finish. Both playtests, one losing and one winning, finished the game without much fanfare. Some clear reward or consequence might be appropriate.

We had a ton of fun building a game that teaches useful skills that each of us had wished we’d learned. It was quite an experience to see the game truly come to life.

The Print and Play version of Git $#!? Done is available in PDF format here.