Why not just start developing our game instead of designing it? This question is spawned from the excitement of developing games, especially with the Unity game engine. All games start with an idea. That idea is translated into a design, and that design is the basis for development and, eventually, the final game.

A game's design is like a blueprint for a house. You would not consider building a house without a blueprint, and it is an equally bad idea to develop a game without designing it first. The reason for this is to save time and frustration. For larger projects, time wasted also means unnecessary funds are expended.

Imagine that you employed a project team of 12 developers, animators, and artists. If you shared your game idea, would they have enough information to go on? Would they create a great game, but not the game you had in mind? All we are doing with our game design is documenting as much as we can in the beginning so that the development process is purposeful. Without question, you will continually modify your game's design during development, so having a strong base from which to start is critical to your success.

Our game design will serve as the foundation for the look of our game, what the player's objectives are, what the gameplay will be, supporting user actions, animations, audio, Artificial Intelligence (AI), and victory conditions. That is a lot to think about and underscores the importance of translating the game idea into the game design.

Throughout the book, we will be covering a range of components. However, in this section, we will cover those that appear in the following list:

• Game idea
• Input controls
• Winning and losing

So, let's look at each component in more detail.

Game idea

The basic concept of our Super Shooter game is that it will be a 3D game featuring a Futuristic Hero Soldier as the player character. The character must fight against Enemy Soldiers, who are intent on destroying our Hero's base and anyone that gets in their way, including our Hero.

Here is an image of what our game will look like:

Figure 1.1 – Our hero shooting bullets at enemies

Now that we have a general idea of what the game is going to be, let's talk about how the player will control the character.

Input controls

It is important to consider how players will interact with our game. Players have an expectation that the industry norms for user controls will be implemented in games, which is why, for our example, the player will control our Hero using the standard set of controls.

Our default set of user input controls, as shown in the following figure, will consist of the keyboard and mouse:

Figure 1.2 – Controls scheme

We will configure and program our game so that user input from the keyboard matches the key and action pairings shown in the following table:

Figure 1.3 – Key mapping

The mouse will also be a significant source of user input. We will implement two components using the mouse, as indicated in the following table:

Figure 1.4 – Mouse mapping

The left mouse button will be our action button to shoot bullets, while the horizontal mouse motion will allow us to rotate our character and face the enemies. As all enemies and the player are going to be moving across a flat surface, it is not necessary to move the camera up and down.

That's how we handle input, but we also need to end the game session at some point! Let's talk about how the player will win and lose.

Winning and losing

Our winning condition will be when all the Enemy waves have been eliminated.

There will be two different ways the player can lose the game:

• The first losing condition is when the base life becomes 0.
• The second losing condition is if the Hero's life becomes 0.

From this short description, you can tell that there will be several things to keep track of, including the following:

• The number of remaining Waves
• The health of the Player's Base
• The health of our Hero

Now that we have defined what is called the game's core loop (start a level, play it, win/lose it, repeat), let's dive deeper into the specific details, starting with our characters.

Our game will feature several objects, but only two game characters. The first game character is our Hero and will be controlled by the player. The second type of game character is the Enemies. They are non-player characters that are controlled by AI. Let's look more closely at both of these characters.

Hero

The player will play our game as the Hero, our game's protagonist. So, what can our Hero player character do? We already know we will be able to move them throughout our game environment using a combination of keyboard and mouse inputs. We also know that the left mouse button—our action button—will cause them to shoot bullets.

Important note

Because the Hero is controlled by a human player, it is referred to as the Player Character.

We will implement the following animations for the Hero:

• Idle: This animation will play when the character is not being moved by the player.
• Run: This animation will play when the character is being moved by the player.
• Shoot: This is an animation that will cause the Hero to shoot a bullet.

That's our player. Now, let's discuss our enemy character.

Enemies

Our game's antagonists will be Enemy Soldiers. We will control how many of them we want in our game and where they are placed. We will also control their behavior through AI. The Enemies will go straight to the base and, once there, they will start damaging it. We will determine how long it takes for our base to be completely destroyed. If during their journey to the base, the enemy encounters the player, they will prioritize shooting at them.

Important note:

Because the Enemy is controlled by AI and not a human player, it is referred to as a Non-Player Character (NPC).

The soldiers will share the following two animations, which the Player Character also uses, but they will be executed in different scenarios:

• Run: This animation will play when the Enemy's AI is moving the enemy toward the base.
• Shoot: This is an animation that will be played when the AI decides to shoot at the Player's Base or the Player's Character.

Careful planning and scripting will be required to create the desired Enemy behaviors; this will include decisions regarding the number and placement of the Enemies, and we will be tackling this during the designing phase and also during the development.

Now that we have defined our characters, let's discuss how the game will be played, looking at the specific details.

The game will start with the player in the center of the game world. The Hero, controlled by the player, will need to defend the Base from the Enemies. To fend off the Enemies, the Hero can shoot bullets. The goal is to defeat all the Enemies before the Base is completely destroyed by them.

Let's look at how we will make all this happen. The following gameplay components are covered in this section:

• Game-world layout
• Starting condition
• Ending condition
• Point system
• Heads-Up Display (HUD)

We will cover each of the preceding components and discuss how they change the game experience. Let's start by talking about how the game world will be designed.

Game-world layout

We will create a base environment that consists of large metallic floor tiles, walls, and doors where the enemies will spawn. The base building will be located at the opposite end of the Enemies' Spawn positions (the Doors in the following figure), where the enemies need to reach to start attacking it.

Here is a mock-up of the shape our game world will take:

Figure 1.5 – Base layout

There are four basic things illustrated in the preceding mock-up, listed as follows:

• Wall: Impenetrable barriers that prevent the player from going outside the play area.
• Door: Impenetrable, like the walls, but will also serve as the Spawn Position of the Enemies. The Enemies will spawn behind them and can penetrate them to enter our Base Area.
• Player Start: This is the Hero's start position.
• Base Building: Our Base. The enemies must be close enough to attack it.

With our base-level design finished, let's discuss how the player will enter that world.

Starting condition

When our game is first launched, we will have several starting conditions set. Here is a list of those conditions:

• The number and placement of Enemies' Spawn Points: As you saw in our earlier mock-up, there will be several possible spawn points in the game (the doors).
• The number of Waves, the number of Enemies in each Wave, and how often the enemies will spawn: We will write a script to spawn waves of enemies, which will be used for each wave.
• Our final starting condition is the base placement: As you can see from the preceding figure, this is placed on the opposite side of the doors—so, the enemy must traverse the whole empty space between them, giving the player a chance to attack them.

We have defined the enemy spawning rules and how the player can play the game. Now, let's talk about how the game will end, looking at the exact implementation of this.

Ending condition

So far, we have established that we will track several components in the game. They are as follows:

• Remaining Waves: A wave is considered finished when all enemies in it die.
• Base Health: Damaged by the enemies.
• Player Health: Also damaged by the enemies.

Based on what we decided earlier regarding the end-of-game condition, we can apply the following mathematical checks to determine whether the game has ended and what the outcome is. Each end-of-game condition is listed in the following table, along with the outcome:

Figure 1.6 – End-of-game conditions

In order to implement these three end-of-game conditions, we know we must track the number of waves, player health, and base health.

Now that we have a full game, let's think about how we can make it more rewarding, by implementing a classic point system.

Point system

Since we are tracking key information that involves numbers, it makes it easy for us to implement a point system. We could, for example, give the player 50 points each time an Enemy is exterminated, and we could also take away points each time an Enemy causes damage to the base. In our case, we will settle with just giving points when Enemies are killed, but you can feel free to expand this area if you want to.

Now, we have several systems that the player needs to be aware of, but right now, the player hasn't got any way to make informed decisions about those systems. So, let's see how we can improve that, using an HUD.

HUD

We have decided to keep track of information during gameplay that has value beyond calculating points at the end of the game. The player will want to see this information as it tends to provide motivation and adds to the fun of the game. So, we will create an HUD for the player, and dynamically update the data in the game.

Important note:

An HUD is a visual layer of information that is always present on the screen.

Here is a mock-up of what our HUD will look like in our Super Shooter game:

Figure 1.7 – UI layout

As you can see, there are several components to our HUD, as follows:

• Hero Health: A classic health bar that allows us to see the amount of life left. We choose a bar instead of a number because it is easier to see in the middle of an intense fight, instead of reading a number.
• Hero Avatar: An image next to the health bar just to show our Hero's face.
• Score: The number of points we have gathered.
• Bullets: The number of bullets remaining. The player must check this number frequently to avoid running out of bullets, as they are limited. Anyway, at the end of the book, you will be more than capable of creating a bullet-drop system if you want to.
• Remaining Waves / Remaining Enemies: Information about the current state of the wave and game, just to let the player know when the game is going to end, putting some pressure on them in the process.
• Base Health: Another important piece of information so the player can see the health of the Base. It's of a sufficient size to let the player notice when the base is being attacked and take action in that case.

Finally, we have a simple, yet fully fledged starter game design with lots of rules and specifications about how it will behave, and we can start creating our game right now. However, there's a good practice that is never too soon to implement: balancing the game's difficulty.