csce 590e spring 2007 game design ii by jijun tang
TRANSCRIPT
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?