Git @#&! Done — Game Design and Iteration

By Fiona, Clara Louise Kelley, and Jin Woo Yu

Concept

Git @#&! Done is the game of version control. The game teaches key skills of good version control practice in software development to 3–4 collaborative players. It should be perfect for people interested in learning about using git and other management software appropriately, but might get a little boring for command line aficionados. Within the game, the players work to finish a coding project for a startup with fellow software engineers in time for launch.

The game relies on challenge and fellowship to create a fun atmosphere. The mechanics are inspired by other collaborative board games such as Pandemic and Flashpoint. Users can take various actions each turn, such as branching, coding, merging, or helping out their fellow teammates. These set of actions, inspired by the concepts of Git, would allow players to understand the action and workflow of using version control. Their actions are prescribed by the set number of action tokens given at each round, representing the amount of work-hours they can put towards the project. It goes without saying that players must be efficient in using their limited resources in order to complete the challenging projects they are given! The game also includes an element of randomness through a deck of cards, which provides players a variety of real-life situations they can encounter while working on their projects, such as bugs, workplace crises and bonuses.

This game is largely inspired by the current educational environment at Stanford, where an understanding of version control using Git is necessary to succeed in a classroom environment, yet version control is never formally taught. The skill is most frequently used in many workplace settings beyond Stanford, making this a crucial skill for any aspiring workers in the tech industry.

Assessment

To assess if players were achieving the intended outcome, we used a combination of surveys and observing the progression in gameplay from the first round to the last.

We compared players pre- and post- survey responses to a set of situations in development (example: Your teammate completed a feature all on their own and didn’t run into any bugs. They don’t want to bother anyone, so they merge directly into master. Can/Should they do this? What might happen?). All players answered reasonably after completing the game, and all players became much more sure of their answers (no question marks or statements like “I think” and “maybe”). For example, on the pre-survey only one player answered correctly that a user should branch to resolve a bug, and on the post-survey all four answered correctly.

Players also answered questions about what they found surprising and frustrating. The complexity and the ambiguity of the instructions/rules came up as a common frustration and a common surprise. While players struggled to play through the first round, by the end they were collectively strategizing several rounds ahead.

We observed many of our players having moments of great fun. Some of our favorite quotes from the gameplay include “merge me, senpai!” and “my intern is so useless, I only get one action point!” Despite players’ initial skepticism towards the game, they all seemed to thoroughly enjoy themselves with smiles abounding.

History / Development

The game was taken through at least three distinct iterations. Our team played the first version of the game together, amending mechanics as we progressed. At the end of this session, we made the following key changes:

• Crisis and Bonus cards: extra interruptions to gameplay to make it feel more variable
• Info and project cards to track goals
• Draw card first, then take points (in case card forces to skip turn)
• Combine approve and merge to one step (one review + one approve and merge to complete a feature instead of two reviews + one merge)

The first playable iteration of game

Next, we playtested with other HCI students during the open session of class. We received the following valuable feedback from our classmates and made key changes:

• Too overbalanced towards randomness: Gameplay seemed decided by card order and dice rolls, not player decisions. Solution: feature cards instead of die to track features, feature lengths pre-determined and player-selected. Players can take out extra features and can have any number of active branches.
• Not enough interesting knowledge: Gameplay felt routine, as if (without action cards) only one choice allowed player to advance and this brought about no new information. Solution: added more engaging “neutral” cards and increased incidence of action cards.
• Did not feel very collaborative except for in review system (game requires a review from another player to complete feature). Solution: players can help complete each other’s features by branching from them and getting merged later. We added more possible turn actions to accommodate this, and this became a key mechanic of the game.
• Players that finish a feature have no incentive to keep contributing to starting new features. Solution: added stretch goals that encourage working on new features.

The second version of the game, with predetermined feature length cards.

Finally, we gathered a mix of board game experts and early software engineers to do a playtest of non-designers.

In this playtest group, we had:

1. A senior in linguistics. A little git experience, and some board game experience.
2. A junior in symsys. Some git experience, and some board game experience.
3. A sophomore in CS. Lots of git experience, and lots of board game experience.
4. A senior in classics. No git experience, but lots of board game experience.

This playtest was our first where we did not actively manage the gameplay, and the feedback we gained from the experience of letting them decipher and interpret our instructions was immeasurable. We made changes according to the following feedback:

• Clarify what “points” are — action points and feature points used confusing and conflicting information. Solution: use action tokens to track turn actions and “bonus points” to track additional features in language.
• Players chose easiest set of features, rather than being randomly dealt a set. Solution: We allowed this change. Now game lets users pick game difficulty level for higher likelihood of flow.
• Extra vs Initial features difficult to discern. Solution: label as “starter” vs. “additional.”
• Neutral cards too technical, confused players to believe that information was useful for gameplay. Solution: make tips more beginner friendly and more silly.
• Edge cases with ambiguous rules, such as: finding a bug after branch is reviewed, getting a bug after all code has been merged and before a new feature is selected. Solution: clearly outline in rules a reasonable interpretation.
• Loopholes such as: grammar mistake in merge rules allowed players to review and approve and merge another player’s branch (ie only one person reviewing code). Solution: more clearly state the requirements for merging.

Many of these changes correspond to — 1. Closing a loophole based on missing wording in the instructions 2. Clarifying a meaning by using more specific and differentiated language or terms 3. Improving the experience for average player type by changing the knowledge level of language used in materials. We also had a player who inspired us to write “Shit Tips,” which are examples of bad advice or bad practice in version control.

First playtest with other Stanford students and only the written instructions and with unlimited branching.

Take-Home Version: https://bit.ly/2usePo5

A Note About Accessibility: One of the players for our last playtest had limited color perception. This caused us to consider our ideal color scheme carefully (although in our physical playable version we are restricted by the marker colors which we have). The color scheme we decided on is visible in the Set-Up and Example of Play diagrams in the instructions.

A Note From Final Playtesting @ Class 3B: Through in-class playtesting, we observed that the players were becoming more and more cognizant of other people’s progress and obstacles.

People started to realize that they should actively help each other out, in order to maximize team productivity. Many responded that the game was surprisingly realistic, even down to the nitty-gritty parts of coding (being blocked by other people branching off of them, etc.) Players also had a great time reading the “shit tip” cards, which were suggested by one of our previous test players!

We’ve had mixed reviews about the graphical representation of the game. The good use of colors made the game much more clear and fun, and the little triangle on the bug card was obvious enough for people to put on a 4-dice without anyone telling them. (The team was super glad to see this!) However, the action card and the project cards were too verbose and sometimes hard to understand, making the initial learning curve a bit steep. We also witnessed an interesting situation, where the players were modding the game as they go, drawing graphical representations of the bugs and debugging actions on the game board.

If we are to iterate more upon this game, we would work on the following

• Make the card deck and the instruction much more succinct (Halve the amount of text we currently have now)
• Make a step-by-step instruction card for everyone (“What to do when I get a bug”, or “List of things to do in my turn”, etc. type of list of instructions)
• Explore the idea of introducing the concept of merge conflicts into the game. Many people responded that the concept of merge conflict was integral in really understanding how git worked.
• Clarify vocabulary used in the game. Action tokens and points were one of the more common points of confusion for many players. This added up to people having a hard time trying to set up project cards and feature cards at the start of the game.
• Another idea was that this game would best be implemented as an electronic version, given the intense amount of record keeping/turn keeping that has to go on every turn.
• Explore the idea of introducing a competitive element, where players would be incentivized to help each other as much as possible.