Tuesday, October 24, 2006

What Aren't Game Mechanics?

Lost Garden made a long post on game mechanics. I will now proceed to disagree with it. Not because it's wrong, just because it's a bit cockeyed.

First, he defines feedback loops in terms of the user experience. There's nothing fundamentally wrong with viewing everything from the user's point of view, but I suggest viewing the user as part of the software. In which case, a feedback loop's definitions change to include the way that the software changes the situation in a way which changes the software's situation.

For example, if the user walks on to that big mountain, the program doesn't just change what the user sees. The program makes thousands of internal adjustments - it feeds on itself, being directed by the user, and the user just gets to see hints. This allows the program to have an "internal reality" which the player sees and deciphers. It's not just "what the player sees" that matters.

This might seem like a small difference, but it's really a critical one. His stated view underestimates the independence and power of the game. This is somewhat harmful for one-player designs, but crippling for multiplayer and, FSM forbid, massively multiplayer games. These kinds of games don't simply "provide feedback to the player". They provide a window into which the players try to make sense of the feedback algorithms the game runs.

The rest of his essay falls into the same POV. While he obviously knows that games are complex and somewhat independent entities, he approaches everything from the angle of what the player sees, does, etc.

This is a flawed approach for one reason which I would think obvious. The "nested feedback loop" idea is powerful because the player spends a lot of time trying to master the various feedback loops and deal with the permutating situations. However, thinking about everything in terms of teasing and pleasing the player can easily lead you to create a "shallow" feedback system which provides immediate fun and gratification, but doesn't offer any of the long-lasting play.

This is a very common mistake, and if there was one mistake I could keep designers from making, I think that would be it. It's very common, even in AAA games, to add more flavor, more minigames, more doodads... but each of these things adds almost nothing to the interconnected complexity of the game, and they rarely build off the same bases as the other kinds of play.

Essentially, if you think in terms of what pleases the player most, you're likely to feed the player "junk food" play. It's the shiniest, tastiest kind, in that initial moment.

But if you think of the player as part of the game system - a knob torquing feedback loops - you can create games which are suitably deep. Deep games provide just as much fun, for longer, for cheaper. Obviously, you still have to the think of the player. But now you think of the player as part of a whole, rather than the whole that the game is part of. And you design the game to run through all the variations and paces at a fun rate. Call it "game-centric games", if you like.

I know it sounds like I'm connecting two separate things. "Good rule design and how you view the player... they don't seem connected!"

But they are. An artist can't paint very well if he views his art as something which serves the paper. A doctor can't doctor very well if he views his patient's comfort higher than their health.

Take the long-term view: your players are pieces of your game, and your game is part of them. While in play, they are one entity, and you have to give it a nice workout.


Patrick said...
This comment has been removed by a blog administrator.
Craig Perko said...

Sorry, Patrick. If it makes my brain hurt to read a comment, I delete it.

The funny thing is, the comment was agreeing with me. :P

Danc said...

Appreciate the commentary!

Here is the thing though: Nothing in the essay talks about the time scale of the mechanics. I left that out since it was fodder for another essay. There is no bias towards simple quick and dirty mechanics. It may be a pet peeve, but it isn't in the essay.

The mechanics as described deal quite nicely with big long term deep system. I particularly think they fit some of the system in MMORPGs most clearly. There is even ample room for nice detailed involved simulations. Hence the big box that says 'simulations'

The whole discussion about burnout, networks of mechanics, milking, etc was about taking a simple concept and describing how you can build bigger, deeper games.

Just because you have simple building blocks doesn't mean the end result has to be simple. Legos, man. Legos! :-)

take care

Craig Perko said...

Of course I understand simple can be deep. Usually, that's the way you get deep.

I'm saying that, IMO, the more you think about the game being a large, internally-consistant spinning thing, the more likely you are to favor deep gameplay. On the other hand, if you think in terms of "players are happy if they are entertained", the design will tend towards shallow entertainment.

Patrick said...

Let me put my take in plain terms:

Part of the joy and beauty of interactivity is the mystery involved, therefore respecting the loop as having imperfect information (even if the game technically offers perfect information, I'm referring to the processes underneath) helps one design a better interactive experience. This seesm like a paradox, but you do the user more of a service if you look at the whole loop holistically than if you put the user in the center. The user will always lack information about the back end, and the system/designer will always lack information about the user.