Asynchronous gameplay is a popular phrase for describing various forms of online games that connect players but don’t require simultaneous play. Many eminent commentators have talked about the possibilities for this kind of gameplay, and how it might be the future for games.
However, in a fascinating debate on Gamasutra initiated by Ian Bogost, Raph Koster and I ran across a confusion of terms. Raph said that asynchronous games have existed for hundreds of years, citing play-by-mail Chess as an example. Except I think play-by-mail Chess is synchronous. When talking about synchrony, we actually meant two entirely different things.
Where many people casually talk about synchrony in relation to whether players are together in real time, I think it means games that require players to be in sync with one another in game time. This article elaborates on that idea and describes how real and game time intermingle.
Game Time or Real Time
Many games are played in real time. Sports, action games, console shooters, racing games and more are all real time experiences in which one or more players acts and reacts to a world in motion. However, like weight and mass, game time and real time are not the same thing. They only appear to be so under certain circumstances.
A single player game might be played in real time, such as Portal 2, but then you have to go away and cook dinner for your wife. So the game is paused or saved, to come back later.
A single move in play-by-mail Chess might not receive a response for several days. A tabletop roleplaying campaign may start and stop over a number of discrete sessions of real time spaced out by long periods where the game is not being played.
Game time is always internal to the game world, and it may not tick forward on a second-by-second basis. Whereas real time is all around us all of the time and always ticks at the same rate (relativity not withstanding).
This is an important distinction.
Synchrony is a property of all games:
Synchrony is often used broadly, such as different game modes. Single and multiplayer modes are the most common example, but there are some subtle mixes also. CityVille, for example, is a mostly asynchronous game with the exception of the gating mechanism that requires you to hire friends to work in a building. Gating requires their action to complete the loop for you to win, so that is synchronous.
That’s why I describe synchrony in terms of loops rather than the whole game. A loop is a basic molecule of gameplay in which the player takes an action and the game reacts in some way, determining whether the player experiences a win, a loss, or another loop. In an asynchronous loop the reaction comes from the game itself, but in a synchronous one it is dependent on other players.
Loops also vary in length. In team deathmatch Halo the loops are in real time, but in PBM Chess the game time only ticks forward when a turn is taken. So a single loop might take days to close. And yet the need for involvement of other players is the same. So that’s why synchrony is related to game time rather than real time.
The more casual definition of synchronous gameplay means ‘playing at the same time’. The dependency on other players that my definition implies is not present, so it could mean players playing alongside each other within a common space, or competitively, or in parallel.
For me that’s just too hazy. Designing with player dependency in mind is very different to that of simple simultaneous presence. YoVille and deathmatch Quake may both be played by groups of players online at the same time, but they are completely different. It is not enough to say they are both ‘synchronous’.
In the debate on Gamasutra, I suggested that the casual definition of synchronous or asynchronous is actually describing a different property to synchrony. I labelled it temporany. The definition of temporany is:
If the play of the game contains the simultaneous presence of two or more players, it is contemporal. If not, it is atemporal.
So your Counter Strike session or Texas Hold’Em games are contemporal, but your Mass Effect or Chu Chu Rocket games are atemporal. Wandering around Playstation Home or YoVille is contemporal, but visiting a friend’s restaurant in Restaurant City is atemporal.
Temporany is about whether players are in the same place at the same time or not, irrespective of why they are so.
Where the Twain Shall Meet
The fun part (for me at least) is how synchrony and temporany interact with one another.
For example: You visit your friend in Farm Town, and he is online at the same time. You help him clean up his crops and chat to one another. Is that contemporal? Yes. Is it synchronous? No. It’s contemporal because both of you are in the same space at the same time. However it’s asynchronous because he doesn’t actually need you to help clean up those crops. Your help is not a requirement of his win.
On the other hand: Your friend in CityVille sends you a gift request. He needs Marble to help complete his community building, and asks you to send him some. Is this contemporal? No, it’s atemporal because you do not need to be online at the same time to send or receive the message. Is it synchronous? Yes. He needs your help to win.
Synchrony and temporany form a grid. There is contemporal synchrony, contemporal asynchrony, atemporal synchrony and atemporal asynchrony. More conventionally, although less accurately, you might call them: multi-play, parallel-play, serial-play (or turn-based-play) and single-play. Quake, World of Warcraft, WeeWar, Portal 2.
Not all combinations of synchrony and temporany work equally well in all situations, and it’s important to understand why. Each tests the tolerance of players differently, and so synchrony and temporany actually form one of the major constraints on all games.
Tolerance is the degree to which your game tests the patience or goodwill of players before they will stop playing.
Everything from teaching the player the rules of the game, to how it asks for money, tests player tolerance. The general rule is that the less engaged the players are, the lower their tolerance.
Tolerance is an unavoidable factor in all games, but you should always try to reduce it where possible. Synchrony and temporany test tolerance in many ways. Largely this is because of the fallibility of individual players, but it’s up to you to remember that players are not ideal and design for that.
Lexulous is a game cited by Jane McGonigal in Reality is Broken as an example of what she calls an asynchronous game with millions of players. Using the basic rules of Scrabble (and originally named Scrabulous), the game was a major hit on Facebook. However, contrary to when Jane wrote her book, it has lost practically all of its 5m users. As have the official versions of Scrabble that followed it.
The reason is Lexulous is synchronous, not asynchronous. Players either forget or don’t want to take their turn, which leaves many individual games orphaned. It’s not fun for other players relying on the forgetful player either, so they are more likely to drift away too. Their tolerance has been reached.
It’s an example of how atemporal synchronous (i.e. turn-based) play can have major issues – but also of how, for the more engaged players of Scrabble, it’s not a problem. All three games may have low MAU, but they have very high engagement rates (35-50%) compared to most other Facebook games. If you love Scrabble, you’ll remember to take your turn.
Another example of how games overcome issues of synchrony and temporany is drop-in/drop-out play in Left 4 Dead. The game is based around cooperative play and, unlike most cooperative shooters, you really can’t just go it alone if other players let you down. If you do you will die.
However the major problem with this design is how players leave or join the game. If the game is reliant on cooperative play then what happens when a player disconnects mid-session?
Left 4 Dead solves this by always being ready to drop an AI character in if a player drops out, and the AI is good enough to make the experience nearly seamless for the remaining players. The AI character is also ready to drop out again if another player wants to join the game. And so tolerance issues are minimised.
What tends to work least well (in terms of tolerance) is designs where players have to depend on each other. In social games the need for scale is paramount for this reason. Similarly, online team sports (such as Football Superstars) also have significant issues because of tolerance.
Generally speaking, the more co-ordinated a group needs to be, the more likely it is to represent only a fraction of players in the game. And if the game is wholly reliant on a co-ordinated group of players, the more likely it is to have a smaller - but passionate - audience.
World of Warcraft is largely played asynchronously, for example, and only a small subset of players get into the guild side of it because it’s a hassle (as satirised wonderfully by The Guild). Texas Hold ’Em is by far the most popular card game online in part because it’s easy to step in and out of. More serious card games tend to have much smaller audiences.
Finally, easing tolerance is the basis of many freemium business models. In CityVille you can pay for that Marble instead of waiting for your friends to send it, and in Ikariam you can speed your game up by paying. It works because players don’t want the aggravation that comes with waiting, and a small amount of cash seems an easy price to pay in order to get away from busywork and back to having fun.
Fun comes in many forms, and everybody wants to have some. Some of those forms ask more of players than others, however, and some of them have to account for issues of synchrony and temporany in ways that others do not. By clarifying what those two properties are, we are more easily able to see how they interact – and thus account for likely pitfalls in our designs.
So the point of getting the terminology clear is that it makes us better worldmakers.
(Today’s image comes from Wikipedia.)