Networked GraphicsBuilding Networked Virtual Environments and Networked GamesIssues in Networking Graphics

Issues to be Considered

Initialization Server and Peer Responsibilities Critical and non Critical Synchronized and unSynchronized Ownership and Locking Persistency Latency and Bandwidth Object Sharing

Initialization Assets already installed or cached on

local systems To avoid huge downloads during gameplay

If assets are not available locally, the user can only join a running session after the assets have been loaded to a local cache. User has to wait until the assets are

available. To keep user busy, a video is played as an Intro to the game.

Once all assets are available, the initial state needs to be downloaded. Requires a list of assets and their

placements for a level Requires a description of services and users

Some NVEs allow continuous download of assets

Server and Peer Responsibilities Delegate responsibilities for different

behaviors to different client and server processes.

A centralized server that performs all calculations for behavior is the easiest to implement: Complex tasks that might need access to

large databases Complex calculations related to physics

simulation Fast paced games, easier to have server

execute behavior and distribute to all clients at the same time (taking into account latency)

Different Approaches Strict Server/Client

Dumb client that relies fully on server for all calculations and only renders and sends and receives device I/O

Strict Peer to Peer No one is responsible for maintaining state Each peer assumes responsibility for

executing behaviors and distributing results. Could cause conflicts.

Hybrid systems Server maintains canonical view Delegate server role for some objects to

the objects owner on a client. Owners have sole ability to execute behavior.

Critical and Non Critical A MMOG is a collaborative environment,

where clients and server exchange information via messages that describe changes in state.

Communication can be unreliable and information can be dropped or delayed.

Some data being sent is more critical than others Objects that are close have more meaning than

those that are far away or hidden (local visibility)

Objects that were deemed not critical due to distance or obstructed view, could very quickly become critical – local visibility can change rapidly

Audibility may be deemed to be less critical than visibility – a footstep vs a building collapsing.

Synchronized and UnSynchronized Synchronization is concerned with timing of

events Certain events may need to happen at the same

time, if not the game appears to be unfair. E.g., a the movement of a ball in a soccer game.

Some events require joint synchronization, that means that several actions (all from different clients) have to occur at the same time, e.g., a group of dancers, players running across a field.

Synchronizationcan also mean maintaining the ordering of events (FPS: shooting and dodging, which happened first.)

Tight synchronization between clients and a server, requires a common time reference. That can be done via NTP. Not very accurate, may work for most situations, but some may require more accurate method of maintaining a common clock.

Ownership and Locking Some objects maybe modified or edited

in an environment and some objects are immutable.

The system has to determine which objects maybe edited and which may not by use of flags. E.g. in an OS, using read, write and execute flags.

If an object maybe edited or modified, then if it is being used by a client, it has to be locked so that users cannot overwrite each others actions.

Users will see edits that are being made by another user when an object is locked by that user. They will have to wait for object to be unlocked to make their edits.

Persistence – maintaining state In many NVEs and NGs, players

manipulate the space (build, destroy, add to) or achieve certain levels, or acquire certain goods (currency, assets).

This information has to be stored so that the next time the environment is recreated, it has to be consistent with the last changes made by the players, or the players have to be able to continue at the level where they were last at with their latest attributes.

This requires a back-end database that stores player and environment information so that the next time it is started, it resurrects where it left off.

Latency and Bandwidth Designers have to make strategic choices based

upon the needs of their games and the environment that it will be distributed in to players.

Biggest impact of latency is on synchronization. Using local inputs and extrapolation, the behavior

on the client can be made to look very continuous, however, it can lead to divergence from the real state, which will then need to be corrected, creating a possible glitch at client.

How often states have to be synchronized will depend on the ”playability” of the game.

Limiting user participation (no. of active players) can mitigate some problems

Object Sharing Systems

Principle of object sharing systems is that the client processes access locally stored objects

Any changes to these objects (i.e. changing instance variables, creating new classes) is automatically propagated to other collaborating clients.

Client A

Objects

Application

Network Object-Sharing

Client B

Objects

Application

Network Object-Sharing

Shared Objects

Client A

Objects

Application

Network Object-Sharing

Client B

Objects

Application

Network Object-Sharing

1

2

3

4

1. Application alters a variable on object2. The system observes this alteration3. Msg sent from A to B describing change4. B receives this and applies change to local copy of object

Object Sharing Considerations

Need to get frequency of updates right: e.g., don’t send an update every time an instance variable changes, may not have great impact on play.

Objects are typically owned by the process that created them: they share the fate of that process. If process disappears (i.e., is down), object disappears from other collaborators state space.

Can be client-server or peer to peer

Client A

ReplicaObjects

Application

ReplicaManager

1

2

Server

ReplicaObjects

Application

ReplicaManager4

Client C

ReplicaObjects

Application

ReplicaManager

Client B

ReplicaObjects

Application

ReplicaManager

3

5

5

6

6

Sequence of Events – C/S

1. Client A creates an object2. Adds it to its object sharing system (replica manager)3. Sent over the network4. New instance created on the server5. Relayed to clients B and C

Client A

ReplicaObjects

Application

ReplicaManager

Server

ReplicaObjects

Application

ReplicaManager1

Client C

ReplicaObjects

Application

ReplicaManager

Client B

ReplicaObjects

Application

ReplicaManager

2

2

3

3

Server loses contact with Client

1. Server deletes object created by A2. Sends instructions to Clients B and C3. Clients B and C delete object

GENERAL OBJECT SHARING

Sharing Policy Visibility: Frequency and size of updates,

depends on what is visible to user. Of course what was invisible at time “t” could become visible at time “t+dt”.

Locking data structures that are being changed.

Degree of Change: Comparing data structures and if different “enough”, send an update.

Partial Changes: However, only a few objects in a data structure maybe changing, so why send the whole data structure? Flag which variables have changed, and send

only those updates. Or send only differences in data structures.

OWNERSHIP

Who can make changes to an object Generally only the owner/creator or the

server can update or destroy an object. In most environments that rule for changes

to objects suffices. However there are situations where

objects can be shared, and several users may want to move the shared objects, e.g., building blocks. This can be solved by declaring every user

to be an owner. But this can lead to chaos with an object

jumping around depending on who is moving it and when the update is being received at other clients.

Example of a shared object

Two clients are moving one object and sending updates to a third and each other.

The two clients that are moving the object, will ignore each others updates and just see their own movements.

However, the third client will see the object being “jerked” around. The object will appear to be jumping around as each client moves the object and sends updates.

Client A Client B Client C

Using a server to coordinate actions If a server is brought in to the picture,

the server will require the clients to send a request to move object.

Upon receipt of an accept from the server, the client may start to move the object on local system.

This can appear to be very slow for a client (low responsiveness).

Client can move object as it is requesting a move from server (local update only): If server accepts, all is OK. If server rejects, then client has to move

object back to original position.

Client A Server Client B

Request Move Object O to XYZ

Move Object O to XYZ

Move Object O to XYZ

Client A attempts to move Object O to XYZ

Object O moves to XYZ Object O moves to XYZ

Server authorizes move

Sluggish response for Client A

Client A Server Client B

Request Move Object O to XYZ2

Move Object O to XYZ2

Move Object O to XYZ2

Client A moves Object O from XYZ1 to XYZ2

Client A confirms moves Object O moves to XYZ2

Server authorizes move

Local Prediction, Client A moves object

Client A Server Client B

Request Move Object O to XYZ2

Reject Movement

Client A moves Object O from XYZ1 to XYZ2

Client A moves Object O from XYZ2 back to XYZ1

Server refuses move

Move refused by server, Client A moves object back

Client Requests a Lock From Server

In this situation, the client requests a lock on the object.

The client can then make consecutive moves without having to send requests to the server.

Client A Server Client B

Request Lock Object O

Grant Lock Object O

Client A requests lock on Object O

Client A gets lock and makes move to XYZ1

Object O moves to XYZ1

Server grants lock

Move Object O to XYZ1

Move Object O to XYZ1

Client A makes move to XYZ2

Object O moves to XYZ2

Move Object O to XYZ2

Move Object O to XYZ2

Client A requests lock and then sends in move object

Client A Server Client B

Request Lock & Move Object O to

to XYZ2

Grant Lock Object O

Client A requests lock and move Object O from XYZ1 to XYZ2

Client A gets lock and makes move to XYZ2 Object O moves to XYZ1

Server grants lock

Move Object O to XYZ1

Object O moves to XYZ2

Move Object O to XYZ2

Move Object O to XYZ2

Client A sends in request for lock and also moves object locally