Development

Peer-to-Peer

While multi-player online games are very successful, their fast deployment suffers from their server-based architecture. Indeed, servers both limit the scalability of the games and increase deployment costs. However, they make it easier to control the game (e.g. by preventing cheating and providing support for billing). Peer-to-peer, i.e. transfer of the game functions on each each player’s machine, is an attractive communication model for online gaming. We investigate here the challenges of peer-to-peer gaming, hoping that this discussion will generate a broader interest in the research community.

Today, millions of players are connected to several online gaming communities [1]. World of Warcraft1 is an impressive example of online game success: more than 6, 000, 000 players pay monthly fees to play in this Virtual World, 500, 000 players being connected at any time. These numbers are expected to grow in the future. Most online games rely on a central server or a cluster of servers. Such architecture allows to easily handle tasks like players’ access control, management of the states of the game, synchronization of players, as well as billing.

These drawbacks, the high cost of a centralized solution, as well as the players frustration in front of under-provisioned systems and long delays are strong incentives to investigate alternative decentralized peer-to-peer solutions. Indeed, a peer-to-peer architecture strongly reduces deployment investment: there is no need to physically deploy important resources, and all players can benefit from the shared resources (storage, CPU and bandwidth) making the architecture scalable. Moreover, peer-to-peer is by nature more robust as there is no single point of failure. Consequently, the architecture does not fail a priori if any of its members leaves the game (gracefully or because of a crash/disconnect). Last, a peer-to-peer network can organize itself very easily to optimize the delay among peers.

While peer-to-peer gaming architectures are promising, they yield a lot of challenging research topics. In particular, questions are raised about distributed storage, management and consistency of the game states, election of the peers to communicate with, optimization of delays, synchronization of players and protection against cheating. To our knowledge, little work has been done in this area (see related work, section 3), especially considering large scale games with possibly millions of players.

Defining a Non-Authoritative Game

A non-authoritative multiplayer game has no central entity to control the game state, so every peer must control its own game state, communicating any changes and important actions to the others. As a consequence, the player sees two scenarios simultaneously: his ship moving according to his input and a simulation of all other ships controlled by the opponents:

The player’s ship’s movement and actions are guided by local input, so the player’s game state is updated almost instantly. For the movement of all the other ships, the player must receive a network message from every opponent informing where their ships are.

Those messages take time to travel over the network from one computer to another, so when the player receives an information saying an opponent’s ship is at (x, y), it’s probably not there any more – that’s why it’s a simulation:

In order to keep the simulation accurate, every peer is responsible for propagating only the information about its ship, not the others. This means that, if the game has four players – say A, B, C and D – player A is the only one able to inform where ship A is, if it got hit, if it fired a bullet or dropped a bomb, and so on.  All other players will receive messages from A informing about his actions and they will react accordingly, so if A’s bullet got C’s ship, then C will broadcast a message informing it was destroyed.

As a consequence, each player will see all other ships (and their actions) according to the received messages. In a perfect world, there would be no network latency, so messages would come and go instantly and the simulation would be extremely accurate.

As the latency increases, however, the simulation becomes inaccurate. For example, player A shoots and locally sees the bullet hitting B’s ship, but nothing happens; that’s because A’s view of B is delayed due to network lag. When B actually received A’s bullet message, B was at a different position, so no hit was propagated.

Leave a Reply

Comment
Name*
Mail*
Website*