5 . 2. Design Considerations

1. 5.2.Design Considerations Game design aspects

2. A Performance Problem Design exploration of a performance problem within a simple game

3. InvadersLayer • Lethargic Invaders… Recall that the space invaders example design was broadly as shown: ● Update background ● Update player ● Update enemy ships ● Update missiles ● Update overlay items Update ● Clear Screen ● Draw background ● Draw game objects ● Draw explosions ● Draw overlay objects Render

4. Lethargic Invaders… ● Update background ● Update player ● Update enemy ships ● Update missiles ● Update overlay items ● Clear Screen ● Draw background objects ● Draw game objects ● Draw explosions ● Draw overlay objects From a design(ish) perspective (i.e. mostly ignoring code optimisation), if the game is running too slow what should we consider in order to try and improve performance? Update Render Start 5 mins 4 mins 3 mins 2 mins 1 min 30 sec Finished

5. To do: Apply this to own game • Lethargic Invaders (Design considerations) How many objectsneed to be updated each tick? How much effort is required to update each object? How many objects are we drawing each frame? How many pixels are we drawing each frame? How much effort is required to draw the pixels?

6. Lethargic Invaders (Update considerations) How many objects need to be updated each tick? Can the alien army be reduced in size? Will this reduce game difficulty? How can it be offset? How many missiles are active at a time. Can this be reduced? What will be the impact?

7. Lethargic Invaders (Update considerations) How much effort is required to update each object? What is the algorithmic complexity of the collision detecting algorithm? Would a faster approach (if possible) be of any benefit? How much effort is needed to collision test/deform bases? Are other approaches faster?

8. Lethargic Invaders (Draw considerations) How many objects are we drawing each frame? Are non-visible objects drawn (i.e. outside of viewport/camera, behind other visible objects) ? Can they be culled? How many objects need to be drawn? What is the impact of reducing the ‘FOV’? Can non-essential objects be omitted, e.g. special effects? What impact will this have on the game? What is the screen resolution? Can it be lowered, or user-controlled? How many pixels are we drawing each frame?

9. Lethargic Invaders (Draw considerations) How much effort is required to draw the pixels? Of relevance to 3d games: model complexity, shader complexity, post-render effects, etc. Of relevance to 2d games: Are image transforms used (texture resizing, pixel manipulation, etc.)? Does the game use any post-render screen effects (e.g. motion blur, edge enhancement, etc.)?

10. Space Invaders (Questions) Should we clear the screen to black at start? Are we pointlessly drawing? Does scrolling background make any difference? If other graphics cover entire screen, no real need (but small saving) Overlap between sky and mountains can be minimised, but not fully removed. Not really – very small update cost. Draw cost mostly the same.

11. Software Design Considerations Balancing factors within game development

12. Software Design Considerations The following considerations are key to all good software design: Performance / Efficiency: Is it fast? Does it use resources efficiently? Reuse / Extension: Can new features be added? Which bits of code are reusable? Maintainability: Can bugs be easily corrected both pre- and post- delivery

13. Thinking about design importance… This house believes: Performance and efficiency of the game update and render is paramount to providing the most impressive feature set. Reuse and extension of the game codebase for sequels and new games is most vital to future survivability. Maintainability of the current codebase is most important to deliver a bug-free game on time to ensure current survival. Each group must select the one factor that they feel is the most important and justify why. Start 10 mins 9 mins 8 mins 7 mins 6 mins 5 mins 4 mins 3 mins 2 mins 1 min 30 sec Finished

14. Design (Performance and Efficiency) Design: Clearly defined performance targets/constraints Avoiding anything unimportant or unnecessary Using simple models as an approximation of more complex models Implementation: Using efficient and appropriate algorithms Coding in a manner that maximises hardware capabilities (e.g. caching, coherence, etc.).

15. Design (Reuse and Extension) Design: Designed with an explicit aim to facilitate extension and refinement Having clearly defined boundaries between components/systems; strong use of encapsulation / component interfacing Designed and coded for the general case where possible Clear and complete documentation

16. Design (Maintainability) Design: Consistent coding standard applied throughout Best coding practices adopted Strong use of encapsulation and component interfacing Clear and complete documentation Development code contains extensive debugging features Clear and consistently applied testing procedures throughout development

17. To do: Think about this • Design (Getting a balance) It’s all about balance… All areas return benefits, all areas incur cost. Finding a correct balance is key – although difficult. Suggestions for your development… Develop a reusable and extensible design. Produce excellent code (i.e. readily maintained) For computationally intensive bits of the code (either update/render) prioritise performance. Consider using a profiler

18. Summary Today we explored: • Areas to consider when thinking about performance in your game design. • Balance between performance, extensibility and maintainability To do: • Complete Question Clinic • Think about design balance in your game and how it will map onto mark scheme • Think more about what you hope to submit for the Week 6 hand-in