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

4. Working 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 (3 rd 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. 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 –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

6. 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 3 rd year work –We expect 3 rd year projects to be well architected

7. Games Development Practices The Game Loop and Timing CO2301 Games Development 1 Week 14

8. Basic Game Program Structure Basic program structure used in TL-Engine: #include 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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