The difficulty balance

There are a lot of considerations to make when determining how difficult your game should be. If it is too difficult, players will lose interest, and if the game is too easy, it might not appeal to your intended audience. Some games include difficulty options for users to select from. Other games have multiple levels, each with increasing difficulty. There are several questions that we must contend with in order to achieve our desired difficulty balance.

In this section, we will first look at some questions relating to difficulty balance, followed by our implementation plan.

Difficulty balance questions

There are a lot of questions about our game that we need to consider in our game design. A review of the questions in this section will help us gain an appreciation of the issues that even a simple game such as ours must contend with, in order to achieve the desired difficulty balance.

The first set of questions, listed here, relates to the overall implementation of difficulty in our game:

• Should we have different levels of difficulty, selectable by the player?
• What specifically will be different with each difficulty level?
• Should we have multiple game levels, each with an increased amount of difficulty?
• What specifically will be different with each game level?

Consider the following questions regarding the Enemies in our game:

• How many Enemies should be spawned in each Wave?
• At what distance should an Enemy become aware of the Hero?
• How much damage should an Enemy inflict on the Player with each attack?
• How much damage can an Enemy endure before it dies?

The next set of questions listed here refers to our playable character, the Hero:

• How much life should the character have?
• How much damage will the character take from a single enemy attack?
• Should the character be able to outrun Enemies?

We also have the base and bullets to account for in our game. Here are a couple of questions for each of those game assets that we will implement in our game. In the case of the base, the questions are as follows:

• How many attacks should it take for an enemy to destroy a base?
• What is the ideal max number of enemies spawned in a Wave?
• Where should Doors and the Base be located in the game environment?

And now, let's talk about questions in the case of Bullets, as follows:

• At what pace should the player shoot bullets?
• At what pace should the enemy shoot bullets?
• How much damage will the bullets inflict on the Enemies?
• How much damage will the bullets inflict on the Player?

As you can see, there are several questions that we need to answer as part of our design. Some of the questions may seem redundant as they relate to more than one component in the game. Now, let's answer some of those.

Implementation plan

Based on the questions posed in the last section, we must come up with some answers. Here is a list of some of those decisions:

• We will spawn five enemies in the first wave and add two new enemies per consecutive wave.
• We will establish a pretty small vision area for the Enemies, making it easy for the Hero to sneak past them and, perhaps more importantly, outrun them.
• We will configure the Player's bullets to damage enemies so that two bullets are needed to kill them.
• We will configure the Enemies bullets to damage the player so that 10 bullets are needed to kill them.
• The Player will shoot bullets at a frequency of 2 per second.
• The Enemy will shoot 1 per second.

It's important to take into account that this is the first balance pass, and we will surely change this based on the testing we will carry out when the game is implemented. The idea is to consider this first version of the game as a Prototype, which will be tested on a small group of players to validate our ideas and iterate them. The invaluable feedback of the early players of the game could convert it completely. Usually, a Prototype is a quick version of the game, made with the most minimal features possible to quickly test and discard ideas. After a fair amount of iterations and testing sessions on the prototype, we will have solid ground to start the real development of the game (or discard it completely if we can't create a fun game).

In this book, we will skip the Prototype phase and jump directly to the development of the game due to the scope of the book, but consider doing Prototypes before starting any real project. Just remember, a prototype is a quick, cheaply done version of the project with the sole purpose of testing ideas. We will probably discard the prototype project entirely before starting the real development, so don't spend too much time doing it with clean and proper practices. Now, we can say the game design is completed… or can we? Actually, the game design never ends, even after prototyping!. It will keep evolving as the game is developed, but let's keep that for later. Now, let's talk about how we can communicate our great ideas with everyone in our team, using documentation.