2.1. THE GAME LOOPCentral game update and render processes

KEY COMPONENTS/ACTIONS IN A (2D) GAMEIdentifying commonality between different game types

Exercise: Distilling Key Components/ActionsSelect one of the shown genre of game (assuming a 2D game).

Think about the game in terms of how it looks, the features that it has, the things that it does.

Try to identify common aspects that most games in the genre will share in terms of features and behaviour.

Start

10 mins9 mins8 mins7 mins6 mins5 mins4 mins3 mins2 mins 1 min 30 secFinished

Easy:

Hard: Puzzle game

Adventure game

Racing game

Platform game

Rhythm game

Key (2D) Game Components/ActionsThings most 2D game have...

• Front-end (titles, menus)

• Assets• Graphical assets (animations,

backgrounds)• Sound assets (sfx, background music)

• Objects• In-game objects (sprites, platforms, etc.)• HUD objects (score, lives, time, etc.)

• Object Containers• Levels, Areas, Maps

• Input Events

{other things as needed}

Things most 2D games do...Once per game/per level• Load assets• Construct objects• Populate containers

Lots of times / second• Consider input events• Update objects• Draw graphics• Consider sounds

{other things as needed}Note: There is no correct answer. Each model will impose a certain set of assumptions, suiting some types of game but not others.

Game Container

construct {Build objects()

}

update {Update objects()

}

draw {Draw objects()

}

objectobjectobjectobject

objectobjectobjectobject

Game Object

construct {Load assets()Build containers()

}

Game Engine

run {loop {

Update active layers()

Draw visible layers()}

}

Game consists of

objects (player,

collectables, score, etc.).

Assets are loaded at runtime and can be managed via an asset manager

Input events may be ‘consumed’ by

the main game loop, layers and/or

objects

Objects reside within a container (front-end, game level, config

screen, etc.)

Asset Manager

Input Events

There may be separate update/draw management for game containers

THE UPDATE/DRAW LOOPThe central mechanism to evolve and render game objects

The importance of timing…

Timers

● Most games require a timer to manage the game loop

● Early games used the machine as the timer

○ the update/render loop would run as fast as possible (tied to processor speed)

○ used as typically no spare CPU resource and common platform hardware

○ Approach does not scale to varied platforms or increased hardware capabilities

Tying things together…

Early Approaches

● Early solution was to use a fixed frame rate as the timer (with one update/render tick every frame)

set up fixed rate ticker ( 30/s )

when( tick event ){

update()render()

}

while( running ){

record tStart

update()render()

record tEnd

if( tEnd-tStart < tickPeriod )wait( tickPeriod –

(tEnd-tStart)) }

Why is this problematic?● UPS reduced if update

and draw take too long

● game runs slower, not just displayed with lower FPS

Breaking things apart…Assume you have access to the following methods

● update() – update all game objects● render() – draw all game objects● time() – get the current time (ms)● sleep(ms) – sleep for specified number of ms

And the following constraint and target:

● ups –number of update/s (constraint)● fps – equal to ups (target)Develop an algorithm that adapts to different update and render loads. Hint: The fps should be reduced to ensure the ups remain on target.

Optional: Produce an algorithm that compensates for timing/sleep inaccuracies (see SleepTimerTest in the Java Code Repository)

Start

10 mins9 mins8 mins7 mins6 mins5 mins4 mins3 mins2 mins 1 min 30 secFinished

while( running ) {

tBefore = time()update()render() tAfter = time()

sleepTime = updatePeriod - (tAfter - tBefore) - overTime

if( sleepTime > 0 ) {

sleep( sleepTime)overTime = time() - tAfter - sleepTime

} else {

timeBeyondPeriod = timeBeyondPeriod - sleepTime overTime = 0

while( timeBeyondPeriod > updatePeriod ) {

update() timeBeyondPeriod = - updatePeriod

} } }

updatePeriod = 1000 / UPStimeBeyondPeriod = 0overTime = 0

Peri

od

Loop 1 Loop 2

s

o

r

u

Peri

od

Loop n Loop m

Generalised approaches (Semi-decoupling)● Previous slide can be viewed as a form of semi-decoupling

● The AI (update) runs at a fixed rate as before, but the frame (draw) rate just runs as fast as it possibly can (however, no real point running faster than the update loop).

Generalised approaches (Full-decoupling)● “Full” decoupling runs the update loop as fast as possible● A variable interval duration and delta (change) value are used:

○ on faster machines more AI ticks/s with a smaller delta value

○ on slower machines ticks take longer and the delta value will be larger

PRACTICAL ADVICEIssues and aspects you should consider as part of your game loop

Decoupling behaviourWhen designing game objects decouple the update and render behaviours. Ask two separate questions: ‘how will I update this’ and ‘how will I draw this’

• e.g. for an animation, select the animation to be display in the update phase and render it in the draw phase

The draw phase should not change the game state (i.e. properties, etc. of objects, it should simply visualise the game state)

XNA update/draw loop controlXNA provides good control over how the update/draw loop performs

For Java: explore game.engine.GameEngine.run()

GraphicsDeviceManager class

•SynchronizeWithVerticalRetrace property – get/set if the maximum draw rate will be limited by the screen refresh rate

Game class

• IsFixedTimeStep property – controls if a fixed update time should be used

• TargetElapsedTime property – get/set the target fixed time step duration

GameTime class

•Has methods to determine the actual ellapsed time (needed if not using a fixed time step)

• IsRunningSlowly property – true if the target fixed update time step cannot be obtained

Concurrency (multi-threading)The update/draw game loop increasingly involves aspects of concurrency

• In the most basic sense, the CPU/GPU run in parallel, i.e. CPU tells GPU what to render and lets it get on with it

• Aside: The graphics pipeline can be stalled (forcing the CPU to wait for the GPU to ‘catch-up’) in various situations (sometimes unavoidable, e.g. getting render target data)

•Multi-core CPUs, e.g. current gen consoles, PCs, etc. can have numerous concurrent update threads. This will likely require synchronization.

Summary

To do:Finalise initial game idea,

team/no-team,

development language

Read section to be

completed in Project

Development Report

Think about game idea in

terms of game objects,

layers, updating, drawing

Today we explored:

Core game components and actions

The update / draw loop and the different ways of managing time

Things to keep in mind about the update / draw loop