Click "Sleep" for a dark background.
Click "sleep" again if text isn't dark.



Linearity. Emergence. Convergence pt.5

The Nature of Emergence

The nature of emergence is countless possibility and chaos. Emergence is the result of a set of rules, parameters, conditions, factors, and elements mixing together to produce one possibility of many. Many gamers understand the term "emergent gameplay" to mean surprising, unexpected happenings in video games that developers don't intend to create. Again, a definition that relies on developer intent and notions like "surprising" and "expected" is problematic in itself. I've carefully designed the definitions posted in part 1 of this series to avoid such problems. But to give the notion some credit, there's a simple reason why emergence and the unexpected are commonly conflated ideas. And explaining why will help uncover the nature of emergence. 


"Life finds a way" ~Jurassic Park


In part 4 of this series I proposed that the way we think and learn is very linear because thinking is strongly tied to linear language. There's another limitation of the mind that is key to understanding the surprising quality of emergence. That limitation is our short-term memory (STM). With about 7+ 2 bits of information we can hold actively in our minds, our perception is pretty limited and easily overwhelmed. To get more utility out of our STM we chunk data and store important information in our long-term memories (LTM). Putting information into our LTM is a slow and somewhat mysterious process that generally takes a lot of repetition and practice. And chunking is a tool that is stronger the more LTM we have, which allows us to recognize more patterns and create more specialized groups. The point is, because of these mental limitations we are not very observant, and we are very forgetful. Perhaps a better way of putting it is a lot of things can surprise us because of our limited focus and attention.

As funny as it sounds, I think the number 11 is a somewhat elusive, surprising, and challenging number for us to comprehend. I say this somewhat jokingly because 11 is the lowest number we can't count to on our fingers; in some ways I don't think we have a strong intuitive grasp of numbers beyond 10 or beyond our STM capacities. As I've detailed in my article Complexity You Can Count On, it doesn't take much for to overwhelm us. In the article I detail a game called doodle god in which players make matches of 2 tiles to create new elements. At around 15 matches keeping track of all the possible combinations, attempted combinations, failed combinations, redundant combinations, and successful combinations is more than most people can handle mentally. At this point, efficiency, speed, and progress begin to slow like an overtaxed computer. It doesn't take long before your progress stops as your brain is overloaded simply trying to organize everything. Even if you extend your mind by writing things down the shear number of possibilities to explore and organize is a daunting task. 

It seems that the shear volume of possibilities is an important factor here. For video games, the gameplay rules (complexities) are what result in countless possibilities. I say countless because for most games the number is so large and grows so quickly that the value is practically infinite. We really don't have an intuitive or adequate understanding of such an explosion of possibilities from so few rules and conditions. Like the classic rice and chessboard story (see video now), would you have guessed that the final rice amount could travel light years and back again? How many possible combinations are there in Chess within the first 4 moves? Would you guess close to 200,000? How about the first 10 moves in Chess? Would you guess trillions? The math quickly gets hard to calculate. But mathematicians claim that there are more possible combinations of moves in Chess than there are atoms in the universe!  


I'm not surprised this is possible, but it still blows my mind. 


The point I want to make is it shouldn't be surprising that some emergent possibilities are surprising. Out of the billions of different sequences, positions, and combinations of actions that you can explore just within World 1-1 in Super Mario Brothers on the NES, there will surely be some possibilities that the developers haven't considered, the playtests haven't encountered, the speed runners haven't check, and the TAS gamers missed. If you think "billions" is too high of a number, just consider that even in the very strict level design in the video below, that every frame (30 frames per second) the player could be doing something slightly different from any of the Marios you see. It's seems somewhat foolish to be surprised about things we haven't (and can't) take the time to investigate, measure, count, experience, or observe. 

The more complexities (in this case rules of the game that affect the gamestate) in a game the more potential emergent possibilities. For example, each new successfully matched element discovered in doodle god increased the number of potential combinations by an ever increasing amount. Gameplay dynamics and other rules tend to explode a system with emergent potential. As carefully as we design, emergence seems nearly impossible to fully control. We try to guide it with design or guard against it with fail safes, but emergence seems to have a life of its own, unbounded by limitations. If there's even the smallest crack in your system, emergence will allow that crack to be explored. Such is chaos. Such is the nature of emergence. 


The Nature of Gameplay

Gameplay has a nature of its own. Games are systems with rules and a goal of some kind that creates the value scale by which we evaluate all of our goal-seeking in-game actions. If the goal of a game is to collect 10 coins, then clearly the number of coins we have and our ability to collect these coins become key considerations. To win, we have to understand what actions we can do (mechanics) and develop our skills to get the job done. This control or agency is important to what games are. Without some degree of control to influence the game states and game outcomes, there is no gameplay; there is no game. This means there must be at least 2 player influenced gamestates in gameplay to be of consideration here.

Part of the nature of skill-based games is experiencing the squeeze. The squeeze is the narrowing of player expectations and possibilities as players attempt to succeed in challenges. The squeeze most clearly exists in consistent skill-based systems and is part of the nature of skill-based games because of a simple balance that's required. Challenges of increasing skill are about requiring more effort of the player. More dexterity, knowledge, adaptation, reflex, and timing skills. Another way of thinking about the type of design that supports skill-based play is a design that limits viable player influenced gamestates. If there are more ways to "not win" than to win, then the player must use their skills to carefully influence the gamestate to one of the few winable possibilities. In other words, the nature of skill-based gamepaly is of limitations and restrictions. 




Skill-based (game). A system with at least one goal or a goal like objective where, out of all the possible gamestates, there are more player influenced gamestates that are not conducive to achieving the goal. Put simply, a system where it is easier to fail than win from blind interaction. With such a system conscious effort (skill) is required to consistently and reliably win. 


Skill-based play, goals, and given objectives are at the heart of gameplay. They are not necessarily part of interactive experiences, a category that is much more broad than gameplay. Understanding how designers create skill-based play is the key to understanding the nature of gameplay. Gameplay is all about real challenges, real skill, and real player development. The real part of the half-real experience that is gamplay comes from the fact that our failures and victories are because of us. The other real part is that we really have to learn and practice to build more skill to overcome increasingly difficult gameplay challenges.

But challenge in itself, in its most raw form, is not very interesting. There's only so much you can do with gameplay designed around pure challenge, challenges where there is nothing for players to learn to build their skills over the long term. The design goal of the DKART skill measuring games my brother and I made was to create a series of games to purely test players skills. We wanted players to be able to see what they were made of without having to study the game rules, learn new controls, or practice anything. While these games are fun and informative, they're quite "raw." With no complexities to learn and LTM knowledge skills to build, the whole experience can only be so interesting. It's clear that the video game medium as a whole needs a lot more range when it comes to the types gameplay challenges possible. 

To increase the range of gameplay experiences, games are designed with more complexities (rules). In one of the later articles in my series Appraising the Art of Combat, I concluded that there is value in complexity for complexity's sake. Complexity not only gives a more detailed definition to the gameplay and its interactions, but it gives players a higher knowledge skill ceiling. This is key for game design and understanding its nature. Knowledge skill is the most important skill because it is most directly stressed by increasing gameplay complexities (i.e. there are more game rules to learn), and it is used to augment the other 4 DKART skills. 

So for games to be meaningful they must be skill-based. To have enough creative range to work with, games are designed with complexities. Complexities make games harder to play by expanding the skill ceiling, particularly knowledge skill. When developing knowledge skill players use a universal learning method of trial-and-error, which essentially means we try things, analyze the results, tweak, and try again. Put it all together and it's clear that the nature of gameplay is an experience of many errors, experiments, and tweaks propelled by the slow learning pace of the player. I covered many of these same ideas in my series A Defense of Gameplay. The games that focus largely on execution with as few complexities as possible still share this nature. 


Linearity, emergence, and gameplay all have natures, which is to say there are strong limitations inherent in these ideas that shape works. In part 6 we'll look at what happens when these natures clash and converge. 

« Linearity. Emergence. Convergence pt.6 | Main | Linearity. Emergence. Convergence pt.4 »

Reader Comments (3)

Out of the billions of different sequences, positions, and combinations of actions that you can explore just within World 1-1 in Super Mario Brothers on the NES...

I believe there are actually far less than 248,400 ways to play 1-1 (discounting foolishness with pausing.)

About 3:50 time limit with 30 FPS gives us a max of 6900 frames (less with deaths and early wins) * 9 D-pad states * 2 A button states * 2 B button states. Even adding in pausing would only double the number of options.

Of course if we are including hardware differences, anything is possible. :)

December 19, 2012 | Unregistered CommenterUbrasaur

Oops! Just a correction to my last post: instead of 36 input states * 6900 frames, it should be 36 ^ 6900, because input states depend on history. So yes, it is quite the large number. >_<

December 19, 2012 | Unregistered CommenterUbrasaur

@ Ubrasaur

LOL. I have been sitting here for the past 5 minute with a calculator in hand trying to explain why the number is much higher than 248,400... and then you beat me to the punch.

I love how you challenged my idea and brought the math to back it up.

Keep it up.

December 19, 2012 | Registered CommenterRichard Terrell (KirbyKid)

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>