1. Networked Graphics Building Networked Virtual Environments and Networked Games Issues in Networking Graphics

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

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

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

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

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

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

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

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

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

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

12. Client A Objects Application Network Object-Sharing Client B Objects Application Network Object-Sharing Shared Objects

13. Client A Objects Application Network Object-Sharing Client B Objects Application Network Object-Sharing 1 2 3 4 1.Application alters a variable on object 2.The system observes this alteration 3.Msg sent from A to B describing change 4.B receives this and applies change to local copy of object

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

15. Client A ReplicaObjects Application ReplicaManager 1 2 Server ReplicaObjects Application ReplicaManager 4 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 object 2.Adds it to its object sharing system (replica manager) 3.Sent over the network 4.New instance created on the server 5.Relayed to clients B and C

16. Client A ReplicaObjects Application ReplicaManager Server ReplicaObjects Application ReplicaManager 1 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 A 2.Sends instructions to Clients B and C 3.Clients B and C delete object

17. GENERAL OBJECT SHARING

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

19. OWNERSHIP

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

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

22. Client AClient BClient C

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

24. Client AServer Client B Request Move Object O to XYZ Move Object O to XYZ Client A attempts to move Object O to XYZ Object O moves to XYZ Server authorizes move Sluggish response for Client A

25. Client AServer Client B Request Move Object O to XYZ 2 Move Object O to XYZ 2 Client A moves Object O from XYZ 1 to XYZ 2 Client A confirms moves Object O moves to XYZ 2 Server authorizes move Local Prediction, Client A moves object

26. Client AServer Client B Request Move Object O to XYZ 2 Reject Movement Client A moves Object O from XYZ 1 to XYZ 2 Client A moves Object O from XYZ 2 back to XYZ 1 Server refuses move Move refused by server, Client A moves object back

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

28. Client AServer 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 XYZ 1 Object O moves to XYZ 1 Server grants lock Move Object O to XYZ 1 Client A makes move to XYZ 2 Object O moves to XYZ 2 Move Object O to XYZ 2 Client A requests lock and then sends in move object

29. Client AServer Client B Request Lock & Move Object O to to XYZ 2 Grant Lock Object O Client A requests lock and move Object O from XYZ 1 to XYZ 2 Client A gets lock and makes move to XYZ 2 Object O moves to XYZ 1 Server grants lock Move Object O to XYZ 1 Object O moves to XYZ 2 Move Object O to XYZ 2 Client A sends in request for lock and also moves object locally