Network Replication

1. Network Replication • Possibly the ugliest thing to learn this semester • Many different states • Simulated Functions • Is it an Event or function? • Roles

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

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

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

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

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

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

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

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

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

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

12. The Solution • Doesn’t quite exist….. • The Network code in Unreal is intended to give the clients a reasonable approximation of the game state.

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

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

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

16. The Relevant Set Rules • 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. • 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. • 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

17. 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.0 Movers: 7.0 Projectiles: 6.0 Pawns: 4.0 Decorative creatures (such as fish): 2.0 Decorations: 0.5

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

19. The 3 Types of Replication Variable • Actor Variables that are considered relevant can be replicated from the server to the clients.

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

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

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

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

24. Stolen from RocketLauncher.uc • replication • { • reliable if (Role == ROLE_Authority && bNetOwner) • bLockedOn; • reliable if (Role < ROLE_Authority) • ServerSetTightSpread, ServerClearTightSpread; • }

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

26. 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; }

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

28. Variables are always Reliable • The reliable / unreliable keyword is ignored on variables. • Objects and Actors are the only ones able to be unreliable.

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

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

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

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

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

34. AutonomousProxy • Aka The player • This code is written in UnrealScript (As of up to UT2004) • Uses an error / correction approach

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

36. PlayerController.uc function ClientAdjustPosition ( float TimeStamp, name newState, EPhysics newPhysics, float NewLocX, float NewLocY, float NewLocZ, float NewVelX, float NewVelY, float NewVelZ, Actor NewBase )

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

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