1 / 96

IAT 410: Advanced Game Design

IAT 410: Advanced Game Design. Instructors: Magy Seif El-Nasr, Eric Yang Teaching Assistant: Ai Nakatani . Class Overview. Developing a game. Learn by doing (design, develop, test, prototype cycle) Learn about tools Learn to Critique other’s work. Lab assignments.

yin
Download Presentation

IAT 410: Advanced Game Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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”

More Related