1. Computer Game Development By Jijun Tang

2. Contents for the Presentation Group members, group name, logo Description, specification, goals, game play System requirement, audience, rating Interface, input/output, interactions, cameras Premise/limitations/choices/resources Content designs/3D/2D/animation, audio Level designs, flexibility/scripting language? Version control/testing strategy/documentation Brief timeline (demo date is early Dec)

3. Homework Game treatment document Each group to turn in one Due: Sept 17 th, before class Print and bring it in class Expected page lengths 4-5 pages, 11pt font, single space.

4. Example of Treatment http://www.csc.kth.se/utbildning/kth/kur ser/DH2650/spel08/The%20Game%20 Treatment.doc

5. Requirement

8. Highlights

9. Production Details

11. Game World

13. Examples http://pyrrha.csisdmz.ul.ie/4075/treatment.html

14. Premise Story is the typical example of premise  Time  Place  Characters  Relationships  Motivations  Etc.

15. Choice and Outcome Well-designed choice  Often desirable and undesirable effects  Should relate to player goals  Balanced against neighboring choices Too much weight to every choice is melodrama  Orthogonal choices – distinct from others Not just “ shades of grey ”

16. Resources/Economies Resources  Things used by agents to reach goals  To be meaningful, they must be … Useful – provide some value Limited – in total or rate of supply Economies  Systems of supply, distribution, consumption  Questions regarding game economies: What resources exist? How and when will resources be used? How and when will resources be supplied? What are their limits?

17. Interface Typical perspectives:  First-person  Over-the-shoulder (OTS)  Overhead (top-down)  Side  Isometric

18. First person

19. OTS

20. Overhead and Side

21. Isometric

22. Audio Interface General categories of audio  Music Powerful tool for establishing mood and theme Pay attention to license issues  The campus is cited 960 times last year  Sound effects  Dialog

23. Example

24. Huds

25. System Design Two general approaches to design  Special case Experiences built one scene/level at a time Anticipate states while pre-scripting events Solved by discovering the intentions of the designer  Systemic General behaviors are designed Scenes/Levels are specific configurations Some events may still be pre-scripted Solved by understanding the system

26. Cybernetics Study of communication, control, and regulation Model

27. Cybernetic System A basic cybernetic system has:  Sensor – detects a condition Thermometer  Comparator – evaluates the information Switch  Activator – alters the environment when triggered by the comparator

28. Example System

29. Feedback Feedback:  information about the internal or external changes of system that make the system adjust its output  The portion of a system ’ s output that is returned into the system Feedback Loop  The path taken by the feedback

30. Positive Feedback Amplify changes Leads to runaway behavior Difficult to make use of From Bob Craig

31. Negative feedback Counteracts changes Leads to goal seeking behaviors Most common form in systems From Bob Craig

32. Feedbacks in a Game Negative feedback  Stabilizes the game  Forgives the loser  Prolongs the game  Magnifies late successes Positive feedback  Destabilizes the game  Rewards the winner  Can end the game  Magnifies early successes

33. Platforms Platform: General description of hardware and software  Personal computer – PC, Mac, etc.  Console – Wii, PlayStation, Xbox, etc.  Handheld – DS, Game Boy Advance, PSP, etc.  Mobile device – Cell Phones, NGage, PDA, etc.  Arcade – custom vending games (e.g. Time Crisis) PC Games compared to other platforms:  PC Games are developed and used in the same platform, other platforms may require proprietary development kits.  Console games are popular because consoles are used in a “lean-back” position, while PC is used in a “sit-forward

34. Game Saves Save triggers:  automatically saved at certain points  Disadvantage: Player has little control Save-anywhere  Allow the player to save the state at any point in the game  Disadvantage: System needs to save many different variables, also may make it too easy for the player Save points:  Save only the accumulated points  Disadvantage: Rather limited Coded text saves to save a bit space Do you really want user to save?

35. Genres Genre – a category describing generalities of conventions, style, and content

36. Major Genres Action Adventure Arcade Casual Education Fighting First-person shooter Platform Racing Rhythm Role-Playing (RPG) Simulation Sports Strategy Puzzle Traditional

37. Audiences Target audience  Group of expected consumers  Age, gender income …  What does your audience know?  What does your audience demand? Demographics  Study of relevant economic and social statistics about a given population Demographic variables  The relevant factors

38. Audiences Market  Demographic segmentation of consumers  Market segments: Smaller sub-segment of the market; more tightly defined Demographic profile  Typical consumer attributes in a market  Age, Social class, gender etc.

39. Audiences Heavy Users  Those of the numeric minority of potential users responsible for majority of sales of any product  80/20 rule: in anything a few (20 percent) are vital and many(80 percent) are trivial. Hardcore gamer  Game industry term for heavy video game users Casual gamer  Game industry term for all other gamers

40. Hardcore Players Play games over long sessions Discuss games frequently and at length Knowledgeable about the industry Higher threshold for frustration Desire to modify or extend games creatively Have the latest game systems Engage in competition with themselves, the game, and others

41. Design Procedure Waterfall method  Development methodology  Design and production are broken into phases Iterative development  Practice of producing things incrementally  Refining and re-refining the product  May iterate many cycles before get it right

42. Waterfall vs. Iterative testing

43. Prototypes  Early working models of the product  Used to test ideas and techniques Physical prototypes  Non-electronic models; physical materials Software prototypes  Used regularly during iterative development

44. Other Document Types Preliminary design document Initial Design Document Revised Design Document General Design Document Expanded Design Document Technical Design Document Final Design Document

45. Communication-Flowcharts Flowcharts  A typical technique for diagramming steps in a process  Most developers are familiar

46. Example Flowcharts

47. Communication-Diagrams Associative diagram  Drawing that helps manage and organize information visually Mind Map  A style of associative diagram  Key words and figures are placed on branches

48. Psychology Working Memory  Holds roughly 7 ± 2 items at one time while other cognitive operations on them  Each slide should not have more than 6 items Attention  Method of enhancing perceptions relative to other stimuli in the same environment  How we focus on important things  Limited capacity

49. Psychology Classical conditioning  Reaction to stimulus is conditioned by pairing with another stimulus that elicits the desired response naturally

50. Psychology Unconditioned stimulus – Meat Unconditioned response – Salivation over meat Conditioned stimulus – Tone Conditioned response – Salivation over tone

51. Psychology Operant conditioning  Learning by encouraging or discouraging Operant  A response; the action in question Example: pressing a button Reinforcement contingency  Consistent relationship between the operant and a result in the environment

52. Psychology Reinforcers  Increase the probability an action will be repeated Positive reinforcement  Positive stimulus that reinforces the behavior Ex. Use umbrella and be dry Negative reinforcement  The removal or prevention of a negative stimulus Ex. Use umbrella and keep from getting wet Punishment  Reduces the likelihood of a behavior with a stimulus Ex. Being burned by a hot stove

53. Programming Teams In the 1980s programmers developed the whole game (and did the art and sounds too!) Now programmers write code to support designers and artists (content creators)

54. A Team Picture

55. Different Programs Game code Anything related directly to the game Game engine Any code that can be reused between different games Tools In house tools Plug-ins for off-the-shelf tools

56. Team Organization Programmers often have a background in Computer Science or sciences They usually specialize in some area (AI, graphics, networking) but know about all other areas Teams usually have a lead programmer They sometimes have a lead for each of the major areas

57. Skills and Personalities Successful teams have a mix of personalities and skills:  Experience vs. new ideas  Methodical vs. visionary But hard-working is always the key

58. Methodologies A methodology describes the procedures followed during development to create a game Every company has a methodology (way of doing things), even if they don't explicitly think about it

59. Methodologies: Code and Fix Unfortunately very common Little or no planning Always reacting to events Poor quality and unreliability of finished product “Crunch” time normal

60. Methodologies: Waterfall Very well-defined steps in development Lots of planning ahead of time Great for creating a detailed milestone schedule Doesn't react well to changes Game development is too unpredictable for this approach

61. Methodologies: Iterative Multiple development cycles during a single project  Each delivering a new set of functionality  Refinements are needed The game could ship at any moment Allows for planning but also for changes

62. Methodologies: Agile Methods Deal with the unexpected Very short iterations: 2-3 weeks Iterate based on feedback of what was learned so far Very good visibility of state of game Difficult for publishers or even developers to adopt because it's relatively new

63. Make Coding Easier Version control Coding standards Automated build Code review Unit testing and acceptance testing

64. Version Control Recommended to use for team project Version control is  Database with all the files and history.  Only way to work properly with a team.  Branching and merging can be very useful  Used for source code as well as game assets (text and binary) Tools:  CVS is one of the most popular tool  Source anywhere  SVN

65. Coding standards Coding standards are  Set of coding rules for the whole team to follow  Improves readability and maintainability of the code  Easier to work with other people's code  They vary a lot from place to place Some simple, some complex Get used to different styles Sample standards can be found at: http://www.chris- lott.org/resources/cstyle/CppCodingStandard.htmlhttp://www.chris- lott.org/resources/cstyle/CppCodingStandard.html

66. Automated builds Dedicated build server builds the game from scratch Takes the source code and creates an executable Also takes assets and builds them into game-specific format Build must never break

67. Quality Control Code reviews  Knowing others will read the code will make coding more carefully  Another programmer reads over some code and tries to find problems  Sometimes done before code is committed to version control  Can be beneficial if done correctly Follow coding standards, and put comments

68. Avoid Run-time Errors Run-time errors are hardest to trace and have the biggest damage Initialize variables, use tools (Visual.Net is good at this), check boundaries, etc.  purify on Windows  valgrind on Linux Asserts and crashes  Use asserts anytime the game could crash or something could go very wrong  An assert is a controlled crash in the debug version  Much easier to debug and fix  Happens right where the problem occurred  Don't use them for things that a user could do Open a non-existing file Press the wrong button