Tuesday, January 17, 2006

Languages Marching On!

(This is an extremely long post, and I'm afraid I wrote it at about 3 AM. I'll re-write a new post on the same subject while I'm more awake, but you'll have to forgive the way this one bounces around. Long story short: I tried the kind of notation Lost Garden is suggesting more than a year ago, and it doesn't work.)

I'm sure you've already heard about Lost Garden's notational essay, unless I'm your sole source of game design information.

In short, he or they or she or it is speccing out a bare-bones methodology for describing gameplay. There's a couple of severe flaws, aside from the irritating writing style, which includes, in all seriousness, phrases like "Let us praise the advent of music notation as a potent and world changing enabling technology."

Obviously, the author has a lot of good points. Right now, we're in a world of primitive designs, like cavemen scratching out stick figures. There's a couple of new artists coming along. Some are trying sculpture, some are trying paints. Inside those realms, each person is trying to codify the whats and hows, and we're ending up with calligraphy, impressionism, cubism, and so forth.

Which one is "best" will probably never be a question that can be asked, any more than what the "best" style of art is. Some people will go on liking cubism, even though it's the most wretched style of art ever born. It's just the way people are, and if people like it, it has value.

However, there is some scientific merit (or demerit?) to most game design theories that are coming out these days. They can be largely reviewed with logic and a bunch of statements with the words "is like" in them.

For example, the notation he is proposing "is like" musical notation. Long story very short, yeah, musical notation gives about 80% of the song for about 20% of the effort. The rest of the song is gained through the nuances you flesh out after playing through it a few times and understanding when to stick some verve in and shake up the rhythm just a touch. The stuff computers have a bitch of a time doing.

He wants to use notation for representing "mechanical" and "emotional" pieces of the game. Verbs/tokens/rules make up th e mechanical side and actions/rewards/risks make up the emotional side. This is, of course, brutally standard fare. In my opinion, it's also a false dichotomy. The very concept of separating "mechanical" from "emotional" is like saying you're going to separate "food" from "taste".

His first cue is "buzz notes", which are essentially rewards. That's fine. Rewards are great things. Of course, every player gets different amounts of buzz from different things. For example, lots of people found they loved playing dark side in Jedi games. I couldn't stand it - not because it was too evil, but because it was too childish. Therefore, those buzz notes didn't resonate with me. Does he address this? Well, sort of.

He suggests "buzz channels", which are essentially different instruments. For example, light side and dark side would be different instruments. Actually, they'd probably be several different instruments. By simply noting what the player prefers, you can weight given channels heavier. Although he doesn't mention this, it is inherent.

He moves on to actions. "Verbs", as people have taken to calling them. And totally falls apart. Verbs without a state are like people running around saying "love eat hate date". What are they saying? Who knows? Can you track the feedback? No, not really. It might be mildly useful for linear games, but god help the person who tries to track a combinatorial game using this system.

Even saving the state of the game into these things - which I think he is suggesting - is not going to help. You don't need the state of the game. You need the state of the feedback loops. You need to see the patterns that forge the present in order to see how they will forge the future.

Now, I'm not saying this is useless. I'm saying you can't design a game with it. You can tweak a game with it. You can identify weak points in your play. However, at this stage he's assuming that players can't look ahead. "Low points bad!" No, not at all. (He knows this, but he's going from a theory of "burnout", which is like talking about how big the ocean is without mentioning it is made of water.)

Low points are great, so long as the player knows there is a high point coming. Many players delay the rewards until he can slam them all down together. This ends up looking like "unrewarding" play, because there's a long dearth of rewards.

Trickles of rewards are not the answer. He knows this, but for the wrong reason. Let me sum up: you do not and never did want a steady stream of rewards. You use your rewards to build up anticipation of future rewards! That is the whole purpose of early game rewards!

Moreover, the system in no way allows for player-controlled rewards (such as delaying the lesser line vanishings to snag a Tetris). It does not allow for anticipation. It does not allow for player-chosen rewards, such as when a player decides that grenading the jeep is the fun part of the game.

He mentions "expected rewards", but he grossly (in both meanings of the word) simplifies this critical part of game design. In fact, if all a system does is manage expected rewards, it would be 80% of game design. You want that 20% work for 80% result? Expected rewards management.

He does have some nice resonance between suppression, burnout, and risk. But without expectation, it's like talking about a cake and getting only frosting.

He talks about game structure, talking about a "progression of notes" - he's really talking about the cycles of game play loops. Which loops are active. If you want to stretch the metaphor, he's talking about which parts of the orchestra are playing at any given time. But he doesn't say that.

Now, the attempt is good. Any attempt is good. It doesn't deserve to be attacked like this. But it's in my nature.

I just don't think it's much of a breakthrough. I tested reward waveforms and pulse modulation methods several years ago, and I found them wanting for several reasons, not least of which are the ones mentioned above. These systems are simply not adaptable enough to deal with the actions and reactions of a diverse set of gamers.

They are theoretically useful for tuning pacing issues in a linear-ish game. Half Life 2 could have used it, for example. But the method simply does not have the robustness needed.

In order to be robust, there are a couple rules that need to be acknowledged.

First, the execution of a game is, like the playing of a song, always going to change from developer to developer. Right now, we're a bit like jazz. There's nothing wrong with that, and jazz doesn't take much notation. A core beat, a basic melody, then let the musician play. Similarly, we don't need to write the whole game out. We talk about the core elements, and the developer is familiar with how to actually glue the core elements together, with his own special brand of blues and soul.

Those are two separate elements. First you have to learn your instrument, then you can learn to play songs. These are two entirely seperate pieces of the puzzle.

And they are addressed with two different but related languages.

The language of a particular game would be a language of rewards. When you offer them, what they are, how much the player can push them. The language of all games would be one of play loops. Each play loop is an instrument - or a few instruments.

So, like someone who scrawls "guitar" or "soprano" at the beginning of a staff, before writing the pattern of rewards, you specify a kind of loop. Is it a personal empathy loop? An engine breakthrough loop? A statistical improvement loop? Is it played "with verve", perhaps meaning the player can push it around? The developer is assumed to know how to "play" the play loop. Otherwise, he needs to go learn that, first, like you need to learn to play the guitar before you can play "Stairway to Heaven". Well, arguably.

Then you can talk about the rewards. Remember, the strength of a piece of music isn't in the notes it plays. It's in how the notes relate to the other notes. It's not exactly which rewards get pinged: it's when they get pinged, and what other cycles are going on to support them.

We're talking about harmony and confluence of rewards. It's not how a play loop runs. It's how a play loop connects and resonates with the other play loops.

The fundamental problem with this, of course, is that it is still very difficult to talk about interactivity.

Still haven't figured that part out, yet.


Patrick Dugan said...

You're definetly right about a false dichotomy in the mechanics vs. emotion part, I think its reflective of the game/story dichotomy, which many see as being indicative of the first two, respectively.

I think the basic problem with the musical idea is the formal proscription of linearity in the notation. It seems to imply a way to tune up a level design, rather than measure the patterns in a combinatorial, non-linear game, as you said. What we need is a model for how verbs and other basic game elements interact and self-organize.

crankyuser said...

Super interesting. I still need to read Koster's Theory of Fun before I can comment more -- his lecture at GDC was a little over my head.

Just noting that this is the second time I've been here today, the other being for your review of the cult book and ideas about hurricanes. I don't recall how i got there, though.

And I'm also a game designer in Seattle. Convergence!

Craig Perko said...

Alas, I am no longer in Seattle. But you are certainly welcome to keep reading. :)

crankyuser said...

How misleading ;)

Danc said...

Great essay. It is always better to have a thoughtful critique than apathy. :-)

I'm curious how your logging system turned out. I'm also curious how you would improve upon an admittedly incomplete idea.

Mind you, from the prototyping point of view, 'tweaking a game' is what design is all about. Build, test, tweak, iterate is the critical loop. I'm looking for a better feedback mechanism, not a method of writing down game designs in a completed form.

Ultimately we are all looking for tools to make our lives easier. It is a pragmatic pursuit, not an ideological one. The more attempts the merrier. :-)

Happy day,

Craig Perko said...

I find that tweaking the balance is easiest when you have a plan that tells you how the game will work. This idea is kind of a "pre-tweak" tweak. Or something.

I'm not sure which "logging system" you're referring to: I have several, but none of them were mentioned in this post.

Picklebro said...

I think you and Danc's 'seperate schools of thought' are actually part of the same notation. I could see great potential in using your ideas to enhance his framework. I don't see your comments disproving him, but rather improving on his original suggestions.

My take-away was that you had some great points to work towards creating the depth and breadth needed to move towards creating a functional notation.

Craig Perko said...

Mmm, yes, once I started restricting the scope of the notation, it started to shape up.

However, it can't handle the stress of notating moment-to-moment play. It simply can't handle the interactivity - it falls apart.

Like all notations to date.

Picklebro said...

I'm not sure I see where it falls apart, but I'd love to - can you demonstrate?

Craig Perko said...


You see, the notation, when improved, is quite good at showing exactly what's happening when. It's good at keeping the player's interest peaked in the right ways at the right times, and judging when the player is feeling a given level of excitement.

However, games are interactive. The timing gets all mixed up if, say, the player wanders off to search back the way he came. Or if the player uses the wrong weapon, and therefore runs out of that ammunition when you expected him to have it later. Or if he doesn't find the somewhat-hidden cache of grenades.

Each player plays a game a little differently. While a notation like this can do quite well at showing what did happen on a specific play-through, or what you'd like to happen in general, it can't bridge the gap. There's no way for it to adapt to a player's screw-ups and strategies.

It cannot directly guide your game design, because it is a linear, non-interactive notation.

I explain my logic more clearly in the posts following this one:

The Other Kind of Score


A Matter of Size

Neither of these notations is particularly interactive, either. However, it shows that you can get something useful if you reduce the scope of the problem.

Craig Perko said...

I'm not sure that was clear enough. They say that everything that can be understood can be explained clearly, but I really have a hard time explaining that one. Let me give a concrete example.

If your game goes fight-fight-powerup-fight-pause-boss, you have designed each bump to have particular characteristics to bring the player's enthusiasm to a fevered pitch.

What happens, however, if the player is one of those slow "reload, search, reload" players? For them, it'll be:


Which is a different pattern that leads to a different emotional state.

The notation doesn't have any way to notate that, or account for it.

Is that clear?

Eduardo Pelitti said...

I posted a comment on:

I'd like to hear some opinions :)

Craig Perko said...

Over the past year, my thoughts on this matter have advanced. I'll make an update post this weekend. :)