# How can I prepare the different difficulty levels for my game?

I've though about creating the game for the easiest difficulty level, and from there scale up and create the other, more difficult difficulty levels, but I'm not sure it's the fastest way to go.

How should I create the different difficulty levels for my game?

There is never just one way to do things in game development.

But the usual unspoken consensus between developer and player is that "medium" represents the way the game is meant to be played. So you usually develop the game to be balanced on medium difficulty.

However, there is a general problem with difficulties: Players don't know how good they are at your game before they played it. So when they pick a difficulty at the beginning they don't yet know what's the ideal difficulty for them. Also, players rarely change the difficulty while they are playing, because it is quite an immersion breaker to be able to change the fairness of the whole world at a whim. That means if the player chooses poorly, they will have a bad time full of frustration or boredom.

A better solution than having preset difficulty levels can be to have an adaptive difficulty ingrained in your game design.

• Make the game harder for good players. No, I don't mean to make them weaker. Players expect to be rewarded for good play, not punished. Give them more or less of a challenge. For example, in a 4X strategy game, make the opponents band together against the player when the player expands too fast and ignore the player when they are weak.
• Make the basic goals relatively easy to achieve, but provide stretch-goals for completionist players which represent a far greater challenge. "So, you can beat the first level. But can you beat it in under 1 minute? Without getting hit? While killing every single enemy? And while collecting every single star in the level?". You can do that in form of achievements or with a medal system. Tell the player about these stretch-goals before they play the level for the first time, so skilled players can try to achieve all this on their first try.
• Provide ways to complete challenges faster and more rewardingly, but which require more skill to pull off. For example, when you have an RPG game, make sure that a player who uses advanced combat tactics can win a battle faster than when they just spam the basic attacks. That means players who have a good grasp of the game mechanics can advance through the story faster because they spend less time level-grinding. With "faster" I mean real-time, not game-time. This is where good UI design plays an important role.
• How important do you consider it to be able to personally complete the stretch-goals and challenges you set? Apr 4 '18 at 14:12
• @Kevin You mean if I as a developer can reach those goals in my own game? Not much. You should do the math to verify that it is at least theoretically possible to achieve those goals according to your game mechanics. But players will get better than you at your own game. The top players in competitive games are very rarely game developers themselves. So adding objectives you might not be able to complete by yourself without cheating isn't necessarily bad. Apr 4 '18 at 14:14
• @Kevin And you should of course listen to your playtesters. They should be able to tell you if your goals seem reasonable to them. There is nothing inherently wrong with creating a goal which can only be achieved by the top 10 speed runners in the world, but remember that if you do that you are catering to only to those 10 people. Apr 4 '18 at 14:49

Basically to define a base difficulty to scale (whether down or up), you must considerate a playable difficulty, one that engages the player on your game, with challenges (peak points) and points on the game where the player can feel relaxed, which are interest curves, basically every good entertainment content follows one.

On the programming side of things, you could play with normalized values, or have an explicit mapping. The example above is with normalized values as if they represented difficulty percentage, but all should be considered from base difficulty values (e.g., spawn quantities, drop rates, damage taken, etc.).

namespace Game
{
//For the sake of example, the values assigned are lineal to each other. It is up to the
//Game Designer to tweak the values.
public enum Difficulty
{
Easy = 1,
Medium = 2,
Hard = 3
}

public class GameController
{
public static float difficultyMultiplier;

public void ChangeDifficulty(Difficulty _difficulty)
{
difficultyMultiplier (1f * (int)(_difficulty)) / ((1f) * (int)(Difficulty.Hard));
// Cases examples:
// Easy = 1/3 = 33.3% hard.
// Easy = 2/3 = 66.6% hard.
// Easy = 3/3 = 100% hard.
}
}

public class Enemy
{
float strength;

public void HitPlayer(Player _player)
{
_player.HP -= (strength * GameController.difficultyMultiplier);
}
}
}


I suggest you to read Jesse Schell's "The Art of Game Design: A book of lenses", which explains in more detail the Game Flows.

In general, as a matter of practicality, you might want to find a difficulty level that suits your and your testers' skills and balance around that to begin with. What name you end up assigning to that difficulty in the end is secondary and may very well change as designs evolve and emergent gameplay becomes more apparent.

However, where to start and whether it's easier to scale up or down also depends on the kind of game and how you implement difficulty levels.

Many shooters and RPGs simply assign modifiers to certain numbers (e.g. health points, damage). This is easy to implement, and easy to change later on, but often affects the volatility/randomness of challenges (e.g. random critical hits insta-killing the player on "hard") as well as their duration. With this method, I'd advise to find a good middle ground first (smooth, interesting gameplay) and go from there, in both directions. Start on "medium".

Another approach would be to keep the numbers the same, but add or remove obstacles and assistance depending on difficulty. For example, levels for a puzzle game might be easier to design around a fairly simple premise, with complications added in harder difficulties. Start on "easy".

A game focused around timing (e.g. racing game) or resource conservation (e.g. "get from A to B without running out of fuel") might be calculated around the worst case (highest difficulty) scenario where a player playing perfectly might just about make it, with additional pickups or more lenient parameters added in easier difficulties. Designing around the maximum possible score is especially useful in "score attack" games. Start on "hard".

• Small caveat: if you have a stable testing team & a long enough testing/development cycle, your testers will likely get really proficient at your game. Be careful about using veteran testers when establishing skill thresholds for new players. With that in mind, there's sound advice here. Mar 19 '18 at 18:38