1 / 12

CO1301: Games Concepts

CO1301: Games Concepts. Lecture 8 Commercial Games Development – Programming Concepts. Dr Nick Mitchell (Room CM 226) email: npmitchell@uclan.ac.uk Material originally prepared by Laurent Noel. Lecture Outline. Game Program Components & Roles Technical Design Decisions Program Testing.

cmckillip
Download Presentation

CO1301: Games Concepts

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Lecture Outline • Game Program Components & Roles • Technical Design Decisions • 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 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). Programming Roles

  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 3rd 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 3rd 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.

More Related