1. UML Sequence Diagrams (Slides adapted from Michael Mateas) UC Santa Cruz CMPS 171 – Game Design Studio II www.soe.ucsc.edu/classes/cmps171/Winter11 ejw@cs.ucsc.edu 13 January 2011

2. UC SANTA CRUZ Lab Update  Alienware machines  OS update: Melissa?  IPs now registered with PS3 edu site  Still need to create accounts  Have not received list of email/usernames for 2nd Mac team  Still working on SOE-WPA wireless  Global Game Jam  January 28-30  Please avoid using game lab this weekend, starting late Friday afternoon  OK to conduct a daily scrum meeting (but then should find another place to work)  Only time during year you’ll be kicked out for a long time.  Discussion: video recording of lab (accessible to all in class)

3. UC SANTA CRUZ Microsoft Visit  Will have visitors from Microsoft Game Studios in class next Tuesday  Jason Major (Halo series game engine programmer)  Recruiters (Cordy Rierson, Rick Martinez, MGS)  Presentation open to all  Also, recruiting focused presentation at 4pm, E2 180 (Simularium)  More detail on recruiting, internships, permanent positions  Bring a resume  Schwag

4. UC SANTA CRUZ Upcoming deadlines  Thursday (Jan. 13): sprint 1 plan due  Due today, by midnight  Friday (Jan. 14): scrum board up, updated burndown charts  Many teams already have scrum boards up – good job!!  Friday (Jan. 14): team status reporting  Due by midnight  Report on team activities this week  Be sure to use new team status reporting template  Several students didn’t last week, and lost points as a result  See http://www.soe.ucsc.edu/classes/cmps171/Winter11/team-status-report-template.html  Note: this week begins different reporting template for Scrum Masters  Tuesday (Jan. 18): Sprint 1 design document  Tuesday (Jan. 18): Winter release art asset plan

5. UC SANTA CRUZ Sprint 1 Design Document  Details will appear on web in next 1-2 days  Required elements  Title section  UML structure diagram for your design  Printout of 1 or more pages  UML sequence diagrams for your design  If creating your own game engine, must include sequences for:  Initialization, menu system, main game loop, player collision, enemy collision, and end of level  If using an existing game engine, must include sequences that show how your code is called from the game engine  Less clear to me which sequences are most important here, depends on the game engine. In general want to represent interesting and/or complex sequences  Also: need to be prepared to give a presentation on this on Thursday, January 20 (either in-class or in-section)  Schedule either in-class or in-section with Ken

6. UC SANTA CRUZ Art/audio asset production plan  Goal of this document  Identify art assets and audio assets needed for this release  Describe who will be creating these art & audio assets  Required elements  Title section  Inventory of art assets required  A list of every texture, every 3d model, every 2d sprite (and whether animated or not), background image, menu background, HUD image, etc.  If it’s art, and in release 1, it needs to be listed  For each piece of art  List the name of the person creating that art  List the Sprint in which they will create this art  A signature/email from each artist listed indicating they understand the plan, and agree to it (if they disagree, implies you need to negotiate with them and/or find more artists)  Inventory of audio assets required  A list of every song, explosion, sound effect, etc.  If it makes a noise, and is in release 1, it needs to be listed  For each audio file  List the name of the person creating that audio  List the Sprint in which they will create this audio  A signature/email from each artist listed indicating they understand the plan, and agree to it (if they disagree, implies you need to negotiate with them and/or find more artists)  If you don’t have artists/musicians yet  Instead of list of names, provide plan for how your team will find these people

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

8. UC SANTA CRUZ UML Sequence diagrams  Sequence diagrams capture the temporal order of interactions between system objects (might be literal code objects or subsystems)  You should capture a sequence diagram for each of the important chains of events that happens in your game  Collision detection  Controller event (player pressing a button)  Main loop  NPC action selection (if there are significant inter-object interactions)  Interface interactions

9. UC SANTA CRUZ Lifelines  Lifelines represent object instances or roles  The box at the top of the lifeline names the object instance or role  A dotted line under the box indicates how long the object lives Object name Class

10. UC SANTA CRUZ Messages  Messages indicate method invocations between objects – more generally, messages sent between roles  Bars on the lifeline indicate the period of time during which execution/handling of the message takes place  Dotted lines indicate return  Returns are optional, though it’s recommended to use them if you are returning a value

11. UC SANTA CRUZ Instances may create new instances  If you need to show one instance creating another, use the > message stereotype  StarUML doesn’t let a > message (stimulus) connect directly to a object/role box, so here’s an approach you can use

12. UC SANTA CRUZ Self messages and call stacks  Objects/roles can send messages to themselves  If working with object instances, this represents a method on an instance invoking other methods on the same instance  Bars are nested to indicate the call stack

13. UC SANTA CRUZ Indicating if-then semantics on individual messages  Guards are used to indicate if-then semantics on individual messages  The message is sent only if the test in square braces is true guard Multi-instance

14. UC SANTA CRUZ Combined fragments  Combined fragments frame a subset of object interations  They are used to show that a subsequence has alternatives (if then blocks) or loops  Here’s a loop example Loop control (use name field) Annotation label used for comment

15. UC SANTA CRUZ Alt fragments  Alt fragments indicate if-then blocks  Use interaction operands to indicate alternative sequences [foreach character]loop Test Invinciblealt c : CollisionManager char : Character hero : Character 8 [collision] : isAttacking() 9 : doDamage() 10 : kill() 11 : damage() [invincible] [!invincible]

16. UC SANTA CRUZ Miscellaneous features  All the message types used in the example are blocking message types (normal method invocations)  Non-blocking messages (e.g. sending a request via an IPC mechanism like sockets) are indicated with open arrowhead  StarUML doesn’t support this, so use annotation  Parallel processes can be indicated with a par combined fragment  Various view options exist  Hide/show sequence numbers, show message arguments, etc.  Important! View options can’t be retrospectively applied. So select view options before starting diagramming