2004 Web and Downloadable Games White Paper 

IGDA Online Games SIG 

The game presents an `upsell screen' communicating the limitations and instructing the player 

how to `unlock' the game. 

To unlock, players typically click a button to visit the distributor's web site, where they may 

complete a secure form using a credit card to purchase an unlock `key'. 

The key is delivered via email and/or displayed on a webpage. 

The player copies the key from the email message and pastes it into the game, or has it read 

automatically from the clipboard when the game is started. 

The game is now forever unlocked. 

c) 

Downloadable Clients with Web Based Services 

It should be noted that even in the downloadable games described above, it is now possible, and 

often appealing, to use network services in conjunction with the downloaded client. This is often done 

for customer support interaction, but is also used for things like high score lists, brag sheets, player 

forum links, etc. Even though the game itself exists locked on the client and the network is not a part 

of the game play, the net is still used to provide experiences that are perceived valuable in relation to 

the game. This is increasingly the model of choice for downloadable games, as it allows the 

developer a way to contact the player for a variety of reasons, such as further upsells, game 

upgrades, tournament announcements, and so forth. 

2. 

Architecture  

Game architecture is defined as the structure and organization of the game software. This section will 

briefly describe three possible architectures for online games, client server architecture, peer to peer, and 

standalone games. 

a) 

Client / Server 

In a client server system, each player sends packets to other users via a server.

31

 Packets are 

received by the users via the same server. However, servers slow down the exchange of messages 

in an online game. Despite being likely bottlenecks, servers do have multiple purposes. First, servers 

can reduce message traffic to individual users by not sending packets to those users if the packet in 

question is out of the area of interest of the potential packet recipient. Second, servers can compress 

multiple packets into a single message, eliminating redundant and unnecessary message flow. Third, 

servers can also convert packet bursts into smoother packet rates, thus delivering packets at a slower 

rate than they are generated by the individual users. Servers can also be configured to communicate 

with their user clients reliably. Finally, client server architectures are also preferred if there is an 

administrative or control task that must be performed, such as accounting for time spent in the game 

on an individual basis.  

When an online game relies on a client server architecture, the server is responsible for receiving 

input commands from each client, updating the game state, and sending out updates to the 

concerned clients. The server's biggest job is keeping track of entities such as avatars, monsters, 

rockets, score, etc. The server must calculate when a player is hit; use physics models to calculate 

the position of moving objects; turn key presses into jumps or weapons fires, etc. The server also 

informs clients of world state: gravity, lighting, and map information. Aside from its role in gameplay, 

the server is a session manager that starts and ends games, accepts client connections, and 

performs numerous other administrative tasks. 

The client usually sends simple avatar control commands to the server. It then uses its cache of the 

game state, plus dead reckoning and any updates from the server, to render a representation of the 

avatar's area of interest of the virtual world. The graphic rendering is performed on the client side. 

The client has long been the main area of interest in the game developer community because it is 

where all the graphics

are generated. However, in a client/server model, from an architectural point of 

31

 J. Snyers d'Attenhoven 

Management of Networked Virtual Environments, 

Free University of Brussels, 

Belgium, 2002 

Page 63 of 93