July 19, 2007

Critique: The Chemistry of Game Design

This Blog has moved to

http://www.gamedesignreviews.com/.

This particular Page has moved to

http://gamedesignreviews.com/scrapbook/critique-the-chemistry-of-game-design/.

If you are a recurring visitor, please update your bookmarks & rss feeds. We apologize for the inconvience.

9 comments:

Susan said...

Actually, it is proven. What Cook describes is amazingly similar to basic learning theory. His chain of skill atoms is like a rubric for a lesson plan. Educators use this kind of model all the time to teach. A good game is basically a good teacher. jolifanta.wordpress.com

Krystian Majewski said...

What I would like to know is if this specific Tetris Skill Chain diagram has been empirically tested. If there are people out there who learn Teris just like that.

steve said...

Great points here. I'd like to comment on the paragraph: "Are those really Skill Atoms?"

I would agree that these aren't really "atoms", and a better term should be used. Maybe just "skill". After all, "Reach Platform" isn't even trying to be an atom - it's obviously a combination of jumping and knowing that you can stand on platforms.

However, you could argue that "atom" is indeed a good word, because as far as the player is concerned, it's a discrete skill they have learned. "Riding a bike" could be an atom, and "Riding with no hands" another. So it's not atomic in terms of what the skill involves, but atomic in terms of how the player learned it. This is very player-centric, and thus will probably have some variation from player to player. But I think, if you know your target audience, you can generalize pretty successfully.

And using that player-centric definition, it can help you as a designer. If you find that skill A is not being learned by players, that's probably a sign that it's not "atomic" enough. So, you should break up that skill into smaller ones, A0 and A1. Then, you can find ways to teach A0 and A1, and once they learn those, they can finally learn A. Of course, if A0 is still not small enough, you should divide even more!

Krystian Majewski said...

I wouldn't be so sure if this model is really player-centric. As a player learning to ride a bike is totally different from learning that pressing Button A rotates the Tetris piece. Yet, in this model, both are treated equal.
It seems more like the model is not player-centric but analytic-centric: it focuses on those skills which are easy to analyze.
So breaking down Skill A into A0 and A1 will not necessarily result in more exciting game but in one which yields a more exciting diagram.

Danc said...

Hi krystian!

This is a wonderful post on the essay. Everyone raises some good points. Let's see...

What is it good for?
There are two uses of skill atoms.
- Clarifying a design: This is a nice simple framework with very few exceptions. By mapping your design onto this framework, you are forced to be explicit about things that would otherwise involve hand waving. I find that the simple act of writing something down can help clarify my thought process. There are lots of similar techniques. Skill chains tends to be a bit more comprehensive than most since they clearly include all elements in a functional framework. When you add that new piece of art, you can clearly assign it a purpose. Admittedly, some folks enjoy their fuzzy thinking and random urges to add random things to their random project. In a strongly artist medium like game design, not all creators are interested in analytic thought. :-)

- Regression testing a design: I'm a big believer in personal observation of players. However, there are situations where this is not possible. In any game involving a larger number of players, very long term mastery of skills, or very short term mastery of skills, automated logging becomes interesting. Skill chains become a logical way of instrumenting a game so that you know you are getting useful, clearly organized information back.

It is this second use where I see the most promise for skill chains. Game design is a highly iterative activity. If we can give game developers easy-to-implement feedback mechanisms that let them understand where they fail in a rapid clear-cut manner, they can evolve their games towards a fun state more quickly.

People are not atoms
This is true, yet simple models can still be useful. Both macro and microeconomics offer simplified models of human behavior that can be quite powerful with a limited scope of activities. Just because we can't model everything doesn't mean we shouldn't attempt some measurable aspects of game players. If early scientists had given up because they had incomplete theories, we would never be where we are today. :-)

Limits
There are many limits to skill atoms. I think the strategic processes that some players engage in while playing Chess or Go (or StarCraft or Civilization) are quite difficult to instrument. We can only measure and model that which has happened previously. If each game results in unique situations that require unique improvised skills, then skill atoms aren't very useful.

The flip side of this is that there are many strategies we can measure. For example, in Civilization, the strategy of exhausting the technology tree is explicitly rewarded. My rule of thumb is that a skill chain will never be complete since the players are always smarter than the developers. However, for most games, it can be complete enough to offer insight on the majority of the player's actions.

Has the Tetris skill chain been tested?
I provided this diagram primarily as an example of what a skill chain might look like. I'm sure it could be improved if someone starting instrumenting Tetris and testing how the results held up over a larger population. I used my own experience learning Tetris as the foundation.

There are some obvious dependencies that can be determined logically. It is mechanically impossible for the player to regularly complete lines if they can't rotate or move, for example.

Lovely stuff,
Danc.

ChronoDK said...

As far as I know alchemy is not a real science - chemistry is. That is why I think using alchemy as the metaphor for this model is rather brilliant, and why I feel that your first point of critique is a bit harsh. I don't think the model was ever meant to provide an exact scientific description - it's alchemy, not chemistry.

Other than that - nicely done critique. Those are points I will keep in mind when (not if) I start using the model. Your blog has just been bookmarked in the same folder as DanC's :)

Krystian Majewski said...

Thanks for your answers.

ChronoDK: I think I need to apologize a bit. Of course, my intension was not to argue against scientific thinking. In the contrary: science means developing falsifiable theories. So the way to do science is to be as skeptical as possible. This can be easily misunderstood, especially if the skeptic is not diplomatic enough. ;-)

As for Dancs comments:

I agree that having a model to work on has an advantage over "hand waving". I think the strength of your model is that it helps a game designer be more consequent with his vision then he otherwise would be.
However, I'm a bit unsure how well the results of the model will represent real player behavior. Having some experience in web design I often encountered very organized people doing very logical and scientific predictions of how users will use their website. Those predictions were shattered as soon as real people sat behind the monitor to actually use the website. Users didn't read the text they were supposed to read, they clicked the wrong buttons and did everything backwards. I would like to see how your model works being tested against reality.

Also I have noticed that your systems tend to focus so much trying to measure things, which are difficult to measure. In this system you try to measure what the users learn, in your system of game play notation you try to measure the reward they receive. It might be a good idea to focus more on what you can really measure, like the game itself. Developing a model of a game is difficult enough, no need to make things even harder and add a model of the player on top of it. The disadvantage would be that the results of such model need more interpretation. The advantage would be that as a game designer, you don't have to subscribe to a specific model of mind the player to be able to use the system. I will post an alternative to your system of gameplay notation soon, stay tuned.

Danc said...

I look forward to seeing what you come up with, Kristian.

One of the lessons I've learned about logging is that it helps to have a clearly defined set of questions that you are interested in answering. A framework like skill chains helps you get to those interesting question without reinventing the wheel every time.

Skill atoms ask some really basic questions:
- When do players start performing important actions in the game?
- When does the player experience designer-specified feedback intended to cue them into learning a new set of actions?
- When do players stop performing interesting actions?

These are very measurable activities that can be logged in the game, not pie in the sky theory. The theory, however, suggests what to measure and why it is important. One without the other is flying blind.

Shattered predictions
Skill atoms are not intended to be used as an a priori description of the game design. As you say, when designs meet players, designs get munged. I've been running usability tests this past week and am always impressed at how complex 'obvious' designs turn out. To imagine that you can jot down a design for skill atoms out of your head and that you'll have created a great game before it is built is foolish.

Instead, you accumulate skill atoms through iterative building, testing and watching players interact with a system. With the complex simulations (even Tetris!) at the heart of most games, it is difficult to predict what skills are valuable until you play. The good designer observes what behaviors are interesting and then codifies them with feedback systems so that they are accessible by and interesting to a broader population. Actions + Simulation + Feedback. In other words, they create skill atoms.

And then you test your design. Did people learn the skill? Did they use it? For how long? Watch them, did they become frustrated or bored when the logging system said that they had stopped pursuing a skill? At this point, you revise your atoms. Ideally the design improves. :-)

take care
Danc.

Krystian Majewski said...

Thanks for taking your time to explain your approach, Danc. I think I have a better understanding of the model now. It is an interesting concept and I'm looking forward to the next essay.

Until then, here is the post about the notation system I mentioned.