Has anyone else taken a look at Rules of Play (http://www.amazon.com/exec/obidos/tg/detail/-/0262240459/qid=1073367866//ref=sr_8_xs_ap_i1_xgl14/102-7395500-9603313?v=glance&s=books&n=507846)? I had flipped through it at Borders and planned on buying it, but after reading Scott Miller's description (http://dukenukem.typepad.com/game_matters/2004/01/the_problem_wit.html) of it, I decided to pick it up.

I've barely scratched the surface, and I'm enjoying it immensely. It's basically a textbook on game design. Not just computer games, but board games, sports, whatever. Why we play the things that we do; what makes games fun; and so on. It's more academic than something like Rouse's book (http://www.amazon.com/exec/obidos/tg/detail/-/1556227353/qid=1073368177//ref=sr_8_xs_ap_i4_xgl14/102-7395500-9603313?v=glance&s=books&n=507846). Anyway, just thought I'd share. It will be on the book of the week club at some point, even though it will easily take a month to read.

This book's authors presented the topic of this book at the GDC last year('03). I think the topic is great and an important one to address (half the battle), but their presentation at least seemed rather weak. For an 'academic' perspective their presentation seemed very anecdotal, and thrown together unorganized. As I remember they presented a bunch of kind of random anecdotal, and barely related stories as evidence (including one pretty interesting academic reference studying four square) to support a number of classifications, and attributes of rules. Classifying anything in a useful was is generally hard, and I don't think game rules are an exception. I saw the presentation as a work in progress, that I expect will take at least another five years to develop, and flesh out. The thing that was really missing for me was any justification of how their classifications, and definitions are sufficient, complete, useful, or correct.

I'm interested in hearing how the book turns out. I would love to read it, if it significantly one ups the GDC presentation. From the amazon reviews it doesn't sound like it does. I look forward to reading other people's opinions.

I attended a design workshop by Eric Zimmerman a few years ago during an academic game development summit. The workshop was good and I enjoyed it greatly. Eric also gave a keynote which was interesting as well.

I haven't read the book yet, just my 2 cents .. :)

I am about half way through the book and really like it. It is kind of "duh!" in the early parts, but when you actually get into the schemas it's really interesting.

For example one thing I found interesting was the discussion on positive and negative feedback. Positive feedback is rewarding a player for doing something well, negative feedback is helping the losing, or punishing the winning. Positive feedback is pushing the winner closer to winning exponentially, while negative feedback is leveling the playing field regardless of skill. (Positive feedback will bring a game closer to ending, a negative feedback loop will keep players equal).

So look at a RTS. Everyone starts out with equal footing, players who are playing well will end up with higher income, more units, and will exponentially be come more powerful. More units can capture more resources, can produce more units, Rinse, Repeat. POSITIVE loop.

Now consider a FPS mod that gives players who seem to die a lot more starting health. The weak skilled still get a fun playing experience because the game levels the playing field for them. A NEGATIVE feedback loop.

I never really thought about game play in terms of this before. Pretty interesting stuff.

If you are making a similar to an existing game then you don't need this book, because gameplay has already been established. But if you want to really invent your own game with different gameplay, this book is very helpful.

AMAZON REVIEW POINT:
The reason the reviews are quite mixed on amazon is you have to consider the readers. If you are a reader looking for a game design book like the others computer game design books - talking about design documents, fleshing out characters, etc. then you are not going to like this book. If you question "Why is chess a good game, or why in the world is a game like SimCity actually fun" then this is a good book.

The reviews would probably be higher if the book were advertised as "understanding games" rather than "game design".

-Jeff

Originally posted by shaft
So look at a RTS. Everyone starts out with equal footing, players who are playing well will end up with higher income, more units, and will exponentially be come more powerful. More units can capture more resources, can produce more units, Rinse, Repeat. POSITIVE loop.

I experienced such a game many, many times. That first one was called Dune...

Now consider a FPS mod that gives players who seem to die a lot more starting health. The weak skilled still get a fun playing experience because the game levels the playing field for them. A NEGATIVE feedback loop.

that could be a very exciting game because the decision of the game's outcome would fall in the last moments!


I never really thought about game play in terms of this before. Pretty interesting stuff.

I think this is part of the reason most of the mainstream RTS games are boring all the same way: you either get into that POSITIVE loop within your first few clicks, or you simply won't win the game. And this principle is working in nearly all of them. In this regard there is really no difference between the first Dune and the last Warcraft imo.


If you are making a similar to an existing game then you don't need this book, because gameplay has already been established. But if you want to really invent your own game with different gameplay, this book is very helpful.

I think you answered the questions I had about this book anyway. Thank you for that!

There are some built-in negative feedback loops that rebalance gameplay with RTS games, however:

#1 - The bigger you are, the harder it is for you to defend your territory. The Romans found this out the hard way in real life.

#2 - Games with limits to the number of buildings / units also prevent the winning player from gaining too great of an advantage over his opponents - he's going to have a tough time fighting off attacks from two determined opponents simultaneously.

#3 - Some games make the cost of building units (or maintaining units) based upon the total unit count. So the bigger you are, the bigger the portion of your economy you have to spend on maintaining your size.

#4 - The old Civilization answer... the bigger your empire, the more problems you are going to encounter from parts of your empire going bad.

I prefer these "organic" solutions to play balance over blatent handicapping. This always bugged me in the DAYTONA arcade game in head-to-head play... the second-place player could have an indicated speed of LESS than the leading player, but still somehow be gaining on him. It really robbed the game of much of its fun for me.

Actually the books makes reference to the dangers of "obvious" loops. In fact they point out racing games as often using negative feedback to keep the race "Tight", but it is very bad if the player can notice this.

The book doesn't teach you how to design a game, it just points out some things to keep in the back of your head. (also know that the positive/negative loop thing is just one of the MANY schemas in the book for understanding games).

Pretty much in each schema chapter you'll say "I've seen that in game X and that did/didn't work". But the point is, the book gives you a quantitative list of ways to view games and game play. So if you are inventing new game play you have a starting toolbox to work from.

But it's a pretty good toolbox.

PS: In the previous message, You mentiom Civilization - the more problems you have the larger your empire is, IS an example of a negative loop. It's a well done negative loop. But it is a game balancing technique to help keep the players equal longer.

Think of how the gameplay would be different with a POSITIVE feedback loop. The stronger you get, the EASIER it is to manage your empire. That game play tweak would make the game drastically different.

So when the designer of CIV was testing his game, with no feedback loops (larger civs didn't have any more problems then small civs) he probably thought the game ended too quickly, and players didn't get the experience he wanted them to have. Instead he added a negative loop that prolonged the gameplay. He tweaked the "larger civ / more problems" ratio until he got the play he wanted.

A feedback loop doesn't even need to be anything thats coded. Consider the fact that in an RTS the larger the army, the harder it is for the player to manage them all. This is a negative loop that exists in the game play.

Its all just concepts.

@Coyote: re #1: in the typicall RTS the successfull player does not care about defending but about attacking fast and furious.

re "organic solutions" : i think i understand what you mean and i think you make a point. those solutions are elegant and preferable. however the solutions you pointed us out to are, well, not that "realistic". i mean the restrictions of the total # buildings /unit one could build for example is not really "organic" in the sense I think you wanted to show us. an "organic solution" here would be more like increasing the costs of a building with each item you build, so that the player reaches a point where he just can't afford any additional items. the pitty is that would not be realistic aussi :confused:


@shaft: actually such a toolbox is even more valuable as a means of communication. it sort of clarifies the language of what means waht i games/gameplay. i could imagine that 2 gamedevs who both have read the book could communicate in a very efficient manner about games/gameplay. could be very usefull if you design a game within a team of devs.

Originally posted by shaft
Its all just concepts.

Heureka!:D

Picked it up yesterday and it's very interesting. Even if it doesn't improve your game design skills or teach you anything directly applicable it should get you thinking about various aspects of games and game design.