Tag Archives: polish

Up, Up and Away!

Against Eschatological Design

Posted on by

The last few months of a game’s development is a magical time.  Ideally, everything is coming together, the team is firing on all cylinders, and the experience is getting better by the hour.  Bugs are getting fixed, the build is more stable and performs better, the art is looking polished, and playtest results begin to climb to their highest levels right as the game is locked down.  The difference between those last precious moments of post-production, where everything is happening too fast to follow, and the months (often years) of glacially slow progress at the beginning of a project are so stark, they create the perception that a switch has been thrown, that the game has suddenly become fun.  The designer’s new-found power to affect change, and the positive feedback from the rest of the team, leads to a feeling of vindication and exhilaration.  Finally, all the hard work has paid off and the game has crossed the Fun Barrier.

It is tempting, after the flush of this experience, to look back on a game’s development as a power curve.  To retroactively smooth out the experience so it fits a nice mathematical progression, making the outcome of a fun game inevitable from the start.  To pretend as if the only unknown was if the game would cross the Fun Barrier before the project ran out of time or funding.  To ensure success on the next project by figuring out how to increase the exponent on the power curve, to work harder and add features faster, to run more playtests and balance earlier, so the game has time to reach the steep end of its exponential curve.

Up, Up and Away!

Fun = (Iterations * Time) ^Talent ?

The problem is that fun doesn’t really work that way.  A player experiences fun as a binary switch, either they are having fun at a given moment or they aren’t, like a square wave.  There’s no such thing as almost fun; an experience doesn’t gradually go from 90% enjoyable to 100% fun in a continuous curve.  A game gets better because it sustains a fun experience for longer stretches at a time, with less unfun gaps in between.

Worst Line Rider level ever

Fun = Fun * Polish ?

An experienced game designer is sensitive to very short, almost subliminal moments where a mechanic is actually fun.  Even in an early prototype phase, they can detect these snippets and predict with confidence which mechanics have potential and which ones don’t.  So, instead of finding ways to be more effective at polishing hopelessly dull gameplay, they can quickly abandon mechanics that never display those glimpses of greatness and focus exclusively on eliminating or minimizing the unfun gaps in those mechanics are already fun in spurts.  This is why exceptional designers tend to produce simpler, more reliably enjoyable games with fewer mechanics that feel almost effortless to play.  And why the vast majority of average games are released with an abundance of features, but subject players to hours of tedium or frustration as they labor to find fleeting moments of fun on their own.

Case Study: Tribes

Posted on by

Previously, we have explored how the community balances a game, sometimes despite the developer’s best intentions.  Tribes is a great example of how the community not only determines how the game is ultimately played, but often decides the path of future development.

Tribes shipped in 1998 to a fair amount of critical and commercial success.  It featured large multiplayer battles on open terrain that were beyond anything that had been seen before.  Players could choose between three armor classes (Heavy, Medium and Light), pilot vehicles, plant bases, purchase weapons and equipment… it even had jetpacks!  It also had one very significant bug, an unintended side-effect of the physics system known as “skiing”.

That flag is on fire because it's sweet

Go Zebra Tribe!

By tapping the jump button while descending a hill, players could exploit this physics bug to accelerate to an incredible speed.  Combining this technique with the jetpack would allow players to quickly cross even the largest maps, much faster than the designers anticipated.  This worked even with heavy armor, meaning there was little incentive to choose the lighter, more agile classes.  It was faster than vehicles, making them redundant.  Since most of the weapons did not have instant travel projectiles, it became almost impossible to hit anyone outdoors.  Nearly every aspect of the gameplay was affected.

In a short time, the game balance was totally wrecked… and the players loved it!  They invented new strategies, found new ways of attacking bases, used old weapons in new ways.  They became experts in using another physics bug called “body blocking” to physically bar enemies from escaping with their flag.  The chaingun, a weapon that had been scorned, became their weapon of choice because it fired one of the few projectiles fast enough to hit a skiing player.  They re-balanced the game around this new game mechanic.

Speaking of unexpected effects...

The Tribe has spoken.

The developers attempted to fix the game with a patch, but the community rejected it.  By that point, everyone who did not like the effect of skiing had already left the community.  The remaining players where those that thought it was fun.  Unfortunately, this smaller community was the only audience for a sequel, so the development team were forced to cater to them.  Tribes 2 not only included an “official” version of skiing, but even explicitly taught new players how to do it!



Takeaways:

  1. Don’t just test for bugs, but to ensure the gameplay experience is the one the designers intended.
  2. The ultimate balance of a game lies in the hands of the community that plays it.
  3. Fun activities are rare, and when we find one (even as the result of a bug) we ought to embrace it.

Balancing in Passes

Posted on by

As with any creative endeavor, balancing a game is a difficult process to predict, and even more difficult to schedule.  To alleviate some of the pressure, game designers invented a circular excuse known as The Balancer’s Paradox:

  • Balance cannot happen until the end.  Every game element and knob impacts the balance, so until they are all present and functional the game cannot be balanced (and it won’t be fun.)
  • Balance cannot wait until the end.  Until the game is balanced it is not clear what elements are actually necessary or what knobs will be needed to balance them, so a complete list cannot be finished until the game is balanced.

This is very effective at eluding production demands, but unfortunately to ship the game the designer must actually find a way around this quandry.  The best solution is to balance in passes.  At several points during development, attempt to balance the elements that exist, using the knobs that are available.  The resulting balance will not have much longevity, but it should give you enough information to prioritize the remaining elements and knobs.

There are several crucial points at which a designer should stop and do a balance pass:

Pass Stage of Development Goal
Role The paper designs for all the game elements are finished A manageable number of roles with no overlap
Flow The elements can be tried in the game Elements allow the player to achieve flow
Strengths The game rules work well enough that elements can be tested against each other Elements that are strong enough to be useful
Limits Playtesters begin to abuse elements by using them outside their role Limit every element to its intended purpose
Exceptions The balance is stable enough for small exceptions to appear Eliminate bugs, unexpected uses and local imbalances
Perceptions The balance is polished, but the assets are not yet final Support the balance with matching effects, sounds, animations, etc.

Definition: Tuned

Posted on by

Tuned  (See also: Polished, Tweaked)

A game mechanic can be considered tuned when it correctly constrains the player experience to have the desired effect

The opening four bars of “Smoke on the Water” by Deep Purple are perhaps the best example of the power chord.  Nothing screams sex, drugs and rock & roll like these iconic sounds.

Smoke on the Water

Smoke on the Water

 But if you play them even a tiny bit incorrectly, you’ll have a discordant mess.  Instead of the desired effect (impressing all the girls at the party) you will achieve the exact opposite.  In the same way, game mechanics must be precisely tuned to insure they work together to produce the desired experience and prevent undesired ones.

Not about war, either

A Fire in the Sky

Unlike balance, which must be considered across the entire community for the life of the game, a game that is tuned for one individual is probably tuned for most players.  That is because the tuning process constrains the entire possibility space, not a specific experience.  As it eliminates poor experiences and emphasizes or rewards the desired ones, the differences between player skill levels and choices are automatically included.