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
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.
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.
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