Focus onNetworking Engine

Contents

● “Super IsoBomb” Network Engine Introduction● Game Networking Middleware APIs● Game Networking Issues Overview● “Super IsoBomb” Protocol Messages

● Original Version:– Jason Winnebeck– Jon Hilliker– Jim Clase

● Networking and Upgraded Version:– Peter Mowry

● Super IsoBomb Networking Paper– http://www.rit.edu/~pem1491/IsoBomb/network.php3– Game Networking Middleware Selection, General Game

Networking Research, Protocol Specification and Issues● Super IsoBomb Home:

– http://www.rit.edu/~pem1491/IsoBomb/● Original Super IsoBomb Home:

– http://www.rit.edu/~jpw9607/isobomb/

● 1: C++ Game Networking Middleware– Research Possibilities– Select from Canidates

● 2: Protocol Design Initial– Research Game Networking– Design Protocol

● 3: Implementing– Test, Redesign, Re-implement, Targeted Research, etc

● SDL_net– Component of open source (OpenGL-based) cross

platform Simple Direct-Media Layer (SDL)● HawkNL

– Low level C-based library; cross platform wrapper for WinSock and Unix Sockets

● GNE (Game Networking Engine)– Created from HawkNL; higher level

● Quazal Net-Z– Commercial API, cross platform (including console

systems); Distributed Objects; only 30 day trial

Game Networking MiddlewarePotential APIs

Game Networking MiddlewarePrefered APIs

● ReplicaNet– Network shared C++ objects

● DirectPlay– DirectX Component; Windows-oriented;

integration with DirectVoice● RakNet

– C++ Packet-based API

● Has most of the features of DirectPlay, or at least those desired for “Super IsoBomb”

● Bonus Features like:– Object IDs, Time Stamping

● Intends on adding further optimizations– Such as Packet Combining, Improved Compression

● Excellent documentation, tutorials, “Quick Start”● Focused Goals and very well supported

RakNet

TCP vs. UDP

● “Lesson two: – TCP is evil. Don’t use TCP for a game.”

● “Lesson three: – Use UDP.”

● “Lesson four:– UDP is better than TCP, but it still sucks.”

http://www.gamasutra.com/features/19990903/lincroft_05.htm

How does RakNet Send Packets?

● UDP with layers– More efficient than TCP– More customizeable overhead

● enum PacketReliability{ UNRELIABLE, // 3, 1, 7 UNRELIABLE_SEQUENCED, // 3, 7 RELIABLE, // 3, 1, 5, 7, 2, 4, 6 RELIABLE_ORDERED, // 1, 2, 3, 4, 5, 6, 7 RELIABLE_SEQUENCED // 3, 5, 7};

General Architecture

● Server keeps sole authoratative game state– Efficiently synchronize game state– First major step towards Anti-Cheat

● Client is “dumb rendering terminal”– Send input requests to server– Not so dumb - Doom to Quake to Unreal– Receive game state and simulate/predict

Optimization!● Optimization is a primary concern of real-time game

networking!● Minimize traffic for good client simulation● Client simulation – make it look optimized:

– Prediction logic– Smoothing algorithms– Server is authority– Sometimes trade-offs between accuracy vs. smoothness

Smoothness at the expense of Accuracy

Server – accepting move requests Client – simulating smooth local

Zero Security Optimization:Client Authority

● Perfect Client smoothness for its objects– Each Client has authority over some objects (like its

character, its bombs, etc)● Possible methods:

– Client sends server updates of its objects;Server relays opponent updates to each Client

– Peer to Peer● A fully authoratative server sees the real game

– Any authoratative server has the power to cheat,including non-dedicated servers

What to send . . .

● Send full game state updates?● Send game state updates only for some data?

– Ex - 50 world units around the player(assumes player with fixed camera)

– Ex – Information for the current small zone● Send input or triggers or deltas?

(assume deterministic game logic or partly)

Message Groups (by purpose)

● Game Setup Triggers:Join, Disc, Start, StartPlayer, Map Change

● Character Movement● Thrown Bomb● Homing Bomb● Game Triggers: Powerup, Virus, Damage

Messages by Reliability

● Server to Client; Reliable; don't need to combine

– PlayerJoinedStruct – 1 - server event– PlayerDiscStruct – 2 – server event– GameStartStruct – 3 - server event– GameStartPlayerStruct - 19 – server event

Messages by Reliability

● Server to Client; Reliable group

– ThrownBombSpawnStruct - 24 - server event– ThrownBombHeadBounceStruct - 19 - server update– BombExplodeStruct - 9 - server event– HomingBombSpawnStruct - 28 - server event– PowerupCollisionStruct - 9 - server event– VirusSpawnStruct - 8 - server event– DamagePlayerStruct - 2 - server event

Messages by Reliability

● Server to Client; Unreliable group

– PosVelStruct - 13 - server update– HomingBombUpdateStruct - 16 - server

update

Messages by Reliability

● Client to Server; Reliable group

– MapChangeRequest - 2 - client request– MoveRequestStruct - 8 - client request– ThrownBombRequestStruct - 5 - client request– HomingBombRequestStruct - 2 - client request

Next Version of RakNet

● Easier Packet Combining– Thus, I didn't do it manually in this version

● "streaming and a transparent compression / encryption scheme"– Bandwidth optimization– Security improvement

Game Setup Triggers:Join, Disc, Start, StartPlayer, Map Change

● Create and remove player Ids● StartGame – number of players to expect● StartGamePlayer - Information for one player

– Starting Position, Score● MapChangeRequest

– List of current requested map for each player– Change when all are same and not current map

Character Movement – Possible

● Client-side authority over position– Warp cheat

● Request/Update– Client sends move requests– Server sends PosVel updates– Client attempts to predict and smooth movement

● List of moves with time stamps applied● Gradually reposition over time interval - anti-pop

Character Movement – Final

● Client-side authority over position verified– Client sends position– Server checks legality of move:

● time stamp > current time● distance (use velocity and dt)● height steps (1 tile up per tile change)● *movement through another character

*only illegal expected without cheats

Thrown Bomb – Possible

● Basic – spawn request and spawn– Prediction failed

● Hit Floor – basic with single repositioning● ID-based bounce and Hit Floor

– Update only when bounce– Non-deterministic logic => Basic fail when no bounce

● ID-based continual updates

Thrown Bomb – Final

● Rewrote more deterministic logic– Update( dt ) – enforce constant dt values– Projectile motion overall equation instead of deltas

● Spawn + Deterministic Logic– => accurate client-side prediction

● Character positions are unreliable– Update in event of character bounce (not wall bounce)

Homing Bomb – Possible

● Deterministic AStar path finding– Dynamically finds path to target– Just send Spawn?– Character (target) position is unreliable!

Homing Bomb – Final

● HomingBombRequest● HomingBombSpawn

– (time stamped for prediction)● Continuously sends HomingBombUpdate

– (time stamped for prediction)● BombExplode

– Ping/2 delay; Could be predicted by sending explode earlier if and only if destination position is known then

Game Triggers:Powerup, Virus, Damage

● PowerupCollision– Player ID, powerup type, virus type, time stamp

● VirusSpawn– Sent if collision with an infected player

● Damage event sent– Fatality inferred

Additional Questions?

(Demo Next)