Monday, November 10, 2008

Project Horseshoe 2008: There and back again

I’m writing this on the long flight back from Project Horseshoe 2008. The last bittersweet night, we stayed up till five AM playing games and talking about games. The conversation shifted from the slow death of games as we knew them, to fresh games that will change the world, to the little tips we use to thrive each day. There is something distinctly surreal about chatting quietly with such an intimate knowledgeable group during the wee hours of the morning, there on a lonely porch in the uncharted depths of Texas. And yes, there were indeed baby racoons.

This year, I took a risk. If you’ve been following this blog for a bit, you know that I’ve been working on skill atom techniques for modeling gameplay. I’ve written about it. I’ve used it myself. There has even been a talk or two. Yet, aside from a few furtive emails with other happy heretics, I’ve never had a chance to do the following:
  1. Explain the model to a crowd of natural skeptics, working designers who have been successfully building games for years.
  2. Get them to tear it apart.
The cautionary tale of the secret paint formula
I’m reminded of a story that Norman Rockwell used to tell. He once became good friends with a fellow painter who was famous for his rendering of luminescent, sensual skin tones. The painter used a secret formula for his paint and he guarded it jealously from potential imitators. When the painter died, he willed his greatest gift, his secret paint formula to Rockwell.

Rockwell excitedly tried out the formula, but ultimately found it disappointing. The paint was too slick and difficult to control, so he gave up on it and instead fell back on his own preferred techniques. The real secret had never been the paint formula. It was just one little piece of the painter’s vast organic, highly individual process. The real secret was the intuitive wisdom that comes from making a thousand paintings. Sadly, such a thing is not transferable to others. When he died, his specific way of creating paintings died with him.

Are skill atoms the same thing as the secret paint formula? Are they a glossy coat of theoretical hand waving that only works for the people who invented it? Many people I’ve talked with see ‘game grammar’ as nothing more than a time wasting intellectualization of a fundamentally intuitive activity. I went into the weekend with this thought very much at the forefront of my mind.

Why stop there?
If all we had done was validate or invalidate the skill atom model for simple games, it would have been a useful weekend. But by god, this is Project Horseshoe and people are nothing if not psychotically ambitious. To up the ante, our group decided to apply skill atoms to multiplayer games. I’ve never done this.

How do you model a deeply psychological behavior like bluffing? Gifting? Competition? Collaboration? Goodness! I didn’t have a lot of answers prepared for this topic and honestly expected that the skill atom model would immediately collapse under the weight of all the crazy things that happen as soon as you add two or more players to a game design. All it would have taken is one smart designer to raise a single counter example and my fragile model would burst apart, defeated by reality.

Some questions that I had included:
  • Could we even begin to talk about multiplayer with skill atoms? The alternative is that this is a model that is limited to only single player experiences. That would be like coming up with a model of physics that worked for one ball in a vacuum, but wasn’t useful for something useful like say…building bridges.
  • Would the system scale to complex systems? Often when you use a diagramming technique (like UML or state diagrams) to understand real world projects, the resulting diagrams becomes so convoluted that the model does more to confuse than to illuminate.
  • Would the system be useful to designers during every day work? It is much easier to come up with a academic system of analyzing games that works best if you are an ivory tower dweller who can devote hundreds of hours to breaking down each interaction into pretty diagrams filled with obscure invented lingo. However, I’m looking for utilitarian tools that can be applied in that critical 10-minute gap between playing a prototype and deciding what to try next.
  • Can this system be taught to other designers? Like the secret paint formula, most game models I run across are only useful to their inventors. If I can’t observe other designers applying the model successfully without my intervention there is something horribly wrong with the approach.
We ripped the skill atoms apart. We analyzed multiplayer M.U.L.E. We looked at charades and then took on football and buffing in MMOs. We used skill atoms to prototype a new multiplayer game about gifting using a bag of plastic Indians. At some point, not so long from now, our group will come out with a report. In that report, we’ll be blunt about what we found. What worked? What was flawed? The results are fascinating.

Our team’s report will be one of several reports to come out of Project Horseshoe by groups of game designers just as crazy and inspired as we were. If any one of these reports starts gaining momentum, the world of gaming as we know will change. It turns out that moving our industry forward isn’t about complaining. It is about getting smart people together where they have the time and the space to think. Grab a beer (Aventinus Double Bock, no less), join the mind meld and use the vast pool of centuries (!) of game design experience to come up with real solutions. Then follow up again and again and again.

In that spirit, I can't wait to share our final report with everyone.

Time for some much needed sleep, chock full of dreams.

PS: Warm kudos to George, Linda and Teresa for putting Project Horseshoe on. It is obviously a labor of love and is utterly unique compared to the other events and conferences I’ve attended. If you ever get an invite, don’t hesitate to go.


  1. Although it was a pleasure to meet you, Dan, and to meet many of the other attendees, overall I personally found Project Horseshoe a complete waste of time and (a lot of) money. The conference isn't a good fit for everyone, and it is worthwhile to mention this instead of offering a blanket recommendation.

  2. Wow, sorry you feel that way Allen. Apparently PH isn't a good fit for everyone, but I'll agree with Danc here: for some, it's just fantastic. I think it very much depends on what your expectations are coming in...

    Anyway, Dan, here's the book that came to mind after your presentation:

    Well worth the read.

  3. It was great being part of such a spirited group.
    The best thing about this experience, for me, is that it pointed to clear new paths worth exploring. And since more than half of innovation is asking the right questions, I feel it's an excellent outcome.

    Allen, I'm sorry this was your experience. I did feel a bit frustrated last year too and, if it hadn't be for the feeling of connection and potential, I wouldn't have come back. I'm glad I did.

  4. Without knowing what you thought I would offer up this model to work with skill atoms on something like a multi player game. I'll run the condensed one here cause I would fail to write up a fleshed out model stream-of-conciousness style.

    The skill atom is one level of abstraction within the whole system.

    Or to use a very primitive particle model we have something which goes from atom up to material.

    "Killing a Goomba" is on the level of skill atom, (or even a small chain of skill atoms).

    "Killing [any killable thing] by jumping" is a skill molecule.

    "Rescue the princess" is a skill material, which is composed of several of these molecules.

    This also goes backwards into smaller sub-particles beneath the atom.

    "To Jump" would be the level of a skill proton.

    "Press Button" (on the mouse/joystick) would be found on the level of the skill quark.

    Now the problem of defining "bluffing in poker" as a skill it does not exist on the same level of abstraction as the skill atoms, is belongs in the realm of Skill Material, composed of the molecules of "reading card value skill molecule" and "reading opponent probable card values skill molecule" and "reading opponent behavioural pattern skill molecules".

    Now we can try and disassemble these molecules into something resembling a chain of skill atoms. But I wont try that here. ^^

    What is interesting is that each level of abstraction has its own interaction circuit. Even the Quark of pressing the button has a decision, a verb several states and feedback. This turtles up to rescuing the princess or winning by bluffing.

    Or maybe I am just crazy.

  5. Hey Danc,
    As always, I'm looking forward to reading that report on Skill Atoms. Oh, thanks for not using a creepy spider for PH Post this year.

  6. Hey Dan, it's funny I just discovered Project Horseshoe and have been fantasizing about going there, and then here you are writing about it on your way back from it! Awesome. It comforts me greatly to know that people ARE talking about game design in a scientific way... from reading mainstream gaming media, I sometimes feel like I'm the only one who thinks about games the way I do. Anyway, I've been a fan of yours a long time, and keep up the wonderful work!

  7. Does anyone know of an online forum for or including several game designers? I'm a part of a Game Development Club at my school and I'm pretty much the only designer (we have like 30 programmers, an artist, and me), so my thinking buddy is an excellent pad of paper. All the online communities I've found seem to be dominated by programmers.

    I highly recommend spending several hours in a library putting off homework and just THINKING and writing down everything you think up, good or bad, on paper. It's easier to assess something that's not inside your brain, and writing down thoughts makes room for new ones. It's the best means of designing games I know, and it's great for other things.

    But it'd be nice to do so with other people!

  8. Danc,

    A quick response to some of your thoughts:

    * "Would the system be useful to designers during every day work"

    ** The skill atom theory helps me a lot, mainly in two ways. One, it helps me to make more informed design decisions that I feel more confident in. Two, it really helps to communicate the otherwise difficult notion of a user's progression in a product.

    * "Can this system be taught to other designers?"

    ** After reading your Princess-presentation, I've briefly outlined the core idea to a few friends who also work as designers. They've all immediately picked up on the simplicity and immediate implementability (?) of the concept.

    I should add that I've worked in different ways with games as tools for learning, and normally loathe simplified models of didactics. Hence I approached your concept with a fair share of skepticism. It took some time before I accepted that it would really be of use.

    Like you say, the tool is only valuable if it fits the artist. For me it's a perfect fit. I've tried it out for problems that had haunted me for a while, and I immediately found new ways forward. For that, I thank you! I'll keep using and promoting the model, no matter what you find in your report ;-)

  9. @kelsey - have you tried the IGDA? There's an online forum for game design, and a student mailing list to contact other students (including, presumably, some designers). Obviously, if you attend a conference like GDC you'll also meet a lot of other people who you can follow up with by email.

    @DanC - sounds exciting! Can't wait to hear what your group came up with. Though... you couldn't at least give a hint as to what state the Skill Atom model is in? Did it at least partially survive?

  10. @Vincent: The baby raccoon was for you. :-)

    Thanks for all the good comments. The skill atoms survived the exercise, but we had to flesh out the process of how players choose to continue looping in an atom, or if they bail out to attempt a different skill. The nice thing is that many of our model tweaks help out the single player applications as well.

    take care

  11. PH was a fantastic experience for me all around. I had a fantastic time working through these questions with you and the rest of the group. George, Teresa, and Linda deserve all the credit for creating an environment where the types of discussions and discoveries we had around skill atoms could happen.

  12. Good stuff Dan, waiting with baited breath on the Horseshoe articles.

    I've been following your blog with interest for a while, and just recently decided to have a bash at retroactively applying it to my current project (a game mod), I initially was just going to drop you an email as it's pretty rough stuff, but some of the aspects mentioned in your post (multiplayer/oponents) prompted me to throw it up on a blog.

  13. Courageous act, most people would just keep their perfect model in a golden pedestal, refusing to let it out, and tout that it didn't take off because "people don't understand". I know I would :) I'm glad you're really pushing this thing forward. The first time I read about it I was blown away, and I really hope you give it the amount of polish and thought it deserves!

  14. Looking forward to the report! Attending Project Horseshoe is a far-in-the-future goal of mine. The writeups that follow have profoundly influenced me as a game designer.

  15. @Ian: You have good taste in Associations! Thanks.

    @Danc: I forgot to note (as these things are best conveyed parenthetically) that your blog is among my favorites! By which I do not mean that I have it bookmarked, but that if a post of yours appears in my RSS reader, I read it first.

  16. Danc,

    I've read about your Project Horseshoe experience from last year and this year as well and I want to say I'm thoroughly impressed with the types of discussions and the reports that come out of it. I'm actually a native of Texas and was wondering how/when you folks convene.

    Now, I want to say that I'm not an active game designer in that I spend much of my time at work or in my self-owned software consulting business, but it's always a pleasure and an intellectually stimulating activity to discuss games and game design. I play quite a few of them myself and have fully fleshed out my own ideas for two or three games, without ever having the opportunity to implement them.

    The thing is, my process has been somewhat mentally blocked (or delayed, rather) because of the fact that I try and think in terms of skill atoms while writing out the ideas for the game. The game design documents are long and tedious in their description of behaviors, because I've found that ever since I've read up on skill atoms, I tend to think of my game design in those mannerisms and even try to drive the creative process using that very precise, logical method, which so far hasn't been very conducive for creative purposes. I have a feeling if I actually decide on the basic principles of gameplay first, and make a tree structure/breakdown (as Tex did) it would assist in my finalization of the GDD process and help fill out some of the missing details as opposed to doing it from the start and being a mental obstacle as it is right now.

    For example, I'll think "it would be cool if this turn-based strategy game worked with squads instead of individual units. The squad leaders of the many squads on the field will be controlled by the player and issue orders to their AI-controlled squadmates for them to carry out a tactic or formation in the following turn" and then I'll think of the skill chain to try to accurately capture this and have to go back several steps to get anywhere. The breakdown of the above would go something similar to thsi: "The player can use squad leaders to issue orders." -> "The player can select the squad leader" + "The squad leader can issue orders." -> "The player selects the entire squad, which automatically selects the leader for the player." + "The player selects a squad by hovering the targetting reticle over the squad and pressing (A) on the control pad." | "The orders can be issued by pressing (A) on the control pad." | "The orders that can be issued are so and so." and further and further. But, the problem being that each and every interaction causes me to think of breaking it down to it's smallest part, which is both tedious for a GDD (and probably should be reserved more for the detailed design document and/or game manual) and a roadblock/obstacle. I just can't seem to help it since I know the theory and it makes sense to me on a lot of levels.

    It would be really cool (and very appreciated) to see an article on your process for a game development life cycle, along with any criticisms or lessons learned from post mortems. How do you go about getting your ideas vs actual design out of the way and then focus on the more detailed aspects, like audio, video, modeling, etc.?

    Ahad L. Amdani

  17. Ahad makes a good point. Although I think it's too much to ask of you right now: my impression so far is that the groundwork is set, but there's a bit more to be done to come up with a specific "guide" to this approach.

    My guess here is that, to make things more practical, in these early stages of game design you need to "broaden up" the scope of each atom (ie, be less precise in your descriptions). Especially when a mechanic is already a well-established tripe in games; for example, you can ignore the details of the squad behavior and describe it as a single atom, while you work other equally "big"/"broad" atoms into the design. Only after that will you break up each one into more and more atoms.

    (This intuition comes from my background in pattern recognition, in that when searching a state-space you probably should allow bigger changes at first -- ie, try to mix and match bigger atoms, and only after that deal with more and more details, in order to converge efficiently to a solution you'll be happy with. Dealing only with local features -- ie, small atoms, like the situation you're describing, you're more likely to hit barriers and stop at local minima because you're discouraging big changes; this is because it's conceptually harder to mix and match a big set of small atoms than a very small set of big atoms.)

    This leads me to the question I've been meaning to ask Danc: in your method, do you allow any kind of abstractions (such as, for example, the "big atoms" I mentioned), or is it always laid out in a large network with the smallest possible atoms?

  18. @Jotaf: See, that's what I think is the best way to approach the GDD, it's just hard when I know I really do need to break it down eventually to keep myself from doing so right away. I definately agree with the statement that it's conceptually very difficult to mix and match the big set of small atoms rather than the small set of big molecules/chains.

    I guess I should think of the general game design in the way of skill chains and skill molecules. I believe these closest resemble the "abstractions" you're referring to Jotaf.

    @Danc: Just realized there's a registration form at; I hope to see that report soon, I'm going through the 2006 and 2007 reports again in an effort to review and compare against what actually occurred in industry since then.

    I'd love to post an article comparing what was discussed in the Game Design Think Tank sessions versus what came of it in industry within the next couple of years. Do the 2008 reports already touch on the subject?

  19. Process for using skill atoms
    The most effective way I've found of using the skill atoms is as an analytic tool as part of interative development.

    - Generate a concept. Use napkins if this is what it takes.
    - Get what you believe the core of the concept in a playable form. This means prototyping, not document writing.
    - Play the prototype. If it is at a point where it might be worth someone's time, get them to play it and observe their reactions.
    - Note what goes wrong as well as intriguing sparks of fun.
    - Analyze the problems using skill atoms. This helps you understand more clearly what the root cause of the issue might be.
    - Attempt to flesh out sparks of fun using skill atoms. Can you identify the skills that are being triggered? Can you improve the stimulus to help the player focus more attention on learning those skills? Can you adjust the rules so those skills become richer?
    - Implement the highest priority fixes.
    - Repeat. Over time your skill trees will grow.

    I tend not to use skill atoms in a prescriptive manner. They are less A) a method of writing static design documents and more B) a magnifying glass that lets you identify where the design is broken so you can find solutions faster.

    The former is not that interesting of a problem. The later is what game designers do every day.

    Being blocked
    If you are blocked, the two things I find that work best are talking to others or building a working version of what you are stuggling with. Both give you more information which is often the key thing that helps you break through blocks.

    Big vs. Small atoms: What would be an example in your mind of a 'big' atom? Skill atoms are good at describing skills. There may be other tools that are more useful if you are trying to describe something other than a skill.

    take care

  20. @Danc: I see, so you've found more utility from this concept as a fine-tuning tool during playtesting and prototype analysis. Very interesting.

    As for being blocked - the first suggestion is exactly what I'm doing at this point in time, to kind of flesh out the idea among my peers and see if they think it's both fun and new/interesting, or at least tried and true.

    By "big" atoms (of skill) I, at least, meant combinations of skills, forming skill chains or skill molecules.

    For instance, the skill of commanding your army into a new formation breaks down into the skill of commanding your individual squads into their sub-formations which breaks down to being able to select your squad leader and issuing an order as well as being able to identify which sub-formations lead to which (full) formations.

    Maybe my understanding of the skill atom theory is incorrect, but I would consider the totally abstracted, top-level skill (commanding army into new formation) a skill molecule which is composed of the skill chains that tie together the individual skill atoms (pushing a button to select the squad leader, pushing a button to issue an order, identifying sub-formations that lead to full formations, etc.) - all of this molecule then being considered a skill atom if the design considers only high-level areas.

    So, say, the design says:

    You'll beat a level by commanding your army into the proper formation to effectively march against the opposing army and defeating them or completing an objective.

    So, in that respect, the skill atoms would be: Beating a level, Commanding an Army Into Proper Formations, Effectively Marching Against The Opposition, and Completing the Objective.

    Those skill atoms are actually molecules of chains and futher broken-down atoms.

    At least, that is my understanding as it stands. The stimulus and interaction of commanding an army is broken down in the end to being able to push a button to select your squad leaders and issuing orders.

    I use that as a simplified example, but I hope I get my point across about how I'm using skill atoms as an abstraction of player interactions within the scope of their play experience. This could be incorrect from your original concept.

    I look forward to trying out my game design, anyhow.

    Ahad L. Amdani