1. Focus on Networking Engine

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

3. ● Original Version: – Jason Winnebeck – Jon Hilliker – Jim Clase ● Networking and Upgraded Version: – Peter Mowry

4. ● 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/

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

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

7. Game Networking Middleware Prefered APIs ● ReplicaNet – Network shared C++ objects ● DirectPlay – DirectX Component; Windows-oriented; integration with DirectVoice ● RakNet – C++ Packet-based API

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

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

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

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

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

13. Smoothness at the expense of Accuracy Server – accepting move requests Client – simulating smooth local

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

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

16. Message Groups (by purpose) ● Game Setup Triggers: Join, Disc, Start, StartPlayer, Map Change ● Character Movement ● Thrown Bomb ● Homing Bomb ● Game Triggers: Powerup, Virus, Damage

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

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

19. Messages by Reliability ● Server to Client; Unreliable group – PosVelStruct - 13 - server update – HomingBombUpdateStruct - 16 - server update

20. Messages by Reliability ● Client to Server; Reliable group – MapChangeRequest - 2 - client request – MoveRequestStruct - 8 - client request – ThrownBombRequestStruct - 5 - client request – HomingBombRequestStruct - 2 - client request

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

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

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

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

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

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

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

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

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

30. Additional Questions? (Demo Next)