1. Games Development Practices Semester 2 Overview
CO2301 Games Development 1
Week 14

2. Project Preparation
This semester you do a team games project in the Professional Skills module
The primary goal is to work effectively in a team
The next few lectures will cover several miscellaneous topics in Games Development
These will provide you with the technical background needed for the project:
Technology topics to enhance your projects.
Advice / techniques on dealing with artists/artwork

3. Technology Topics Game Loop and Timing / Front-Ends
Look at the outer loop of a game (in more detail than last year)
Ensure games speed is not linked to the computer speed
Look at different techniques for this and some problems/examples
Also look at putting code around the game loop:
Initialisation, front-end, menus etc.
Sound Effects (due to API changes this might change)
All our projects so far have been silent
Will use a sound API in a TL-Engine project to add sound effects and music

4. Working with Artists 3D Modelling 3D Artwork Conversion
Look at Autodesk Maya to help understand the art process
Study its features and do some simple modelling
Games programmers very, very rarely create artwork, but it is useful to understand the artist’s tools
Especially if you get involved in tools development (3rd year topic)
3D Artwork Conversion
Practice exporting 3D models from various formats into a format suitable for the TL-Engine
Examine the problems that can occur at this stage and how to solve them
Again, very relevant for tools development (a common junior role)

5. Working with Game Engines
Introducing Unity
Commercial game engines are enormously powerful
Yet fairly simple to use
Whilst AAA titles often use their own engines, existing game engines are a less risky alternative used for many games
Unlike other courses we avoid relying on game engines
Better to write your own code rather than use someone else’s
Want to avoid becoming simply a “level designer”
Nevertheless, experience with a game engine is useful
Refreshing to be able to sidestep the technicalities for a while

6. More Technology Physics Engines
Have manually created simple physics in our games
E.g. Basic collision with lines, spheres and boxes
This kind of work is central to games development
As well as good practice on common games match
But only appropriate for simple cases
We will look at adding physics engines to game content
Decoupling the game and the physics engine brings problems

7. Game Architecture
In the latter part of the semester, we will move on to look at the software architecture of a modern game engine
Using topics from Software Development and Advanced C++
Lots of UML (class diagrams) to illustrate the points
Take UML seriously!
Will look at how we can make a general engine that is not tied to just one game
Use TL-Engine architecture as an example
Show problems with that architecture and suggest improvements
Material leads directly into 3rd year work
We expect 3rd year projects to be well architected

8. Games Development Practices The Game Loop and Timing
CO2301 Games Development 1
Week 14
(Recaps and extends 1st year material)

9. Basic Game Program Structure
Basic program structure used in TL-Engine:
#include <game engine libraries>
Initialise game engine
...
Load game media
Initialise game scene
while (game is playing) {
Render the game scene
Move/Animate/Update game scene }
Shut down game engine
End program
Game
Setup
Game
Loop

10. Limitations of this Structure
Too simplistic, assumes:
Game is set-up only once, i.e. only one level
No front-end - nothing before game set-up
Program ends when game-loop ends
Can’t go to next level, or back to the front-end
We need a more complex structure
Multiple “game” loops, one for game, one for front-end
In fact, front end likely to be more complex: multiple screens/menus
Outer loop combining these together
The exact structure needed depends on the style of the game progression

11. Revised Game Structure
Slightly more generic game structure:
Initialise engine {
Front-end setup
Front-end loop (until “Start Game” or “Quit”)
Front-end shutdown
if (“Quit”) Shut-down engine and end program
Set starting level
Level setup
Game loop (until “Next Level” or “Game Over”)
Level shutdown
} while “Next Level”, loop to Level setup
} Loop to Front-end setup

12. Basic Game Loop Game is displayed like a film or animation
Sequence of static images (frames), displayed very quickly
Objects change position only slightly from frame to frame
If the fps is high enough, we don’t perceive separate images, but instead we see an animated scene
Basic game loop performs in this manner:
Render Scene – draw a static image of the scene
Update Scene – Move the objects by a small amount
Loop for as long as the game is running

13. Game Loop Timing We can time the game loop:
Get the time each iteration (frame) of the game loop
Must use a high precision timer
Subtract the time at the previous iteration from the time at the current iteration…
..to give us the duration since the last frame
This is the frame time
The frames per second (FPS) or frame rate is the frequency of the game loop
FPS is related to the frame time:
FPS = 1 / frame time
And frame time = 1 / FPS

14. Issues with Untimed Game Loop
In many labs we have not used game loop timing
Render and update the scene as fast as possible
So the frame time / FPS has been dependent on computer speed
The scene is rendered more frequently on a fast machine, less frequently on a slow one
The render rate is not a problem, rendering at a higher fps will give a smoother look to the game
But…
The scene is also updated at different rates on different machines
Using statements like MoveX(0.1) will cause models to move at different speeds on different computers

15. Managing Different FPS
Imagine two computers running the same game
Computer A: frame time of 0.01 seconds (100 FPS)
Computer B: frame time of 0.02 seconds (50 FPS)
[Note: frame time is a more useful measure than FPS]
To move a model at 500 units per second:
Use MoveX( 5 ) on the faster machine A
Use MoveX( 10 ) on the slower machine B
I.e. move models further each frame on slower machine to keep up with faster machine
In general, to move at M units per second:
Use MoveX( M * frame time )
Confirm this formula with above two examples

16. Incorporating Frame Time
Method applies to movement, acceleration, rotation etc.
First we measure everything in units per second:
E.g. if the units of measurement for our game are metres, then we might choose 5 metres/second for a speed
Or 30 degrees/second for a rotation
Convenient way to measure in any case, previous statements like MoveX(0.1) lacked context
Also helpful to use sensible units when working with artists
Calculate the frame time
Add “* FrameTime” to operations like Move, Rotate, or when working with similar variables
MoveX( Speed * FrameTime )
Speed = Speed + Acceleration * FrameTime;

17. Manipulating Time
By adjusting the frame time value, we can actually speed up and slow down game speed
I.e. Fast and slow motion
For example:
SlowTime = FrameTime * 0.5;
MoveY(20 * SlowTime);
RotateX(10 * SlowTime);
Can adjust the factor (0.5 above) in real-time for “bullet-time” effects, action replays etc.

18. Difficulties
Method shown applies when working with operations that work by addition, e.g:
Movement is addition of velocity to model position
Rotation is an addition of angles, etc.
Occasionally, we need different operations
E.g, if we want to half speed every second:
Speed = Speed * 0.5; // Every second
This would need timing adjustment, but multiplications need a different method:
Speed = Speed * pow(0.5, FrameTime);
Need to watch for odd timing cases like this
See mouse smoothing in lab for this week

19. Advantages / Disadvantages
Call the above method variable timing
Main advantage of variable timing:
Adjusts well, to large differences in frame rate
Different speed machines (PC games)
Game with large changes in performance in different areas
Allows simple & smooth time speed-up / slow-down
Disadvantages of method presented:
Have to adjust many operations in scene update with “* FrameTime”
Occasional need for more complex adjustments which can be hard to identify / calculate

20. Fixed Timing Method There is an alternative fixed timing method:
Pick a fixed frame time, e.g. 0.02s (= 50 FPS)
Call this the tick
Typically a sensible frame rate for expected hardware
Measure everything in units / tick
E.g. Aeroplane speed = 2 metres per tick
(If tick set at 0.02s then equivalent to speed = 100m/s)
Write scene update as normal using these values
E.g. MoveX( 2 )
Method continued on next slide…

21. Fixed Timing Method Get frame time for machine as usual
The actual frame time is may not be equal to the tick
Calculate FrameTime / tick
E.g. if actual frame time = 0.05s, and tick = 0.02s
Then FrameTime / tick = 2.5
Take the whole part of this result and call scene update this many times
Call scene update two times in the example above
Carry the remainder over to the next frame
I.e. Add the 0.5 to the next FrameTime / tick

22. Using Fixed Timing
Slower machines call scene update multiple times per frame, to keep up with the ideal tick
Can be a problem though – multiple calls can slow down machine even more
Faster machines call scene update less often
Reverse problem: may not call scene update at all between frames – no visual update
However, this technique means the scene update code does not need many changes

23. Choosing a Timing Method
Variable timing is more flexible where practical
Can be difficult with advanced game operations
AI, physics engines etc. can cause difficulties
Fixed timing is simpler to work with
But not as smooth, and has problems with very fast or very slow machines
However, these drawbacks don’t always occur
Particularly on consoles - machine speed is constant
Some games use both methods for different game content
E.g. variable timing for models, fixed for particle systems