1. Central game update and render processes
2.1. The Game Loop
Central game update and render processes

2. Key Components/Actions in a (2d) Game
Identifying commonality between different game types

3. Exercise: Distilling Key Components/Actions
Select 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.
Easy:
Racing game
Platform game
Rhythm game
Puzzle game
Hard:
Why have I classified platform, racing and rhythm games as ‘easy’ and adventure and puzzle as ‘hard’? The reason for the distinction is due to how well bounded/defined most people would consider each genre – ‘adventure’ and ‘puzzle’ are rather open descriptors.
Adventure game
Start
Finished
30 sec
2 mins
8 mins
9 mins
10 mins
7 mins
6 mins
3 mins
4 mins
5 mins
1 min

4. Key (2d) Game Components/Actions
Things 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}
Why bother identifying these aspects? To a large extent they provide the abstract and conceptual building blocks of most games and also define the types of objects and actions that will need to be developed. By taking your game idea and breaking it up into the components/actions shown here you will have gone a good way towards solidifying your game design – i.e. it will break up your game into smaller development chunks.
Note: There is no correct answer. Each model will impose a certain set of assumptions, suiting some types of game but not others.

5. Game consists of objects (player, collectables, score, etc.).
There may be separate update/draw management for game containers
Input events may be ‘consumed’ by the main game loop, layers and/or objects
Input Events
construct {
Load assets()
Build containers() }
Game Engine
run {
loop {
Update active layers()
Draw visible layers()
Game Container
construct {
Build objects() }
update {
Update objects()
draw {
Draw objects()
object
Game Object
As with the previous slide, this slide is not intended to provide some definitive/agreed game engine structure (which doesn’t exist), instead it is intended to provide a flexible structure that can be used to start the process of transforming a game idea into the in-game objects, relationships and behaviours that will be needed to create the game
Asset Manager
Game consists of objects (player, collectables, score, etc.).
Objects reside within a container (front-end, game level, config screen, etc.)
Assets are loaded at runtime and can be managed via an asset manager

6. The Update/Draw Loop
The central mechanism to evolve and render game objects

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

8. Tying things together…
set up fixed rate ticker ( 30/s )
when( tick event ) {
update()
render() }
Tying things together…
Early Approaches
● Early solution was to use a fixed frame rate as the timer (with one update/render tick every frame)
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

9. 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
2 mins
3 mins
Finished
4 mins
30 sec
1 min
7 mins
10 mins
9 mins
8 mins
6 mins
5 mins

10. sleepTime = updatePeriod - (tAfter - tBefore) - overTime
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 ) {
timeBeyondPeriod = - updatePeriod
} } }
updatePeriod = 1000 / UPS
timeBeyondPeriod = 0
overTime = 0
Period
Loop Loop 2 s o r u
Period
Loop n Loop m

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

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

13. Practical Advice
Issues and aspects you should consider as part of your game loop

14. Decoupling behaviour
When 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)

15. XNA update/draw loop control
XNA provides good control over how the update/draw loop performs
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
Game class
IsFixedTimeStep property – controls if a fixed update time should be used
TargetElapsedTime property – get/set the target fixed time step duration
GraphicsDeviceManager class
SynchronizeWithVerticalRetrace property – get/set if the maximum draw rate will be limited by the screen refresh rate
‘XNA provides good control over how the update/draw loop performs’ – but the default setting will suffice in most cases
For Java: explore game.engine.GameEngine.run()

16. 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.
Whilst a fascinating topic, an more in-depth coverage of concurrency falls outside the scope of this module.

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