Games are an interesting medium. Unlike just about every other popular form of entertainment, such as film, literature, and theatre, games depend on player choice. As a game designer, most of your time is spent crafting which choices to present to the player.

The most interesting question to us is: How can we take the lessons learned from game design and apply them to open source software design in general as well as to the communities that surround them? Games create systems through their rules in the same way that all software creates systems through their code and communities do through their processes and traditions.

Games are choices that lead to feelings

Player choices range hugely in scope. At the highest level, choices can affect the game’s entire story; many developers have become particularly well known for this, with games focusing on stories and the choices around them. At the lower level, players can have very fine-grained decisions to make, like whether they dodge to the left or to the right when facing a boulder rolling at them. Halfway between there’s an interesting space where players have no choice in what the next plot point is, but they have significant freedom to choose how the story gets to that point. The most interesting example of this in recent times is Arkane’s Dishonored 2.

At its core, a game’s choices form a system in which a player operates. As a result of these constrained interactions, the player is emotionally affected in ways that are deliberately designed by the game’s creators. If you play an action game, the game’s available choices are constructed such that the player leaves the game feeling excited and exhilarated; if you play a story-heavy adventure game, the game leaves you feeling like you’ve explored a vast new world and met new people. The most effective systems evoke the feelings and reactions needed for success in that environment.

How do games go from these choices to these feelings? In an attempt to answer this question, Robin Hunicke, Marc LeBlanc, and Robert Zubek’s paper MDA: A Formal Approach to Game Design and Game Research proposes a method for breaking down a game’s design into three components:

• Mechanics, which are the rules that define the game
• Dynamics, which are the emergent properties that are caused by the mechanics interacting with each other
• Aesthetics, which are the emotional impacts that the dynamics have on players

To understand how these components apply in the context of a non-game open source project and its community, let’s take a bit of a deeper dive into each of them.

Mechanics: the rules of the game

Let’s lay out some rules for a game that you’ve probably played before. It’s not a new game; in fact, it may be the world’s oldest game and possibly predates the human species itself. This game is known by many different names, but usually, it’s a variant on the word “chase.”

This game has two rules:

1. One player is “it,” which is an undesirable state to be in
2. When the “it” player touches another player, that player is now “it”

On the face of it, it’s an extremely simple game. However, if we examine what happens when these two rules play out over time, we start to notice some interesting things happening.

Dynamics: the intended consequences

The first rule of the game states that the “it” player doesn’t want to be “it.” The second rule states how the person can rid themselves of this affliction: by touching another player. There’s an unstated rule that’s implied: To avoid becoming “it,” players should ensure that the “it” player does not touch them.

The easiest way to do this is to move away from the “it” player and out of their reach. However, when this happens, it means that the “it” player must attempt to move back into range. When these two actions—moving out of range and attempting to move back into range—play out over time, we end up with the “it” player continuously chasing other players.

You’ll notice that the two rules didn’t once mention anything about chasing. It happens anyway because the rules require it.

Aesthetics: the emotional fallout

We now have a situation in which at least one player is being chased by another. Humans are animals, and animals generally want two things: to eat dinner and to avoid being dinner. The game of chase triggers both primal feelings: When you’re being chased, you’ll feel hunted and pursued; when you’re chasing, you’ll feel like a predator.

We now see how a simple two-rule game creates extremely strong emotions. What’s fascinating about this is that we can apply the same principles outside of building games.

Outside of games

In 2009, Twitter added support for retweeting, which allowed users to forward another user’s tweet to their followers without having to copy and paste the original tweet. This also allowed users (and Twitter itself) to have an accurate count of the number of times a tweet was shared. Importantly, the number of retweets a tweet received became publicly visible on each tweet.

As a result, each tweet immediately gained the potential to be part of a popularity contest. When a piece of content is shown to be popular, such as how many times other people have chosen to forward it, then the likelihood of someone else deciding to share it increases.

It’s no coincidence that @horse_ebooks, one of the most popular accounts of the “weird Twitter” movement, started within one year of retweets being tracked and popularity stats made visible. Until the account was abandoned in 2013, it regularly posted nonsense phrases that were designed to look like a malfunctioning spam bot but were actually hand-written by a human. The key to its success was the network effect afforded by retweets and the public display of its popularity. @Horse_ebooks isn’t alone; other accounts, including @dril, @leyawn, and @wolfpupy have achieved similar popularity through retweets.

These outcomes would not have been possible without the change in the rules that retweets created. As a result, the human dynamics of popularity contests kicked in, resulting in what can only be described as text-based standup comedy. Through a simple change in the rules, Twitter could modify community behavior in the direction it wanted it to go.

Where to take this

Game design is the study of how systems affect people. However, it’s important to realize that games aren’t the only systems that can affect people: If there are humans involved, they’ll feel something that’s a direct consequence of the choices your software makes.

This is even more pertinent when it comes to how open source software is made. Open source is produced with much wider capacity for exposure to people in both development and user roles. Accordingly, as developers of open source software, we need be even more mindful than usual of how the mechanics our systems create affect people. This is as much of an opportunity as it is a warning: If you keep in mind how the mechanics of your system work when applied to people, you’ll be able to craft products that have an extremely powerful impact on their lives.

Whether interaction design for your graphical interfaces, consistent APIs for your computer interfaces, and codes of conduct for your human interfaces, the thought you put into each can make a huge difference in whether people want to use your software, build upon it, and participate in your community. Even small changes in the rules, like Twitter adding the retweetability, can have an oversized impact on how people perceive your project. This means that even the smallest change should be considered for how it might change the rules and how the method you define will affect the dynamics and aesthetics of your open source software and its community.