Sunday, July 16, 2006

Game Infrastructure

Okay, so you're thinking about rules. You're designing a game, and you've got all these ideas, and you slap together a ruleset to let you play.

Wrong!

It doesn't matter whether it's a computer game or a tabletop. Rules are not the critical part of game design.

"Say whut?"

Yeah, that's right. How your game handles conflicts and wins and losses is just a paintbrush, not a painting. Different rules will let you paint in different ways, but they are't your game. They aren't even close.

You can't just use your paintbrush to paint a picture. You'll just get a vaguely damp piece of paper. Might want to invest in some paint.

Today, I'm talking about paint.

Game infrastructure isn't about a real-world infrastructure to support your game. It's about your game-world situations and systems. Using these, it barely even matters what your rules are, because you're painting the player experience directly.

Let me give an example.

Set in a dystopian future, you are mankind's last hope! Yeah! This game has guns, and health, and a party, and all sorts of running around cities shooting people and buying upgrades! And stuff!

Those are all simply rules - some even not that much.

The infrastructure goes more like this:

There's a trading system that runs between the towns. Various guilds provide various competing pieces of equipment. By allowing the player to help or hinder guilds (on quests or incidentally) the player can change the prices and even the offered goods from various guilds.

This allows you to control the player's motivations. He likes the Scrabble Gun? He's going to help out the guild that makes it.

This isn't just a standalone piece of the game. It hooks into every other facet - rule or infrastructure - simultaneously. What a guild wants done varies from town to town. Characters who are allied with or part of any given guild may join your team... or oppose you, all depending on how you've treated their guild.

It's not just a rule: it is an overarching structure which allows you to develop any part of the game world in tandem with it, and affect any part of the game world with echoes from another part of the game world.

It connects and supports all the game world. Hence the term "infrastructure".

Generally, a game doesn't need very many pieces of global infrastructure. Otherwise, things start to get really, really tangled up! Imagine if a player is faced with guilds, nobility, magicians, demons, knights, political parties, stupid card games - all at once. Things get convoluted really fast. That might not be terrible for the player if you do it well, but it is inefficient: the gain is significantly less and the work significantly more each time you add another piece of global infrastructure.

Instead, what you want to do is very carefully choose what kind of game your infrastructure should support. Each kind of infrastructure will push a different kind of... spin... on your basic rules and player experience.

For example, competing guilds will tend to produce a fractious situation with the player siding with one side or another. This will insure the player is always disliked by somebody, and it will also tend to get the player heavily invested in his favorite group. Fractious situations always do that.

Any infrastructure built out of multiple competing parts will do that, whether it's guilds or nations or a rebellion or knock-knock jokes. I call this a fractious infrastructure. It is very common.

An infrastructure built out of a single, overwhelming faction has the opposite effect: it unifies the player with the characters, and doesn't promote emotional investment. Usually, unified infrastructure like this is found only in small or good-natured games, where there is really nothing to rebel against. The reason to have this kind of infrastructure is to tightly control the player's progression and focus mostly on the game rules, rather than the progression of the game.

A limited infrastructure is one which the players can use up at any speed, but when it's gone, it's gone. An example of this is gold gathering in Warcraft, or the card-based system I created a few posts ago. This is useful for making for extremely cagey play.

A reactive infrastructure is a bit like a cross between fractious and unified infrastructures. This infrastructure reacts to what you do and propagates that throughout the game world. If you buy swords, swords become more or less common. If you kill peasants, people fear you. If you are known as a slave trader, people try to sell you their daughters.

Reactive infrastructures lead to a heavy-agency situation, where the player has an inordinate amount of control over the world. If that's what you're looking for, go for it!

However, it's not quite that easy if you want to include emotional investment. Most reactive systems are totally passive, and you need active systems to make the player invest. An active reactive system requires a lot of effort.

The key is keys: elements which stay the same and push the player into new situations. Keys gather emotional investment, but must do so carefully to avoid giving the player an undue change in control or irritating them with unwarranted stupidity.

I'll have to discuss keys some day soon. They're very, very, very useful, and their use is remarkably subtle.

Now that I'm thinking about it, I wish I'd written this about keys. But the essay is done, now, so I'm not about to delete it.

3 comments:

Craig Perko said...

Of course: they are like a paintbrush. But paintbrushes are only one part of the process.

Craig Perko said...

No worries, I'm not one of those people who assumes the worst.

Patrick said...

Rules are a game at a low enough level, like when you're designing a stuipid card game. Thats why for a 20 old its an extremely instructive exercise. Content and, really, computation brings it into the ballpark you're speaking of. Obviously an active system grounded by the right keys is what we should strive for, I'll post on the infrastructure elements of Fianna in due time. UI forthcoming, about to meet Brenden for some dinner.