Lecture 1 CS171: Game Design Studio 1I

1
Lecture 1CS171 Game Design Studio 1I

• UC Santa Cruz
• School of Engineering
• www.soe.ucsc.edu/classes/cmps171/Winter2008
• michaelm_at_cs.ucsc.edu
• 7 January 2009

2
The year-long game design studio sequence

• CS 170
• Exposure to a variety of alternative game designs
• Indie, serious games, political games, art games,
  etc.
• Individual concept development
• Team formation and game design
• CS 171
• The heart of making the game
• Course is process-based, providing a series of
  milestones for completing game
• Some design work will continue, especially early
  in the quarter
• Like the second half of last quarter, there will
  be lots of presentations
• CS 172
• Emergency design revisions (the oh my god
  moment)
• Final playtesting and tuning
• Finish game
• Win awards at indie game competitions

3
Class mechanics

• Syllabus online at
• www.soe.ucsc.edu/classes/cmps171/Winter09/
• Login and password for secure page (readings)
• User name cmps171
• Password N2JmMD
• Migration from slugforge to gforge

4
Introduction to UML

• The Unified Modeling Language (UML) consists of a
  collection of diagrams for describing a software
  design
• Creating a UML description forces a team to
  develop a software design before diving into the
  nitty-gritty of writing code

5
Class diagrams

• A class diagram describes your object oriented
  design
• Classes are drawn as boxes.
• Members are listed inside the box. Fields appear
  in the top sub-box, methods in the bottom sub-box
• Access indicated by (public), - (private),
  (protected) and (package)
• Classes are connected together with lines
  indicating class relationships

6
Generalization links

• Generalization links indicate subclass
  relationships
• An open arrow points to the parent

7
Aggregation links

• Aggregation indicates that instances of one class
  will contain instances of another class
• In aggregation, the lifespan of the enclosed
  instances is independent of the lifespan of the
  enclosing instance
• Container classes (lists, hashtables, etc.) will
  always have aggregation links to what they
  contain, though many classes will contain member
  instances of other classes

8
Composition links

• Composition links indicate that one class
  contains instances of another class, but the
  contained class is created and destroyed with the
  instance class
• The contained instances will be destroyed when
  the containing instance is destroyed
• In C, this is the difference between a member
  variable of type MyClass and MyClass

9
Realization

• Realization links relates a class that implements
  (realizes) a behavior specified by another model
  element, to the model element that specifies this
  behavior
• In Java, classes that implement an interface
  realize the interface
• In C, classes that are children of a pure
  abstract class realize behavior specified by the
  pure abstract class

10
Dependency links

• Dependency links represent arbitrary relationship
  between classes, where a change made to one class
  may require a change to another class
• The arrow points from the dependent towards the
  independent class
• Youll want to use link labels for dependency
  links
• On the class diagram, only indicate important
  dependency relationships (ones that help
  communicate in the team)

11
Creating class diagrams for games

• When creating a game architecture, youll want to
  make sure youve covered at least the following
  game elements in your class (structure) diagram
• Input handling
• Representation of game levels, if present
• Player class
• Enemy classes, including container holding active
  enemies
• Physical object classes, including a container to
  hold them
• Collision detection
• Classes for drawing player, enemies and other
  game objects
• Classes for handling audio
• Classes for game interface (menu system) and HUD

12
Discovering your object taxonomy

• The golden rule Nouns are classes, verbs are
  methods
• Once youve done a preliminary analysis of the
  nouns (objects) in your architecture, organize
  them into an inheritance hierarchy
• Inheritance organizes objects that share
  functionality
• Once you have a preliminary understanding of your
  inheritance hierarchy, then work on composition
  and aggregation (which objects contain which
  other objects)
• Many of you will be building your code within an
  engine or library, typically subclassing library
  classes to create game-specific functionality. So
  youll be including some engine (library) classes
  in your structure diagram