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
• Actor is an Object capable of moving and
interacting within the Level Object
• The Level is filled with Actors
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
Clients
• Maintain as closely as possible a proper
representation of what is happening on the
server
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.
• 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.
• 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
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)
• 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!
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
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...
The Solution
• Doesn’t quite exist…..
• The Network code in Unreal is intended to
give the clients a reasonable
approximation of the game state.
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.
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.
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
The Relevant Set Rules
1.
2.
3.
4.
5.
The actor belongs to the ZoneInfo class, then it is relevant.
If the actor has static=true or bNoDelete=true, then it is relevant.
If the actor is owned by the player (Owner==Player), then it is relevant.
If the actor is a Weapon and is owned by a visible actor, then it is relevant.
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
Further Prioritising (Actors)
• Every Actor has a variable called
NetPriority
Bots: 8.0
– Relative Ratios
• Default of Actor is 1.0
• Inventory / Pickups 1.4
• Players / Vehicles 3.0
Movers: 7.0
Projectiles: 6.0
Pawns: 4.0
Decorative creatures (such as
fish): 2.0
Decorations: 0.5
• Replication can be divided into 3 parts
– Actors
– Variables
– Function Calls
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.
The 3 Types of Replication
Variable
– Actor Variables that are considered relevant
can be replicated from the server to the
clients.
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
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.
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!!
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
Stolen from RocketLauncher.uc
• replication
• {
•
reliable if (Role == ROLE_Authority &&
bNetOwner)
•
bLockedOn;
•
•
reliable if (Role < ROLE_Authority)
ServerSetTightSpread,
ServerClearTightSpread;
• }
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
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;
}
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
Variables are always Reliable
• The reliable / unreliable keyword is
ignored on variables.
• Objects and Actors are the only ones able
to be unreliable.
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)
•
•
•
•
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.)
•
•
•
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.
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".
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
AutonomousProxy
• Aka The player
• This code is written in UnrealScript (As of
up to UT2004)
• Uses an error / correction approach
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
PlayerController.uc
function ClientAdjustPosition
(
float TimeStamp,
name newState,
EPhysics newPhysics,
float NewLocX,
float NewLocY,
float NewLocZ,
float NewVelX,
float NewVelY,
float NewVelZ,
Actor NewBase
)
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)
References
• http://unreal.epicgames.com/Network.htm