Focus on Networking 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 – – Game Networking Middleware Selection, General Game Networking Research, Protocol Specification and Issues ● Super IsoBomb Home: – ● Original Super IsoBomb Home: –

● 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 Middleware Potential APIs

Game Networking Middleware Prefered 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.”

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 server event – ThrownBombHeadBounceStruct server update – BombExplodeStruct server event – HomingBombSpawnStruct server event – PowerupCollisionStruct server event – VirusSpawnStruct server event – DamagePlayerStruct server event

Messages by Reliability ● Server to Client; Unreliable group – PosVelStruct server update – HomingBombUpdateStruct server update

Messages by Reliability ● Client to Server; Reliable group – MapChangeRequest client request – MoveRequestStruct client request – ThrownBombRequestStruct client request – HomingBombRequestStruct 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)