+ All Categories
Home > Documents > Network Replication

Network Replication

Date post: 07-Jan-2016
Category:
Upload: ganit
View: 55 times
Download: 0 times
Share this document with a friend
Description:
Network Replication. Possibly the ugliest thing to learn this semester Many different states Simulated Functions Is it an Event or function? Roles. More Architecture. Unreal is made of Objects. The Game Level is an Object - PowerPoint PPT Presentation
Popular Tags:
38
Network Replication • Possibly the ugliest thing to learn this semester • Many different states • Simulated Functions • Is it an Event or function? • Roles
Transcript
Page 1: Network Replication

Network Replication

• Possibly the ugliest thing to learn this semester

• Many different states

• Simulated Functions

• Is it an Event or function?

• Roles

Page 2: Network Replication

More Architecture

• Unreal is made of Objects. The Game Level is an Object

• Actor is an Object capable of moving and interacting within the Level Object

• The Level is filled with Actors

Page 3: Network Replication

The Server

• This is the source of all the gameplay, and the server is responsible for ticking the game.– A tick is the games clock– The tick is not fixed and scalable, to allow the

game to run at a variable Frame Rate

• In a single player game the server is the machine you play on

Page 4: Network Replication

Clients

• Maintain as closely as possible a proper representation of what is happening on the server

Page 5: Network Replication

Replication Terminology

• Variable– A Name associated with a modifyable

variable.

• Object– A data structure consisting of a fixed set of

Variables

• Actor– An object that can independently move

around the game level.

Page 6: Network Replication

• Level– A level is an Object that contains a set of

Actors

• Tick– This is the operation which updates the entire

game state, given that DeltaTime has passed.

• DeltaTime– Is the varaible time between the last tick

update and the present.

Page 7: Network Replication

• Game State– This is the set of all actors that exist within a level,

and the current values of all of their variables.

• Client– A machine running an approximation of the Game

World

• Server– The machine responsible for ‘Ticking’ the game

level, and maintaining the Game State

Page 8: Network Replication

The Unreal Game Loop

• The Server sends the current state of play to all clients

• Concurrently, Clients send their requested movements and actions to the server, and receive the new game state information from the server

• The client and server then perform a tick operation updating the game state (Server) and approximation (Client)

Page 9: Network Replication

• During the Tick operation the game state can change in 3 ways:– Variables and Actors can be modified– Actors can be created – Actors can be destroyed

• In games of old, like Doom each client ran a copy of the game world, and sent their actions to every other client. (A P2P network)

• The complexities of Unreal Negate this approach– Thankyou Physics!

Page 10: Network Replication

Variable Tick Operations

• As the tick is not fixed, Updates are performed with reference to DeltaTime.

• Position += Velocity * DeltaTime;

• Fixed TimeStep games simply use

• Position += Velocity

Page 11: Network Replication

The Problem

The bandwidth needed to update the entire game state on client machines would be incredible. (Approx 300kb/s for standard deathmatch levels of the original Unreal Tournament)

Multiply this by 30 or more Ticks a second...

Page 12: Network Replication

The Solution

• Doesn’t quite exist…..

• The Network code in Unreal is intended to give the clients a reasonable approximation of the game state.

Page 13: Network Replication

The Server wears the Pants...

• The game state on the server is always regarded as the one True state of the game.

• Actors on Client Machines are referred to as proxies, because they are just a temporary approximate representation of the object.

Page 14: Network Replication

Relevant Actors

• Unreal minimises the Actors which it updates for clients, to only those deemed relevant

• Pretty much any actor the player can see, or has seen recently, as well as any actors with static=true or bNoDelete=true

• See the references if you want the full details on relevance.

Page 15: Network Replication

The Relevant Actors

• These are the only actors that are considered to need updating to / from the client machines

• If an actor is not relevant it will still run locally, but changes will not be sent to other networked machines

Page 16: Network Replication

The Relevant Set Rules

1. The actor belongs to the ZoneInfo class, then it is relevant.

2. If the actor has static=true or bNoDelete=true, then it is relevant.

3. If the actor is owned by the player (Owner==Player), then it is relevant.

4. If the actor is a Weapon and is owned by a visible actor, then it is relevant.

5. If the actor is hidden (bHidden=true) and it doesn't collide (bBlockPlayers=false) and it doesn't have an ambient sound (AmbientSound==None) then the actor is not relevant.

6. If the actor is visible according to a line-of-sight check between the actor's Location and the player's Location, then it is relevant.

7. If the actor was visible less than 2 to 10 seconds ago (the exact number varies because of some performance optimizations), then it is relevant.

This can be altered by people with a developers licence through the

C++ function ULevel::GetRelevantActors

Page 17: Network Replication

Further Prioritising (Actors)

• Every Actor has a variable called NetPriority– Relative Ratios

• Default of Actor is 1.0• Inventory / Pickups 1.4• Players / Vehicles 3.0

• Replication can be divided into 3 parts– Actors– Variables– Function Calls

Bots: 8.0Movers: 7.0Projectiles: 6.0Pawns: 4.0Decorative creatures (such as fish): 2.0Decorations: 0.5

Page 18: Network Replication

The 3 Types of Replication

Actor– The Server identifies the set of relevant

Actors for each Client, and tells each client to create and maintain a proxy of that actor.

Page 19: Network Replication

The 3 Types of Replication

Variable– Actor Variables that are considered relevant

can be replicated from the server to the clients.

Page 20: Network Replication

The 3 Types of Replication

Function Call– A function called on the Server may be routed

to execute on the Client– Or a function called on the Client may be

routed to execute on the Server

Page 21: Network Replication

Example (from the reference)You see two opponents running toward you, shooting at you, and you hear their shots.• You can see the opponents because the server has recognized that the opponents

are "relevant" to you• You can see that the opponents are running toward you because the server is

replicating their Location variable to you• You can see them animating because the server is replicating their animation

variables to you.• You can hear their gunshots because the server is replicating the ClientHearSound

function to you.

(The ClientHearSound function is called for a PlayerPawn whenever that PlayerPawn hears a sound.)

It is only when the client will see or hear anythign that it needs to be replicated.

Things like AI will never run locally on the clients.

Page 22: Network Replication

Your Responsibility

• The game engine does not keep track of what actors are relevant to who

• This is your job.– Any Objects / Variables you create

• How?– The Replication Block!!

Page 23: Network Replication

The Replication Block

• Do you need one for every class?• No• Only when your Class defines new

variables or functions which need to be replicated (get seen or heard)

• In UT only about 10 of the 500 classes needed replication statements

• In ut2004 there are roughly 140 replication statements

Page 24: Network Replication

Stolen from RocketLauncher.uc

• replication• {• reliable if (Role == ROLE_Authority &&

bNetOwner)• bLockedOn;

• reliable if (Role < ROLE_Authority)• ServerSetTightSpread,

ServerClearTightSpread;• }

Page 25: Network Replication

Breaking it Down...

• The previous statement divides into two clear sections

• Variables to be sent to clients– Role == ROLE_Authority

• Variables to be sent to the Server– Role < ROLE_Authority

Page 26: Network Replication

replication{

// Variables the server should send to the client.reliable if( Role==ROLE_Authority )

Weapon;reliable if( Role==ROLE_Authority && bNetOwner )

PlayerName, Team, TeamName, bIsPlayer, CarriedDecoration, SelectedItem, GroundSpeed, WaterSpeed, AirSpeed, AccelRate, JumpZ, MaxStepHeight, bBehindView;

unreliable if( Role==ROLE_Authority && bNetOwner && bIsPlayer && bNetInitial )ViewRotation;

unreliable if( Role==ROLE_Authority && bNetOwner )Health, MoveTarget, Score;

// Functions the server calls on the client side.reliable if( Role==ROLE_Authority && RemoteRole==ROLE_AutonomousProxy )

ClientDying, ClientReStart, ClientGameEnded, ClientSetRotation;unreliable if( Role==ROLE_Authority )

ClientHearSound, ClientMessage;reliable if( Role<ROLE_Authority )

NextItem, SwitchToBestWeapon, bExtra0, bExtra1, bExtra2, bExtra3;

// Input sent from the client to the server.unreliable if( Role<ROLE_AutonomousProxy )

bZoom, bRun, bLook, bDuck, bSnapLevel, bStrafe;unreliable always if( Role<=ROLE_AutonomousProxy )

bFire, bAltFire;}

Page 27: Network Replication

Reliable and Unreliable

• Unreliable Packets may– Disappear– Arrive out of order

• Reliable Packets will eventually be received (not always in order)

• The amount of packets lost varies, and an estimate is between 1% and 10% of all unreliable packets could be lost

Page 28: Network Replication

Variables are always Reliable

• The reliable / unreliable keyword is ignored on variables.

• Objects and Actors are the only ones able to be unreliable.

Page 29: Network Replication

Replication Conditions

• Firstly the roles each Class may have– ROLE_None– ROLE_DumbProxy– ROLE_SimulatedProxy– ROLE_AutonomousProxy– ROLE_Authority

• Checks can also be done using boolean checks– EG: if (Role < Role_Authority)

Page 30: Network Replication

• Role==ROLE_DumbProxy means the actor is a temporary, approximate proxy which should not simulate any physics at all.  Dumb proxies just sit around and are only moved or updated when the server replicates a new location, rotation, or animation information. (This situation is only seen in network clients, never for network servers or single-player games.)

• Role==ROLE_SimulatedProxy means the actor is a temporary, approximate proxy which should simulate physics and animation.  On the client, simulated proxies carry out their basic physics (linear or gravitationally-influenced movement and collision), but they don't make any high-level movement decisions. (This situation is only seen in network clients, never for network servers or single-player games.)

• Role==ROLE_AutonomousProxy means the actor is the local player.   Autonomous proxies have special logic built in for client-side prediction (rather than simulation) of movement. (This situation is only seen in network clients, never for network servers or single-player games.)

• Role==ROLE_Authority means this machine has absolute, authoritative control over the actor.(This is the case for all actors in single-player games.)

(This is the case for all actors on a server.)

(On a client, this is the case for actors that were locally spawned by the client, such as gratuitous(pretty but pointless gameplay-wise) special effects which are done client-side in order to reduce bandwidth usage.)

Page 31: Network Replication

• bIsPlayer: Whether this actor is a player. True for players

• bNetOwner: Whether this actor is owned by the client for whom the replication condition is being evaluated.  For example, say Fred is holding a DispersionPistol, and Bob isn't holding any weapon. When the DispersionPistol is being replicated to Fred, its bNetOwner variable will be True. When it is being replicated to Bob, its bNetOwner variable will be False.

• bNetInitial: Valid only on the server side, i.e. if Role==ROLE_Authority.   Indicates whether this actor is being replicated to the client for the first time.   This is useful for clients with Role==ROLE_SimulatedProxy, because it enables the server to sent their location and velocity just once, with the client subsequently predicting it.

Page 32: Network Replication

Simulated Functions

• For proxy Actors only functions marked simulated will execute on the client machines

• Actors like Weapon.uc and Vehicle.uc rely heavily on simulated functions

So in effect, "Simulated" means "this function should always be executed for proxy actors".

Page 33: Network Replication

Network Optimisation

• The game already runs on the server fine

• The Network optimisation goal is to make the clients view of the game world as realistic as possible to the player

• Vectors get rounded!!!– Converted to 16bit ints for data stream– Bypass this by passing 3x Floats IF you need

the accuracy

Page 34: Network Replication

AutonomousProxy

• Aka The player

• This code is written in UnrealScript (As of up to UT2004)

• Uses an error / correction approach

Page 35: Network Replication

Player Prediction

• MoveAutonomous• SavedMove Class

– Linked list of Moves

• Calls the ServerMove function each Tick• Server Processes, then the Server calls

ClientAdjustPosition• The client then updates the postion to match

the Server, then re-runs any moves after the given TimeStamp

Page 36: Network Replication

PlayerController.uc

function ClientAdjustPosition

(

float TimeStamp,

name newState,

EPhysics newPhysics,

float NewLocX,

float NewLocY,

float NewLocZ,

float NewVelX,

float NewVelY,

float NewVelZ,

Actor NewBase

)

Page 37: Network Replication

Network capabilities of UT

• You have both TCP and UDP class access built in to UT

• If programmed it will allow you to interface with the real world! (Well any software you like)

Page 38: Network Replication

References

• http://unreal.epicgames.com/Network.htm


Recommended