Formal Abstract Design Tools & Mechanics, Dynamics, Aesthetics

1. Formal Abstract Design Tools&Mechanics, Dynamics, Aesthetics FADT: Doug Church MDA: Marc Leblanc

2. Why FADT? • Communicate design concepts • Shared experiences allow you, to a degree, to circumvent the need for language • But that’s rooted in common experience and assumes similar interpretation • Other media have a way to talk about their design:

3. Why FADT? Other media have a way to talk about their design, as confusing as they may be: • Mise-en-scene • Fabula • Leitmotiv

4. What happens when… • You haven’t played the same game? • When the team gets large? • When you want to pass on your experiences? • When you want to mix/cross genre elements?

5. Formal: precise definition, sharable • Abstract: focus on underlying ideas not game specific implementation (reward, not gold pieces or magic armor) • Design: game design! • Tools: to be applied to creating games

6. Three FADTs • Intention • Consequence • Narrative Tradeoffs and incompatibility OK

7. FADTs do NOT: • Tell you how to design a game • Tell you how to balance a game What FADTs do: • How to discuss your game design • How to describe design ideas to steal… I mean, borrow • How to discuss your design goals

8. Intention • Making an implementable plan of one's own creation in response to the current situation in the game world and one's understanding of the game play options.

9. Perceivable Consequence • A clear reaction from the game world to the action of the player. • NOT cause and effect: an error message, any response, is not perceivable consequence

10. Story/Narrative • The narrative thread, whether designer-driven or player-driven, that binds events together and drives the player forward toward completion of the game.

11. Let’s apply to a game Resident Evil • Intention • Perceivable Consequence • Story

12. MDA • Mechanics • Dynamics • Aesthetics • …Another kind of FADT

13. State Games are State Machines • All gamesare computer games. • Game design transcends media. Input Output Rules (Player) (Graphics/Sound)

14. Games as Software Code

15. Games as Software Code Process

16. Games as Software Code Process Requirements

17. Games as Software Code Process Requirements Rules

18. Games as Software Code Process Requirements Rules Game “Session”

19. Games as Software Code Process Requirements Rules Game “Session” “Fun”

20. A Design Vocabulary Code Process Requirements Rules Game “Session” “Fun”

21. A Design Vocabulary Code Mechanics Process Requirements Rules Game “Session” “Fun”

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

23. A Design Vocabulary Mechanics Dynamics Aesthetics

24. Definitions • Mechanics: The rules and concepts that formally specify the game-as-system. • Dynamics: The run-time behavior of the game-as-system. • Aesthetics: The desirable emotional responses evoked by the game dynamics.

25. Mechanics Dynamics Aesthetics The Designer and The Player   Designer Player

26. Mechanics Dynamics Aesthetics The Player’s Perspective

27. Mechanics Dynamics Aesthetics The Designer’s Perspective

28. MDA is a “Taxonomy” of Design Knowledge • Knowledge of Aesthetics • Knowledge of Dynamics • Knowledge of Mechanics • Knowledge of the interactions between them.

29. Dynamics • How did the rules create the fun? • What patterns emerged in the dynamics of the game?

30. Discussion • What other settings, genres or subjects might fit this game?

31. Part II: Aesthetics Explored

32. “Requirements Analysis”for Games • We need to understand the emotional requirements of our software.

33. Requirements Analysis… Scenario: The customer wants to cancel an order and get a refund. Actions: • Log onto website. • Navigate to “pending orders” page. • Click “cancel” button next to order.

34. …for Games? Scenario: The player wants to blow stuff up. Actions: • Find rocket launcher. • Find victims. • Kick major booty.

35. What’s the Difference? • With productivity software, the user brings his goals to the application. • With games, the application brings goals to the user. • Software eschews emergent behavior. • Games embrace it.

36. We Need an Aesthetic Lexicon We need to get past words like “fun” and “gameplay.” • What kinds of “fun” are there? • How will we know a particular kind of “fun” when we see it?

37. 1. Sensation Game as sense-pleasure 2. Fantasy Game as make-believe 3. Narrative Game as drama 4. Challenge Game as obstacle course Eight Kinds of "Fun"

38. 1. Sensation Game as sense-pleasure 2. Fantasy Game as make-believe 3. Narrative Game as drama 4. Challenge Game as obstacle course 5. Fellowship Game as social framework 6. Discovery Game as uncharted territory 7. Expression Game as self-discovery 8. Submission Game as pastime Eight Kinds of "Fun"

39. Clarifying Our Aesthetics • Charades is “fun.” • Quake is “fun.” • Final Fantasy is “fun.”

40. Clarifying Our Aesthetics • Charades: Fellowship, Expression, Challenge • Quake: Challenge, Sensation, Competition, Fantasy • Final Fantasy: Fantasy, Narrative, Expression, Discovery, Challenge, Masochism • Each game pursues multiple aesthetics. • No Grand Unified Theory.

41. Clarifying Our Goals • As designers, we can choose certain aesthetics as goals for our game design. • As with other software, our process is driven by requirements, not features. • However, one word is not enough to describe a goal.

42. Aesthetic Models • Our substitute for “use cases” or “scenarios.” • A rigorous definition of an aesthetic goal. • Serves as an “aesthetic compass.” • States criteria for success as well as possible modes of failure. Some examples…

43. Goal: Competition Model: A game is competitive if: • Players are adversaries. • Players have an ongoing emotional investment in defeating each other. Some Failure Modes: • A player feels that he can’t win. • A player can’t measure his progress.

44. Goal: Realistic Flight Simulation Possible Models: Our flight dynamics are realistic if: • They match a mathematical formula, or, • They pass our “realism checklist,” Failure Modes: • Counter-intuitive system behavior.

45. Goal: Drama Model: A game is dramatic if: • Its central conflict creates dramatic tension. • The dramatic tension builds towards a climax.

46. Goal: Drama Failure Modes: • Lack of conflict. • Lack of tension. • The conflict’s outcome is obvious (no uncertainty). • No sense of forward progress (no inevitability). • Tension does not increase towards a climax.

47. Part III: Dynamics in Detail

48. Understanding Dynamics • What about the game’s behavior can we predict before we go to playtest? • How can we explain the behavior that we observe?

49. State Formalizing Game Dynamics Input Output Rules (Player) (Graphics/Sound) The “State Machine” Model Examples: Chess, Quake

50. Models of Game Dynamics • Again, no Grand Unified Theory • Instead, a collection of many Dynamic Models. • Dynamics models are analytical in nature. Some examples…