[...] You’ve been blogged on this post by Raph Koster, author of the “theory of fun” paper you’ve cited! http://www.raphkoster.com/2008/01/25/psysal-causal-chains-and-snowfall/SQUEE!(Reply to this)(Thread) psysal 2008-01-29 07:18 pm UTC (link) That’s cool! Thanks for the [...]

Games of pure chance can’t be. But I’m not sure you’d call them games. Most definitions of “game” allow them, so I can see an argument either way.

Definitely. I have commented before how training is effectively a game nested in the larger game as well.

[organize team]
[develop procedures and strategies]
[establish team roles]

I’ve played New York City’s “Midnight Madness” puzzle hunt for the past couple years, and my team (Red) spends a lot of time before the game building the team, strategizing, and assigning roles. For many of us, this is half the fun of the game.

Maybe this is just equivalent to practice, and of course all games can be practiced. Failing to practice or strategize doesn’t change the nature of the game, so perhaps this sort of thing has no place in a strict analysis of the “objectives of how to win a soccer game.” Similarly, the structure of Midnight Madness remains the same even though other teams do not organize well.

But it seems to me that team- and community-building objectives are compelling goals for many game players, and are therefore relevant to a game designer using a game grammar to understand how people play.

This at once is very logical and insightful into how often this sort of thinking doesn’t happen in games I find this method though survives addative game design (add features to a core system) better than it does subtractive (build a complex system of features and then remove some).

This is true, but it’s not a very big problem if you built the game with this in mind to begin with. It’s not hard to be subtractive about the systems if you built them using the more addative method. It’s only when you start with a big complex system and then try to make it work from that top down level that it’ll break things if you’re not paying attention. But Raph typically talks about starting at the smallest “game” possible and working up anyway. And besides, having a chart like that makes it extremely clear what you can and cannot remove from your system. If you try to yank a dependency you’ll know that you’re likely to break the entire chain that relies on that dependency. And you’ll also know more clearly if you don’t need something… if there are more parallel paths to completing a task than you need, you can remove some of them without worrying, and if something doesn’t actually act as a dependency to your main goals you can consider removing it completely.

“The person with the ball cannot be closer to the goal than all the defenders.”

I CRY NERF!

Pretty neat.