1. CO1301: Games Concepts Dr Nick Mitchell (Room CM 226) email: npmitchell@uclan.ac.uknpmitchell@uclan.ac.uk Material originally prepared by Laurent Noel Lecture 16 Commercial Games Development – Programming Concepts

2. Lecture Outline 1. Game Program Components & Roles 2. Technical Design Decisions 3. Program Testing

3. Part 1: Game Program Components  A game usually consists of 100,000’s of lines of programming.  It can be broken down into several distinct sections:  Graphics or 3D engine  Responsible for drawing what you see on the screen.  Often the most complex and high-profile section.  Game logic & data  Manages characters, levels & objects from the design.  Implements the rules of the game (using the attributes and data tables from the game design).  AI (Artificial Intelligence)  The program that drives the behaviour of Non-Player- Characters.  This is also becoming a high-profile, complex area.

4. Further game program components:  GUI and Front End  In game graphical interface as well as the opening titles and menus.  Controller support  Network implementation  Will be linked to game logic  Miscellaneous Technical  Sound and Music, CD/DVD reading, Video playing, Copy protection etc.  Support Tools  Level design (‘Modding’) tools, scripting tools, artwork conversion tools, optimisation tools etc.  We will look at such applications throughout the course.

5. Programming Roles  Programming roles can be put into three categories depending on the components they are responsible for:  Graphics Engine  Game Logic & AI  Tools and Technology  Most starting positions are in the ‘Tools and Technology’ category.  Unless you can show flair in the other areas (i.e. with a portfolio).

6. Part 2: Technical Design Decisions  In the previous lectures we passed over the technical decisions needed in the early stages.  Now that you have a little experience in programming in a simple game environment, we will return to this point.  If you wish, you could cover some of these points in your current game design assignment.

7. Sourcing a Graphics Engine  A graphics engine is a complex program. An early decision when designing a game is whether to:  Create a new engine.  Reuse an existing engine.  Buy in a 3 rd party engine  This is primarily a question of resources.  But it will have implications for the game programmers.  Create a new engine  Can be tailored for the game.  Will take a long time.  Will be able to reuse later.  Reuse an engine.  Quick and cheap.  API known but may not be quite suitable.  Technology becomes dated with too much reuse.  Buy an existing engine  Powerful, expensive.  API unknown and may not be quite suitable.

8. Sourcing of Other Components  This kind of sourcing decisions occurs for other components in the program.  There is usually the decision whether to create a new component, or whether to reuse an existing one.  Often components are reused, but updated.  In some cases there is also a choice of 3 rd party components  E.g. Miles Sound System or DirectSound.  There will be cost considerations as well as technical ones.

9. Algorithmic Decisions  The more difficult algorithms or programming processes that are needed in a game should be assessed and documented in the design.  E.g. If the game needs hundreds of intelligent NPC’s, then the AI techniques that will be used should be outlined in the game design.  Or if the graphics engine will use a new technique it should also be described.  We haven’t covered these techniques yet - in your game design try to identify the technical challenges, but don’t worry about identifying the solutions.

10. Part 3: Program Testing  We have covered the need for testing in the lifecycle of a game. Now we will describe the process for the programmers involved.  After a game reaches its ‘beta’ stage, it will be sent to a test facility.  Within a matter of days they will report back with an initial set of error (‘bug’) reports.  The programming team will identify who ‘owns’ each bug and attempt to fix them.  The ‘fixed’ game is sent back for testing and the process repeats until the publisher is happy that the game is sufficiently ‘bug-free’

11. Bug Classification  Error reports are usually classified by severity, e.g.:  Class A: Program crashes or locks-up.  Class B: Major graphic, function or logic error.  Class C: Minor graphic, function or logic error.  Class D: Playability or other concern.  Notice in this example that class D reports are not really errors, but reflect the opinion of the tester.  Error reports also contain other information e.g.:  Hardware & operating system used.  Location (in the game) of the bug.  If the bug is repeatable.  Hours of play before the error.

12. Error Reports Exercise  Now classify the bugs identified on the handout.  Also, for each bug decide whether it should stop a game from being released to the public.