Design Thoughts: Unquantifiable Elements

You know, despite all this high theory on game design, there always seems to be an unquantifiable element of the best games which can only be described as fun. Chris Crawford says that fun is a bad word for a game designer to use, and I tend to agree, because it’s impossible to say exactly what fun is, or prove that something is fun. However, everyone seems to be in agreement that it does exist.

Katamari Damacy, a wacky PS2 game imported from Japan, definitely seems to have this unquantifiable element within. While there are some elements of time pressure and choice within the actual game play, they aren’t really the central focus. Instead, the central focus is rolling a huge ball around the level, sticking small objects to it until it gets big enough for larger objects to get caught. The concept and execution are just wacky enough, and the game play just relaxing enough to keep you going. The music is excellent as well. But in the end, it’s not the concepts of choice, behavior, timing, story, or consequence which make the game work, it’s the unquantifiable elements provided by rolling cats, cows, and people into a huge ball. This can’t be explained by an academic analysis, and in fact, looses the point if you try.

Design Thoughts: Design Elements

The fundamental idea behind my approach to design is that all interesting complexity is built through the combination of simple elements. Each element in the design is simple, consistent, small, and discreet. When several elements are combined, a series of cascading, tangential, or emergent behaviors is often formed from the intersection of these elements. In some cases, a single atom will intersect with several others, forming several of these new behaviors.

Increasing the number of tangential elements in a situation gives players a feeling of choice: do I go for the health pack now, or save it for later? I need to take several gambles based on what I know about my current (or future) surrounding and condition to answer this question, and I experience this balancing of factors as my freedom of direct choice within the situation.

Increasing the number of cascading elements adjusts the difficulty of a given scenario; this is because cascading elements often have an additive effect on the given challenge. Tripping an alarm will trigger more guards to arrive, increasing the difficulty of the situation, while rolling a barrel down the hill might topple several of the arriving guards, decreasing the difficulty of the situation. Cascading elements can often be put to multiple uses (for good or bad), and often feature some level of indirection (I push barrel, barrel hits guard).

Emergent elements adjust the perception of intelligence within your system; this is because highly emergent systems produce behaviors which appear to go beyond the original programming. While tangential and cascading elements can be directly created, emergent elements are only created from the intersection of multiple elements. A colony of ants appears to have a centralized intelligence, but is actually a decentralized system; no ant commands another ant, and no ant is aware of any plans for the colony; yet their discreet predictable behaviors form complex societies and tunnel structures which appear to be planed. Emergent elements require a reasonably large number of agents interacting to fruition (though only 1 behavior is required), thus many games do not have the correct conditions for them to appear.

Many designers have proclaimed emergent systems as the new frontier of game design; but I'd argue it's one we've been fighting against for years. Quite a few of the more tricky bugs you find in games are really just an example of what we'd classify as emergent behavior. And most of what people refer to in games an emergence is really just cascading effects; though certainly, when unexpected, the two share some similiarities in appearance.

A single element may exist within multiple of these categories, and its intersections may produce results in any of these categories, regardless of which category it exists within. As the number of elements in a design increases, the number of potential tangential, cascading, or emergent elements produced by the addition of a new element increases. Thus, by following this approach, the possibility space can grow exponentially rather than linearly.

Although there are other ways to build complex systems, it’s my belief that this type of complexity is more inherently interesting to people. This is because a large portion of the human brain is designed around recognizing and classifying patterns, and the patterns created by these types of system tend to have a logic which is very visible, but hard to quantify down to their simple root elements.

Design Thoughts: The Time Domain

Everything happens within a construct of time; even in games which don’t use time as a limiting mechanic, the time a user is willing to think about a given problem is finite. Within all games, it’s extremely important to pay attention to the layering and pacing of decisions within the time domain.

The brain wants to classify and organize information as part of its primary function, and will interpolate information to fill in gaps. Once we’ve done this with various elements, we no longer need to think about them consciously. For instance, if I tell you a high level goal like “open the door”, you don’t think about all the various muscles which are required to be precisely synchronized to make the task happen; you simply decide to do the task, look for the door, and move to open it. What is actually millions of small decisions is summed up into only a few.

As users become accustomed to playing a game, and move into it’s optimization phase, they are effectively thinking less about the micro decisions, and more about the macro decisions of the game; doing a double wall jump is no longer something to think about, but rather one motion within a greater goal.

Thus, it is important to layer and temper our decision points over time. You can think of this as the beats, measures, melodies, and song form within a piece of music, or the letters, words, sentences, and paragraphs of a story. These groupings have become fundamental to all music and writing, and have evolved separately in every culture of the world.

It's important to understand how these rhythms exist within your game, but it’s just as important to understand how they relate to the consequence within your game. The tempo and rhythmic figures will help you determine exactly how much consequence a single decision can have, and what the allowed error metric is for a decision. Consider a single attack resolution as our beat (letter), a combo sequence as our measure (word), a single battle as our phrase (sentence), and the situation we’re trying to conquer as our song form (paragraph). The resolution of each collection of smaller elements builds the resolution of the larger elements; thus, the consequences of each layer are, in a sense, passed up to the layer above.

The brain will attempt to group several beats into a single decision, but only to the extent that consequence allows. If the consequence is too great for a mistake at this level, all focus will remain and higher order strategies will not be able to be processed. If consequence for individual mistakes at this level is low, the brain will group these decisions based on an acceptable error threshold, and the brain will be able to think about higher order strategies while running on ‘auto pilot’ for these lower level decisions. This continues up for any number of levels until the timeframe of consequence is too large to process; in Chess, this would the player’s ability to think some number of moves ahead; in an action game the limiting factor might be your knowledge of your immediate surroundings.

As the tempo of the game is increased, the ratio of ‘consequence over time’ increases, potentially suppressing higher order strategies in favor of more focus on lower level decisions. Slow the tempo down and there’s more time for higher level decisions to be processed. Again, the brain is operating at its level acceptable error threshold, and adjusting its focus accordingly. By paying attention to this threshold, decision groupings, and relative consequence, we begin to see a measurement and layering of complexity that must be achieved for a given challenge level, with a clear understanding of where the complexity should lie at each layer.

I personally feel that it’s vital for designers to understand these different levels within their game; if they do not, they end up putting too many or too few dynamics into each layer, often suppressing higher level strategy from being observed, or not providing enough interesting dynamics to continually challenge the user. Those mistakes lead to frustration and boredom respectively. We often simplify this matter into a ratio of hit points and damage amounts, but those are really the outer edges of the spectrum, the interesting pacing happens in the middle.

Design Thoughts: Why do we play?

Why do we play?

Play is a learning function. Most play involves training the brain to perform useful root functions, such as recognition, classification, and decision making. Our brains are designed to quickly classify objects into various groups based on our level of interest in those things. The more interested we are in a particular category, the more we break it into smaller, manageable groups. So while we start with music, we might move to jazz, and then be-bop. Each concept is uniquely classified into its various categories and subcategories within our mind, and we navigate the various levels of classification freely and without difficulty.

Our desire to play, in essence, is our desire to get better at these root functions of the brain. Playing allows us to increase the speed at which a decision can be reached based on classifiable information (a game of catch), or to increase the accuracy in which we can make a decision based on available input and prediction (chess).

The phases of play

As a user plays a game, they go through three phases. The first is the learning phase, where the user’s primary focus is learning the basic functions of playing the game.

The second phase, exploration, is the golden part of most games. During this phase, users explore the boundaries and solutions within the possibility space provided by the game.

Eventually, as the exploration of the possibility space is exhausted, play moves to the third phase, which is optimization of the acquisition of goals through the game space. Whether this is optimizing the pieces in a game of Tetris, the resources in an RTS, or your character’s design in an RPG, optimization occurs in all games. The wider the possibility space, the longer the game’s interest can last. Once the user has mastered the optimization functions within the game to a sufficient level to reach their goals, interest in playing quickly fades.

From a game designer’s perspective, it is important to understand and maximize the usefulness of these phases of game play. For instance, if you create a large possibility space, but there is little reason to optimize your play within that space (i.e., you can achieve the goal without those optimizations), the user will find no desire to learn and master those optimizations.

Design Thoughts: Axis's of game design.

There are many goals of game design, but probably the most important is the ever illusively defined “fun”. It’s hard to define what features or dynamics create a game fun, and the dynamics of this definition change for each person. Chris Crawford says fun is a bad word, and I tend to agree. However, there are some constants involved in every game, mainly, a balance between several axis’s of design:

Strategy vs. Reactionary

Strategic games often require complex thought over the consequences of a given move or choice. They usually don’t force the user to form decisions in highly limited amount of time, but instead the user is asked to weigh the options of all available moves while forming some type of long-term strategy to accomplish their goal.
Reactionary games rely on users training themselves to certain stimulus, and being able to react to that stimulus under tight time pressure.

Depth vs. Breadth

This is a measure between how much there is to do in a single game element, or the depth of a game system, and how many elements are in the game, or the breadth of the game’s systems.
Games which feature deep systems can interest users in a single system for a much longer time, but if the user grows weary of playing with that system, they often become wary of the game as a whole.
Games which feature many shallower systems often give the users options. While each of these systems may be less satisfying that a single deep system, the variety in game play attracts a potentially wider audience, and allows users to spend more time with the game as a whole, since as they become bored with one system, there are other systems to play with. Any system which intersects in some way with another system will often create emergent or tangential effects, which often further widen the possibility space.

Skill vs. Luck

People are fascinated by the concept of luck. But while people are fascinated by facing the odds, they often want some measure of skill involved for the act to seem gratifying. Even when playing purely luck based systems, the human psyche tends to place skill based beliefs onto the system. This is why people often develop superstitions and systems to playing purely luck based games – they want to believe there is more to it than luck; that blowing on the dice will cause them to roll a seven, or an article of clothing will cause the cards to be dealt in their favor.
Purely skill based games are popular with those with a competitive edge. However, with any purely skill based ability, a small number of people will rise above the average skill level by such an amount that very few people will ever be able to compete with them.
Most mainstream games combine skill and luck, and generally speaking, the most popular social games involve a large amount of luck with a minor amount of skill. This acts as a great equalizer, making it possible for anyone to win.
Examples of pure luck based games: Slot Machines, Craps
Examples of Luck biased games: Backgammon, Uno
Examples of Skill biased games: Tetris, Poker
Examples of pure Skill based games: Street Fighter II, Chess

As a game system is created, it’s important to think about how it fits into the above axis’s, and consider other successful games which lie in the same space. This will often lead to a clearer understanding of both what will make that system successful, and what audience it will appeal to. Of course, I still believe the first audience should always be yourself.

Design Thoughts: Burningman as MMP

Burningman is an interesting experience, one I highly recommend. It's amazing how fast you become acclimated to the altered social rules in such an environment. After an hour, wondering across a rollerscating rink, or climbing onto a pirate ship moving slowly across the desert, seems about as normal as seeing a gas station on the highway. I often find that people playing and creating Massively Multiplayer Games are so accustomed to a single idea of what an MMP must be that they forget how malleable our social and mental rule set really is. They latch on to a single feature or approach, unable to envision alternate solutions, and unable to follow changes out to their logical conclusions. My only explanation for this is one based around the idea of gravity.

See, when your out in the desert surrounded by 30,000 people sharing a mutual alternate reality, it becomes very easy for you to accept that reality. You acclimate the rules of that reality, and process the logic consequences of those rules quickly. But if your one person in an alternate reality, with 30,000 other people around you not sharing that reality, well, things are a little bit different. Ideas have gravity, and a critical mass of shared understanding must be achieved if they are to prosper.

The gravity of the MMP market is very much around the model of Everquest (or a Diku Mud to go back further), though certainly each company has it's own internal gravity around their internal ideas. Each deviation from this model, even a small deviation, ends up being a battle at one level or another. What I find so funny is that the possibility space of the model is so much smaller than the possibility space of a traditional game model; a feature or approach that appears in 60% of 3d games yet hasn't in MMPs is often viewed as radical or unheard of.

Until that gravity center is around more than one style of MMP, players and developers alike will have difficulty breaking away from the gravitational center. The publishers, press, players, and developers will all feel the pull towards the gravitational center; an irresistible, and sometimes unquantifiable urge, to push every result towards the same basic model. Hopefully the influence of radically different games like Puzzle Pirates (and to some extent Dungeon's and Dragon's Online) will speed the growth of this center of gravity; but it's never quite fast enough for my tastes.

Design Thoughts: Exception based systems

For the past few days I've been thinking about the differences between two types of game designs. When I approach a design problem, I'm often looking for a clean system which can solve the problem; a system which I can retain entirely in my head, and translate into logical code functions. In many ways, this is a top down design approach to a problem, where you design the outer walls of your possibility space and everything lives within those walls. It's clean, and can usually be well coded.

I use this type of design in a bottom up approach, however: by building multiple, well designed systems, interesting emmergent or tangental behavior is formed out of the intersection of multiple systems. Thus, I've always looked at myself as a very bottom up design, when in fact, it's the interaction of multiple top down systems which has been my focus all along. Like a slime mold or ant collony, each system is relitively simple, but builds a complex result.

A Magic the Gathering tournament has been going on at work; this is my first time playing Magic, and to be honest, I still don't know if I enjoy it. It is, however, the perfect example of what I'm starting to call an exception based system. An exception based system is a design built of the concepts of trump cards; in other words, a series of plays which can be broken by other plays, which can often be broken by other broken plays. The rule systems of these games often look somewhat like an arms race in motion; as each new edition is released, old cards are removed out of the system and replaced with new cards, which are often unbalancing in some new way. There's no real sense of a well designed and balanced structure, because the very cards which unbalance the structure are being counterbalanced by other unbalancing cards. Thus, you're left with a wonderful feeling of power when you obtain truely broken cards; only to find out later that they can often be trumped by some other, completely broken card.
Now, it would seem to me that an exception based system usually starts out as a well ordered design; but like a plant left unattended, it grows outside of the confinds of it's pot, until eventually there's little semblance of the very structure it came from. The programmer in me finds this very annoying. The system is unclean, untidy, and it will likely make my code look that way. There's no clear structure to work from, nor any clear way to determine the full possibility space provided.

However, the player in me finds something compelling about such a mess of a system. Any system that messy is bound to have exploits and tricks within it, and of course, those types of optimizations of stratagy are exactly what game mastery is all about. So over the last few days I've been trying to wrap my head around exactly how to harness such a system in a controlled fashion; can you build a system based purely on exception like rules and still quantify and retain it's possibility space? Or must it evolve over time, growing out of it's originally planted pot? Certainly that's been the approach used with Magic, as they cycle cards in and out of play, slowly bringing the game into some semblance of balance through many iterations.

First post

Well, I fired up an old HTML editor at 3am thinking that maybe I'd make another web site for all the writting I've been doing. But then I thought "Am I really going to do this the old fashioned way? Surely the web has changes since the 90's". Hense the new blog. We'll see how it goes, but for tonight, we'll keep it simple.

Here's a link to an article I wrote on some basic game design theory and application, as applied to my current project, D&D online.

http://www.ddo.com/index.php?page_id=76