As much as I’ve been touting greater use of emergence in games, it’s a non-trivial problem in terms of execution.  Developers face a few challenges if they go down this path.

Balance

The massive possibility space that’s so beneficial to player engagement also happens to be impossible to balance.  It’s simply too large to test all the permutations.

Talent, experience and iteration go a long way toward dealing with this issue, but a simpler approach is to re-think what it means to be balanced.  If unusual, lop-sided situations are re-cast as part of the experience — and the build-try-fail loop is short — players will find them entertaining instead of frustrating.

Being a live product also helps– anything too extreme can be quickly adjusted if it’s having a large impact on play (and by large impact, I mean it’s driving all players to pursue a single strategy, thereby undermining the benefits of an emergent system).

Noise

Having a large possibility space isn’t much good if it’s hard to find the interesting bits.  Similarly, if players can’t differentiate one approach from another, then being emergent isn’t going to increase engagement.

In both cases it helps to make the core elements of the game — the ones that can be combined during play to produce different results — as orthogonal as possible.  Having a +1 sword, +2 sword, and +3 sword as options is not being orthogonal.  A better approach would be attributes that are more binary in nature:  sword vs. not-sword, AOE vs. not-AOE, DOT vs. not-DOT, ranged vs. not-ranged, etc.   The ability to combine any of those together creates a much more discrete, understandable and useful set of permutations for the player.

Representation and Visual Fidelity

Emergence works by combining core elements in many different ways, but in a large possibility space it’s not possible to create unique assets for all permutations.  Emergent elements are often represented by simply visually stitching together smaller bits.  The challenge is making the combined element quickly understandable, even if the player has never seen that particular combination before.

Having only a handful of core, orthogonal elements helps, since the player only has to learn their function and not all the permutations, as does limiting the number of elements in any combination.  Really strong art direction makes a big difference too, particularly on smaller gaming devices where core elements might be very small.

Take poker as an example.  The individual cards are core elements, and a hand is an emergent element.  The uniqueness of each hand comes from stitching together a few cards, not a new asset.  The number of cards in a hand is constrained, each card is visually distinct, and the number of possible hands is very large.  But the player can immediately recognize what they have, even if that particular set of cards is new to them.

When I talk about the build-try-fail loop, I’m talking about the time it takes a player to set up a strategy, try it, and determine it’s success.  The build-try-fail loop applies to any game, emergent or not.  For example, Clash of Clans has a very long build phase (it can take several hours to collect the resources and create the units for a single raid), a short try phase (at most three minutes), and failure is moderately difficult to assess (you can’t build units specific to the defensive target’s setup).  By contrast, Candy Crush Saga has a modest build phase (the time it takes for energy to accrue), a lengthy try phase (several minutes), and failure — which isn’t known until the end — is hard to evaluate due to the random initial state of the puzzles.

The examples above have artificially long portions of this loop for monetization purposes, and it’s hard to argue with their success at doing so.  Nevertheless, the more emergent a game gets, the more it benefits from shortening this cycle.  Specifically:

• Experimentation is encouraged. The longer it takes to set up and make an attempt — a new level, puzzle, raid, whatever — the less risk a player is willing to take.   Reducing this time investment gives players the freedom to try new strategies and explore the entire possibility space the game has to offer.
• Learning is accelerated. The more frequent the attempts, the faster the player will come to understand the game and it’s potential.  And if you agree with the thesis that fun is primarily about learning (solving problems, figuring out new strategies, etc.), then more learning means more enjoyment for the player.  An emergent game with a large possibility space has more available to learn and therefore more potential fun to be had.
• Failure itself becomes fun instead of frustrating. The less invested a player is each time they try something new, the more likely the results will be treated as interesting or entertaining instead of unpleasant.

This is part four of a multi-part series on focus in game design, using examples primarily from Knockabout Games.  The first post can be found here.

In 2005 my company Knockabout Games built a mobile game for Superscape based on a license to the movie Dodgeball.   We did our homework — that is, we played all the old console and pc implementations of dodgeball and watched the movie — but none of us thought this was a very hard question to answer.  After all, the thematic answer is driven by the license (“it’s a tongue-in-cheek view of niche sports, specifically dodgeball”).  And it’s dodgeball.  Which means that functionally it must be about dodging.

Except, not really.  We designed all our features to support the core concept of dodging, only to find that wasn’t particularly fun (and was quite difficult on a handset with a “team” of 4 or 5 characters).  What was far more enjoyable, once we had the first playable in hand, was hitting opponents with the ball.

So midstream we changed the focus and modified (or dropped) all the game’s features accordingly.  “Dodging” was now a supporting feature, one that you had to pay much less attention to.  And we added things like a unique throw per team (e.g. a curveball or one that bounced off the back wall) and a method for moving your team in lockstep and throwing multiple balls at once.  These were simple changes, but overnight the game went from “crappy licensed movie game” to “hey, this is a lot of fun”.  Indeed, one reviewer later observed they couldn’t think of a specific reason to like the game, except that they couldn’t put the damn thing down.

This is part three of a multi-part series on focus in game design, using examples primarily from Knockabout Games.  The first post can be found here.

I’ve designed a lot of computer pinball games.  My first one, “3D Pinball For Windows“, has the odd claim to fame of being seen by pretty much anyone who ever owned a PC.  Back in 1994, when I started working on that game, I wasn’t asking myself “what is the game about”.  I just went and made a pinball game (one that was about as kitchen sink a design as you can imagine).  It wasn’t great, but it was entertaining and acceptable for the time.

So when I sat down to make a computer pinball game for a mobile phone in 2003, I really wanted to get to the underlying core of what pinball was about.  At a minimum, I wanted to identify a key element a mobile pinball game could be built around that wouldn’t be crippled by the device.

What I settled on was “motion”.  Pinball is all about sending the ball careening around the playfield.  Unimpeded motion is far more appealing than obstacles;  and any motion that ends with a reaction (e.g. a target drops or a spinner turns) is better than one that ends with nothing happening at all.

Some of the things we did to reinforce motion in the game:

• Every possible angle away from the flippers resulted in a target being hit or, more often, the ball gliding gracefully up a ramp or through an arcing channel.
• We changed the underlying collision detection to be different than the visual, narrowing things like posts and the ends of walls so that the ball was more likely to glide past and into a lane or ramp than bounce back.
• Lights were laid down in all channels and ramps that would light up briefly as the ball went past, adding to and enhancing the motion.
• We made the game easy.  There were lots of reasons to do this, but more fundamentally, one ball in play for a long time is more continuous motion without interruption.

Reviewers and players loved the game, although it fared poorly as a commercial title (it only appeared on three handsets, limiting its distribution).  It did very well in OEM, which was oddly appropriate given how most folks discovered “3D Pinball For Windows” a decade earlier.

Next week:  Dodgeball

This is part two of a multi-part series on focus in game design, using examples primarily from Knockabout Games.  The first post can be found here.

In 2004 JAMDAT (now EA Mobile) contracted us to build an NFL-licensed title with full teams and rosters for a mobile phone.  Devices were pretty limited back then — the first real color handsets had only been out a year and the iPhone was a long way off.   Football games to that point were fairly primitive affairs with limited graphics.

Professional sports is well tread territory on other platforms.  Our thematic answer to the question “what is the game about” came with the license — this was “NFL football”, real as can be given the constraints of the platform, and all the expectations that come with that:  play calling, recognizable players and teams, season long play, etc.

But there were many options open to us on the functional side:  should it be about passing?   scoring?  play calling?  We ultimately settled on a very basic idea:  football was about “contact”.

Why contact?  Because it is what defines the real football experience and distinguishes it from other sports, and it happens on every single play.  It is the essence of football, and since we couldn’t replicate Madden on a 1′ x 1′ screen, we had to go to the roots of the game and build it up again from there.

In practical terms, here’s what that meant:

• Tackling was not binary.  Every single tackle, once started, took time to resolve.  You’d push a player back, or you’d drag (or be dragged) another yard or two.  Sometimes you’d break free.  On rare occasions you and the defender would bounce off each other and fly 10 yards through the air.  But the guiding principle was that you always kept moving when tackled, and the play wasn’t over when the tackle began.
• We tied phone vibration to tackling.  We didn’t use it for anything else, so the association was very clear in the player’s head (vibration means I’m being tackled, it’s not some UI feedback in the game).  And of course, vibration really does feel like contact, so the more we extended tackling, the more this feature enhanced the game.
• Because tackling was no longer an instantaneous affair, things like horrible keypad latencies could be hidden by the tackle.  It’s frustrating to press a button on a phone and not have the screen update your action in time.  In this case, even if you were late on the keypress and got tackled, you could still, say, change direction and keep moving (the player couldn’t tell if they started moving a different way before or after the tackle, since they were able to continue).

We were the top rated football game for mobile for two years, and the game sold well for JAMDAT (although sports and mobile were not what we expected overall).  We got a lot of favorable comments about play balance and graphics and such, but I believe the thing that made it work was the underlying focus on football as “contact”.

Next week:  Precision Pinball