Downloadable Drivers License Templates by loe11327

VIEWS: 139 PAGES: 57

More Info
									 CSCE 590E Spring 2007


Game Design II

By Jijun Tang
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
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
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
Positive Feedback

   Amplify changes
   Leads to runaway behavior
   Difficult to make use of




                                From Bob
                                Craig
Negative feedback

   Counteracts changes
   Leads to goal seeking behaviors
   Most common form in systems




                                      From Bob
                                      Craig
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?
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
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
Waterfall vs. Iterative




                   testing
Hats
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)
A Team Picture
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
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
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
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
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
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
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
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
Make Coding Easier

   Version control
   Coding standards
   Automated build
   Code review
   Unit testing and acceptance testing
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
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.html
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
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
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
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
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)
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
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!
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
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
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
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)
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
Platforms

   Browser and downloadable games
     Small games – mostly 2D
     Need to be downloaded quickly

     Run on the PC itself (on any browser
      usually)
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)
Languages

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

   C used to be the most popular
    language for games
   Today, C++ is the language of choice
    for game development
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
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
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
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
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
C++: Weaknesses

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

   Lacking features
     No reflection or introspection features
     No method of object serialization

     No native support for message passing
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
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
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
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
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
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
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
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
Scripting Languages

   Popular scripting languages
     Python
     Lua

     Other off-the-shelf options such as Ruby,
      Perl, Javascript
     Custom scripting languages
           UnrealScript, QuakeC, NWNScript
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?

								
To top