Creating a system of game play notation

It occurred to me the other day, “What does the world of music have to offer to game designers?”

On my first dive into the topic, I latched onto the use of musical notation to express complex melodies. After pounding on buttons in my last session of Mario and Luigi: Partners in Time, there was an eerie parallel with the rhythm of rewards in a typical game. The bloops and bleeps of the various attacks and power ups seemed remarkably close to a strange form of music. What would they look like if we were able to write them down like music?

This essay describes a game play notation system that can be used to record and analyze any game. It turns out that games can benefit greatly from the use of a symbolic notational system that describes the rhythm and flow of a game play experience.


This is not an idle exercise. Our current design methodologies are broken and I’m searching for a replacement. We’ve explored design tomes in an attempt to learn from software development. No one reads them. We’ve recently explored the land of movies with the creation of ‘game scripts.’ The result is bloated cinematic epics based on movie-like scripts that somehow manage to avoid describing the ‘fun’ in any meaningful fashion. It should be no shock that design tools influence the final results. Design a game using a script and you’ll get a script-like game.

If you really want to change how games are made, you have to change the design methodology at its very core. This article is a step towards providing a new set of pragmatic tools for practicing game designers. When implemented as part of your design methodology, it will change how you design and ultimately what you design.


Notational systems in music

Music notation as an information technology
For thousands of years, early musicians composed new music using their instincts. Music was learned by rote memorization of previously composed tunes and limited innovation happened mostly during individual performances. The business of music was in the performance of old favorites with original works few and far between.

Eventually early Catholic monks began using a rough notation that helped codify and record sacred songs. Early musical notation was crude, but provided crucial information for understanding the songs. Over time, a pleasant fellow named Guido of Arezzo added a staff for recording pitch and timing information was recorded with more accuracy.


In our world of silicon wafers and mechanical gizmockery, we don’t typically think of such innovations as a technological advance. For the time, however, the introduction of musical notation was a major advance in information technology. It reduced the cost and increased the speed of music composition. The benefits of musical were two fold.

• Rapidly understand and communicate complex structures: Instead of dedicating dozens of hours memorizing a particular song, you could learn the basics of a song by spending a few minutes glancing at a sheet of music.
• Provide a framework for analysis and modification of failing compositions: Instead of getting together a group of musicians to learn and play a song in order to understand its flaws, you could quickly identify issues on the sheet of music and with a few pen strokes make major changes.

Impact on music composition
As the process of describing music became codified, the act of creating original works became more prevalent. This was driven by two factors. First, the growing existence of a large worldly audience with a taste for new works provided a strong business incentive for composers to write new songs. Second the existence of a well-defined system of notation provided a comprehensive set of tools that facilitated and accelerated the creative process. The combination of both business need and process / technology maturity led to an explosion in the development of new music.

The songs of the times before the creation of advanced musical notation tended to be quite simple compared to the great symphonies of later generations. The human mind can build and modify complex systems much more easily if it has a way of simplifying them into an easy-to-manipulate notational format. Without musical notation, it is questionable if we would have the great symphonies and arias that grace music halls across the nation. Even ‘original’ pop music, with its heavy use of modern electronic notation systems, is unlikely to exist.

Imagine instead, a thousand years of dancing to Auld Lang Syne at every single event. Let us praise the advent of music notation as a potent and world changing enabling technology.

The primitive state of game design notation
Game designers are still in the early prehistory where they seek to create addictive gaming experiences by tweaking old designs. They are much like the minstrels of ages past. They apprentice themselves to the designs of past masters in order to learn and continue our mysterious and sacred trade. They may innovate mildly in each performance, but never much more. That is the way of it has been and how many imagine it will always be.

The lack of a well defined language of game design is crippling. New ideas emerge from a game designer as vague emotional statements that dissipate quickly. They have no tools to record them in a coherent manner. How would you create a symphony is written music did not exist? Game design exists in a similar state.

The state of the art is the game script, stolen almost directly from the movie industry. The most a modern designer can manage is stringing together a fluffy narrative that reads like a movie script. Is it any surprise the many modern games feel like recycled game systems linked together with an innumerable series of plot snippets? We simply do not have the symbolic language to create anything greater without risking deadly design ambiguity.

We lack the basic informational technology to do more than this. We lack the terminology and we lack the system for describing important systematic interactions.

In the world of music composition, Guido of Arezzo sat down and said “Pitch is a critical factor in music and we should represent this factor symbolically.” He created a powerful design tool that unlocked the creative potential of millions.

We need to do the same for games.

• We need to understand the basic mechanical elements that describe the game play experience.
• We need create a notational language for expressing, analyzing and manipulating these key elements of game design.

The challenge
Creating a complete and robust notational system is a Herculean task. There are so many aspects to even a simple game that it seems impossible to capture them all without building a monster theoretical diagram that no one understands, maintains or cares about.

In these situations, I love to simplify the problem down to one that we can solve. Often the results give us 80% of what we are looking for with 10% of the pain.

Here’s the basic premise: If we can measure and transcribe existing game experiences in a robust symbolic fashion, we can reuse the same system to improve new games. Just like the Catholic monks of yore, we are figuring out how to record our medium in a meaningful fashion.

The game play model
The first issue to solve in any recording problem is answering the question “What information should we record?” We’ll start with a simple, yet comprehensive game play model that I’ve been working with for some time. It deals with two aspects of game play,

• The mechanical structure of the game
• The psychological experience of the player.

Elements of a game’s mechanical structure
The mechanical structure of the game defines the basic elements of a game and how they interact. These elements have no value associated with them, they simply form an interactive machine that clicks and burps when it is poked.

• Verbs: Discreet actions that can be performed by tokens on other tokens. The act of jumping in a platform game is an example of a verb.
• Tokens: Any object in the game that is manipulated. The player’s avatar or an enemy is an example of a token.
• Rules: The basic rules of interaction between tokens and verbs. The logic that an avatar jumping on an enemy kills it is an example of a rule.

Elements of a player’s psychological experience
The psychological experience describes how the player reacts to the mechanical structure of the game.

• Actions: An action is the goal oriented series of executed verbs that is necessary to activate reward. “Save the princess (in order to win the game)” is an example of an action.
• Rewards: An indicator that the player has done something meaningful in the context of the game. The general goal of a reward is to make the player feel good. The fireworks when you save the princess are a good example of a reward.
• Risks: An indicator that the player is executing their actions in an unsuccessful manner. The general goal of a risk is to provide feedback that points a way forward. The simplest version of this feedback is “Don’t do that again.” The death animation when you die is a good example of a risk.

In the past I’ve argued that a simple model of fun is based off a series of layered psychological reward schedules. As the player is rewarded with a series of overlapping rewards, they build up a complex and mildly addictive buzz.

Both the mechanical and psychological structures I’ve described are present in all games, ranging from Tetris to World of Warcraft’s leveling system to Dance Dance Revolution. In my experience, any game can be described in a complete and robust fashion using these six simple elements, so it should be a very useful starting place for our notational system.

Notational devices
In the upcoming sections, I’m going to describe five important notational devices derived from our game play model.

• Buzz notes
• Reward Channels
• Verbs
• Master Buzz Meter
• Statistics

Buzz note: The basic notes of a game
In music, you get a burst of emotional value when you hear a note. In a game you gain a burst of emotional value when you receive a reward.

Rewards act as the core building block of our notation system. We are starting simple and ignoring verbs, tokens, rules, actions, and risks. These elements matter, but we’ll add them as we need them. One big benefit to starting with rewards is that most built-in rewards are relatively easy to measure. They are typically events that are triggered by the game in response to a player action.

If you collect a star in Mario 64, a cute little award animation plays and a resource counter increments. If you complete a line in Tetris, your points increase. Ultimately, someone has to program the basic feedback systems in any game title. Given a set of game mechanics, it is trivial to classify and tag the reward events.

Psychologically, rewards create a little blurp of pleasure in the user that rapidly degrades over time. We represent this psychological response as a symbol in our notational system. This pulse is represented by a “buzz note.”


A buzz note is an exponential curve with the following characteristics

• Start time: The time at which the reward occurs.
• Strength: The magnitude of the reward.
• Fall off period: How long the pleasure takes to dissipate.

For now I’ve displayed the buzz notes in a rather literal manner as curves. In the future, as we identify different classes of buzz curves we can start using more symbolic representation.

Reward Channels: The instruments of the game
Imagine that your rewards are instruments. As a designer, you set up systems that the player triggers that result in a cascade of buzz curves along a number of discrete reward types.

Visually we can give each reward its own channel and then simply record the buzz notes when they occur. The visual metaphor is inspired by many of the old tracking programs used to create MOD files.


It turns out that many games, even seemingly complex RPGs, have no more than several dozen reward channels. This works out well since you end up with a set of channels that you can rapidly scan on a single screen. The ability to make complex game data ‘glance-able’ is a critical factor in the creation of a useful notational system. Remember, we are attempting to take a complex emotional experience and compress it down to an easy to manipulate symbolic experience. A successful notational system needs to fit in a person’s head without genius level comprehension skills required.

Introducing verbs into the mix
We run into an interesting divergence from the musical metaphor. Rewards alone are not enough to produce a meaningful notation of the game experience. You clearly see what the player experiences, but it is difficult to understand what happened in order to cause the cascade of rewards. If we don’t represent the player’s interaction, our game notation is meaningless.

Ideally, we could record the actions that the player performs. However, it turns out that this is quite difficult. Imagine in a game of chess that you capture a pawn. There were countless moves that lead up to the capture of that pawn, some of which involved the player’s intent and other’s the opponent’s intent. You can describe a conceptual strategy that defines the action of capturing a pawn, but identifying the exact sequence of events that go into an action is difficult.

The solution to this dilemma is to record all the verbs that the player performs and list them them according to time across the top of our chart. The game designer can quickly scan through what the player is doing and see rewards are occurring simultaneously. Sometimes there will be a direct correlation. Other times there will be an indirect correlation.


When you record an actual game play session, the result is quite fascinating. You can see on a single scrolling screen the entire history of how the player experienced the game. Down the side are the reward channels and sprinkled across the channels are the timed reward events.

In more advanced implementations, you can add a playback head that scrubs through the log file and shows the actual recorded game play in either a video window or the actual game engine. This provides a very clear understanding of what happens at various points in time.

The Master Buzz Meter: The volume graph of the game
All this detailed data is very useful for digging into specific problem areas, but too much data is useless. When a dozen testers generate reams of data, you simply don’t have time to look at it.

If you sum up the buzz curves across all the reward channels, you get a single graph that shows player buzz over time.


You can use this to quickly identify periods of low reward activity.

• First by glancing at the chart you can learn to ‘read’ problem areas quickly.
• Second by setting thresholds, the system can automatically mark areas of low reward activity and call them out with color.

Statistical snapshots
Even using the Master Buzz Meter, our notational system can generate far too much data to process in a reasonable amount of time. Games are interactive and every game session results in a static snapshot of a single player’s experience. A dozen players playing a dozen sessions and you are in the hundreds of data files to analyze.

Here we turn to statistics to give as an overall view of game play. From each of our elements, we can determine a variety of key statistical factors that help us understand various systems at a glance.

Master Buzz Meter Information

• Average buzz per session: By sorting sessions by average buzz, you can identify low buzz scenarios and examine them in more detail.
• Average buzz across all sessions: This allows you to track progress on various versions of the game. As you make improvements, you should see the average buzz score improve with each subsequent prototype.
• Variation per session: What is the standard deviation for the master buzz meter? This tells you if certain sessions are providing highly variable experiences.
• Variation across all sessions: This tells you if players are having dramatically different experiences.
• Gameplay time: Very short sessions are often worth looking into.

Reward Channel Information

• Average time between rewards per session
• Average time between rewards across all session: This helps determine the reward frequency. In the standard display, reward channels sorted by reward frequency since it gives you a real world grasp on what activities are core game mechanics and which ones are additional layers on top. In general, you should focus the majority of your polish efforts on the high frequency action – reward cycles.

The major point of all these statistics is to be able to quickly select from potentially hundreds of log files a ‘typical’ game play scenario and one or two outlying game play scenarios. The designer can then dig into these in more detail, identify problem areas with prototypes and start building a list of solutions.

Essential Technology: Logging Systems
As might be apparent, a critical aspect of using our notational system is a robust logging system. This should be built into your game engine and the data should be recorded religiously from the first prototype onward. If you aren’t logging, you are prototyping blind.

The type of data you collect is highly flexible. In the most basic situation, you are recording player verbs and reward events. Such information can be highly compressed and stored in a wide variety of media without too much slow down. In more advanced situations, you are creating a complete record of the game play. This is a lot more data, but may be worth the effort as you become more experienced with interpreting subtle notational symptoms.

Advanced features include:

• Playback of log files in the game engine with full seek and scrub capabilities.
• Capturing sections of the log file for reference in future discussion. Think of this as taking a snapshot of a problem area.
• Zooming mechanisms similar to those in video timelines for looking at the big picture and then zooming in on the details of a particular area.

Expanding the Notational Model
What we’ve built so far is a very simple notational system. Here are some other factors worth taking into account when you build such a system for your games. Some are based on basic human psychology and others are issues worth keeping in mind.

• Burn out
• Expected and Unexpected Rewards
• Suppression
• Risks
• Game Structure
• Unusual events

Burnout
When a reward repeated, it becomes less effective and the strength of the buzz curve is reduced. However, if the sequence of rewards is interrupted by other rewards, the reward recovers some of its former impact.

There is some interesting work to be done here to determine what patterns typically cause burnout.

Expected Rewards
Two common types of rewards are expected rewards and unexpected rewards.

• An unexpected reward is a reward that the player doesn’t know is coming. The player experiences a small bit of delight when they happen upon a random bonus. It is represented by a standard buzz curve.
• An expected reward is one that the player is told will happen. These two part buzz curves consist of an expectation curve and a standard buzz curve. The expectation curve is kicked off by a defined hint that promises a future reward. The player then experiences a mild buzz of expectation until the promised reward is delivered.

The classic expected reward is a hidden room in Zelda. The player is shown a room that they cannot get to. The expectation of reaching the room will give players enough of a buzz that they’ll keep playing the game even when there are few short term rewards. The buzz that comes from uncompleted tasks can be an extraordinarily powerful motivator for more hardcore player personalities.

In our notation system, an expected reward is recorded by tagging certain events in the game as ‘hints’ that are associated with a particular reward. Once the hint is given, a mild buzz curve is in existence until the promised reward is reached.

Suppression
When a player experiences too many rewards at once they suppress the lower strength buzz curves and only focus on the easily discernable rewards.

Suppression in combination with Burnout tells us why we can’t make a game that is all rewards all the time. First, if we repeat rewards, players will learn to ignore them. If we pile too many rewards on at once, players will also ignore them. By building these concepts into the notation system, we ensure that designers are always aware of such concepts.

Risks
Identifiable risks should be treated just like Buzz notes and recorded in their own risk channel.

Some risks can be recorded and some cannot. Often the most powerful risks are opportunity costs as opposed to concrete punishments so be careful of thinking you have all the risks accounted for if you add risk notes to your system.

Game Structure
In music, songs often have distinct sections that form a structure. For example a chorus might be label A and the refrain might be labeled B. Several classic structures include Binary: AB, Ternary: ABA or Ronda ABACADA.

Most games possess substantial structure as well.

• Binary: AB where A = The game is off, B = Actively Playing the Core Game. This might be your typical arcade game.
• Ternary: ABCA, where A = Off, B = Playing the exploration portion of the game, C = Playing the combat portion of the game. This might be your typical console RPG.

All games will at least have a Binary structure. If your game has discrete sections, you should record and label them. Often each section has unique balancing issues that must be dealt with individually.

Unusual events
Part of using the notation system correctly is understanding what constitutes a meaningful event and logging it appropriately. Rewards, for example, are more than just power ups and coins. They also include many of the aspects of the game that historically have passionately been defended as important, but no one can tell you why.

• Plot: Plot sequences are really just another reward. Press the right button and get a bit of plot. The wonderful thing about plot sequences is that they act as a nice reward, but they also tend to contain a clue that sets up another expected reward.
• New graphics: You know those sexy new graphics the artist spends so much time slaving over? It turns out that they can be easily represented as a reward. Simply record the first time that the player sees a new monster or a new area as a reward. This helps you identify the rate at which you introduce new artwork and ultimately how much artwork you need. If you are balancing your other rewards appropriately, you can often maintain the player’s buzz without investing in heavy art resources.
• Dying and death. Record these! They are the most basic form risk and often provide important insight.
• Resetting or restarting. You need to look at the entire play experience and record it as part of your game structure.. This involves player who save and restart. It involves resetting or turning off the game in frustration. Ultimately the log file should contain the player’s entire experience with the game, not just small snippets of game play. Those hours they weren’t playing the game are just as important to your balancing efforts as they hours they are playing the game.

Other areas of further work
Here are some obvious holes in the current system that -- while not preventing its usefulness -- should be acknowledged.

• It needs real world testing: This is a design for a notational system, not a case study. Real world testing will help polish the system.
• Social Rewards and other player invented goals are not measured: Any reward or risk that is not explicitly called out in the game mechanics cannot be measured. The joy that a player gets from taunting another player or the fun they experience from randomly stacking crates is difficult to track at this time.
• Long games are difficult to manage in an iterative manner: If a game takes 6 months to experience, it can be difficult to collect enough log files to gain a statistical understanding of player experiences. You still however can focus on sections of the games that occur on shorter time scales.
• Rules, Actions, and Tokens are not well described: There are several other major elements to a game design that are not included. This means that the notational system is not a complete and cannot be used to design full games.
• Buzz note values are not derived from real world data: We can make assumptions about how long a buzz note will last and which ones are stronger than others. However, until we hook someone’s head up to a pleasure sensing device, these are merely educated guesses.

Practical usage of a notational system for games
So once you’ve created your logging system and built out your pretty pictures, what next? What do we do with all this data?

Our notational system is a method of clarifying and providing conceptual feedback on psychological impact of existing game mechanics. Woot. That is indeed a mouthful so let’s dig into it in more detail.

• “Existing game mechanics”: You need to have a working game in order to record game notation.
• “Psychological impact”: By focusing on rewards, we are illustrating a crucial part of the player experience, but at the expense of the mechanical structure. You can’t design a full game using this form of game notation.
• “Clarify and providing conceptual feedback”: What we do get is the ability to describe a game using well defined terminology. Instead of saying “This is boring”, you can point to a period of 5 second in buzz graph with no rewards and identify the events leading to that situation.

How to use it
Our notation system is best used in an iterative development process where play testing is readily available.

1. Build a benchmark suite of successful games. Typically this can involve logging publicly available games such as Tetris or past games that you have worked on.
2. Build a prototype with logging.
3. Examine the initial log files in details. Compare and contrast them to your benchmark suite. Are there any glaring issues? Focus on the high frequency rewards first.
4. Record these issues in terms of the results you want to see in the next set of logs. Create goals for future success in terms of buzz curves, reward channels, and statistics.
5. Create a new prototype and repeat the process. See if you hit your goals. If not, try again.

You’ll need to have a group of dedicated testers. Try to get a good mix of first time testers (Kleenex testers) in addition to your more experienced testers. These will provide the log files that drive the process forward.

Benefit: Steerable design
This is a very different form of a development than many teams practice. The game industry is roughly five to ten years behind the rest of the software industry in terms of process management and methodology. They’ve historically focused heavily on a waterfall-like development methodology with long preproduction cycles and rigidly defined production milestones. The rigid methodology is one major factor that leads to risk averse, stagnant design.

By using the notation system as a critical part of development, you build into the team strong structures that encourage a more agile form of design.

• Prototyping is essential. You can’t develop the next step without prototyping first.
• Design goals are easily communicated and cover the immediate future. No more fuzzy ideas that introduce unacceptable design risk.
• You steer the design using constant feedback instead of writing it down in a fit of artistic genius.
• Ironically, all this lets you take more risks, not less. The feedback cycle provides a safety net that encourages innovation instead of punishing it.

By having clearly defined goals coupled with strong feedback, you’ll design better games with fewer expensive errors.

Benefit: All game content is on an equal playing ground
Art resources, physics systems and combat mechanics all are ultimately translated into the notational system in the form of the customer experience. Instead of optimizing each silo, you can focus on optimizing the overall game experience.

Benefit: Tightly targeted games
You’ll also likely make smaller games that serve customer in a more focused manner. By clearly understanding what works and what doesn’t work, you can invest in the right features instead of being throwing more features at the customer in the hope that a few will stick.

You may not make God of War, but you may make Nintendogs. In our world of ever increasing development costs and industry consolidation, being able to hit your market in a highly targeted manner means higher profitability with lower risk of failure.

Conclusion
That brings us to the end of our exploration of game play notation. We’ve covered a lot of heady concepts quite quickly, so here is a quick recap:

Key concepts

• Notational systems are good! A notational system can increase the creation speed and final quality of a game design. It provides powerful information management tools that help mere mortals manage designs of staggering complexity in a reasonable fashion. It works for music and it can work for games.
• We can display basic elements of the player experience in notational form: By focusing on the psychological rewards that a player receives, we can represent the player’s fun over time. By also recording the verbs that the player performs, we can link player behavior to they player’s psychological state.
• Layered information display makes log files useful: Our systems ‘layers’ information at various conceptual levels of detail for ease of use. You can easily get quick overviews of the game and you can dig down in to find out the exact details of the game play.
• The use of notation encourages rigorous design habits: Instead of being forced to rely on vague, often emotional hand waving, a designer can identify problem areas and describe them to the team with a high level of rigor and accuracy.
• When used in conjunction with iterative prototyping, game play notation can enable a powerful agile design process: Logging prototype play sessions and recording them in a simple notational form provides the entire team with a clear feedback mechanism. You’ll make more focused games more efficiently.

The future
The industry needs to develop a solid set of information technology that describes how games play. If we can’t accurately describe what we are making, we cannot have an accurate discussion about how to improve our product. We should all be tired of muddled design documents that no one reads and bear only a limited resemblance to the finished product. Our current design practices are expensive and inefficient. They actively hurt the advancement of our art by promoting risk adverse behavior.

I encourage folks to explore game play notation systems as one path toward building modern, effective design tools. It certainly isn’t the only path, but it is more promising than the status quo and worth pursuing.

The notational system I’ve described is a first attempt. After all, there were several hundred years between the notation of the ancient Catholic monks and the development of our modern musical notation. However, if the technique is useful, others will innovate and improve on the basic concepts. If you implement such a system, drop me a line. I’d love to hear how it worked out for you.

take care
Danc.

References
http://cunnan.sca.org.au/wiki/Musical_notation
http://www.lsc.k12.in.us/TecumsehMS/Art.MiddleAges/neumes.jpg
http://chronicle.augusta.com/stories/123199/cy2_124-4983.shtml
http://www.rpfuller.com/gcse/music/terms.html
http://en.wikipedia.org/wiki/Definition_of_music
http://en.wikipedia.org/wiki/Musical_structure