Canabalt is an exceptional game. In case you missed it – a real possibility since despite its breakout popularity, time passes very quickly in mobile and browser-based games – it was among the first modern wave of one-button infinite runners that then led to countless clones. You can still play it free in browser at Canabalt’s website.

The game’s iOS version’s source code has been released for perusal. Quite often the source code for a game is just an uninformative, case-specific mess, a huge hard-to-navigate tangle quite difficult for an outsider to glean much value from. Part of what’s nice about Canabalt being such a tiny, straightforward game that takes place in a single mode and setting is that its code is proportionally tiny and straightforward too.

One of the things apparent from inspection of the code is how important the player’s current speed is in calculating the difficulty of the upcoming semi-random obstacles.

(I’m getting this from the sequence.m file in the source code, by the way.)

In Canabalt the player isn’t following a pre-defined, hand-laid path of obstacles, nor is what shows up purely random. The faster the player is running the higher hallways are that cut through buildings the player must jump up to reach, the wider gaps between buildings are, and the narrower rooftops can be. Put another way, the faster you run in Canabalt, the harder the game becomes.

That makes sense. The rule of thumb for flow is that as a player demonstrates more skill they need to be presented with more challenge in kind.

Some years ago, while discussing this feature of Canabalt’s design at a Super Happy Dev House meetup out in Silicon Valley, a gentleman I was speaking with about this (who I wish I could credit, but now many years later I can’t recall who it was) pointed out that because…

(1.) the game produces more challenging environments as you run faster,

(2.) running into small obstacles like boxes slows you down without any other penalty, and

(3.) your only scoring metric for success is total distance run

…the optimal way to play if trying to achieve a high score is to stumble and tumble over obstacles frequently to keep from building up too much speed. Put another way, if you want to have fun and push yourself to play it “right” by jumping over as many of those obstacles as you can, running faster and faster up to the maximum speed, you’re going to be penalized for doing so and risk earning a lower score than if you manage as slow and steady a pace as you can by bopping into more obstacles deliberately.

We’ve seen the same thing for generations in Super Mario Kart games. The person in first place is given special disadvantages (like being the target of any blue turtle shells) and meanwhile the players further back have special advantages (ex. more often get the ‘best’ power-ups from the semirandom pickups). It makes for an exciting match with lots of order switching. However a player trying to perform optimally may be wise to avoid the very front position until near the end of the final lap.

Jesper Juul wrote in his short book “The Art of Failure” (2013), “A game designer must always ask whether the optimal path for the player is the right one; does the game push the player toward taking the most interesting and enjoyable path, or toward taking an uninteresting path? It is the responsibility of the designer to make sure that the optimal path is the right one… what will happen if users actually follow the optimal path of achieving the performance goal?”

It’s a point that Juul worded quite well here, but unfortunately moves on from rather promptly in his book. I think it’s an important observation that helps us efficiently define and test for whether a game’s mechanics are balanced and well tuned.

Should a player be cycling between many different weapons, or always leaning on the same one? If the former is more interesting and enjoyable – and in most cases variety is likely preferable – then attention must be paid to how the environment, weapons, and enemy combinations ensure that using a variety of attacks is also the optimal way to play.

If what a game rewards through high scores or gold or unlocked powers requires going through an awfully boring, labor-intensive, monotonous routine of rearranging inventory elements every time the player comes across another potential item to carry for sale, then there’s a clear dissonance between the optimal and the enjoyable way to play. The attentive player may then feel locked into playing the game in a less fun way, in case the game’s later challenges have been tuned in such a way as to require the player be at their peak possible level by that point.

To pass a clear judgement on the mechanics in such a case: it’s broken, or at least unfinished, until values are tuned or features are rethought so that the optimal way to play is also the most enjoyable.

Have you checked whether your game projects pass this test?





Permalink: https://www.hobbygamedev.com/adv/game-tuning-and-balance-is-the-optimal-strategy-most-enjoyable/