Networked Games: Types, Technologies, and Architectures

1. Networked Games • Objectives – • Understand the types of human interaction that a network game may provide and how this influences game play. • Understand what technologies may be employed in the development of network games. • Realise the different architectures available for network game deployment.

2. Gaming environment • We consider gaming environments that place emphasis on the following requirements: • User views of the gaming environment must be consistent “enough” to ensure successful game play. • Users interact with the gaming environment in “real-time”. • Gaming environment is graphically represented, with possible use made of sound and tactile feedback. • Typical examples of the type of games we consider: • Unreal Tournament, Age of Empires, Quake Arena. • Round based games (i.e., not real-time) are not considered. • For example, Civilization III.

3. Achieving user-to-user communications • The only method available to provide user-to-user communication is via message passing. • There are three approaches: • Centralised server – state information is held on a centralised data store. • De-centralised server – state information is held on a number of data stores. • Peer – state information is held by the user’s node. • Irrelevant of approach, message passing over a computer network is required. • Protocols need to be derived to aid in satisfying real-time and consistency requirements.

4. Centralised server approach • Users are geographically distributed, however, management of state is accomplished at a single geographic location (server). • User nodes simply update state as indicated by the server. • This means that any potentially state changing event that is derived from a user node, say U1, must be sent to the server via a message, with state change occurring at U1 only when appropriate message received back from server. • Node-server communication may occur via two methods: • Pull: Node periodically polls the server. • Push: The server periodically sends new state change information to node.

5. Using pull approach to gain state updates • When the pull approach is used there is the possibility of missing state update messages. • If nodes are too slow in requesting state information then they could miss some state update messages. • For example, assume the the interval between U1 requesting messages from the server is t1. If the server has identified three messages for collection during t1 then U1 will only receive the last one. • This problem may be overcome by buffering messages. However, if this is a persistent problem buffer overflow will occur. • Using the pull approach may be wasteful if state updates occur less frequently than node requests. • Nodes will be wasting their time requesting state updates when there are no updates required.

6. Using the push approach to gain state updates • The push approach seeks to overcome the problems associated with the pull approach. • Message passing is reduced as nodes do not send wasted messages when no state update is available. • Server sends message only when update has occurred. • Problems may occur is node is unable to consume server message (possibly due to processing overheads). • This may be overcome by buffering messages at the client side. However, if this is a persistent problem buffer overflow may occur.

7. Issues related to central approach • Not scalable. • If complex gaming environments are used (many hundreds of entities) and user numbers are large a single server may not be able to cope. • Problem of users on varying quality of service network connections with server. • High message latency may result in users gaining messages out of date. • Error prone connections may result in users not gaining messages. This may be overcome with transactions, but this approach will add to message latency. • Real-time requirements may be difficult to satisfy. • As no local management of events may occur, there is a high possibility that responsiveness of the gaming environment may suffer. • For example, if you move the joystick to the left nothing will happen until your node has informed the server, the server has updated the state, and the server has informed your node of state update.

8. De-centralised server approach • This approach is an enhancement over the centralised server approach. • Additional servers attempt to overcome scalability problems. • High performance network links may be guaranteed between servers (much more likely than guaranteeing such performance between clients and servers). • We can place servers geographically close to users (e.g., Europe, China, USA) to reduce the message latency problem. • Problems arise when attempting to ensure the consistency of servers. • Complex protocols, which are not, yet, scalable, are required. • Quite sophisticated support infrastructure required, not practical for networked games (vendors need to put a lot more effort towards providing this approach)

9. Peer approach • Commonly used in networked games. • Each user node may derive state without any centralised control. • You may notice that some games have a designated server, this is to ease problems encountered due to message ordering, but more usually associated to problems when users join a game. • This approach is commonly termed “Frequent State Regeneration”. • Potential for nodes to update state frequently (no need to wait for server to update state). • Peers pass messages to each other indicating changes in their own state. • For example, U1 moves their avator to the left. The node of U1 indicates this movement via a message sent to all other nodes. • Only if a node instigates a change state event does it notify of changed state to peers.