docAn introduction on First-Person Shooter game architectures
download 
Report Transcription
An introduction on First-Person Shooter game architectures
An introduction on First-Person Shooter game architectures Giuseppe Reina 01/12/2011 Giuseppe Reina @ Eurecom 1 Motivation • Huge business – Rapidly evolving from small 2-20 players rooms to Massively Multiplayer Online (MMO) worlds – World of Warcraft • • • 11 million subscribers on Nov. 2011 15 euro monthly subscription 750 millions euro/year • Massive Multiplayer Online Games are expensive to deploy • First-Person Shooter games (FPS) – Need for expensive hardware resources – Demand for distributed game techniques to offload the dedicated machines – … or more in general Fast-paced games – Best selling games for console (Halo, Call of duty, Battlefield, etc…) – Most challenging to distribute 01/12/2011 Giuseppe Reina @ Eurecom 2 First-Person Shooter gameplay 01/12/2011 Giuseppe Reina @ Eurecom 3 How is this talk organized • 1st part (today) – Tech talk – Technical background on game engines – Multiplayer architectures – Latency compensation techniques • 2nd talk (next week – Dec 6th) – High scale distributed gaming – Peer-to-peer gaming challenges – Our contribution 01/12/2011 Giuseppe Reina @ Eurecom 4 What happens when you play a game? 01/12/2011 Giuseppe Reina @ Eurecom 5 Game Engine Storage Simulation Internet Networking Game engine Physics Engine Graphic Rendering (2D – 3D) Collision Detection Sound Artificial Intelligence I/O Devices Player Scripting 01/12/2011 Giuseppe Reina @ Eurecom 6 The key concepts of a game engine • The game state • Command • The simulation • Game loop – Group of virtual objects (called entities) – They are monsters, avatars, weapons, NPCs – …but also bullets, explosions and other special effects! – Represents the user intention in controlling one or more entities – A command, when executed, modifies the game state – Natural evolution of the game entities according to the physics engine, the collision detection system and the AI – Keeps everything together! – Cycles of the loop are called ticks – The tick rate determines the pace of the game • 01/12/2011 ~60 Hz in FPS ( 1 tick every 15 ms) Giuseppe Reina @ Eurecom 7 Game loop (local game) Player Command Fetching Graphics and Audio Rendering Player Command Execution Simulation (Physics, collision and AI) 01/12/2011 Giuseppe Reina @ Eurecom 8 CASE SCENARIO: SUPER MARIO BROS 01/12/2011 Giuseppe Reina @ Eurecom 9 Player command fetching Player command fetching Graphics and Audio Rendering Player Command Execution Simulation (Physics, collision and AI) “Jump & Shoot” 01/12/2011 Input state Giuseppe Reina @ Eurecom Command 10 Player command execution Player command fetching Graphics and Audio Rendering Player Command Execution Simulation (Physics, collision and AI) “Jump & Shoot” Command 01/12/2011 Mario.velocity.up = JUMP_SPEED; <<new Fireball>>; Firewall.position = Mario.position; Fireball.velocity = FIREBALL_CONST_VEL; Giuseppe Reina @ Eurecom 11 Simulation execution Player command fetching Graphics and Audio Rendering Player Command Execution Simulation (Physics, collision and AI) // AI computation KoopaTurtle.artificialIntelligence.step(); // Physics simulation Mario.position += Mario.velocity; Mario.velocity -= GRAVITY; Fireball.position += Fireball.velocity; KoopaTurtle.position += KoopaTurtle.velocity; // Collision detection detectCollisions(Mario); detectCollisions(Fireball); 01/12/2011 Giuseppe Reina @ Eurecom detectCollisions(KoopaTurtle); 12 Graphics and Audio Rendering Player command fetching Graphics and Audio Rendering Player Command Execution Simulation (Physics, collision and AI) 01/12/2011 Giuseppe Reina @ Eurecom 13 Toward multiplayer games PEER-TO-PEER ARCHITECTURE 01/12/2011 Giuseppe Reina @ Eurecom 14 Peer-to-peer: Lockstep algorithm CMD1 CMD2 CMD3 Peer 1 Waiting CMD4 CMD1 Peer 2 Waiting CMD1 & CMD4 CMD2 CMD3 CMD4 CMD1 CMD2 CMD3 CMD4 Peer 3 Peer 4 Executing Commands Waiting ACKs 01/12/2011 Giuseppe Reina @ Eurecom CMD1 CMD2 CMD3 15 CMD4 Lockstep algorithm (contd.) • Pro – – – – Easy to implement Works with big number of entities Robust to cheating Peer-to-peer • Cons – Consistency • Hard to ensure that a game is completely deterministic – Latency • Each player in the game has latency equal to the most lagged player – Hard to support late join – 1-to-N communication • The Doom case – Very poor performances! 01/12/2011 Giuseppe Reina @ Eurecom 16 CLIENT/SERVER ARCHITECTURE 01/12/2011 Giuseppe Reina @ Eurecom 17 Client/Server: The dumb client Frame Obj1 Obj2 Obj3 … Client 01/12/2011 Client Client Client Client Side Server Side Server Giuseppe Reina @ Eurecom Simulation (Physics, collision and AI) Player Command Execution Graphics and Audio Rendering Player Command Fetching 18 The dumb client (contd.) • Pro – Single authoritative machine – Tolerant to cheating – 1-on-1 communication • Cons – Scalability – Robustness – Does not work with big number of entities 01/12/2011 Giuseppe Reina @ Eurecom 19 Latency (or Lag) Lower • Run command Casting Area Spell Precision Shooting Rockets Aiming & Shooting Machine Gun Vehicle Racing Exploring (God Game) Fighting (God Game) Combat Moving (God Game) Highest Aiming Weapon / Shooting Sniper Drinking Health Potion Mouse Control Avatar Control Camera Control Tightest Immediate Control Tasks 01/12/2011 Deadline Building (God Game) Lowest • Effects of lag – Introduce inconsistencies • Consistency vs. Reactiveness – Affects fairness – Reduce game experience – One of the biggest causes of game failures User tolerance in FPS – 50 to 100ms for direct manipulation tasks – 100 to 150ms for indirect control tasks – Similar results have been shown for other non-FPGs (RTS games, Sport games and so on.) Giuseppe Reina @ Eurecom 20 Common issue: Fireproof player Shooter (PlayerA) 01/12/2011 ClientA Target (PlayerB) Server Giuseppe Reina @ Eurecom ClientB 21 Common issue: Shoot-round corners Shooter (PlayerA) ClientA 01/12/2011 Target (PlayerB) Server Giuseppe Reina @ Eurecom ClientB 22 Optimization and compensation techniques • Real time illusion – Entity interpolation – Client prediction • Fairness – Lag compensation • Bandwidth optimization – Delta encoding – Area of Interest 01/12/2011 Giuseppe Reina @ Eurecom 23 Client prediction • The problem – Unacceptable to wait for message exchange between the client and the server – Need for immediate feedback for direct manipulation task • The solution – Decoupling the simulation! – The client can simulate some state locally because the server will necessarily come up with the same result – Independent from the server simulation – Gives the feeling of immediate control 01/12/2011 Giuseppe Reina @ Eurecom 24 Client prediction (contd.) Move? P0 to P1 P0 P1 Move? P1 to P2 P1 P2 P2 P3 P3 P4 01/12/2011 ClientA Move P0 to P1 Move? P2 to P3 Move P1 to P2 Move? P3 to P4 Move P2 to P3 Giuseppe Reina @ Eurecom P0 P1 P1 P2 P2 P3 Server 25 Entity Interpolation • The problem – Cope with choppy and jittery entity animation of a moving object • The solution – Go back in time for rendering to interpolate between two different state of the game entity – Drawback: it increase latency 01/12/2011 Giuseppe Reina @ Eurecom 26 Lag compensation • The problem – How to make sure that aiming at a player will actually give you the possibility to kill him? • The solution – Keep a history of all recent player positions for a fixed amount of time – Move back in time the player’s avatar to check eventual collisions 01/12/2011 Giuseppe Reina @ Eurecom 27 Bandwidth Optimization • The problem – There are on average 200 active entities on a 8 player FPS match – Pack them into a server frame is extremely expensive. • The solution – Area of Interest and local perception filters • Define an area of interest of an avatar (everything the avatar can see or hear) • Send object updates only for the objects inside the area of interest • Use perception filters to set the update rate – Delta Encoding • Ship only the fields that changed from the last acknowledged update 01/12/2011 Giuseppe Reina @ Eurecom 28 Conclusion • Overview of how a game engine works • Multiplayer architectures techniques • Latency optimizations for games • Next talk – Scalability issues and distributed architectures – Peer-to-peer gaming challenges – Our contribution 01/12/2011 Giuseppe Reina @ Eurecom 29 Questions 01/12/2011 Giuseppe Reina @ Eurecom 30 01/12/2011 Giuseppe Reina @ Eurecom 31
