2008年03月18日
Asynchronous Multiplayer
Today, I want to take a break from coding and talk about asynchronous multiplayer games and what separates them from normal MMO games.
Synchronous vs Asynchronous
Ever since games like Ultima Online came out new online games have been popping up every month. Many of the major blockbuster games like World of Warcraft offer a shared world in which many players can interact in realtime. These can be called synchronous games.
Some other examples of synchronous games are Lineage, Second Life, Habbo Hotel and Counter Strike. These games have different genres, network structures, platforms and targets but they all share the common trait of having a shared world in which people can play together simultaneously. From a real life standpoint, games like basketball and football are synchronous games because they require that you have other people playing in the same place at the same time.
The opposite of synchronous play is of course asynchronous games. “Asynchronous Multiplay” by Ian Bogust described asynchronous play as having these characteristics.
- Asynchronous play supports multiple players playing in sequence, not in tandem.
- Asynchronous play requires some kind of persistent state which all players affect, and which in turn affects all players.
- Breaks between players are the organizing principle of asynchronous play.
- Asynchronous play need not be the defining characteristic of the game.
Examples of asynchronous games are Duels, Battle Mail kung-fu, KDice and Animal Crossing. All of these games don’t require the players to be in the game world at the same time to interact with each other.
A real life example of asynchronous games is play by mail games. Games like chess can be played asynchronously by sending moves via snail mail. Another example are chain letters, because people can interact with each other by sending letters but, they all don’t have to act in tandem.
Persistent State
Persistent state is one of the key points of asynchronous play because it answers the question of , “How do we create interaction and communication between people if we have a game in which people don’t play together simultaneously ?”
Let’s look at a simple example in fig A. The circles represent active players and the black boxes represent a game world. In a synchronous world when player A moves (1), player B gets immediate feedback of player A’s action (represented by the red line 2). Since the world is synchronous Player A can immediately communicate his actions to B .
fig B. represents an asynchronous world. First player A enters the game and moves the purple box (1,2). The new world state is then saved. When player B enters he knows that player A was or is inside the world because the box was moved (4). Player A’s actions are communicated to player B through the purple box. The purple box is our persistent data.
As you can see if we didn’t have the box, player B would have no knowledge of player A’s actions.
Persistent data in it’s simplest form can be a high score table, like in Space Invaders. The score table is a very simple method of communicating to other players about what score you got and how many points they need to beat your score. A more complex examples is in Duels where players can create persistent characters and use those characters to battle other players.
Sequential Gameplay
Sequential gameplay in asynchronous games is advantageous because it allots more time for the player to plan and react. It also reduces the requirement for a player to be online consistently monitoring their game. That’s why asynchronous games are aimed more toward casual gamers who don’t want commit long hours playing. Although, one possible problem with sequential gameplay is that one player’s state is often dependent on another player’s state. You need a way to handle non-reactive player’s or really long and drawn-out games. Synchronous games can avoid this problem because players’ states do not have to depend upon other players’ actions.
Technical
One major problem with synchronous games is that they often require lots of algorithms to keep all the players and the world state synchronized. In many MMO games the majority of packets come from just updating player positions. With asynchronous games all the player usually needs is the last state the world was in. This means that we don’t need to keep persistent connections using sockets. Usually just simple http requests are good enough to build a asynchronous game which is suited for platforms which don’t have stable Internet connections like mobile phones.
So?
Asynchronous games isn’t a new concept, but something people didn’t really notice -including me- because they are shadowed by larger blockbuster games. I think with the rise of popularity in casual games and web 2.0 apps asynchronous games will become more popular. It’s also attractive to developers because asynchronous games offer a wide target audience and lower development costs.
Leave a Comment
Trackbacked