IAT 410: Advanced Game Design

1. IAT 410: Advanced Game Design Instructors: Magy Seif El-Nasr, Eric Yang Teaching Assistant: Ai Nakatani

2. Class Overview Developinga game • Learn by doing (design, develop, test, prototype cycle) • Learn about tools • Learn to Critique other’s work Lab assignments Blogs (individual assignment)

3. What would you learn? • Why games work, Game design principles (what?) • Interaction models • Balance • Feedback • Motivation • Immersion • Design and Development cycle (how?) • Tools: rendering engines, game engines, prototyping tools

4. Books • Tracy Fullerton’s Book: Game Design Workshop: Designing, Prototyping, and Playtesting. 2004

5. Structure • Lectures: more on how-tos rather than theory (that is IAT 312) • Labs • Lab tutorial • Lab assignment • Presentations • Quick • Be prepared • Send us presentations before class (MUST)

6. Schedule • Course webpage: http://www.sfu.ca/~magy/courses/IAT410-Fall07/index.html • Tentative at: http://www.sfu.ca/~magy/courses/IAT410-Fall07/schedule.htmlThis is where you go for DUES and UPDATES

7. Grading • Project • Group of 5 (individual grade: weekly assessment, and attendance) • 45% on deliverables • 5% Concept presentation (individual) • 15% paper prototype, testing doc, and presentation • 15% prototype, testing doc, and presentation • 10% final game, testing doc, and presentation • 20% labs • 30% critiques (on ur blogs) • 5% weekly assessment

8. IMPORTANT • All deadline are to be submitted before the class, i.e. Monday midnight • Send all assignments, presentations, and documentations by email to magy@sfu.ca with subject [IAT-410], all emails without this subject will be ignored. • Note about LABS, no email necessary (check marked)

9. Some games from previous classes

10. Your Next assignments: Setup blog for this class and email me the link (easy?)DUE Monday 9/10, 11:59p Game Concept – Presented and Voted onDUE Monday 9/17, 11:59pPresented in labs, 9/18 No labs or lecture next week, get ready for the concept competition

11. Concept Document How to present your game idea?

12. How do you design a good game? • Do a lot of research • Have a good team • Test, test, test • Prototypes (small, use all tools possible) • You can use some of the frameworks around: • MDA framework (this week’s labs) • Game balance, fit to an old model (e.g. rock, paper, scissors) • Read Tracy’s book (chapters 1-5) • There are several other good books and papers I can recommend

13. Time for Game Trivia Let’s see if you know the games I play …

14. Game Trivia

15. Game Trivia

16. Game Trivia

17. Game Trivia

18. Game Trivia

19. Game Trivia

20. Game Trivia

21. Game Trivia

22. Game Trivia

23. Concept Document Outside Resources: Fogg Conceptual Designs (handout)

24. Concept Document • Use the template supplied by Fogg • 1. Title Page • Title • Visual to situate your game, genre • Design Challenge: what is new about your game • 2. Overview • Genre, if one exists • discuss aesthetics of your game (use MDA to refer to a list of aesthetics)

25. Concept Document • 3. User Description • Who is the audience? Age? Gamers? • 4. Storyboard of experience : discuss gameplay • What is the player doing? GamePlay • point out the features of your game • show the mechanics that will achieve the aesthetics you pointed out earlier • Discuss underlying systems of your game

26. Concept Document • 5. Prototyping: nothing there • 6. Features/Functionality • More details on the game system • More details on the aesthetics • More details on the mechanics of the game • 7. Justification of the Design • Is it based an already accepted system? Or new (can argue for originality)? • Basically: why should we give you money to build this game?

27. Concept Document • 8. User Testing: nothing there • 9. Shortcomings • List problems of the design • List Risks • 10. Expansion • What are the alternative designs you are thinking of trying? • 11. Next Steps • 12. Summary

28. MDA framework • Slides are Marc’s slides, used at GDC 2005 • Marc is a great guy, look up his game Oasis (Warning: very very addictive), but a MUST play

29. The Designer-Player Relationship   Designer Player

30. The Designer-Player Relationship   Game Designer Player

31. The Designer-Player Relationship   Creates Consumes Game Designer Player

32. The Designer-Player Relationship   Creates Consumes Game Designer Book Player

33. The Designer-Player Relationship   Creates Consumes Game Designer Book Movie Player

34. The Designer-Player Relationship   Creates Consumes Game Designer Book Movie Painting Player

35. The Designer-Player Relationship   Creates Consumes Game Designer Book Movie Painting Chair Player

36. The Designer-Player Relationship   Creates Consumes Game Designer Book Movie Painting Chair Car Player

37. The Designer-Player Relationship   Creates Consumes Game Designer Book Movie Painting Chair Car Pizza Player

38. The Designer-Player Relationship   Creates Consumes Game Designer Player The difference is the way that games are consumed.

39. An Extreme Opposite Example:A Theatrical Play The “design team” knows: • Script • Lighting • Acoustics • Seating • Intermissions

40. Games, on the Contrary The designer doesn’t know: • When will the player play? • How often? For how long? • Where? With Whom? And most importantly... • What will happen during the game?

41. Obligatory Editorial This lack of predictability is the essence of play. It should be embraced, not eschewed.

42. Games asSoftware Code

43. Games asSoftware Code Process

44. Games asSoftware Code Process Requirements

45. Games asSoftware Code Process Requirements Rules

46. Games asSoftware Code Process Requirements Rules Activity

47. Games asSoftware Code Process Requirements Rules Activity “Fun”

48. A Design Vocabulary Code Process Requirements Rules Activity “Fun”

49. A Design Vocabulary Code Mechanics Process Requirements Rules Activity “Fun”

50. A Design Vocabulary Mechanics Process Dynamics Requirements Game “Fun”