A Matter of Size!

_{This post is a further exploration of the concepts found here. So you should read that first. Or at least look at the pretty diagram.}

I've continued to think about how to represent games. Some people are down on the music analogy, but the more I've thought about it, the more I think something very similar to it is necessary. After all, each "instrument" we use, such as a close combat FPS system or a puzzle system, is more than simply "on" or "off".

Not only does each loop have a "difficulty", it also has a "current state" and a "type". For example, if you get injured during an FPS loop, this makes the next challenge more difficult. This is not just inside the game loop, though. For example, your exploration game loop uses the same hit points as your combat game loop. So, when you get injured exploring, it makes combat more difficult despite the lack of combat-related injuries.

In a diagram, this can be represented fairly easily with touching circles and a label. However, such a diagram doesn't tell you when you'll fight enemies, or how difficult the traps will be. You'll need another diagram for that, and both are missing the critical link between the two. We need a clearer representation.

Fortunately, we can use a "music-like" representation. Here:



I'm not suggesting this is in any way the BEST representation, but I think it does get the job done. As you can see, every play loop has challenges and upgrades. Challenges generally knock you down, upgrades generally make you stronger. These are represented as red or green circles.

The end state is represented by a "cross". This cross is not only within the active play loop, but can also propagate to other play loops. If the cross is missing, the end state is unmoved in other game loops, or is simply on the circle, in the primary game loop.

The position up and down the ladder represents the "power" of the challenge or upgrade. For example, a low-lying green dot might represent a clip of ammo, whereas a low-lying red dot might be a small monster. On the other hand, a boss is up on top, and tends to drop the player's state to quite low thanks to the hammering the player receives.

As you can see, some upgrades and challenges affect other game loops, others do not. This gives you a feeling as to what they are, and lets you fine-tune your player's power in any given game loop. In addition, one challenge or reward can be in multiple game loops, reflecting a complex situation such as dogs and snipers attacking simultaneously, or a boss which requires puzzle solving.

Now, this is awfully detailed. Generally, there is little need to be this detailed. Instead, we should create "chords", which are commonly used multiple-playloop relationships. For example:



Using a simple "outline the block" system, we can quickly identify our "chords" that we use. Then we can write them in simple progression, in plain English:

Discovery, long-range accent, short-range accent, empty beat. Discovery, trap, long-range combat, ammunition. Upgrade, short-range fight, short-range upgrade, double challenge. Secret, discovery, jumping puzzle, heavy double challenge.

You can even shorten them further, by category. For example, you could call it a "short range accent diminished" or simply "S-" for the quick little short-range fights. You could call the short-range only upgrade "S+".

Similarly, the difference between a secret and a discovery is a small one, and both are simply the opposite of a jumping puzzle.

The patterns are quite clear. You just have to write exactly what the pattern is, so that the game developers know what kind of progression to have. You can write several different progressions, in the same way a song has several different chunks of melody that have different feels. The choice of the player will usually determine which melodic pattern is played at this moment - whether they crawl through the ducts or cross the bridge makes for a very different experience.

But you don't need to specify which, or either. You simply specify the melodic progression(s), and let the developer use them as his artistry suggests.

I think there's got to be a way to simplify the final output - I'm just dashing this off in my last moments before bed, though, so I really can't think of anything. The point is: you need to see the effect of an event in one play loop in other play loops. It's critical. What that event actually is doesn't matter: only what effect it has. The actual event will be implemented by the developer. :)