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.