Networking Graphics: Key Considerations and Approaches
This content delves into critical issues in networking graphics, exploring server and peer responsibilities, initialization processes, different approaches in network design, and the importance of distinguishing critical and non-critical data in MMOGs.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
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. Synchronization can 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. Interpolation can be used to overcome delays and losses of information, avoids jerkiness resulting from movement between two updates where one is delayed and thus skipped or one maybe lost. 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 Client B Application Application Objects Objects Network Object-Sharing Network Object-Sharing Shared Objects
Client A Client B Application Application 1 Objects Objects 2 4 Network Object-Sharing Network Object-Sharing 3 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
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
Sequence of Events C/S Client B Server Application Application ReplicaObjects ReplicaObjects Client A 6 ReplicaManager4 Application 1 ReplicaManager ReplicaObjects 5 2 Client C ReplicaManager Application 3 ReplicaObjects 6 ReplicaManager 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 5
Server loses contact with Client Client B Server Application Application ReplicaObjects ReplicaObjects Client A 3 ReplicaManager1 Application ReplicaManager ReplicaObjects 2 Client C ReplicaManager Application ReplicaObjects 3 ReplicaManager 2 1. Server deletes object created by A 2. Sends instructions to Clients B and C 3. 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.
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.
Sluggish response for Client A Client A Server Client B Client A attempts to move Object O to XYZ Request Move Object O to XYZ Server authorizes move Move Object O to XYZ Move Object O to XYZ Object O moves to XYZ Object O moves to XYZ
Local Prediction, Client A moves object Client A Server Client B Client A moves Object O from XYZ1 to XYZ2 Request Move Object O to XYZ2 Server authorizes move Move Object O to XYZ2 Move Object O to XYZ2 Client A confirms moves Object O moves to XYZ2
Move refused by server, Client A moves object back Client A Server Client B Client A moves Object O from XYZ1 to XYZ2 Request Move Object O to XYZ2 Server refuses move Reject Movement Client A moves Object O from XYZ2 back to XYZ1
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 requests lock and then sends in move object Client A Server Client B Client A requests lock on Object O Request Lock Object O Server grants lock Grant Lock Object O Client A gets lock and makes move to XYZ1 Move Object O to XYZ1 Client A makes move to XYZ2 Move Object O to XYZ1 Move Object O to XYZ2 Object O moves to XYZ1 Move Object O to XYZ2 Object O moves to XYZ2
Client A sends in request for lock and also moves object locally Client A Server Client B Client A requests lock and move Object O from XYZ1 to XYZ2 Request Lock & Move Object O to to XYZ2 Server grants lock Grant Lock Object O Move Object O to XYZ1 Client A gets lock and makes move to XYZ2 Object O moves to XYZ1 Move Object O to XYZ2 Move Object O to XYZ2 Object O moves to XYZ2
