October 8, 2010

Delivering User-Generated Content (UGC) in Massively Multiplayer Online Games (MMOG)


A recent series of interviews of gamers conducted by i2media has revealed that the motivations for playing MMOG are a mix of boredom, challenge, relaxation and socializing. This result confirms the results of previous studies on the same topicThe latter point -- gaming for socializing -- has motivated the CNG project (a EU-funded project I am involved in). Indeed, the tools that enable socializing in a game without "alt-tabbing" are rare (Playxpert and Xfire)In the CNG project, we aim at developing tools that allow gamers to share User-Generated Content (UGC). The interviews have revealed that three scenarios are especially expected by players of MMOG:
  1. a player broadcasts live screen-captured video of its game to any other player (in order to show off)
  2. a player streams live screen-captured video of its game to a restricted group (typically a guild)
  3. a player streams animated virtual 3D objects. The “clients” are players whose virtual position is close to the virtual position of the object.
The owner of the game is in charge of managing the "game server", which ensures the consistency of the game, and delivers the content on time. The management of the UGC is definitely not its concern. Here I come: and if the in-game UGCs are delivered in a peer-to-peer fashion? Neither cost, nor responsibility, the peer-to-peer architecture is quite attractive here.

Basically, the gamers' demand can be meet by implementing peer-to-peer live streaming systems in the game, which is a topic that has already been extensively studied. However, there are some specificities.
  • the diffusion of one live video stream requires that every peer receiving the video contributes with some physical resources. A peer that receives several videos will eventually reach its limits. In the scenarios 1 and 2, avoiding congestion at a peer is not difficult: it is enough to not authorizing a almost-congested peer to receive a video. For the scenario 3, the congestion management is more tricky: a player that is unfortunately too near from several UGC objects may experience congestion. Our idea is to revisit the concept of area of interest (AoI).
  • the game is the main motivation for the gamer, the socialization is an option. This is also true for the computing resources: the bandwidth, the CPU and the memory must always be reserved in priority to the game. In other words, the peer-to-peer video streaming system should be friendly to the other applications running on the computer of the end-users. Many classic solutions, including the ones based on Random Linear Coding, are immediately rejected because of their resource consumption. Our idea is to use rateless coding.
  • the live video should be delivered at about the same time for all players, especially in the scenario 3 where two players in the same region should see the same object in about the same shape. Our ideas are here still unclear.
All in all, the CNG project has good chances to be exciting. At least, it represents a good opportunity to tackle not-so-artificial challenges and to implement our solutions in real systems.

No comments:

Post a Comment