Introduction to Game Design Truong Tuan Anh CSE-HCMUT
Games Games are actually complex applications: interactive real-time simulations of complicated worlds multiple agents and interactions game entities move and change and act upon each other use of visual & audio data, GPU programs, other resources must interface (and hide) with low-level libraries that provide hardware services and components (especially graphics) Analysis of game program architecture and concepts how to design and organize a game program? what are relevant tools, techniques, and patterns? 2
Simple Architecture 3
Basic Notations Games: A "game" is an interactive experience that provides the player with an increasingly challenging sequence of patterns which he or she learns and eventually masters... [Koster, Theory of Fun for Game Design, 2004] "a game is a soft real-time interactive agent-based computer simulation [Gregory, 2014] Agent: a game entity/actor, often implemented as an object in an object-oriented programming language (behavior + encapsulated state) how to define different kinds/types of game objects need to integrate game objects into the game loop 4
Basic Notations Game loop: the basic loop that drives discretetime simulation in games also use multiple (nested) or multithreaded loops Time: real time vs game time how to make logic (updates) a function of delta time (the time that has elapsed after the last update point) why/how to control display rate? implement frame limiting and/or frame dropping 5
Game Programming The operations/actions while running a computer game include loading preprocessed assets (textures, models, skeletons, whatever..) handling user input from keyboards, mouse, controllers running the game logic: scripts, physics simulation, game events.. presenting a snapshot of the game world to the player (via GPU) 6
History Chap 1 [Madhav, 2014]
Game Loop
Game Loop Overall flow control for the entire game program: It s a loop because the game keeps doing a series of actions over and over again until the user quits Each iteration of the loop produces one frame (snapshot image) e.g., 60 FPS (frames per second): the loop completes 60 iterations every second 9
Traditional Game Loop Three distinct phases While game is running do Step 1: process inputs; Step 2: update game world; Step 3: generate outputs; 10
Step 1: Process Inputs Detect any inputs from devices: keyboard, mouse, joystick, Other forms of input (stored or generated) instant replay playback data: to watch a recorded sequence of game play (say, the last served ball in a game of tennis) for online games, need to receive and process data from network and propagate onward... on a mobile device, can include data from GPS (Global Positioning System), accelerometer, gyroscope, or real camera (for modified view of reality in augmented reality games) 11
Step 2: Update Game World Iterate through (currently active) game objects in the world and update them (or letting them update () themselves) could include hundreds or thousands of objects (or more) 12
Step 3: Generate Outputs The most computationally expensive output is usually graphics (2D/3D) Also audio, including sound effects, music, and dialogue Rumble effects (force feedback) For multi-player online games, need to send data to network 13
Example: Pac-Man Game 14
15
Example: "Multiple interactions within the program" Case: Gears of War (2006) Models the state of the game world as interacting objects that evolve over time About 1000 distinct gameplay classes have dynamic state and behavior (member functions) About 10,000 active gameplay objects each time a gameplay object is updated, it typically touches (affects) 5-10 other objects 30-60 updates (frames) per second, attempting more or less "photorealistic quality (3D scene, details, lighting, shadows) Written in C++ or a custom scripting language (textual/visual) high-level, object-oriented code imperative programming style lots of dynamic objects to manage (created/updated/destroyed) 16
Example: "Multiple interactions within the program" Case: Gears of War (2006) 17
Example: "Multiple interactions within the program" Case: Gears of War (2006) Initially for Xbox 360 (2006); a Windows version (2007) sold over three million copies in ten weeks online multiplayer features.. Resources about 10 programmers about 20 artists (!) about 24 month development cycle (not incl. the ready engine) about $ 10 million budget Software dependencies one "middleware" game engine (its own Unreal Engine 3) about 20 other support libraries graphics APIs, sound, input, etc. 18
Multi-Threaded Game Loop 19
On Multi-threaded Game Loops Modern CPUs have multiple cores: can run multiple lines of execution (threads) at once (in a true parallel way) Game loop should take advantage of all available cores Why? 20
On Multi-threaded Game Loops Rendering graphics: an extremely timeconsuming operation for AAA games Suppose it takes 30 milliseconds to render the entire scene It also takes an additional 20 milliseconds to perform the game world update On a single thread: 50 milliseconds to complete a frame -> low 20 FPS Two threads: the rendering and world update could be completed in parallel -> 30 milliseconds to complete a frame -> 30 FPS Should custom the traditional game loop How? 21
One Strategy: Multithreaded "split" Loop Graphics (rendering) runs on one thread Everything else runs on a second thread Graphics thread always lags one frame behind the main (second) thread But 22
23
Problem: input lag Amount of time it takes for a (player) action to have a visible effect on screen Rendering thread is at least one calculation step (frame) "behind" the gameplay thread The higher the input lag, the more sluggish (slow to react to controls) the game feels For some genres (such as highly-tuned combat games), a high input lag may be unacceptable A similar problem may occur when delivering buffered messages/events between game subsystems and components 24
Time 25
Real Time vs. Game Time Real time amount of time has elapsed in the real world (for the player) note that the frame rate (fps) is expressed in this real time Game time amount of time elapsed in the game world simulation Real time and game time is often 1:1, but if the game is paused, no game time passes (but still frames are displayed so the game loop needs to run) game time may be slower or faster than real time (for example, bullet time being slower; collision of galaxies being faster) games may even have game time go in reverse (~ time travel) Game loop should take elapsed game time into account 26
Logic as a Function of Delta Time The following code will run differently on different systems enemy.position.x += 5 // update per each frame (loop cycle) At 30 FPS, the enemy would move 150 pixels/sec (original) At 60 FPS, the enemy would move 300 pixels/sec (twice that) Solution? To solve this issue, we need to make the speed a function of delta time (the amount of elapsed game time since last frame/update) not in terms of pixels per frame, but in terms of pixels per second E.g., The movement is 150 pixels per second: multiply 150 by the elapsed portion of second enemy.position.x += 150 * deltatime; 27
Game Loop with Delta Time Note. Game time is always calculated from real time 28
Problems with Unsteady" Frame Rate Basic physics has wildly different behavior based on frame rate physics may require higher and steady rate of updates game characters may move unpredictably at lower frame rates online games may not work properly with variable frame rates Solution (for the classic game loop) use frame limiting to lock down the frame rate to a specific value: pause and wait until the required delta time has elapsed 29
Game Loop with Frame Limiting 30
Problems with Unsteady" Frame Rate Another potential problem: when updates need to take longer than given by the target delay time per frame Solution: frame dropping : skip rendering on the subsequent frame in an attempt to catch back up to the desired frame rate cause a perceptible visual hitch Advanced solution: use another loop to do physics at a faster, steady rate 31
Game Objects
A Simplified View of Game Architecture 33
A Hypothetical Architecture for a 3rd-Person Shooter 34
A Hypothetical Architecture for a 3rd-Person Shooter All player characters and game objects are contained in a game level (possibly using non-owning aggregation) Game objects have position, rotation, and velocity: can be moved around and touch/collide with each other Both players and enemies are "game characters The scene includes parts such as crates, barrels, etc. that have geometry (i.e., shape), are animated, and simulated by physics: generalize them as a class "game dynamic objects" ("rigid bodies", in game physics) Game triggers have (only) volumes and locations in a level, and often provide health power-ups, coins, ammo, generate events, etc. A game camera may have its own logic, e.g., how to follow the player character or have "scripted" actions; so need a specific class Also, e.g. heads-up display (HUD) shows current status (health, ammo); often not part of the 3D level (but can) but a separate display layer 35
Different Types of Game Objects Drawn and updated any character, creature, or otherwise movable object that's also visible in the world in Super Mario Bros.: Mario, any enemies, all dynamic entities Only-drawn static objects, such as buildings, mountains, sky in the background of a level/scene Only-updated cameras (presuming no mirrors reflect the camera object) trigger volumes (for doors, hidden secret passageways, etc.) the whole game/level (depending on the game logic) 36
Game Objects in the Game Loop Create a root GameObject class Create two interfaces: Drawable Updateable The three types (1) - (3) of game objects each implement the right combination of the interfaces Create separate lists of drawable and updateable objects, and add to these lists as appropriate 37
Basic GameObject Implementation 38
39
Summary
Finally: a (simplified) Single-thread Game Loop 41
Takeaways Game and history Game loop Time and Games Game Objects 42