I feel it's important to note that there's a difference between game design as applied to actual games (video games, computer games) and game mechanics design as applied to non-games (applications, web sites). Modern game design (for those designers that apply methods and procedures instead of doing it holistically) deals with the whole scope of the game experience: the topology of interaction (1D, 2D, 3D, 4D, directions between each dimension, etc.), choices the player has made up to each interaction, core mechanics (verbs describing actions all the down to the button press), on and on.
These are important when crafting entire experiences that are essentially self-contained. These are how you tell interactive stories.
Ribbon Hero is a great example of the state of the art of game mechanics as applied to non-games. We're essentially cherry-picking a few of these ideas to make our applications a little less dull, to increase user engagement, but Ribbon Hero isn't the entirety of Microsoft Word, it's a bit of a game atop Microsoft Word. (If we were building an entire word processor as a game, we'd probably want to consider the whole gamut of design knowledge, of course.)
Still, all of the game mechanics references below build on the assumption that you already know not just what a game is, but also why games are compelling for players. This is why they're ordered chronologically. You could skip to the end, read just the 2010 papers and presentations, but you could end up designing features without knowing why they work and be unable to diagnose them if they fail or invent new ones when your competitors copy you. Don't cheat.
That said, in a two hour workshop, we don't have time to discuss all of these presentations, so the high-level summary about the parts that everyone agrees on are:
- Games are puzzles, playing to the pattern-matching parts of our brains
- This means we get better at them, until we've figured them out, and then we're happy, and then we're bored
- Games need structure/mediation to facilitate exploratory learning
- Not a simple, single feature in the Web 2.0 vein, but a complex application with individual features (goals, tools) exposed one at a time, leading to eventual mastery
- The building blocks (atoms) of "real" game design can all be applied to our applications
- a status metric if public
- a measure of progress
- can drive loyalty if redeemable
- can drive community and express social values if players can give each other points (ratings, favorites)
a prerequisite for leaderboards, showing absolute or relative rankings
a prerequisite for levels, a shorthand for an amount of accomplishment
the context of the task at hand, all your previous experience plus something new
- individually, reaching a new level unlocks the reward of "something new"
- globally, players advance through your game or application and eventually require providing new features (or resetting everyone)
- the goals a player has: accomplishing a task, gaining an item (learning a tool/feature)
- one or more quests exist within the context of a level
- the player must be rewarded or punished in a timely fashion to associate the actions they're taking (items, tools and action) with the result (stimulus)
- doing so focuses the player's attention and helps them learn faster
- game boards in traditional games show global feedback of the entire game's state
- for badges (achievements), these are collections for social (these are the things I've done) and personal (I like collecting everything/particular things) fulfillment
- for items (tools), these are the skills (features) the player has developed (learned)
- Additional aspects we won't be dealing with today
- explicit interactions with others: taking turns, trading items, having a conversation
- implicit interactions with others: gifting points, voting up, leaving a comment
- not theming or moving UI elements, but picking the piece that represents you in a traditional game, or dressing up your avatar in a 3D game
- builds loyalty and is an investment
- Advancement versus Elder games
- once your player has mastered the game (ceased advancement), the elder game is emergent, free-form, where the user is proficient and is on their own
Last workshop's brainstorming exercise game up with at least two calendar/time management designs that included achievements. Today, we're going to brainstorm how each of Points, Levels, Quests, Feedback and Inventory can be applied to calendaring.
The scenario is the same:
- You have to travel downtown first thing in the morning
- You then have to be in Cedar Park for an hour-long meeting starting at noon
- You need to be reminded when you have to leave downtown by to make it
- You have anywhere from 45 minutes to two hours of work to accomplish
- Where you work or how long it takes is up to you, but you need to represent setup and teardown time, and travel on either end.
- You have to attend the design workshop at 7pm, here on Anderson, halfway between Mopac and 183.
You have to consider the use cases of entering the data beforehand, and then later being exposed to the data, and where Points, Levels, Quests, Feedback and Inventory come into play.
Selected whiteboard notes
The Lessons of Lucasfilm's Habitat (you can skip "Implementation" and "The Lessons" as they're technical bits)
A Theory of Fun, Raph Koster
Game Design Principles, Nicole Lazzaro
Videogames as language classes, Ryan Freebern
Putting the Fun in Functional, Amy Jo Kim
Add Some XBOX To Your UX : SXSW 2010 Talk : Josh Knowles, Josh Knowles