Difficulty

Most non-sports games have some sort of difficulty progression, but often it is unstructured, unplanned or ill-defined and this results in difficulty spikes, early frustration (too much challenge), or possibly early game abandonment (players get bored from not enough new challenge). A developer challenge for properly structured difficulty progression is to be far enough into development to completely understand the elements that affect difficulty the most (e.g. weapons, single enemy offensive/defensive behaviors, group behaviors, enemy class strengths, and enemy class quantity and group distribution), and yet still early enough to give your team time to refine the tuning of the content (levels, missions or courses) to fit the desired difficulty progression and especially to verify that progression with external subjects (focus testers, etc.).

An example of a
Curved Difficulty Progression

The best structured games start out extremely easy to allow all players to quickly experience the reward of game progress (by completing the level, winning the race, or defeating the opponent). A game can have a linear progression where each successive level, stage, or mission is designed to take an even step in difficulty and the magnitude of that step stays consistent over time. However, the problem with a linear difficulty progression is that it may frustrate casual gamers too soon (say by level 3 or 4) and since most designers should want to make mass market games these days that is a demographic we cannot afford to alienate (we do want those renters to buy, right?).

A curved difficulty progression can often be the best, since it allows for casual gamers to get a reasonable distance into the game, and hard core players will breeze past the first few levels, but the levels then start to increase progressively in difficulty (each step is greater than the last) to continually test their skill and their ability to adapt to the new mix of challenges. As systems designers, we have to figure out how to plan and structure our game difficulty and at a high level a first step is to estimate how often the player will die (see Fig 7), wreck their vehicle, or fail a challenge. From there all categories that affect the estimated failure rate should be added to the difficulty progression table and the table must be followed for the levels, missions or courses as they are built. Finally, the difficulty progression must be verified and tuned via focus testing.

The Challenge

Often the real development challenge is not in knowing how to structure a great and engaging game progression, but in how to steer a large portion of the development team to achieve it. It is one thing for the lead designer to be able to tune or direct all the difficulty balancing of the gameplay on a game with limited systems, but it is a much more difficult and costly maneuver to attempt to steer multiple level designers, effects artists, world builders, and AI programmers to achieve a wider and more desirable gameplay progression on a more complex game. Ideally, the progression is designed and planned early enough to bring the producer and team leads on board into backing such an approach, but on first generation engines often certain elements remain unknown until deep into production (e.g. how different AI behaviors affect difficulty). So, it is best to both plan the progression in advance as much as possible (early production), and to set a planned checkpoint later on to update the progression structure with formerly unknown elements, and finally to set multiple review and feedback loops in the content to make sure the progression structure is supported, followed and satisfactory to focus testers.

I admit to not having yet personally achieved the perfect gameplay progression execution on the games I have designed systems and mechanics for, and I am not sure I can say for sure if I ever will. But in my 15 years of design experience I have learned to identify the progression patterns in top-quality games, and that experience has led me to consciously plan the progression structure much more thoroughly than I used to, and I have strived to work within my influence and abilities to execute content to that structure as much as possible. Each development experience has led to more process learning on my part and, as an external Creative Manager, I now heavily encourage all the design teams I am working with to structure the gameplay progression early on and to build content that fits that structure from the start.

Realistically, the goal for us game designers should not be to build a Nintendo-worthy gameplay experience (it has taken them 20 years to get there), but to build the most enjoyable experience for the specific game we are working on and ultimately to make our users excited enough to play (and buy) our game. Then all will be right in the [game] world and [hopefully] the peasants will rejoice. M’kay?