Games Development PracticesSemester 2 Overview

CO2301 Games Development 1

Week 14

Project PreparationProject 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

Technology TopicsTechnology 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– All our projects so far have been silent– Will use a sound API in a TL-Engine project to add sound

effects and music• Will use OpenAL in this module, will look at fmod next year

• Both widely used in games

Working with ArtistsWorking with Artists

• 3D Modelling– 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)

More TechnologyMore 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

– For more complex physics we will incorporate a physics engine into the TL-Engine

• We will use Havok Physics

– Another rich API to look at• You will constantly see new APIs (e.g. DirectX, OpenAL, Havok) in

games development, must be ready to adapt.

– Decoupling the game and the physics engine brings some issues

Game ArchitectureGame 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

Games Development PracticesThe Game Loop and Timing

CO2301 Games Development 1

Week 14

Basic Game Program StructureBasic 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

GameSetup

GameLoop

Limitations of this StructureLimitations 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

Revised Game StructureRevised Game Structure

• Slightly more generic game structure:

Initialise engine{

Front-end setupFront-end loop (until “Start Game” or “Quit”)Front-end shutdownif (“Quit”) Shut-down engine and end program

Set starting level{Level setupGame loop (until “Next Level” or “Game Over”)Level shutdown

} while “Next Level”, loop to Level setup} Loop to Front-end setup

Basic Game LoopBasic 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

Game Loop TimingGame 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

Issues with Untimed Game LoopIssues 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

Managing Different FPS 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

Incorporating Frame Time 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 variablesMoveX( Speed * FrameTime )Speed = Speed + Acceleration * FrameTime;

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

DifficultiesDifficulties

• 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

Advantages / DisadvantagesAdvantages / 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

Fixed Timing MethodFixed 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…

Fixed Timing MethodFixed 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

Using Fixed TimingUsing 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

Choosing a Timing MethodChoosing 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