Saturday, December 30, 2006

Choosing Choices


Well, okay, there's no magic number. But I like the number three. That's how many choices I try to give whenever players hit a non-skill-based moment.

There's a lot of these moments in a lot of different games. Choosing whether to take a left or a right in a dungeon. Choosing whether to save someone or rob them. Choosing whether to buy a sword or a bow. Choosing what building to build, what party members to take, and so on.

What I mean by "non-skill-based" is kind of iffy. After all, there's skill in equipping your party or building a building or even choosing left from right. But it's not the primary play skill. Whereas the primary play skill needs to be deep and diverse, secondary choices are usually less about skill and more about personal preferences. If there is a best choice, then why offer the others?

These choices are very important to a player's sense of agency - his sense that his choices affect the game world. The going idea is that a player should be able to do as many different things as he wants. This leads to games like Grand Theft Auto, where you can run around and go just about anywhere whenever you want. Of course, this has side effects that you may not like.

First: Because you are offering such a wide ability to choose, you are essentially turning that facet of the game into a primary play skill. In GTA, knowing where things were and how to navigate the map was an important play skill, unlike in most other games, where navigating the map is simply a way to get a breather between today's plot event and tomorrow's plot event.

Second: For various reasons, navigating space/plot in a freeform manner generally results in an extremely shallow set of results. The typical response to this is to seed the map with random fun stuff that has little to do with long-term play. A nifty weapon, a fun comment, a shiny car. These things reward players who decide to participate in the shallow (but broad) play you give them without actually requiring complex long-term play changes.

Third: Has high development cost.

(See? Three choices of poison. I like three.)

Taking the "cheap" way out, and giving them only a few choices, is generally a more effective way to actually give players agency. A good example of this is a game where you can choose out of three approaches to any given problem (typically, stealth, fighting, and magic/ranged/social). In this case, even though the end results are essentially the same (beat the level), the ability to choose an approach gives the player a lot of agency.

Of course, the "cheap" way comes with its share of problems.

First: Insufficient options. A lot of times, the choices you offer will simply not appeal to a player. This is especially true of dialogue trees. Trying to provide choices to please everyone is a bit like trying to lift a couch with a toothpick. Even if you're incredibly skilled, the method is simply not suitable.

By making options "in-game" rather than "breaking the fourth wall", you can reduce this problem hugely. For example, offering weapons in-game and letting the player choose which weapon he wants is much better than asking him whether he wants to be stealthy or brutal.

Second: "Gilded Cage" issues. When a player is made to choose from too few artificial choices or artificially restricted in some way, it really steals away the agency and can be very irritating. This is especially true of dialogue trees. Every drawback is especially true of dialogue trees. :P

Some games try to provide a huge number of options while either making them all equate to the same few choices or while making the vast majority of the options so obviously unappetizing that nobody would choose them. This works pretty well for live games like tabletops where there are no such things as saves or second play-throughs, especially because if they do choose some wacky thing, you can always make stuff up. But this is difficult to do with a computer game, since players will often try everything and quickly figure out that you're offering meaningless choices.

You can reduce this, to some extent, by using the same "in-game" techniques explained above.

Third: Exponential growth. Given two or three distinct choices that have different results, you quickly run into The Branching Tree of Doom. There are effectively three ways to keep this from getting ridiculous. You can have choices have numerical rather than plot results. You can have choices lead to different paths that always go to the same endpoint. And/or you can have some kind of algorithm for determining outcomes based on any given choice, which minimizes scripting by adding ridiculous amounts of engine programming.

Anyhow... that's basically it.

Ahhh... I said I was going to link it up to social games and MMORPGs but, you know what? I'll have to do it in a different essay. This one's already too long.

Help! I've fallen off the internet!

Like everyone, the holiday season is very, very busy for me. Without real access to a computer, I'm rather limited in my blogging options. However, I've had access to an incredible new invention: paper!

So, yeah, I've got some essays ready for whoever still has me on feed. Unfortunately, they need transcribin'. And re-writin'. And a dose of wacky hijinks.

Later today I will give you an essay on how limiting choice enhances agency, and how that relates to social games and MMORPGs. Normally I'd just write it instead of announcing it, but I wanted to make a few simple announcements:

1) Soon I'll have a little more time to follow my favorite persuits. That is to say, ivory tower theory and programming little games. That means more posts to this contraption.

2) I have some new equipment and a backlog of ideas the size of the mooooooon. So, yeah, I'm looking forward to getting back to it.

3) There is no number three, there is only Zuul.

4) What's up with Sid Meier's Railroads? I can't install it! I get "autorungui.dll is missing or corrupt". But no matter what I do (including installing autorungui.dll), autorungui.dll is ALWAYS missing. Apparently, it happens with a couple other games to a couple other people, none of whom have figured out how to fix it.

Anybody know what's up with that?

Saturday, December 16, 2006

LEGO Theory!

LEGO Theory!

(This is longer than I intended. :P )

A player plays a game. As the player experiences the game, the software builds a complex structure of ideas (gameplay, graphics, story, etc) which interlock and support each other. The tighter and smoother these interlocks are, the tighter the game holds together. If you know what a memeplex is, it's essentially that. Regardless as to whether you know what that is, think of this as legos. Each moment of play is another tiny lego, building a giant final structure.

"Yeah, duh, games build on themselves. Who cares?"

Well, at a very basic level, how good the ending of your game is depends largely on how well it "caps" the structure you've created. Some endings which should be good endings flake out because the legos don't support them. Some endings which should be trite and bad end up quite touching because the underlying structure is built specifically to need only a little bit of additional work before the structure completes.

But how to think about your endings is only the tiniest piece of this puzzle. After all, this same basic idea applies to comics and movies and books and classes and business deals and blogs and...

In a single-player game, you'll see that a game builds its structure up much like a TV series might, although using pieces that no TV series has access to (like play).

But in multiplayer games, things can get very complex.


Imagine a tabletop RPG. Six players and a GM. The GM is simulating the world for the players. He is placing pieces and creating a structure. However, any given event usually focuses on one or two characters: this round, Anna the Angel and Bob the Barbarian got hit by a squad of storm troopers. But Cinnabun the Ranger and Drokmok the Dancer don't care as much about that.

Essentially, the GM is trying to build a complicated, tight lego structure for each player, but when he puts a piece down, he can't tell how long it's going to be! It's different for each player depending on how much they care about the event that just happened.

There are three ways to deal with this: loose structures, corrective applications, and self-construction. I bet you've never heard of at least one of these concepts before:

Loose structures are the path most GMs take unconsciously. They quickly learn to create lots of "slack" in their game structure so that players can do various things and feel various ways without making the whole game collapse like a Jenga stack. This does end up creating a structure that looks more like lace than a sturdy wall, but it works okay. It's not very efficient at creating a good game, however.

Corrective applications are not quite as common. When a GM does this, he gives another lego piece to players which don't have enough support. Essentially, he "fills in the holes". Like building a lego structure, you should fill the holes before you cap them. This usually means that the GM does one-on-one mini-sessions with the players who feel left out, or makes sure that roughly the same number of interesting things happen to every character in every session. This isn't the best way to do it, but doing it better would require an astonishing amount of micromanagement.

The third path is the path of self-construction. This is a pretty rare path for "mid-level" GMs to take. A lot of early GMs take it and a lot of advanced ones do, too... but it's too common for a GM to hold on to his game too tightly to allow for this kind of freedom.

In self-construction, the GM sets up parts of buildings and then lets the players try to put them together in any reasonable way they can think of. Players usually cooperate to glue them together into structures of incredible density. The GM is no longer really a Game Master, but a Game Guide: he gives the players new pieces if he thinks they're running out of bits to glue together, and occasionally kicks down someone's building.

The downside to this method is that each player will end up with a different building, meaning that as the game progresses it gets harder and harder to give everyone pieces that fit into their own unique structure. This can be controlled somewhat by an experienced GM, but always happens. It's especially bad for endings: typically, these games require half a dozen individual endings wrapped up into one giant blob.

"So I should think about using a loosely defined progression, keeping all my players happy, and letting them do their own thing from time to time? Gee, thanks, I would have never thought of that on my own!"

In my opinion, each of those methods could have a book written about them, but for now I don't have time to further extrapolate because I'm jumping into...


MMORPGs are kind of the ultimate example of how to do all three of these things. MMORPGs allow players to get as involved as they like with whatever they like whenever they feel the need. It lets them go to whichever piece of structure they want and claim it into their personal story. It doesn't hold them to a specific plot.

Actually, MMORPGs fall short in two ways. First, they don't really allow players to self-construct much. The players can't really build their own buildings very large, save through guild mechanics. There are other ways I would consider superior.

The second way MMORPGs fall short is that they don't have very much in the way of a Game Master (or Guide, or whatever). Essentially, there's nobody who sees a particular player and goes, "they really need this particular piece of building." This lack of guidance means that players get pieces of structures, all right, but none of these pieces have much chance of ever fitting together.

Is there a solution? Well, maybe you could record the "shape" of each piece of play, and then keep updating a player's profile to see what kind of shape might go nicely. It would, however, be quite rough. Worse, it would probably be hard to correctly guess how much time the player wanted to spend this week.

Barrier to Entry

Most games strive very, very hard to lower the barrier to entry. Generally they do this by having an introduction which forces any player who joins to go through a tutorial. This lets the game build a lego foundation so that the player, when he starts receiving pieces of building, has something meaningful to attach them to.

For one player games, this is pretty simple since everyone starts from scratch. For MMORPGs it's actually quite hard, but they spend a lot of time and money on it and it works out.

Now, how about for a tabletop?

Ever tried to bring a new player into a tabletop only to realize that he doesn't fit? This is especially true of my games, since I build rather complex structures and I build them vertical. So a player comes in and I'm giving people pieces that fit into this one weirdly-shaped little node that they all share fifty stories off the floor. The new player gets this thing and just stares at it. It can't even stand up on its own, let alone be used as a foundation for further play.

Chances are, your games are a little less... vertical. But you probably suffer the same problem.

The obvious solution is to have an introductory session with just them and maybe one or two other guys, so you can build a foundation that makes these pieces work out okay. These kinds of sessions work well, so long as you build fast and strong rather than trying to rebuild the same building the other players have. The new player will still occasionally get pieces that don't fit, but if you're running with the player-construction method, everyone occasionally gets pieces that don't fit.

The problem with an introductory session is that it takes hours and hours. If you run games like I do, it is fundamentally impossible to have that much time. If I spent even an hour with everyone who would join Boogaloo if I only laid them a foundation, I would have to spend all my free time doing just that. Yikes!

For my grander schemes, such as an on-line version, this is an even more ridiculous idea.

But... what if...

Assistant GMs

Some GMs have assistant GMs. I generally don't, because it's impossible to tell them enough to keep them up to date as to which players need what kinds of weird structure pieces. Of course, this means that I have a player maximum (functionally about five players, despite the fact that my games generally have two or three times that). There's only so much attention I can spend.

The place you're most likely to see AGMs is in large LARPs, where they are charged with mostly just making sure people know the rules and arbitrating when the rules don't apply.

But, really, is there any reason to have them be AGMs? Can't players arbitrate and teach just as well? Sure, the player may be biased, but once word spreads as to which players are bad at it, they won't get asked to do it any more.

Can't this be used to create a kind of "pryamid scheme" for teaching new players? Instead of the GM spending time, a player spends time. This lets the game scale functionally infinitely.

At that point, the real question is how to track so many player's needs... or to automate their ability to create pieces that fit those needs.

Bleah. Sorry, this was long.

Saturday, December 09, 2006

Ever been hypnotized?

Some people like MMORPGs. Some people don't. You can say the same of all games, but today, MMORPGs. Why do people vary in their preference?

Here's my hypothesis [read "wild-ass guess"]: it has something to do with how easily your brain can be led to believe that the numbers in the game are real and/or important. Which may have something - maybe - to do with hypnosis.

So. Have you been hypnotized? If, so, chime in and answer:

How easy were you to hypnotize?

How do you like MMORPGs?

Tuesday, December 05, 2006

Swords and Smiles 2: Electric Boogaloo

In Swords and Smiles I talked a little about abstraction. Right now, combat is abstracted out, especially in RPGs. These games have very simple combat mechanics: choose "attack", and you'll hit and do damage based on your character, skills, and/or equipment. As interfaces become more complex (Wii) we're seeing this abstraction reduced, the play more openly simulated and interactive.

The question is, can social games use these kinds of abstraction, and can they ride the same wave of unabstraction?

I say "yes". There are lots of ways to abstract out social play. The problem is that when we abstract it, it ends up being very shallow. Imagine an RPG with no levelling or equipment: you simply walk around the map fighting random fights. Click the button, cross your fingers that you'll do more damage than it will. There's not very much interesting about that.

Abstracted social play is the same way. But it can be solved the same way, too: adding in secondary play loops like equipment, levels, plot, etc. It makes just as much sense. What you wear changes how people react to you, and how long you've been doing this sort of thing affects how well you do it.

I can't see any reason why you couldn't make a compelling social game, save one:

Most games have a plot, and a lot of their pull is from that plot. Because the plot isn't affected by the combat, the writers can write pretty much whatever they please. However, in a social game, you'll have to be careful to keep the social play separated from the plot, or you'll end up with a branching plot of DESTRUCTION, impossible to write. That really limits our play options.

However, I think it's still possible. And I have an idea for a game. It involves team-based high school melodrama (or college melodrama, I suppose). I like the idea, but I don't really have the time or energy to write it up. But I'll give you a sample: everyone has confidence and loyalty, but they are opposing. When one goes up, the other goes down, and visa-versa.


Think about it...

Saturday, December 02, 2006

Laser Tag

I'm going to go back to the Swords and Smiles/Interfaces thing tomorrow, but for today I'd like to talk about something slightly simpler. Something to show everyone that game design analysis isn't just some ivory-tower voodoo that nobody ever uses. This essay may seem a little long, but it's extremely straight forward and easy to read.

Yesterday, I played laser tag. With 35 other friends - we bought the place out for a little while.

The basics of laser tag are simple: shoot the other dude to get more points. Most games of laser tag have additional features to make the play more interesting. All of them have terrain, most of them have teams, many of them have special targets (such as bases), ammo limits, lives...

The place we went did all of that - no one feature as well as I might hope, but everything somewhat well. (Except the fact that you could still get shot after you died, which was really dumb.)

They also had one feature which was... very interesting.

Every minute or so, people became invulnerable for twenty seconds. The basic idea being that they could waltz into the enemy base and shoot the base for a while, racking up the points.

Now, from my point of view, this was really a dumb idea. I mean, painfully dumb. You can't do anything to stop these people. You don't even get points for shooting them. Worse, the PA says, "green, defend your base!" every time one gets inside. You end up wanting to shoot it: you know there's some asshole in your base, and he's going to be there for precisely eight more seconds before invulnerability fades and he instantly dies. You can't defend your base. It's physically impossible.

So, why did they do it? Why this stupid "invulnerable" shit?

Take a moment to come up with some reasons they might have done so before reading on.


The more obvious reasons are ones of play rhythm. You want to keep the game going at a frantic pace, and the best way to keep people running from one side to the other is to make them invulnerable for a little while. However, this is a really bad way to control pacing. In fact, it would be better to do it just the opposite: have the various base targets themselves only vulnerable at pseudorandom times. Invulnerable players don't pull the same vigorous defense, because they can't be defeated.

But it's not a bad design. There's another reason for it. Did you think of it?

Shitty players are the problem.

See, in games of paintball, the real issue is that if you're a bad player, you spend most of the game dead and don't really accomplish anything useful. Laser tag is, at its default, the same: if you can't shoot and have no sense of tactics, you'll suck. You'll end up with a big negative score and feel like you wasted your time.

But if everyone gets to be invulnerable for a while, then no matter how bad you are, you get to kick all the ass for twenty seconds. Assuming you're alert enough to realize that you've just gone invulnerable, of course.

So the invulnerability is really to make the bad players still enjoy themselves. I, being the sort of person who doesn't much like luck as a major factor, hate the rule. But I'm also not a bad player, so I'm a bit biased.

Honestly, I don't think it's really the best way to do it. But it is an effective way to do it.

Can you think of other ways? Let's hear them!