Sunday, October 26, 2008

The Princess Rescuing Application: Slides

Last Thursday, I gave a talk on game design to the local Seattle chapter of the IxDA, an interaction design group. About 100 folks were in attendance and the catered finger food was downright delicious. Other speakers included George Amaya, who spoke about recent research on social/party games, and Mark Long, CEO of Zombie. Mark gave a lovely presentation on how narrative and storytelling immerse players. His new game looks gorgeous.

My talk was on building an application that rescued princesses. The goal was to give interaction designers some insight into how game design might be applied to the domain of more utilitarian applications. The talk was recorded and should be up sometime this week. When it appears online, I'll link to the video from this post.

Here are my slides both in PDF format and as the original PowerPoint.
The notes fields are heavily annotated with more details about each visual. For those of you who attended, this deck also includes a third section on game design patterns that I didn't have time to cover in the time allotted.

take care


  1. Just imagined a world where these slides are daily breakfast in "game design academies". Delicious!

    This evening I'll check my app for gamepatterns.

  2. As usual, a very interesting read!

    I imagine that the new controversial interface of Microsoft Word actually makes a lot of sense this way. Compared to older versions, it took the essential features and made them big and shiny. The others options are still there and can be added. What is missing of course is the modular way of teaching the user new skills besides those basic features.

    I think application are fundamentally different from games at one point however: the missing linearity. Games are deterministic, even in massive open world games like Oblivion or GTAIV the first steps teach the player the main skills at first and don't leave him a choice to skip this. But does that work for application design? I can hardly tell my user that he first has to learn how to format text before I let him print it. It sounds harder to me than you admit...

  3. Hi there. Your article is really inspiring. Thank you for sharing.
    I'm an ex-game designer, and I'm now working as interaction designer; I'm interested mainly in community design, and I'm studying exactly what you say: how to make a playful UX using game design techniques. I'm currently working with several other people, to a Playful UX Manifesto. It would be nice to keep in touch.
    Can you contact me at
    Thank you!

  4. Danc,

    What I really like about this presentation is that I'd already read your Chemistry of Game Design article and immediately bought into the skill atoms / STARS atom and chains philosophy for breaking a game down and explaining how it works. I hadn't thought to apply that to a "functional software application" because I continuously tend to forget that games are in fact the same thing, just FUN. And when software can make you forget that, you know it's very well designed. If a user is having fun and/or being very productive, they won't consider it a tool but the actual, necessary workspace.

    This is an excellent presentation, and what really scares me is that analogy between Maya and Spore. Even though your disclaimer holds true and Maya has quite a lot more depth, the point still comes out: does it matter? If a user could learn a concept like 3D modeling by use of either tool, which would they (almost 90% of the time) select to use?

    And one of the better aspects I've seen is the use of the "inventory" screen. It makes perfect sense to keep the interface the user is working with as simplified and as clean as possible, focusing on the core functionality they'll be utilizing 90% of the time to remain there, clearly visible and easily accessible, while having the capability to have small sections/interfaces for modular tools selected from an inventory of features that you've built up over time.

    The only thing I can't fathom how to apply to a software tool or application is the level contexts, i.e. a sandbox environment where they can learn new tools or the original skill sets.

    Most users I know don't want to spend time "learning" a tool beyond what they need to get the job done, and they don't want to sit and test as much as they want to just use it and make sure it's right and move forward. Therefore, they look purely at functionality to achieve an objective as opposed to exploratory learning where they try out the all of the capabilities of their software and try and learn new skills.

    Anyways, great presentation, something I'll be forwarding to at least a few people and talking about for a whlie, and I look forward to seeing the video.

    Take care,

  5. Excellent presentation, inspiring and insightful as always. Thanks for sharing!

    This ties directly into what I'm trying to do for the protein-folding game Foldit, which currently is an uneasy mix of app and game. Besides for level design, the biggest potential area for improvement would be in the inventory screen. I'll see what the others on the project think of that. Though Foldit is also lacking in nesting of explicit goals - that's another thing to work on.

    Anyway, really enjoyed reading the slides - thanks and keep up the good work. :) Hope you're doing well.

  6. MMM, did something get chopped off the bottom of page 32 of the pdf? (no other comment just yet, I'm still reading.)

  7. Hello,

    Great slides and all, as usual. :)

    I wonder, is there some basic terms of use with the content you publish. Not talking about ideas, but exact copies and derivate works of your texts.

    I think you released some content into the public domain and was wondering what you think of putting your articles & slides under some free works license.

    This would allow for copying your idea descriptions without having to pretend to have come up with them by oneself for example ;)

    Well and besides that it would of course allow mirroring your site in case something ever happens to it or it's content :|

  8. So what's the application equivalent of Myst?

  9. Great and thought-provoking presentation. I was wondering what you'd say failed in the infamous Microsoft paperclip contextual help?

  10. i'll take a stab at Clippy (who wouldn't?).

    Clippy inverted the STARS cycle. The *user* gave *Clippy* a stimulus, and then Clippy started going through an inventory of the skills he had available for you.

    So he took all the "fun" out of gaining a new skill--the user might not be punished, but he also never has a sense of accomplishment.

    In addition, Clippy's reaction to the stimulus provided by the user wasn't nuanced enough. He was as likely to interrupt you over a mis-click as he was when you actually were trying something new. In a way, he was effective punishment, because he showed up whenever you did something wrong.


  11. Thank you for your presentation. We are using it with a homeschool coop group in Research Triangle, NC, where kids design a math game together. Your presentation is very useful in our endeavor, and, no less importantly, fun.

    We have just arrived at the delicious difficulty that kills most "learning games" in the crib. When we start inventing the game from game mechanics, math is nowhere to be seen. When we start from math, because of kids' past math experiences, game mechanics are not forthcoming at all. Next on the agenda: exploring mathematics deep enough to see its playful, interesting sides.

  12. opening yr post with a jpeg that asks you to click it, surrounded by whitespace that also accepts the click, that just leads to a uselessly magnified version of the jpeg, is really unfriendly design. just sayin'

  13. Jef Raskin wrote in his book "The Humane Interface" about the dangers of making an application like a game. A fundamental goal of game design is to produce a challenge (a fun challenge, hopefully). This is done via various obstacles, and artificial goals, and a reward/punishment system.

    Hopefully, when you're designing an application, the interface is not so challenging that you need to apply gimmicks to get people to learn it. Hopefully, if you do end up going that way, the basic mechanism is not through progressively changing the rules and complexity of the interface. And finally, one truly hopes that the goals in your application are genuine and not artificial.

    The goal in a word processor is to write something useful, or inspiring. How is the computer going to know what you've written, in order to reward you correctly? How would you structure that task into exploratory levels?

    The goal in photoshop is to create inspiring artworks, or touch up photos, or create a website mock up. How do you measure the progress of such a task and reward it?

    Or is the goal in your presentation simply learning the interface? In which case, I ask, how do you support that goal using these game skills, without undermining the goal by constantly changing the interface around? (and thus ruining habit forming)

  14. Excellent presentation.
    I wonder if applications that try to become closer to games by incorporating fun mechanics (as oppossed to games that try to become closer to applications by incorporating serious objectives) can be labeled "Serious Games" as well.
    Are you applying these techniques in the design of products that you're involved with?

  15. I like that Super Metroid example! I used the exact same example in my thesis last year:

    My thesis actually started out with the goal of adding game-like playful interaction to traditional applications, but I was kind of sidetracked and ended up focusing mostly on improving interaction in games :)

  16. Breton Slivka, if I may attempt to answer for Danc, I would say that yes, this presentation is simply about learning the interface of an app.

    It sounds like you are concerned that changing the interface around as the user becomes more proficient would make the interface even harder to understand. Are you worried that changing the rules and increasing complexity over time would force the user to relearn the app over and over instead of once and for all like in a traditional interface?

    I just read some reviews and excerpts of The Humane Interface, and I don't think there is any incompatibility between that and what Danc writes here. In fact, as I'm reading about the "Myth of the Beginner-Expert Dichotomy" it seems they are very much in agreement.

    As I understand Danc to be saying, give the user a consistent Inventory interface which they can form habits about early on, and then let the user *choose* the specific features that they'd like to add or remove, at their own pace. This is the opposite of automatically and confusingly phasing into a set of features deemed "beginner" and another set deemed "expert".

    What makes this work is that each Item (modular feature) is completely encapsulated and works the same every time, so a user's habits regarding an individual Item never change. Since the user also has habits about the unchanging Inventory interface, they can easily add or remove Items as needed to change the complexity of the app interface in a way that keeps it all understandable.

    There would be no invisibly changing modes to confuse the users. Instead, these Items would be the equivalent of holding down a button to enable a mode - all the changes are directly user-directed, and would necessarily be mirrored by a corresponding change in the user's mental model of the app's state.

    It's like the Jenova Chen's idea of active flow adjustment, or player-oriented DDA, as opposed to the passive, automatic DDA (Dynamic Difficulty Adjustment) that is so maligned by game designers.

    "The only solution is to embed choices into the gameplay, let the player treat choices as part of the play and eventually ignore them. Thus their choices will become intuitive and reflecting their actual desires."
    ~ Jenova Chen

    This is what Jenova Chen is saying, and it seems to me that both Daniel Cook and Jef Raskin are saying the same thing as well.

  17. This is a great insight into both game and application design. If only more applications and games took what you are talking about into account.

  18. That was wonderfully spilled out. It should be taught. Thanks a Bunch

  19. Very well put together article. And I always love a good The Legend of Zelda reference (IMO, the greatest game of all time).

    The only problem I had is that you said Spore is a lot more like a game than Maya, but did not in any way explain how. All I saw was a very large confusing palette of tools and a model elephant. I'd be very curious to see/hear what Spore's "game-like" elements are.

  20. Excellent presentation, thanks for it.

  21. The best text I readed about this theme.


  22. Excelent work, Thanks.

    You help me a lot.