1. Lecture 1 CS171: Game Design Studio 1I UC Santa Cruz School of Engineering www.soe.ucsc.edu/classes/cmps171/Winter2010 michaelm@cs.ucsc.edu 5 January 2010

2. UC SANTA CRUZ 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. UC SANTA CRUZ Class mechanics  Syllabus online at  www.soe.ucsc.edu/classes/cmps171/Winter10/  Login and password for secure page (readings)  Team feedback tool

4. UC SANTA CRUZ 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. UC SANTA CRUZ 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. UC SANTA CRUZ Generalization links  Generalization links indicate subclass relationships  An open arrow points to the parent

7. UC SANTA CRUZ 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. UC SANTA CRUZ 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. UC SANTA CRUZ 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. UC SANTA CRUZ 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  You’ll 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. UC SANTA CRUZ Creating class diagrams for games  When creating a game architecture, you’ll want to make sure you’ve 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. UC SANTA CRUZ Discovering your object taxonomy  The golden rule: Nouns are classes, verbs are methods  Once you’ve 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 you’ll be including some engine (library) classes in your structure diagram