Multiplayer computer games, mobile phones and beyond

Transcription

Multiplayer computer games,
mobile phones and beyond
Michel Simatic
CSC5004
January 16th, 2009
Outline
1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Main constraints brought by video games. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
4 Peer-to-peer architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5 Client-server architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6 Server-network architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7 Mobile games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8 Pervasive and ubiquitous games. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
9 Game communication middlewares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
TELECOM SudParis — Michel Simatic — January 16th, 2009 — CSC5004
2/106
1 Background
1.1 About the speaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3/106
1 Background
1.1 About the speaker
¥ Worked for Alcatel from 1990 to 2002
¥ Since 2002, lecturer-researcher at TELECOM & Management SudParis
¥ Research on video games on mobile phones.
¨ Former leader of JEMTU project
I Goal: Contribute to platforms for games on mobile phones following a technological axis and
a usage axis
I 11 researchers from Institut TELECOM
I Support by TELECOM Foundation (Alcatel-Lucent, BNP Paribas, Orange and SFR)
I Dates: 01/01/2006 - 31/12/2008
¨ Co-leader of PLUG project
I Goal: Study embedded technologies to develop pervasive and ubiquitous games and their
acceptability form a socilogical, culturaln economical and industrial point of view
I 4 academics, 3 industrials and 1 museum
I Support by ANR
I Dates: 01/01/2008 - 31/12/2009
¨ Collaboration with CNAM and ENJMIN
¨ Member of Video games workgroup of Cap Digital industrial pole
4/106
2 Introduction
2.1
2.2
2.3
2.4
Few figures about video game industry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
What makes multiplayer game such an interesting distributed application . . . . . . . . 10
Different types of games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Two levels of functionalities in multiplayer games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5/106
2 Introduction
2.1 Few figures about video game industry
¥ In 2007 [Ducourtieux, 2007]
¨ World (USA + Europe + Japan)
I Software: 20,7 billion €
Consoles:
51,7%
Portable Consoles:
18,8%
PC:
17,8%
On-line:
5,8%
Mobile phones
5,3%
I Consoles: 9,8 billion € (5,6 billion € for non-portable consoles)
I Total is at the same level as music industry
¨ France
I Total = 2,4 billion € (+ 65% compared to 2006)
I In 2007, 23% of French families bought a video game product (+ 5%) for an average cost of
400 €(+ 27%) [Agence Française pour le Jeu Vidéo (AFJV), 2008c]
¥ In S1 2005, French sales podium [Agence Française pour le Jeu Vidéo (AFJV), 2006]
1. Game Gran Turismo 4: 19 million €
2. DVD Shrek 2: 16 million €
3. CD Les enfoirés: 15 million €
4. Book Da Vinci Code: 11,8 million €
6/106
2 Introduction
Few figures about video game industry (2/4)
¥ Casual game revolution
¨ Aging seasoned gamers do not have enough time budget left to play Diablo, Warcraft,
Heroes of Might and Magic. . . But they still want to play [Michaud, 2008]
¨ People play at work [Renou, 2008]
⇒ Akinator, Monlegionnaire, World of Goo. . .
¨ In 2008, casual games = 1/3 of gaming revenues (9,2 B€)
¥ The free to play revolution [Events, 2008]
¨ 2 B$ with games which are free to play (but you must buy contents)
⇒ Runescape (70 M$ revenues), Club Penguin (for 8–12 years old), Battlefield Heroes. . .
¨ Average Revenue Per User (ARPU)
I 1$ for free players (thanks to advertising)
I 15$ for paying users
I >100$ for big spenders
¨ How much does it cost you to get customer’s payment?
I PayPal: 5%
I Prepaid card: 20%
I Cell phone: 65%
¨ Web games will become mainstream (like TV became mainstream way ahead cinema)
7/106
2 Introduction
¥ Distribution of skills in a development team [Capital Games et al., 2006]
¨ Programming: 41 %
¨ Animation: 28 %
¨ Game/Level Design: 11 %
¨ Project management: 8 %
¨ Administration: 12 %
¥ In 2007, in France [Maman, 2007]
¨ 330 companies concerned
I 114 development studios
I 64 editors
I 28 middleware producers
I 23 distributors and hardware specialists
¨ 2.000–2.500 full-time jobs
¨ Around 8 employees per actor
¨ Since 2005, number of created start-up increased by 55%
8/106
2 Introduction
¥ What about multiplayer games? [SirBruce, 2007]
9/106
2 Introduction
2.2 What makes multiplayer game such an interesting
distributed application
¥ A multiplayer game is a distributed application, i.e. a set of autonomous machines
which are communicating and make the game application evolve by exchanging
messages [Natkin, 2002]
¥ Compared to classical distributed applications, multiplayer games have constraints
which are:
1. Classical: Consistency, deployment. . . Thus we reuse classical solutions
2. Original: Reaction time, number of players (users), security. These require
specific solutions
Note: These problems are similar to the problems observed in distributed
simulation applications and collaborative applications (e.g. e-learning)
¥ Mobility of terminals introduces additional constraints
10/106
2 Introduction
2.3 Different types of games
¥ Classification based on [Saha et al., 2002, Nokia, 2003a]
¥ First-Person Shooter (FPS)
Player has a gun and must fulfill a mission (either alone or within a team)
Examples: Quake, Counter Strike. . .
¥ Simulation
Player controls a team (football, hockey) or pilots an engine
Examples: FIFA, Collin Mac Rae. . .
¥ Massive Multiplayer On-line Role Playing Game (MMORPG)
Player controls an avatar in a virtual world
Examples: World Of Warcraft (WoW), Dark Age of Camelot, Lineage (180.000
simultaneous players). . .
11/106
2 Introduction
Different types of games (contd)
¥ Real-Time Strategy (RTS)
Player controls an army dealing with enemies
Examples: Age of Empire, Command and Conquer. . .
¥ Tour-based games
¨ Each player plays one after the other (chess, poker, Heroes. . . )
¨ Player gives its orders to a server during a game turn. Then the server solves all
of the movements
12/106
2 Introduction
2.4 Two levels of functionalities in multiplayer games
¥ One must provide 2 levels of functionalities in multiplayer games
¨ Customer management level
I Managing and animating the community of players
I Access portal (e.g.: http://www.goa.com)
I Forums
I High score storage
I Game downloads (e.g.: http://www.metaboli.fr or http://www.gallery.fr)
NB: Eventually all games will be downloaded (e.g. TMNations 500 MB,
Facade 800 MB. . . )
¨ Middleware level
I Communication and synchronization between the different modules of the
game
¥ Although “the game is 2% of the effort, the rest is customer
management. . . ” [Events, 2008], this presentation concentrates on middleware level
after describing the problems brought by games to this level
13/106
3 Main constraints brought by video games
3.1
3.2
3.3
3.4
3.5
Building a consistent state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Fault tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
14/106
3.1 Building a consistent state
¥ At the same time, two computers may have different view of the current state
because [Natkin, 2002]
¨ Message propagation time is not bounded
Example : Car race [Pantel and Wolf, 2002a]
¨ Messages can be lost
Example : Why a dead man may be able to shoot [Mauve, 2000]
¥ The virtual universe has its own measure of time. Thus, even though current
date/time can be different on the different copies of the game, these copies must
handle the commands at the same virtual date/time.
15/106
3.2 Performances
3.2.1
3.2.2
3.2.3
3.2.4
Bandwidth usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
CPU required to handle messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Taking into account latency and jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Fairness requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
16/106
3.2 Performances
3.2.1 Bandwidth usage
¥ Corresponds to the quantity of used network [Smed et al., 2001, Natkin, 2002]
¥ Seems not to be a problem anymore in fixed network (LAN, ADSL)
although. . . There are still some 56 kbps modems
¥ May be a constraints in mobile networks
Example: I-Mode specifications require application size to be lower than 30 Kb (in
order to limit download time). Note: This limit is a marketing limit
17/106
3.2 Performances
3.2.2 CPU required to handle messages
¥ [Bauer et al., 2002] reminds that it is not the used bandwidth which is the major
constraints with network messages, but:
¨ Used CPU cycles
¨ Memory bandwidth
¨ Volume of input-output
used to handle the arrival of each message
¥ A farm cannot handle more than 100.000 HTTP requests per second
[Bauer et al., 2002]
¥ Network traffic generated by a distributed application handling 100.000 objects can
require up to 80% of the CPU of a 500 MHz processor [Smed et al., 2001]
¥ In Google platform, 15.000 PC handle. . . 2.000 requests per second
18/106
3.2 Performances
3.2.3 Taking into account latency and jitter
¥ Latency = Response time between a command and the materialization of its effect on all
computers of players [Natkin, 2002]
¥ Jitter = Variance of latency during time [Smed et al., 2001]
¥ Latency (and jitter) are inherent to networks:
¨ Internet
I Atlantic crossing w 80 ms (theoretical limit > 25 ms) [Smed et al., 2001]
I Most important German ISP: 342 ms [Pantel and Wolf, 2002a]
I Depends upon the number of crossed routers/providers [Bauer et al., 2002]
¨ Wireless Area Networks (WAN)
[Nokia, 2003a, Chakravorty et al., 2002, Jouglet and Colin, 2005, Koivisto, 2007]
GPRS (2G)
EDGE release 4 (2,5G)
UMTS (3G)
HSDPA (3G+)
Throughput (in kbps)
Latency (in ms)
∼ 40
500
100 − 200
< 500
384
300
1000 − 3000
100 − 300
19/106
3.2 Performances
Taking into account latency and jitter (contd)
¥ Constraints on latency/jitter depends upon the game
¨ FPS: latency < 100 ms [Smed et al., 2001]
¨ Car race: latency may go up to 150 ms (cockpit view) [Pantel and Wolf, 2002a]
¨ RTS: latency may go up to 500 ms as long as jitter remains low [Bettner and Terrano, 2001]
¨ To summarize for a mobile environment [Nokia, 2004]
¥ See [Claypool and Claypool, 2006] for a more recent study
¥ “A game can be considered playable if its users find its performance acceptable in terms of the
perceptual effect of its inevitable inconsistencies” [Brun et al., 2006]
20/106
3.2 Performances
3.2.4 Fairness requirement
¥ Some games based on bids, bets or quiz (e.g. Questions for a champion where the
player must press his buzz before his competitors) require guarantees concerning
fairness of latency despite
¨ Differences in performance of the terminals
¨ Differences in performance concerning access to the network
¥ This requirement does not influence the architecture. It requires another software
layer to introduce delivery delays
¥ This is still a research subject
¨ Fair message exchange framework [Guo et al., 2003]
¨ It is always possible to increase the level of inconsistency in a game by artificially
delaying information. This technique enables the equalization of inconsistencies
among players, effectively improving game fairness at the cost of overall
playability. [Brun et al., 2006]
21/106
3.3 Scalability
¥ Game architecture must be able to [Natkin, 2002]
¨ Reconfigure dynamically itself according to the number of players
¨ Accept an important number of players
22/106
3.4 Fault tolerance
¥ Keep the service available despite failure of some of the elements [Natkin, 2002]
23/106
3.5 Security
¥
¥
¥
¥
¥
Classification according to [Natkin, 2002]
Players authentication
Protection in terms of confidentiality and integrity
Protection of author rights
Respect of game rules [Smed et al., 2001]
¨ Motivated by a vandalism or domination spirit, some players cheat
¨ Protections must be put in place to make cheating as difficult as possible
¨ Cheating techniques:
I Packet and traffic tempering
I Information exposure
I Design defects
I Collusion
¥ In the remainder, we will focus on this last aspect (specific to games)
24/106
4 Peer-to-peer architecture
4.1
4.2
4.3
4.4
4.5
4.6
4.7
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Using total order algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Interest management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Interest management and Content-based publish-subscribe. . . . . . . . . . . . . . . . . . . . . .33
Dead reckoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Consistency algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
25/106
4.1 Overview
¥ Principles [Natkin, 2002]
¨ Each terminal sends to all other terminals all of the commands executed by the player
¨ Each terminal has a full copy of the game. It computes the current state of an
on-going game thanks to the received messages
¥ Examples
¨ Age of Empire [Bettner and Terrano, 2001]
¨ Six in the City [Mitchell et al., 2003]
¥ Comments
¨ Architecture well-adapted to local networks because they allow to quickly broadcast a
message
¨ But it is also used in the case of terminals connected through Internet (mostly for
games allowing a high latency)
¨ It is used by a lot of games because it is a natural extension of the monoplayer version
of a game (except for the problem of random events [Bettner and Terrano, 2001])
26/106
4.2 Evaluation
¥ Building a consistent state
There is no central reference: A synchronization mechanism must be put in place
between the different replicas
⇒ ¨ “Consistency algorithms” (Algorithmes de cohérence)
¨ “Total order algorithms”
¥ Bandwidth usage
¨ Requirements are low if number of players is low [Pantel and Wolf, 2002a]
Example : MiMaze game broadcasts 52 bytes per player with a frequency of 25
Hz ⇒ 52 × 8 × 25 ' 10 kbps [Gautier and Diot, 1998]
¨ If bandwidth is too low (e.g. Internet access through modem), the game must
limit the number of messages sent
⇒ ¨ “Interest management” (Filtrage sémantique) possibly coupled with
“Content-based publish-subscribe”
¨ “Dead reckoning” (Prévision d’état)
27/106
Evaluation (2/3)
¥ CPU required to handle messages
Game must limit number of messages sent (so that there is still CPU to handle
processing related to the game)
⇒ Same solutions as Bandwidth usage
¥ Latency and jitter
⇒ ¨ “Dead reckoning” (Prévision d’état)
¨ “Consistency algorithms” (Algorithmes de cohérence)
¥ Scalability
¨ Limited by CPU required by the least powerful machine to handle messages
[Bettner and Terrano, 2001]
¨ Thus at most few dozens of players for FPS
¥ Fault-tolerance: OK
28/106
Evaluation (3/3)
¥ Security
¨ Packet and traffic tempering cheating techniques: KO
¨ Information exposure
I A terminal can multicast its messages only to terminals concerned by the
changes in its instance of the game
⇒ Content-based publish-subscribe algorithms
¨ Design defects: KO
29/106
4.3 Using total order algorithms
¥ Problem: Prevent consistency problems between the different game replicas
¥ Solution: Use a total order algorithm
¨ Any broadcast message is received in the same order by all of the replicas
¨ Example: Arrow multicast [Herlihy and Mohan, 2003]
30/106
4.4 Interest management
¥ Problem: Limit the number of messages sent by the different terminals
¥ Solution overview [Smed et al., 2001]
¨ It is not necessary to send to each player a copy of all of the actions of other
players
¨ You only need to consider the part of the universe the player can observe and
which it can influence
¨ Game engine can determine the set of objects perceptible by player’s avatar (via
seeing, hearing or touching) = Focus
¨ Game engine can also determine the space within which an object can be
perceived = Nimbus
¨ Messages must be exchanged between players A and B if and only if there is an
intersection between one’s focus and the other’s nimbus
31/106
Interest management (contd)
¥ Example of a hide-and-seek game
32/106
4.5 Interest management and Content-based publish-subscribe
¥ Interest management can be coupled with Content-based publish-subscribe
¥ Content-based publish-subscribe: What’s that?
¥ Example of Mercury [Bharambe et al., 2002]
¨ Have a subscription language as flexible as Gryphon or Siena
¨ Be as scalable as Herald or Scribe
Problems close to the ones observed in “Semantic P2P”
33/106
4.6 Dead reckoning
¥ Problem: Limit the number of messages sent by the different terminals
¥ Solution overview [Pantel and Wolf, 2002b]
¨ A player broadcasts the position and speed vector of its avatar
¨ It broadcasts again these information only in the case they have changed
significantly
¨ Upon receiving this message, the other players take into account this new
position for the avatar copy they hold and memorize the speed vector
¨ From then on, they move, by themselves, the avatar copy using the speed vector
34/106
4.7 Consistency algorithms
¥ Problem: Dead reckoning may lead to inconsistencies
¥ Please refer to [Chabridon and Kodrnja, 2005, Khan et al., 2007] for overview of
solutions
35/106
5 Client-server architecture
5.1
5.2
5.3
5.4
5.5
5.6
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Use farms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Add intelligence to the network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Dynamic multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Example of an architecture: EVE Online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
36/106
5.1 Overview
¥ Principles [Natkin, 2002]
¨ Game is running on a central site (the game server) which receives all of the
commands of all of the terminals of the players (the clients)
¨ Server does all of the computation (except aspects related to graphics and
sounds)
¨ It returns the result to all of the terminals
¥ Examples
¨ Quake
¨ Dark Age of Camelot
¨ Samuraï Romanesque [Potel, 2003]
¨ TibiaME [Nokia, 2003b]
¥ Comments
¨ Architecture well-adapted to Internet network where there is no broadcast
capability
¨ Natural architecture in the case of games based on a virtual world
37/106
5.2 Evaluation
¥ Building a consistent state: As the server is the reference, one could think there is
no consistency problems. But there are. . .
¥ Bandwidth usage
¨ Low on client side
¨ Can reach saturation on server side (because of CPU)
38/106
Evaluation (2/4)
Server = Bottleneck
Example : Quake
⇒ ¨ Interest management
¨ Dead reckoning
¨ Use computer farms (example: Quake on a grid)
¨ Add intelligence to the network
¨ Dynamic multicast
Additional latency can be introduced because of the number of messages handled by
the server (see previous point)
39/106
Evaluation (3/4)
¥ Scalability
Server = Bottleneck (example, in TibiaME MMORPG, 1.000 players per server)
⇒ ¨ Increase number of servers, each one handling its own instance of the virtual
world (and each player being affected to a given server, once for all)
¨ Share the management of the virtual world between different machines (each
player migrating from one machine to another according to his position in the
virtual world)
¨ Use “server network” architecture
¥ Fault-tolerance
Server = Bottleneck
⇒ ¨ Use computer farms
¨ Use fault-tolerant servers
¨ Use “server network” architecture
40/106
Evaluation (4/4)
¥ Security
¨ Packet and traffic tempering cheating techniques
Installation, on the server side, of code checking consistency of information sent
by the client
¨ Information exposure
Server sends only relevant information to the different clients (see last versions of
Quake)
¨ Design defects
Installation, on the server side, of code checking consistency of information sent
by the client
Example : “Runtime verification” (e.g. evaluate how fast a player earns
money [DeLap et al., 2004])
41/106
5.3 Use farms
¥ Problems:
¨ On the server side, cope with CPU requirements
Example: An MMORPG with 100.000 players would lead to a traffic of 200
transactions per second on a database
¨ Do it dynamically so that unused resources can be shared with other games
¥ Solution: Use a farm
¥ Example of product (project?) Butterfly [Butterfly.net and IDC, 2003]
¨ Cluster of 50 IBM eServer
¨ Interconnection with high speed optical links
¨ Cluster management with Globus
¨ A player is transparently affected to one of the eServer s
¨ DB2 database with mechanism for migrating data concerning a player from one
eServer to the other
42/106
5.4 Add intelligence to the network
¥ Problem: Reduce traffic handled by the server
¥ Solution: Add booster box es to do that as soon as possible [Bauer et al., 2002]
¨ Cache management: Booster box caches non real-time information and answer
for the server
¨ Aggregation: Events of 2 (or more) clients are aggregated in a single message
¨ Intelligent filtering: depending on the game state, some events may be no more
significant. Booster box filters them
¨ Intelligent routing: If server is distributed on several machines, booster box
forwards a message to the concerned machine
Booster box is a configurable router adapted to some games
43/106
5.5 Dynamic multicast
¥ Problem: Reduce traffic handled by the server
¥ Solution = Dynamic multicast (Arbre de multicast) [Ramakrishna et al., 2003]
¨ All of the nodes are linked together according to a tree structure
¨ Each node is either parent for other nodes (its children) or a leaf
¨ Server is the root of the tree
¨ Each node sends its messages to its parent. This parent aggregates messages
from its different children before forwarding them to its own parent
¨ Messages issued from the server follow the reverse path
¥ Experience on DOOM with 8 players
# packets sent out by players
# packets in the network
P2P
client-server
Dynamic multicast
56
16
8
207
40
26
44/106
5.6 Example of an architecture: EVE Online
¥
¥
¥
¥
¥
¥
¥
400 GHz CPU / 200 GB RAM [Brandt, 2005]
2 Routers (CISCO Alteon)
14 Proxy servers (IBM Blade)
55 Sol servers (IBM x335)
2 DB servers (clustered, IBM Brick x445)
FastT600 Fiber, 56 x FC 15k disks, DS4300 + 3*EXP700
Windows 2000, MS SQL Server
45/106
6 Server-network architecture
6.1
6.2
6.3
6.4
6.5
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Mirrored server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Zone server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Generic Proxy System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
46/106
6.1 Overview
¥ Principles [Smed et al., 2001]
¨ In this architecture, several servers are interconnected
¨ A client is connected to a given server. This server is communicating with all
other servers and thus all of their clients
¥ Examples (research field)
¨ Quake with mirrored servers [Cronin et al., 2002]
¨ Zone-server [Riera et al., 2003]
¨ Generic proxy system [Mauve et al., 2002]
¥ Comments
¨ Servers work according to a P2P architecture
¨ A client works with its server according to a client-server architecture
client-server
47/106
6.2 Evaluation
¥ Building a consistent state
¨ See client-server for client-server part
¨ See P2P for P2P part
¥ Bandwidth usage
¨ On client side: Limited
¨ On servers side: Distributed
Load distributed among servers
¨ Better than client-server (client is nearer its server)
¥ Scalability
Load distributed among servers
48/106
Evaluation (contd)
¥ Fault-tolerance
¨ If one server stops, game is over for its clients (papers propose solutions to
migrate this clients)
¨ But game goes on for majority of players
¥ Security
Better than client-server (The servers are less loaded. Thus more controls can be
put in place)
49/106
6.3 Mirrored server
¥ In this architecture [Cronin et al., 2002], servers are interconnected with a private
high-speed network dedicated to data exchange between them
¥ Inconsistencies are handled with TSS algorithm
50/106
6.4 Zone server
¥ This architecture is dedicated to mobile terminals [Riera et al., 2003]
¥ Several terminals have the role of zone server (there must be at least 2 zone servers
for fault tolerance)
¨ They serve terminals which are plain clients
¨ They synchronize with other zone servers in case of connectivity loss with a client
¨ A Zone server receives data from its own client and transmits them to other
Zone Server (There is no consistency mechanism, but authors believe TSS
algorithm could be a good answer)
¥ Future work = Selection of the different Zone servers
51/106
6.5 Generic Proxy System
¥ In this architecture [Mauve et al., 2002], a central server is responsible for keeping
the game state
¥ It is working with several proxy to whom it delegates some of its functions
¥ A client connects to the server or to one proxy
¥ When a proxy receives a message from a client, it forwards it to the server and the
other proxies
¥ This architecture improves
¨ Congestion control
¨ Robustness
¨ Latency
¨ Equity
¨ Security (as more controls can be done)
¥ Research subject: Adapt this architecture to an environment with mobile terminals
52/106
7 Mobile games
7.1
7.2
7.3
7.4
Few figures about mobile game industry (1/3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Key issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Example of a mobile multiplayer game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Architectures for mobile games. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
53/106
7 Mobile games
7.1 Few figures about mobile game industry (1/3)
¥ Console game = 50 $ versus Mobile game = 5-7 $
¥ Development: Console game in M$ versus Mobile game = 100-400 k$
¥ Huge number of potential customers
¨ Game consoles: Gameboy, Nintendo DS (On 31/12/2007, 68m units since end 2004), N-Gage,
PSP (on 31/12/2007, 25m units sold since end 2005). . .
¨ PDA (20m units sold in 2007)
¨ Mobile phones (1.100m units sold in 2007)
¥ Prediction that mobile games could generate 11.2 billion $ by 2010 [Patterson and Dredge, 2006]
¥ Other study [Clech, 2007]: +50% in 2006 with:
2007
2011
Asia
1,8 B$
4,6 B$
Europe
1,5 B$
2,0 B$
USA
0,7 B$
1,7 B$
Total
4,3 B$ 10,0 B$
¥ April 2005: Jamdat bought Tetris rights for 15 years for 137 million $ (3Q04, Tetris = 4,1 million $
revenues) [Patterson and Dredge, 2006]
¥ “Times will be hard for small mobile game developers in the near future” [Koivisto, 2007]
54/106
7 Mobile games
Few figures about mobile game industry (2/6)
¥ In France, in 2006 [Séfrin, 2007]:
¨ 10 Million downloads of games
¨ 3–5 € per game
¨ About 300 games offered by 50 editors
¨ 46 % of gamers are female
¨ Contents market = 500–700 M€ (to be compared to 20 B€ of voice market. . . )
¨ 51,7 Million customers
¨ 500.000 Orange customers watch mobile TV (43 minutes/month/subscriber)
¨ Orange launched http://www.ticket-game.com
¥ [Agence Française pour le Jeu Vidéo (AFJV), 2008a] synthetizes French 2007 sales for mobile
contents:
Units (in Million)
Sales
Games
13,3
56,7 M€
Videos
6,0
15,6 M€
Images
20,0
56,0 M€
Ringtones
22,0
54,4 M€
Full Track Music
15,9
19,0 M€
55/106
7 Mobile games
¥ Mobile game sales could be a lot better [Morrisson, 2008]
56/106
7 Mobile games
¥ Top 10 2007 best mobile games sales (in France)
[Agence Française pour le Jeu Vidéo (AFJV), 2008a]
Rank
Title
Editor
1
Tetris
Electronic Arts
2
Block Breaker Deluxe
Gameloft
3
The Sims 2
Electronic Arts
4
Brain Challenge
Gameloft
5
Worms Forts
THQ Wireless
6
Deal or not deal
Gameloft
7
New York nights: Success in the city
Gameloft
8
Desperate Housewives
Gameloft
9
Pac-Man
Namco
10
The Simpsons: Minutes to meltdown
Electronic Arts
¥ Mobile is very well adapted to casual gaming [Michaud, 2008]
57/106
7 Mobile games
¥ [Koivisto, 2007] shows that:
¨ 60% gamers play at home
¨ 60% gamers play more than once a week
¨ Average play session = 15–28 minutes
¨ 45% of mobile game players play multiplayer mobile games at least once per
month ???
58/106
7 Mobile games
¥ Mobile game value chain [IGDA Online Games SIG, 2005]
59/106
7 Mobile games
7.2 Key issues
¥ Unlimited data plan [Michaud, 2008]
¥ Make download really easy
¥ Operator is too strong
¨ Low quality of games
¨ Little development of multiplayer games
¥ Portability
¨ Around 700 different mobiles available in the world
¨ For Prince of Persia, Gameloft made 100 different porting
¨ Gameloft has 2.000 people. 80-90 % are working on porting
Solution = MIDP3? Brew? Wipi? Doja?
¥ Other aspects (FYI)
¨ Limited capacities of virtual machines (e.g. threads)
¨ Limited energy resources [Mascolo et al., 2002, Nokia, 2007]
¨ Limited screen size [Nokia, 2003a], but display could be on a big screen [Rodriguez et al., 2008]
¨ Screen size varies widely [Palm, 2003]
¨ Colors and sounds are limited [Nokia, 2003a]
¨ Input interface is limited [Nokia, 2004], but dedicated devices like Zeemote
[Zeemote Inc, 2009], touch screens [Agence Française pour le Jeu Vidéo (AFJV), 2008b] and
accelerometers may reduce this limit
¨ Deployment [Rawat and Simatic, 2007]
60/106
7 Mobile games
7.3 Example of a mobile multiplayer game
¥ TibiaME (Q2 2003) [Nokia, 2003b]
¥ German adaptation to mobile phone of PC MMORPG
¥ Main challenges: Size (150 KB to download and 390 KB RAM), Latency (up to 4
seconds) and User Interface
¥ Server side: 90% of PC version code (C-C++/Linux) reused (it was already based
on 2D sprites). Uses a PostgreSQL DB
¥ Client-side: Developed from scratch for C++/Symbian OS client-side
¥ Development = Team of 5 people in 6 months.
¥ 1 server handles 1.000 players
61/106
7 Mobile games
Example of a mobile multiplayer game (2/3)
¥ Business model (in 2003) [Nokia, 2003b]
¨ No cost to acquire the client application and no monthly subscription fee
¨ Users pay for the data traffic they create over (T-Mobile’s) GPRS network.
Typical player generates traffic 400 KB/hour ⇒ costs 0.72-3.7 € depending on
deal with network provider.
¨ Game provider has a three-level hierarchy of >100 volunteer game masters and
game counselors, allowing continuous online support.
¥ In 2008 [CipSoft GmbH, 2008]
¨ Premium access subscription costs 9,99 € for 4 months
¨ Episodes are available (30–60 minutes playing time)
62/106
7 Mobile games
Example of a mobile multiplayer game (3/3)
¥ More information on 2008 version [Zuckerer, 2008]
¨ About 3.500 active Premium subscribers and about 20.000 active players altogether.
¨ About 18 simultaneous gameworlds, each capable of having 250 players online at the same
time.
¨ Can go up to over 1000 players per server (Xeon systems [2 CPUs with 2,0 Ghz] with 2 GB
RAM). The reason for the low amount is that the game feels crowded on the mobile phone
with this amount of players. The screen size is small and a few players just fill up a city very
quickly. CipSoft is constantly adding new content to the game to relax the situation and will
eventually lift up the player capacity.
¨ On 24h average, 1.850 simultaneous players over the 18 worlds.
¨ Statistics on countries from where people are playing TibiaME
Most of players come from Brunei, Russia, Poland and Indonesia. The strong regions on the
market are in Far-East Asia and East Europe. Countries with cheap mobile internet access
usually have a high interest in playing the game.
¨ Most of players play more than 4 hours in average per day.
¨ Development team
“As we also work on our main product Tibia (PC-Game) some people work on both teams. The dedicated
TibiaME team has got 5 people working on it. At the moment we are pushing new features and the
development of the game in general. We have got two big updates every year, adding new content and new
features to the game. Between the updates we publish small content episodes for the players.”
63/106
7 Mobile games
7.4 Architectures for mobile games
¥ Peer-to-peer
¨ Well adapted to consoles and PDA (or even mobiles on WLAN), because limited
number of terminals (typically 8) and oad sharing
¨ Not realistic for mobiles on WAN (client/server communications are mandatory!)
¥ Client-server
¨ No load sharing as with Peer-to-peer
¨ Natural architecture with Bluetooth networks and mobiles on WAN
¥ Server-network
¨ Sounds interesting!
Imagine to have several mobiles connected with Bluetooth, one of these mobiles,
the zone server, being connected to the server via WAN
64/106
8 Pervasive and ubiquitous games
8.1
8.2
8.3
8.4
8.5
8.6
Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Product examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Research examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Zoom on “Plug: Secrets of the Museum” (PSM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Business and revenue issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Specific technical issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
65/106
8.1 Definitions
¥ Pervasive game = Game enriched with computing and communication technologies
in order to combine transparently physical and numerical spaces of the
player [Schneider and Kortuem, 2001]
¥ Ubiquitous = Game which can be played anywhere [Schneider and Kortuem, 2001]
¥ ARG = Alternate Reality Games: Games where border between reality and game
universe is blurred [Le Bourlout, 2007]
66/106
8.2 Product examples
¥ In Memoriam - Le Dernier Rituel [Ubisoft, 2006]
¥ ViaTemporis [Scrinéo, 2005]
¨ 29 €
¥ REXplorer [Walz et al., 2006]
¨ 10.000 - 15.000 players per year
¨ Hardware renting for 1,5 hour
67/106
8.3 Research examples
8.3.1 Research examples in limited physical space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
8.3.2 Research examples in unlimited space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
8.3.3 Research examples with augmented reality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
68/106
8.3.1 Research examples in limited physical space
¥ “The Drop”: A spy game taking place in a commercial center [Smith et al., 2005]
¥ “Save the Princess!”: A D&D game taking place in an office (actually a demo game
for TinyLime) [Mottola et al., 2006]
¥ “Pac-Lan”: An arcade game taking place in a neighborhood [Rashid et al., 2006]
¥ “Plug: Secrets of the Museum”: A virtual card game taking place in a museum (see
zoom in slide 8.4).
69/106
8.3.2 Research examples in unlimited space
¥ BotFighters [PriXArs, 2005]
¥ Mogi [Licoppe and Inada, 2005]
¥ Conqwest [Qwest Communications International Inc., 2004]
70/106
8.3.3 Research examples with augmented reality
¥ Human Pacman [Cheok et al., 2003]
¥ ARQuake/Tinmith [UniSA, 2002]
¥ 3D Sky Vaders (A_RAGE: Augmented Reality Active Game Engine)
[A_RAGE Pty Ltd, 2005]
71/106
8.4 Zoom on “Plug: Secrets of the Museum” (PSM)
8.4.1 Presentation of PSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
8.4.2 Technical challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.4.3 Pre- and Post-experimental remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
72/106
8.4.1 Presentation of PSM
¥ Pre-product demo of PLUG project [Cédric et al., 2009]
¥ Designed to let players discover, in a different way, some of the objets of a
museum [Astic et al., 2009]
¥ Players are equiped with NFC-enabled mobile phones
¥ Museum is equiped with RFID tags located besides key objects of the museum
¥ Goal = Collect families of virtual cards associated to these key objects
¥ To do so, players exchange virtual cards either with the RFID tags or with other
players (through NFC peer-to-peer communication).
¥ PSM includes a hint function: It gives a player an indication of an RFID tag which
contains a virtual card interesting for his collection.
¥ PSM is currently implemented for 8 players and 16 tags in the context of the musée
des Arts et Métiers
¥ A PSM game session lasts 55 minutes
¥ Measures made during experiments showed that players take an average time of 90
seconds to move from one tag to another
73/106
8.4.2 Technical challenges
¥ Communications between mobiles are only local ⇒ There cannot be a central server
taking care of the game data
⇒ 5 technical challenges [Simatic, 2009]
1. At the beginning of a game session, all of the mobile phones must be initialized
with the virtual cards they are hosting
2. Each RFID tag must be initialized with the virtual card it is hosting
3. The hint function must be implemented
4. All playing mobiles must be notified of the end of a game session at the same
time
5. The game must tolerate faults concerning the game application on a mobile, a
mobile itself, and faults related to RFID tags
74/106
8.4.3 Pre- and Post-experimental remarks
¥
¥
¥
¥
¥
¥
Importance of in-game communications
Pedagogy versus Fun
Reaching consensus in the definition of player’s main goal
Environment design is capital
Have (qualified) usage people in your project to get correct feedback
Next sessions
¨ Futur(s) en Seine: 29/05/09 – 07/06/09
I 1 PI20 will contribute by developing a synthesis application
¨ PSM version 2: November 09
I With iPhones/iPod touch or Samsung Player Addict & Wiimote & biometric
sensors
I 1 PI20 is contributing to the game design
75/106
8.5 Business and revenue issues
¥ Elements from [Söderlund et al., 2005]
¨ Market structure: Towards pervasive advergaming
¨ Revenue model: Dominant model should be pay-per-use (games as services
rather than as products)
¨ Production process: Game release will be followed by numerous new releases;
This development forces game development companies to radically rethink their
production strategy.
¨ Marketing: What producer(s) of pervasive games want future consumers to
define as “pervasive games”?
76/106
8.6 Specific technical issues
¥ Context management in ubiquituous environment
¨ See Denis Conan’s presentation
¥ Developement tools
¨ mscape [mscape, 2007]
I Single player
I Only location-based (with GPS) games(/applications)
I Programming of “mediascapes”: A mediascape is a collection of media fragments
associated with positions in space. You experience the media fragments as you walk
around the space
¨ Open-MEE [Biswas et al., 2006]
¨ Tools of robotics community
I Microsoft Robotics Studio [Microsoft, 2008]
I Lego mindstorms NXT software [LEGO, 2008]
¨ Issue: Monolithic aspect of current Multiplayer Mobile Game
engines [Rawat and Simatic, 2007]
77/106
9 Game communication middlewares
9.1
9.2
9.3
9.4
Few examples of middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Core middlewares used by game communication middlewares . . . . . . . . . . . . . . . . . . . 81
Zoom on Darkstar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
Zoom on GASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
78/106
9.1 Few examples of middleware
¥ Open source
¨ Darkstar (see zoom in slide 9.3)
¨ GASP (CNAM-CEDRIC, Filao, INT) (see zoom in slide 9.4)
¨ MUPE [Suomela et al., 2005]
¨ Massiv [Massiv, 2005]
¨ Open NeL (Nevrax) [NeL community, 2009]
¨ ICE (ZeroC) [Henning, 2004]
¨ OpenTNL (Torque) [OpenTNL, 2007]
¨ Grizzly (Sun) [Sun Microsystems, 2009]
¥ Commercial products
¨ Neutron (Exit Games) [Exit Games, 2009]
¨ Terraplay (Terraplay) [Terraplay, 2003, Terraplay, 2002b]
¨ NetZ/Eterna (Quazal) [Quazal, 2009]
¨ SNAP Mobile (Nokia) [Nokia, 2009]
79/106
Few examples of middleware (contd)
¥ R&D products
¨ Continuum (FT R&D) [Dang Tran et al., 2003, Dang Tran et al., 2002]
¨ Skype4Games (University of Mannheim) [Triebel et al., 2007]
¨ Real-Time Framework/RTF (University of Münster in the context of
edutain@grid STREP) [Ploss et al., 2007]
80/106
9.2 Core middlewares used by game communication middlewares
¥ CORBA
¨ Continuum is using Jonathan (ObjectWeb) [Dang Tran et al., 2003]
¥ Message-Oriented Middleware (MOM/Publish-subscribe)
¨ Terazona uses a JMS-compliant MOM (C or Java interface) [Zona, 2002]
¨ Terraplay offers a MOM with reliable (or non-reliable) delivery, towards a
machine or a group, with dynamic subscription capabilities
[Terraplay, 2002b, Terraplay, 2002a]
81/106
9.3 Zoom on Darkstar
¥ Open Source Project [Waldo, 2008, Sun Microsystems, 2008]
¥ For games based on a client-server architecture
¥ Philosophy: Make server-side game code reliable, scalable, persistent, and fault-tolerant in a
manner that is transparent to the game developer.
¥ In Darkstar, clients can send messages [Sun Microsystems, 2007a, Sun Microsystems, 2007b]
¨ Directly to the server: Once connected to the server, each client has a dedicated
communication medium between server and itself
¨ Through a Communication channel
I A Communication channel is created by the server (which defines the name of this channel,
as a string)
I Server registers/unregisters clients, either spontaneously or following a client request
I Once a client is registered to a Communication channel, it receives any message sent to this
Communication channel by itself or another client
¥ The server includes an (persistent) “Object Store” based on “BerkeleyDB Java
Edition” [Oracle, 2008]
¥ Note: The multi-node version is not in the current release (which contains only the single-node
server)
82/106
9.4 Zoom on GASP
9.4.1 Java 2 Micro Edition (J2ME) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
9.4.2 Typical modelization of a multiplayer game on J2ME . . . . . . . . . . . . . . . . . . . . . . . . . 85
9.4.3 Standardization of multiplayer game platforms by OMA . . . . . . . . . . . . . . . . . . . . . . 86
9.4.4 GASP: Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
9.4.5 GASP: Data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
9.4.6 GASP: Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
9.4.7 GASP: Event model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
9.4.8 GASP: MooDS protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
9.4.9 GASP: MooDS versus SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
9.4.10 GASP: status and perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
83/106
9.4 Zoom on GASP
9.4.1 Java 2 Micro Edition (J2ME)
84/106
9.4 Zoom on GASP
9.4.2 Typical modelization of a multiplayer game on J2ME
1.
2.
3.
4.
Thread
Thread
Thread
Thread
Game logic execution
Paint
Keyboard event listener
Communication with the platform (game server)
85/106
9.4 Zoom on GASP
9.4.3 Standardization of multiplayer game platforms by OMA
¥ Games Services workgroup of Open Mobile Alliance (OMA) proposes a general
architecture and functional specifications [Open Mobile Alliance, 2007]
86/106
9.4 Zoom on GASP
9.4.4 GASP: Objectives
¥ Implementation, in Java, of OMA/GS specifications for games platforms
¥ Open Source
¥ Target
¨ J2ME mobiles, MIDP and Doja profiles
¨ Games with quick interactions (beyond turn by turn), despite http protocol over
WAN
¨ Small editors
¥ Take into account development constraints on mobile (code size, message size)
87/106
9.4 Zoom on GASP
9.4.5 GASP: Data model
88/106
9.4 Zoom on GASP
9.4.6 GASP: Architecture
89/106
9.4 Zoom on GASP
9.4.7 GASP: Event model
¥ 5 event types:
¨ JoinEvent ⇒ A new player joins the game
¨ StartEvent ⇒ Game start
¨ EndEvent ⇒ Game end
¨ QuitEvent ⇒ A player quits a game
¨ DataEvent ⇒ Data sent during game time by a player or server game logic
¥ 3 types of event listeners:
¨ ApplicationInstance (Game sessions)
¨ ActorSessions (The players)
¨ GASPServer (Interface extended by server game logic)
90/106
9.4 Zoom on GASP
GASP: Event model (contd)
91/106
9.4 Zoom on GASP
9.4.8 GASP: MooDS protocol
¥ MooDS = Mobile Optimized Objects Description & Serialization
¨ Goal: Improve communication speed by reducing size of messages exchanged in
game
¨ Algorithm: Transport game messages by value (primitive types)
92/106
9.4 Zoom on GASP
GASP: MooDS protocol (contd)
93/106
9.4 Zoom on GASP
9.4.9 GASP: MooDS versus SOAP
See [Pellerin, 2007] for more information
94/106
9.4 Zoom on GASP
9.4.10 GASP: status and perspectives
¥ GASP is an Open Source Java platform for multiplayer games on mobile
¥ Status
¨ Publication (ObjectWeb [Pellerin et al., 2007]) of GASPBT
¨ Publication of BomberGASP as demonstrator of GASPBT
¨ Publication of MooDS version 2.0
I Accelerate multiplayer game development (code generation)
I Management of several communication models: Unicast, multicast and broadcast
I Data persistency service
¨ uGasp
¥ Perspectives
¨ Cross-Platform: C# management (Interface MIDP, Doja, Flash and Windows Mobile
client in the context of the same game)
¨ Online/Bluetooth GASP: Development of a link between online and Bluetooth versions
(several groups of users will be able to play the same game)
¨ GASP for pervasive games: uGasp at ICPS & uGasp in “Plug: Secrets of the Museum”
version 2
95/106
10 Conclusion
¥ A multiplayer game is a distributed application with specific constraints:
consistency, reaction time, number of players (users), security. . .
¥ Use of mobile terminals amplifies these constraints or adds some new ones
(e.g..latency)
¥ Classical architectures are able to answer to these constraints
¥ But they must be completed with solutions (possibly specific to games): interest
management, dead reckoning, consistency. . .
¥ Multiplayer mobile games business will explode as soon as:
¨ The costs of playing become low ???
¨ Pervasive and ubiquitous games are more developed
¨ Flash is more and more available on mobile (Why not Runescape or MapleStory
on mobile? [Gamasutra, 2007])
96/106
Références
[Agence Française pour le Jeu Vidéo (AFJV), 2006] Agence Française pour le Jeu Vidéo (AFJV) (2006). Les jeux
vidéo : une industrie culturelle française. http://www.afjv.com/press0606/060613_dossier_etude_jeux_video.htm.
[Agence Française pour le Jeu Vidéo (AFJV), 2008a] Agence Française pour le Jeu Vidéo (AFJV) (2008a). Les
contenus multimédias pour téléphones mobiles ont le vent en poupe : près de six millions de français téléchargent !
http://www.afjv.com/press0805/080506_etude_telechargement_mobiles.htm.
[Agence Française pour le Jeu Vidéo (AFJV), 2008b] Agence Française pour le Jeu Vidéo (AFJV) (2008b). Les
téléphones « touch screen » peuvent-il doper le marché du multimédia mobile ?
http://www.afjv.com/press0811/081117_marche_mobile_touch_screen.htm.
[Agence Française pour le Jeu Vidéo (AFJV), 2008c] Agence Française pour le Jeu Vidéo (AFJV) (2008c). Près de 1
ménage sur 4 a acheté des jeux vidéo en 2007 selon NPD Group.
http://www.afjv.com/press0807/080717_etude_vente_jeux_video_2007.htm.
[A_RAGE Pty Ltd, 2005] A_RAGE Pty Ltd (2005). A_RAGE: Augmented reality active game engine.
http://www.a-rage.com/.
[Astic et al., 2009] Astic, I., Aunis, C., Gentes, A., Gressier, E., Simatic, M., and Zaza, E. (2009). Game design of
“Plug: Secrets of the Museum”, a pervasive game taking place in a museum. In To be published.
[Bauer et al., 2002] Bauer, D., Rooney, S., and Scotton, P. (2002). Network infrastructure for massively distributed
games. In Network and System Support for Games 2002 (NetGames), pages 36–43. Braunschweig, Germany, ACM.
[Bettner and Terrano, 2001] Bettner, P. and Terrano, M. (2001). 1500 archers on a 28.8: Network programming in
age of empire and beyond. In Proceedings of the 2001 Game Developer Conference. San Jose, California, USA.
97/106
[Bharambe et al., 2002] Bharambe, A. R., Rao, S., and Seshan, S. (2002). Mercury: A scalable publish-subscribe
system for internet games. In Network and System Support for Games 2002 (NetGames). Braunschweig, Germany,
ACM.
[Biswas et al., 2006] Biswas, A., Donaldson, T., Singh, J., Diamond, S., Gauthier, D., and Longford, M. (2006).
Assessment of mobile experience engine, the development toolkit for context aware mobile applications. In ACE ’06:
Proceedings of the 2006 ACM SIGCHI international conference on Advances in computer entertainment technology,
page 8, New York, NY, USA. ACM Press.
[Brandt, 2005] Brandt, D. H. (2005). Scaling EVE online: Under the hood of the network layer.
http://www.research.ibm.com/netgames2005/papers/brandt.pdf.
[Brun et al., 2006] Brun, J., Safaei, F., and Boustead, P. (2006). Managing latency and fairness in networked games.
Commun. ACM, 49(11):46–51.
[Butterfly.net and IDC, 2003] Butterfly.net and IDC (2003). Butterfly.net: Powering next-generation gaming with
computing on-demand. http://www.butterfly.net/platform/technology/idc.pdf. No more accessible.
[Capital Games et al., 2006] Capital Games, Lyon Game, DRTEFP Ile-de-France, and OPCAREG Rhône-Alpes et
Ile-de-France (2006). Appui technique de cadrage dans le secteur du jeu vidéo : Principaux enseignements et
conclusions. Technical Report 520.03v2, Ambroisebouteille.
[Cédric et al., 2009] Cédric, L3i, Musée des arts et métiers, NET Innovations, Orange, TELECOM & Management
SudParis, TELECOM ParisTech, and Tetraedge (2009). PLUG: PLay Ubiquitous Games and play more.
http://cedric.cnam.fr/PLUG/. (in French).
[Chabridon and Kodrnja, 2005] Chabridon, S. and Kodrnja, C. (2005). Synchronisation dans les jeux multĳoueurs sur
téléphone mobile. In UBIMOB 05: Deuxièmes journées Ubiquité et Mobilité, pages 57–60. Grenoble, France, ACM.
[Chakravorty et al., 2002] Chakravorty, R., Cartwright, J., and Pratt, I. (2002). Practical experience with tcp over
gprs. In Proceedings of IEEE Globecom 2002. Taipei, Taiwan, IEEE.
98/106
[Cheok et al., 2003] Cheok, A. D., Fong, S. W., Goh, K. H., Yang, X., Lu, W., and Farzbiz, F. (2003). Human
pacman: A sensing-based mobile entertainment system with ubiquitous computing and tangible interaction. In
Network and System Support for Games 2003 (NetGames). Redwood City, California, ACM.
[CipSoft GmbH, 2008] CipSoft GmbH (2008). Tibia micro edition - the first mobile online roleplaying game.
http://www.tibiame.com.
[Claypool and Claypool, 2006] Claypool, M. and Claypool, K. (2006). Latency and player actions in online games.
Commun. ACM, 49(11):40–45.
[Clech, 2007] Clech, G. (2007). 50% de progression du marché du jeu mobile en 2007 ! La vie numérique.
http://www.lavienumerique.com.
[Cronin et al., 2002] Cronin, E., Filstrup, B., Kurc, A. R., and Jamin, S. (2002). An efficient synchronization
mechanism for mirrored game architectures. In Network and System Support for Games 2002 (NetGames).
Braunschweig, Germany, ACM.
[Dang Tran et al., 2003] Dang Tran, F., Deslaugiers, M., and Gérodolle, A. (2003). A middleware for multi-platform,
multi-player video games. In 2nd International Conference on Application and Development of Computer Games
(ADCOG). Hong Kong, China.
[Dang Tran et al., 2002] Dang Tran, F., Deslaugiers, M., Gérodolle, A., Hazard, L., and Riviere, N. (2002). An open
middleware for large-scale networked virtual environments. In Virtual Reality. Orlando, Florida, USA, IEEE.
[DeLap et al., 2004] DeLap, M., Knutsson, B., Lu, H., Sokolsky, O., Sammapun, U., Lee, I., and Tsarouchis, C.
(2004). Is runtime verification applicable to cheat detection. In SIGCOMM’04 Workshops, pages 134–138. Portland,
Oregon, USA, ACM.
[Ducourtieux, 2007] Ducourtieux, C. (2007). Les ventes de jeux vidéo égalent celles de musique. Le Monde.
[Events, 2008] Events, C. (2008). Game developers conference paris. http://www.parisgdc.com/.
[Exit Games, 2009] Exit Games (2009). Exit games - home page. http://www.exitgames.com/.
99/106
[Gamasutra, 2007] Gamasutra (2007). Gamasutra’s Best Of 2007: Top 5 Most Significant Moments In MMOs.
http://www.gamasutra.com/php-bin/news_index.php?story=16758.
[Gautier and Diot, 1998] Gautier, L. and Diot, C. (1998). Design and evaluation of mimaze, a multi-player game on
the internet. In Multimedia Systems Conference. Austin, USA, IEEE.
[Guo et al., 2003] Guo, K., Mukherjee, S., Rangarajan, S., and Paul, S. (2003). A fair message exchange framework
for distributed multi-player games. In Network and System Support for Games 2003 (NetGames). Redwood City,
California, ACM.
[Henning, 2004] Henning, M. (2004). Massively multiplayer middleware. ACM Queue Magazine, 2(1):38–45.
[Herlihy and Mohan, 2003] Herlihy, M. and Mohan, A. (2003). Peer-to-peer multiplayer gaming using arrow multicast:
Peer-to-peer quake. In The 23rd International Conference on Distributed Computing Systems (ICDCS-2003).
Providence, Rhode Island USA.
[IGDA Online Games SIG, 2005] IGDA Online Games SIG (2005). 2005 mobile games white paper. Technical report,
International Game Developers Association (IGDA).
http://www.igda.org/online/IGDA_Mobile_Whitepaper_2005.pdf.
[Jouglet and Colin, 2005] Jouglet, J. and Colin, C. (2005). Pour l’amélioration du ressenti utilisateur dans les services
mobiles. Séminaire INT/archimède.
[Khan et al., 2007] Khan, A. M., Chabridon, S., and Beugnard, A. (2007). Synchronization medium: a consistency
maintenance component for mobile multiplayer games. In NetGames ’07: Proceedings of the 6th ACM SIGCOMM
workshop on Network and system support for games, pages 99–104. ACM.
[Koivisto, 2007] Koivisto, E. (2007). Mobile games 2010. Technical Report NRC-TR-2007-011, Nokia Research Center
Finland.
[Le Bourlout, 2007] Le Bourlout, E. (2007). Les ARG, pour jouer avec le réel. Sciences et Vie Micro, pages 58–60.
[LEGO, 2008] LEGO (2008). Lego.com mindstorms nxt home. http://mindstorms.lego.com/.
100/106
[Licoppe and Inada, 2005] Licoppe, C. and Inada, Y. (2005). Les usages émergents d’un jeu multĳoueur sur terminaux
mobiles géolocalisés : les conséquences interactionnelles des "recontres d’écran". In UBIMOB 05: Deuxièmes
journées Ubiquité et Mobilité, pages 49–56. Grenoble, France, ACM.
[Maman, 2007] Maman, J.-M. (2007). Développeur de jeux vidéo : une aventure possible. Programmez!, pages 81–82.
[Mascolo et al., 2002] Mascolo, C., Capra, L., and Emmerich, W. (2002). Middleware for mobile computing (a
survey). In Gregori, E., Anastasi, G., and Basagni, S., editors, Neworking 2002 Tutorial Papers, volume 2497 of
Lecture Notes in Computer Science, pages 20–58. Springer-Verlag.
[Massiv, 2005] Massiv (2005). Massiv - massively multiplayer online game middleware. http://massiv.objectweb.org/.
[Mauve, 2000] Mauve, M. (2000). How to keep a dead man from shooting. In 7th International Workshop on
Intercative Distributed Multimedia Systems and Telecommunication Services (IDMS), pages 199–204. Enschede,
The Nederlands.
[Mauve et al., 2002] Mauve, M., Fischer, S., and Widmer, J. (2002). A generic proxy system for networked computer
games. In Network and System Support for Games 2002 (NetGames). Braunschweig, Germany, ACM.
[Michaud, 2008] Michaud, L. (2008). Les 5 enjeux majeurs pour l’industrie des jeux vidéo. Agence Française pour le
Jeu Vidéo (AFJV) web site, http://www.afjv.com/press0804/080415_enjeux_jeux_video.htm.
[Microsoft, 2008] Microsoft (2008). Microsoft robotics studio. http://msdn.microsoft.com/robotics/.
[Mitchell et al., 2003] Mitchell, K., McCaffery, D., Metaxas, G., Finney, J., Schmid, S., and Scott, A. (2003). Six in
the city: Introducing real tournament - a mobile ipv6 based context - aware multiplayer game. In Network and
System Support for Games 2003 (NetGames). Redwood City, California, ACM.
[Morrisson, 2008] Morrisson, V. (2008). Perspectives de développement du marché des services sur mobile en france
et en europe. Agence Française pour le Jeu Vidéo (AFJV) web site,
http://www.afjv.com/press0808/080812_etude_services_mobiles_01.htm.
[Mottola et al., 2006] Mottola, L., Murphy, A. L., and Picco, G. P. (2006). Pervasive games in a mote-enabled virtual
101/106
world using tuple space middleware. In NetGames ’06: Proceedings of 5th ACM SIGCOMM workshop on Network
and system support for games, page 29. ACM Press.
[mscape, 2007] mscape (2007). mscape - you are here. http://www.mscapers.com/.
[Natkin, 2002] Natkin, S. (2002). Architectures et technologies informatiques pour jouer à un million de joueurs. Les
Cahiers du Numérique, 3(2).
[NeL community, 2009] NeL community (2009). Home - Open Nel. http://www.opennel.org.
[Nokia, 2003a] Nokia (2003a). Introduction to mobile game development (version 1.1). Nokia forum,
http://www.forum.nokia.com/main.html.
[Nokia, 2003b] Nokia (2003b). Tibiame case study (version 1.0). Nokia forum,
[Nokia, 2004] Nokia (2004). Multiplayer game performance over cellular networks. Nokia forum,
[Nokia, 2007] Nokia (2007). Top 10 energy saving tips. http://www.forum.nokia.com.
[Nokia, 2009] Nokia (2009). SNAP mobile introduction. http://forum.nokia.com/snapmobile.
[Open Mobile Alliance, 2007] Open Mobile Alliance (2007). Open mobile alliance: Games services working group.
OMA web site, http://www.openmobilealliance.org/tech/wg_committees/gs.html.
[OpenTNL, 2007] OpenTNL (2007). Torque network library. http://www.opentnl.org/.
[Oracle, 2008] Oracle (2008). Oracle Berkeley DB Java Edition.
http://www.oracle.com/database/berkeley-db/je/index.html.
[Palm, 2003] Palm, T. (2003). The birth of the mobile MMOG. Gamasutra web site,
http://www.gamasutra.com/resource_guide/20030916/palm_pfv.html.
102/106
[Pantel and Wolf, 2002a] Pantel, L. and Wolf, L. C. (2002a). On the impact of delay on real-time multiplayer games.
In Proceedings of the 12th International Workshop on Network and Operating Systems Support for Digital Audio
and Video, pages 23–29. Miami, Florida, USA.
[Pantel and Wolf, 2002b] Pantel, L. and Wolf, L. C. (2002b). On the suitability of dead reckoning schemes for games.
In Network and System Support for Games 2002 (NetGames), pages 79–84. Braunschweig, Germany, ACM.
[Patterson and Dredge, 2006] Patterson, G. and Dredge, S. (2006). Mobile industry outlook. Technical report,
Informa telecoms & media.
[Pellerin, 2007] Pellerin, R. (2007). The MooDS protocol: a J2ME object oriented communication protocol. In
Proceedings of International Conference on Mobile Technology, Applications and Systems (Mobility Conference).
Singapore.
[Pellerin et al., 2007] Pellerin, R., Delpiano, F., Gressier, E., and Simatic, M. (2007). Gasp – a middleware for mobile
multiplayer games. http://gasp.objectweb.org.
[Ploss et al., 2007] Ploss, A., Linka, F., and ans Jen Müller-Iden, S. G. (2007). Towards a high-level design approach
for multi-server online games. In Proceedings of Game-On 2007, 8th International Conference on Intelligent Games
and Simulation, pages 10–17. Bologna, Italy, Eurosis.
[Potel, 2003] Potel, M. J. (2003). Samurai Romanesque, J2ME, and the Battle for Mobile Cyberspace. IEEE
Computer Graphics and Application, 23(1):16–23.
[PriXArs, 2005] PriXArs (2005). Botfighters. http://www.botfighters.com.
[Quazal, 2009] Quazal (2009). Quazal :: Multiplayer connectivity. http://www.quazal.com/.
[Qwest Communications International Inc., 2004] Qwest Communications International Inc. (2004). Conqwest 2004 ::
big game + treasure hunt + phone cam + semacode + giant animal totems.
http://homepages.nyu.edu/ dc788/conqwest/.
[Ramakrishna et al., 2003] Ramakrishna, V., Robinson, M., Eustice, K., and Reither, P. (2003). An active
103/106
self-optimizing multiplayer gaming architecture. In Autonomic computing workshop, the fifth annual international
workshop on Active Middleware Services (AMS 2003).
[Rashid et al., 2006] Rashid, O., Bamford, W., Coulton, P., Edwards, R., and Scheible, J. (2006). Pac-lan:
mixed-reality gaming with rfid-enabled mobile phones. Computers in Entertainment, 4(4):17.
[Rawat and Simatic, 2007] Rawat, A. and Simatic, M. (2007). Issues for multiplayer mobile game engines. In
Proceedings of Game-On 2007, 8th International Conference on Intelligent Games and Simulation, pages 76–82.
Bologna, Italy, Eurosis.
[Renou, 2008] Renou, A. (2008). Les jeux vidéo gratuits font fureur au bureau. Le Parisien.
[Riera et al., 2003] Riera, S. M., Wellnitz, O., and Wolf, L. (2003). A zone-based gaming architecture for ad-hoc
networks. In Network and System Support for Games 2003 (NetGames). Redwood City, California, ACM.
[Rodriguez et al., 2008] Rodriguez, O., Johnson, E. J., Crabtree, S., and Werth, B. (2008). Carry small, game large:
Big shared screen multiplayer gaming. Gamasutra web site,
http://www.gamasutra.com/view/feature/3649/carry_small_game_large_big_.php.
[Saha et al., 2002] Saha, D., Sahu, S., and Shaikh, A. (2002). A service platform for on-line games. In Network and
System Support for Games 2002 (NetGames). Braunschweig, Germany, ACM.
[Schneider and Kortuem, 2001] Schneider, J. and Kortuem, G. (2001). How to host a pervasive game - supporting
face-toface interactions in live-action roleplaying. In Designing Ubiquitous Computing Games Workshop : Ubicomp.
Atlanta, USA.
[Scrinéo, 2005] Scrinéo (2005). Via temporis. http://www.viatemporis.com.
[Simatic, 2009] Simatic, M. (2009). When vector clocks meet rfid-based pervasive games. In To be published.
[SirBruce, 2007] SirBruce (2007). Total MMOG active subscriptions - absolute contribution.
http://www.mmogchart.com/Chart5.html.
104/106
[Smed et al., 2001] Smed, J., Kaukoranta, T., and Hakonen, H. (2001). Aspects of networking in multiplayer
computer games. In Proceedings of The International Conference on Application and Development of Computer
Games in the 21st Century.
[Smith et al., 2005] Smith, I., Consolvo, S., and Lamarca, A. (2005). The Drop: Pragmatic problems in the design of
a compelling, pervasive game. ACM Computers in Entertainment, 3(3).
[Sun Microsystems, 2007a] Sun Microsystems (2007a). Project Darkstar Client SDK Tutorial, 0.9.4-r3093 edition.
[Sun Microsystems, 2007b] Sun Microsystems (2007b). Project Darkstar Server Application Tutorial, 0.9.4-r3093
edition.
[Sun Microsystems, 2008] Sun Microsystems (2008). Project darkstar community. http://www.projectdarkstar.com.
[Sun Microsystems, 2009] Sun Microsystems (2009). grizzly: Grizzly Project Home Page.
https://grizzly.dev.java.net/.
[Suomela et al., 2005] Suomela, R., Koskinen, K., and Heikkinen, K. (2005). Rapid prototyping of location-based
games with the multi-user publishing environment application platform. In IEEE International Workshop on
Intelligent Environments. Colchester, U.K, IEEE. http://www.tbrc.fi/ampers/documents/rapid_proto_mupe.pdf.
[Séfrin, 2007] Séfrin, C. (2007). Sur mobile, le contenu donne de la voix. 20 minutes High Tech, page 20.
[Söderlund et al., 2005] Söderlund, T., Svahn, M., and Ghellal, S. (2005). Deliverable d4.2: Business and revenue
models. Technical report, Integrated Project on Pervasive Gaming (IPerG). Version 1.2
(http://www.pervasive-gaming.org/downloadables/BO2.pdf).
[Terraplay, 2002a] Terraplay (2002a). Game developer’s guide to the Terraplay system. In Terraplay SDK 2.1,
http://www.terraplay.com.
[Terraplay, 2002b] Terraplay (2002b). Strategies in Terraplay game networking. In Terraplay SDK 2.1,
http://www.terraplay.com.
105/106
[Terraplay, 2003] Terraplay (2003). Creating a Terraplay enable gaming service: White paper (version 2.1).
http://www.terraplay.com/.
[Triebel et al., 2007] Triebel, T., Guthier, B., and Effelsberg, W. (2007). Skype4games. In NetGames ’07:
Proceedings of the 6th ACM SIGCOMM workshop on Network and system support for games, pages 13–18. ACM.
[Ubisoft, 2006] Ubisoft (2006). In memoraim - le dernier rituel. http://www.inmemoriam-thegame.com/.
[UniSA, 2002] UniSA (2002). About the arquake project. UniSA web site, http://wearables.unisa.edu.au/arquake.
[Waldo, 2008] Waldo, J. (2008). Scaling in games and virtual worlds. Commun. ACM, 51(8):38–44.
[Walz et al., 2006] Walz, S. P., Ballagas, R., Borchers, J., Mendoza, J., Kratz, S., Wartmann, C., Fuhr1, C., Tann,
M. J., Shin, D. Y., Hameed, B., Bardos, L., and Hovestadt, L. (2006). Cell spell-casting: Designing a locative and
gesture recognition multiplayer smartphone game for tourists. In Pergames 2006. Dublin, Ireland.
[Zeemote Inc, 2009] Zeemote Inc (2009). Zeemote. http://www.zeemote.com.
[Zona, 2002] Zona, I. (2002). Terazona white paper. http://www.zona.net.
[Zuckerer, 2008] Zuckerer, B. (2008). Re: [fwd: Looking for tibiame information for a course on mobile games]. Mail
from Benjamin Zuckerer (Product Manager for TibiaME) to Michel Simatic.
106/106

Multiplayer computer games, mobile phones and beyond

Transcription

Similar documents

Managed Service

1500 Archers on a 28.8: Network Programming in Age of Empires

Online Map Games – playful interaction with complex real

House Clearance – Furniture, Accessories and

Cairdin A6 postcard:Layout 1

Age of Giants cover`s list

PRESENTATION

please click here - Stillpoint Family Resources

Aurelie Beer Interview Week 1

English - Rockstar Games