Creating a system of game play notation

comments 59
Ported Posts / Uncategorized

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

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.

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.

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.

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




  1. Fangs78 says

    eyejinx: You say that there won\’t ever be a formal language that will help game designers do their jobs better. You say that it isn\’t possible.So why does all other \”entertainment\” forms have these kinds of formal languages? Music has, theater has and the film industry has. There isn\’t ONE language that is used ALL the time by all, but different dialects that all put together gives a potential \”artist\” or \”designer\” a great tool to help him make music. Most languages DO restrict the user a great deal, but without it it becomes quite hard to be productive at all. Why? Because we can schedule the team more efficiently. Because we can implement already-established solutions without having to prototype them. Because we can rely on the expertise of the team rather than having to verify all of our decisions through playtesting. Because we\’re not duplicating effort by rough-drafting and then re-architecting the engine. You seem to disregard the fact that an \”already-established\” solution WILL meet upon difficulties during the developement phase that wasn\’t previously foreseen by the design team. These difficulties COULD potentially lead to a big rewrite of the design, and again rewrite of \”finished\” code. This has a much smaller chance of happening using an iterative design loop. Thus your project would have a much higher risk factor than what danCs project would. This \”flaw\” of current top-down game design is rampant through the industry, as you can see by all the games being delayed (close to all in-fact). The bigger the project, the higher the risk. From a funding point of view, these risks makes a project less interesting to invest in. The only reason companies invest in games now, is because of the huge potential for profits, IF the game is successful. And thus game companies design games that are \”tried-and-tested\” designs with graphics upgrades. Trying to \”sell\” a game to investors with : \”We\’re going to do this amazing new thing that noone has done before!\” will probably be met with alot of sceptisism. And you multiply that with the high risk factor of top-down design, the amount interested investors would be scarce. Iteration promotes creativity. No question about it. And to end this long post : The iteration design HUGELY benefits from the feedback logs that danC is suggesting. And the top-down design doesn\’t.


  2. Dan, I\’m sure you are aware of the work by Ben Cousins (read his GDC lecture about this) concerning ludology and identifying ludemes.It seems there is a great deal of overlap in what you both are proposing.I absolutely agree that there are strong patterns of mechanical and psychological change during gameplay and that we are wise to study the sequencing of those patterns that lead to what we might loosely term \”fun\”.It seems fairly obvious to me that as we study the core patterns, we will inherently become better at reproducing the pleasing patterns and subdue the less pleasing ones.Its like when you are improvising on an instrument, inevitably you end up drawing on patterns you enjoy to create a core structure for your music, then you apply other sequences, scales, harmonies as appropriate. I think its clearly absurd to think that we wont benefit from identifying and applying some solid theories to these \”riffs\” at least, then delving deeper into the composition of these patterns.I just dont see why people would have a problem with this.Its like saying that most music hasnt benefitted from popular patterns being identified and re-used. Like there is no value at all to the three-chord-trick?Almost all of popular music is identification of patterns that please people and their re-use within different contexts (or sometimes simply repetition of those). It seems likely that generally when creating games from \”experience\” all we are doing is subconciously applying the patterns (riffs) we enjoyed in the past.But as any real musician will try to tell you, relying on simple learn by rote riffs is a poor substitute for real musicianship. Sure the three-chord-trick would be fine for a lot of mass media, but if you really want to be an artist, you have to delve deeper into the structure of music.We are at the superficial level right now and I wholeheartedly support the efforts to delve into the deeper structures.


  3. sorry for coming late to this discussion, in only found it just now. my comments come from the perspective of a software developer who\’s helped teach an artist (writer, mostly) how to analyze his own work in order to improve it.first off, i think this is a great start. there are some gaps, as i see them, however. the most notable to me is the question of time scale.when i look at the graphics you produce, you have the executed actions on one axis, and the buzz on the other. the first problem that springs to mind with that representation is that actions (in your definition) are a series of verbs, each of which can take the user a certain amount of time to execute. that means that different actions will likely take different amounts of time to perform, thus making the time (actions) axis non-uniform. the result of that is that the length of time buzz is at a particular high or low point can\’t really be told from the graphs, but that seems to be a very important piece of data.another, related issue is pauses in the game. i\’m not talking about the time spent on the toilet while the game is paused, i\’m talking about the kind of games that allow you to essentially stop playing for a while. specifically, this problem is posed by MMORPGs, where you can essentially log on to the game and not play, but instead just talk to other players. it\’s pretty hard to record the difference between time spent doing something like that and time spent actually playing in order to analyze the buzzlevel/time. does running around in the game world count as play? when you\’re trying to reach a specific point to reach a goal, yes. when you\’re running around out of sheer boredom because your mates aren\’t online yet…? that problem doesn\’t invalidate the model, but makes it hard to apply to non-arcade games, you might have noticed that i\’m hung up on time here as opposed to what the graphs actually _record_, namely executed actions. the thing is, i\’m not sure whether buzz/actions is a good metric, or rather, whether it\’s the _major_ metric you should be looking at. what buzz/actions gives you is a look at how much effort the user has to put in to achieving a higher level of buzz. it shows you which sections of your game are less interesting than others. what it doesn\’t show you is the actual player experience, which in my opinion is better measured in buzz/time. i hope i made that difference clear :-/ i\’m not always good at expressing these things in english.third, the notation system might be problematic when you you look towards how games might be built in the future. i remember a sequence from space quest, where you had to drop a rock on a spider droid. imagine a similar puzzle in a modern game engine. you might take a crowbar from your inventory to push the rock over the edge of the cliff. that\’s a pretty well-defined action that leads to a clearly defined reward. now what if your game world includes a good physics engine? you could drive a car into the rock instead, pushing it over the ledge. or you could drop the car on the spider droid. or you could park the car next to the rock, put a fuse in the fuel tank, and let the explosion push the rock off… my point here is that the more, umm, let\’s say \”realistic\” games get in terms of world interaction, the less simple it becomes to identify which actions led to which rewards.and that, i think, is a very important thing when attempting to analyze your game. specifically, if you don\’t expend any effort, the reward event will probably not be very rewarding. what i therefore think this notation system sorely lacks is a correlation between actions, risks and rewards that determines the strength of the resulting buzz. no, i haven\’t figured that out yet :Pall in all, i get the feeling that the notation system as it is now would be very well suited to arcade-style games, in which the verbs and rules are fairly limited in number and complexity (i.e. side-effects). i can see jump\’n\’runs or simple shooters to be analyzed in this way, but when the shooter allows destroying part of the surroundings in order to kill enemies, things become difficult. and not because the notation system doesn\’t apply, but rather because of the technical difficulty of how to detect and therefore record how an action results in a specific reward.still, it\’s a great start and it\’s given me a lot to think about.i\’m struck by how many of the posters here seem to think how useless the whole thing is, however. i\’m struck by that mainly because it seems to parallel how many, many software developers think about tools to analyze the quality of your software, such as unittesting (not going into that here). there\’s a famous saying that illustrates why tools such as this notation system are useful: if the only tool you know is a hammer, everything will look like a nail. rephrased it might be: if you only know how to design your game intuitively, you\’re not likely to produce the best possible results. learn how to use many different tools, and learn _when they apply_. that\’s the only way known to man to produce works of excellence in a reasonable amount of time (pure chance takes too long).


  4. Anonymous says

    Danc,I find this article fascinating and important, and would like to talk to you. I have hosted a small and elite think-tank on the topic of \”music on computers\” (Project BBQ) that has been extremely successful in influencing that industry over the last 10 years.This year my team is putting on Project Horseshoe, a similar event but for Game Design. https://www.projecthorseshoe.comThis one is by invitation only, and there will only be 50 attendees. Will you please contact me through the contact info in my website? Thanks.,George A. SangerThe Fat Man


  5. Unfortunately, I too am late to the discussion. However, I hope some of my comments will be of value to you Danc. “We don\’t yet have the \’pitch gauge\’ for understanding the magnitude and strength of rewards. The fundamentals still apply, but there are always things that we can\’t measure.”- I can attest that technology exists today which I am using on a current project that does exactly what you say can’t be done. I am interested in the idea of trying out both systems at the same time to see how they synchronize. We already record entire game sessions, voice communication, emotional responses, and physical responses and then provide real-time scrubable data in an after action reviews (AAR). It will be interesting to combine a notation system. I was doing an interview just the other day and was asked to compare MMO’s addictive nature to gambling. Which leads me to another fun idea, apply the notation system to slot machines. Then try to identify what the casinos seem to have mastered, the addictive nature and psychology of a well designed reward structure. I think everyone here will agree that both slot machines and WoW have a very fine tuned reward structure and we as designers understand its power for good and evil. Fortunately, we also understand that reward structure alone is not enough to make an enjoyable game experience. A good successful game requires that we consider the impact of other elements such barrier to entry, learning curve, UI design, art & style, a world, and the list goes on…. One of the most interesting things to consider is that WoW not only uses the power of reward structure effectively it does it to embed the player socially. Which is the type of meaningful experience that Danc has been implying can’t be measured. But actually now it can, to what end I don’t know. Nevertheless, this is the type of information that academic and government studies need in order to prove to those who are not gamers, that games are not just kid’s toys. They are not a form of meaningless entertainment and can have a greater role in society. Danc, I know you spoke on this later in the thread but I’ll restate it. Overall, music is probably the wrong analogy but because you used it people are caught up in it as a limitation. Music notation allows one to archive and recreate later what was written. The system of notation you propose for games obviously will not allow one to recreate a hit game by playing the notation back. You are right though people did miss the point but that is too bad for them. “…Danc is suggesting is that stimuli provoke different reactions in different people.” – Different people perceive, learn, and process information (surprise) differently hence we don’t all agree.“And as I was trying to imply earlier, reducing the point of game design to creating a \”buzz\”, giving rewards and making players addicted is pure BS. It\’s rampant capitalism controlling the theory of design. You\’re assuming that what games most commonly do is what they always ought to do.” – Very good point but its useful for us to know how and why games are able to do what they do well so we can figure out ways for them to do other things we haven’t thought of yet. “Has anyone written music? It doesn\’t exactly spring forth whole and perfect onto the staff.” Actually it is really scary how easily it does. There are many rules that guide western classical music. Most of us know the rules even if we haven’t studied them. This is why when you hear a few notes in a tune you can predict the following note having never heard the piece before. It follows a very well established set of rules that dictates the next set of possible options. A long time ago I used to be a music major. One of the most surprising things to me was that following the rules and notating music down on paper with no clue how it would sound (I recall focusing on making it look interesting on the paper) and then sat down, played it and was surprised how good it sounded. Granted it was not a masterpiece.There is a saying that goes something like… only when you know the rules of music can you break them and play jazz. We need a language to pass on what we know, we need rules to guide us and when we are ready we will play Jazz. I agree that there is limited use in Danc’s system as it applies to the creation of games as we currently think of them. But something I have come to appreciate recently is that in order for us to use games to teach with and learn from (something us designers know how effective games are at this), we need to be able to communicate to people who don’t understand games. This is another reason why developing a language, rules, and tools allows us to communicate and prove scientifically the value of the medium for other uses which unfortunately is required when it comes down to institutionalizing games as learning tool. “There is such a huge difference in any creative field between tailored-for products and from-the-heart work.” – Yes this is true! From-the-heart work is what I like to consider art. The problem is for the most part we are beyond where 1 person can create a game from-the-heart and getting 100 people to create a game from the heart is even less plausible. Games are more akin to architecture…. Sure you can design a house for yourself but most architecture is design for people, a purpose, a location, for multiple uses, for an audience, for a client, the list goes on and games can have just as many design constraints.“The craft is making the good game, not making the game that you think that people will like” and “Game development is an art first and an engineering problem second, not the other way around.” – Actually either of the statements can be true as you stated or reversed and still be true! There is no right way and it depends on who you are making the game for and what are the design constraints. Am I spending someone else’s money on the creation of a game and expected to make a profit? If so, I damn well better care about the target audience otherwise I’ll not be making games for very long. Or do I not care about anyone else, and have millions to spend on making the perfect game that only I’ll love. Maybe someone else will love it too but hey its art I don’t care if they like it. Either way is valid and to not be aware of constraints is dangerous business. “All of this theoretical guff is just skirting around that realisation, trying to make it not so because for it to be an art means that it is unsolvable and involves learning how to trust instincts. Something that most developers are very bad at doing.”-I like to believe that game designers are actually really good at trusting our instincts. It’s the people that fund games who are not. It is after all their money we are spending and we need to be conscious of their concerns. I don’t know about you but billionaires don’t knock on my door and offer to give me money to make games. Yes I know, sad but true. “So, I guess my thoughts are these: Any approach to notate game design without being able to \’run\’ said game from the notation will mostly be useful for tweaking and understanding existing games; not creating new ones.” – Well stated but with the thorough understanding of existing games we can learn to create new ones with gleaned knowledge.“I come from a rather radical sect of software development that believes that design documents are generally a load of whooey. They are at best a promise of a conversation and at worse an excuse for why things didn\’t work out. They are never, ever accurate and never will be.” This is probably the most factual statement written on this entire board. =D. But at the very least the bibles serve us by documenting our thought process. I grown to appreciate the notion that even if I create the document for just me and nobody else then it still worth it.“Ultimately, the symbolic system has to map back onto the concrete questions of implementation (not just code, but art, scripting, sound, etc.), and so while it can be helpful to annotate the structural mechanics of a design, there will always need to be fuller, more concrete desriptions of the play experience.” – Yep, I think the games are like architecture analogy I used earlier works very well to explain why this is useful. An architect is like a game designer. Both are keepers of the vision and need to communicate it to the hundreds of people that will eventually help bring it to reality.“I really wish that we could once and for all get rid of this notion that the field of game design will somehow benefit from a formal language, as I\’ve said elsewhere. It\’s a fool\’s errand, and for that reason, best left to the academics.” Eyejinx you know as well as I, that academics lack our experience with the medium. Increasingly, colleges (the academics) are adopting and teaching the art of making games. The most foolish thing we can do is to allow those who least understand the medium, pass on the knowledge of game design.“- How do I record useful feedback from my prototype play sessions?” – Welcome to the world of biofeedback. Wireless, USB, and no calibration required! What faster way can one see what someone else is thinking than to graph what they are thinking! As I mentioned earlier, this technology exists in a commercially useable form today. “No one\’s saying you shouldn\’t create tools to overcome your personal shortcomings.” – Damn Michael! No need to get personal!“What I object to is the notion that there\’s a universal formal language of game design that will help all game designers to do their jobs better. That’s just bunk.” – Bunk it is, but you chose to limit your view and created the bunk. Creating a language for game design is not about helping game designers do their job better. It’s about being able to communicate more effectively and pass on our knowledge and mentor the next generation of game designers. We are far beyond an apprenticeship only society. How can we teach the art of game design if we can not agree on the words we used to describe and create it? Like music, Art too has a language and rules. For years the only way to learn art was to either journey alone making unnecessary mistakes or become an apprentice and study from a master. But today you can go to any art schools, learn the language and rules. These become a foundation that helps artists understand the basics of the medium from which they can grow. One day through study and practice they will find their own personal style possibly breaking rules and expanding the language they used to guide them. Remember, language never remain stagnate and change as needed by the people who use it.


  6. Hello Danc, I am really late on this, I just have to hope that you\’ll still read this…Well I enjoyed your article A LOT and there is something I wrote I\’d love to hear your opinion. I\’m Alessandro Canossa, at the moment writing a Phd on level design in Denmark. I don\’t know how to get in touch with you, but if you have time and are curious enough to google me, please send me a line. I am not a webstalker, I repeat, I\’d just like to hear your opinion on my articles. Ciao.


  7. 引越業界No.1クラスの安さと安心。お客様にあった様々なプランをご用意。秘密厳守なので単身女性も安心のキング引越センター


  8. Pingback: Software Engineering Research Questions – A2Z Facts

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s