1. CSCE 590E Spring 2007 Game Design II By Jijun Tang

2. Announcements We will meet in 2A21 on Wednesday Please bring laptops on Wednesday Please install Adobe Flash 8.0 professional trial version Think about group name and log

3. Design of Everyday Things Norman ’ s five principles of design  Visibility Making the parts visible  Mappings Understandable relationships between controls and actions  Affordances The perceived uses of an object  Constraints Prevent the user from doing things they shouldn ’ t  Feedback Reporting what has been done and accomplished

4. System Components Objects  Pieces of a system Attributes  Properties determining what objects are Behaviors  Actions the objects can perform Relationships  How the behavior and attributes of objects affect each other while the system operates

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

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

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

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

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

10. Waterfall vs. Iterative testing

11. Hats

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

13. A Team Picture

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

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

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

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

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

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

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

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

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

23. 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) CVS is one of the most popular tool

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

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

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

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

28. Testing Unit tests  With very large codebases, it's difficult to make changes without breaking features  Unit tests make sure nothing changes  Test very small bits of functionality in isolation  Build them and run them frequently  Good test harness is essential

29. Testing Acceptance test (or functional tests)  High level tests that exercise lots of functionality  They usually run the whole game checking for specific features  Having them automated means they can run very frequently (with every build)

30. Bug Report and Trace Bug database  Keep a list of all bugs, a description, their status, and priority  Team uses it to know what to fix next  Gives an idea of how far the game is from shipping  Doesn't prevent bugs, just helps fix them more efficiently

31. Leveraging Existing Code A lot of code that games use is the same It's a total waste of time to write it over and over Instead, spend your time in what's going to make your game unique Avoid Not Invented Here (NIH) syndrome!

32. Leveraging Existing Code Reuse code from previous project  Easier in a large company if you have an engine and tools group Use freeware code and tools  No support  Make sure license allows it

33. Leveraging Existing Code Middleware  Companies provide with components used in game development physics, animation, graphics, etc Commercial game engines  You can license the whole engine and tools and a single package  Good if you're doing exactly that type of game

34. Platforms PCs  Includes Windows, Linux, and Macs  Can have very powerful hardware  Easier to patch and allow for user content  Need to support a wide range of hardware and drivers  Games need to play nice with other programs and the operating system

35. Platforms Game consoles  Current generation PS2, Xbox, GameCube  Fixed set of hardware – never changes  Usually use custom APIs – not very mature  They have very limited resources  Currently much better sales than PC games (although that changes over time)

36. Platforms Handhelds and mobiles  Extremely limited hardware (although rapidly improving)  Programming often done in lower-level languages (C or even assembly) However, DS and PSP in C++  Much smaller projects, teams, and budgets  Emerging market

37. Platforms Browser and downloadable games  Small games – mostly 2D  Need to be downloaded quickly  Run on the PC itself (on any browser usually)

38. Platforms Multiplatform development  The closer the platforms, the easier the development  Use abstraction layers to hide platform- specific code, especially for GUI  Choice: Target the minimum common denominator for platforms (easy, cheap) Or do the best you can in each platform (more expensive and time consuming)

39. Languages C/C++ Java Script: Flash, Python, LISP, etc. C# XNA for PC and Xbox

40. C++ C used to be the most popular language for games Today, C++ is the language of choice for game development

41. C++: Strengths Performance  Control over low-level functionality (memory management, etc)  Can switch to assembly or C whenever necessary  Good interface with OS, hardware, and other languages

42. C++: Strengths High-level, object-oriented  High-level language features are essential for making today's complex games  Has inheritance, polymorphism, templates, and exceptions  Strongly typed, so it has improved reliability

43. C++: Strengths C Heritage  C++ is the only high-level language that is backwards-compatible with C  Has APIs and compiler support in all platforms  Easier transition for experienced programmers

44. C++: Strengths Libraries  STL (Standard Template Library) Comprehensive set of standard libraries  Boost: widely used library with wide variety of functionality  Many commercial C++ libraries also available

45. C++: Weaknesses Too low-level  Still forces programmers to deal with low- level issues  Too error-prone  Attention to low-level details is overkill for high-level features or tools

46. C++: Weaknesses Too complicated  Because of its C heritage, C++ is very complicated  Long learning curve to become competent with the language

47. C++: Weaknesses Lacking features  No reflection or introspection features  No method of object serialization  No native support for message passing

48. C++: Weaknesses Slow iteration  C++ is fully compiled into binary format from source code  Compiling large numbers of files is very slow  This will only become more of a problem as games become more complex

49. C++: When to Use It? When performance is crucial If your current code base is mostly C and C++ If you have a lot of in-house expertise in C++ Avoid using it for high-level code, such as tools

50. Java for Game Development Why use Java?  It's a high-level OO language that simplifies many C++ features  Adds several useful high-level features  Easy to develop for multiple platforms because of intermediate bytecode  Good library support

51. Java for Game Development Performance  Has typically been Java's weak point  Has improved in the last few years: still not up to C++ level, but very close  Uses Just-In-Time compiling and HotSpot optimizations  Now has high-performance libraries  Also has access to native functionality

52. Java for Game Development Platforms  Well suited to downloadable and browser- based games  Dominates development on mobile and handheld platforms  Possible to use in full PC games More likely to be embedded into a game  Not currently used in consoles

53. Java in Game Development Commercial games using Java  Downloadable games like those from PopCap Games: Mummy Maze, etc  Online card games  PC games using Java as a scripting language: Vampire: The Masquerade, Star Wars Galaxies  PC games fully written in Java: You Don't Know Jack, Who Wants to Be a Millionaire

54. Scripting Languages Why use scripting languages?  Ease and speed of development  Short iteration time  Code becomes a game asset  Offer additional features and are customizable

55. Scripting Languages Drawbacks  Slow performance  Limited tool support  Dynamic typing makes it difficult to catch errors  Awkward interface with the rest of the game  Difficult to implement well

56. Scripting Languages Popular scripting languages  Python  Lua  Other off-the-shelf options such as Ruby, Perl, Javascript  Custom scripting languages UnrealScript, QuakeC, NWNScript

57. Scripting Languages How to choose a scripting language  Consider whether you need one at all  What features do you need?  What kind of performance do you need?  What debugging facilities does the language have?  On what platforms does it need to run?  What resources and expertise are available?