Chapter 1: Designing a Game from Scratch

Welcome to the first chapter of the book! I am sure you are as super excited as I am to start this amazing journey into game development with Unity. We will be approaching game development in four parts. First, we will be talking about the basics of game development, looking at topics such as how to design your game before you start coding, and then we will prototype a simple first level using Unity. Then, we will dive into graphics to find out the look and feel of a good game. Later, we will learn how to get everything moving through the use of scripting; and, finally, we will see how you can finish and publish your game. As you go through the chapters, you will apply every concept to a full game project, so you will end the book with a fully functional shooter game.

In this chapter, we will design our game, Super Shooter. This phase is known as pre-production, where we will create a development plan. Our game design will include all the functionality we want in our game: the player character, the non-player characters, game assets, animations, and more. We will use screen mock-ups, as well as a narrative, to document our game's design. We will look at related concepts regarding the use of Unity for our game along the way. We will be discussing which pieces of documentation are necessary for all the design work we will be doing throughout this chapter.

Specifically, we will examine the following concepts in this chapter:

• Game concept
• Game characters
• Gameplay
• The difficulty balance
• Documentation

Game concept

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 to go on? Would they do great things, but not have a cohesive set of components for your game? 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, and 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. These Enemies are intent on destroying our Hero's base and anyone that gets in their way, including our Hero. He will have a limited number of bullets he must keep track of.

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. The player will control our Hero using the standard set of controls. Players have an expectation that the industry norms for user controls will be implemented in games. So, our default set of user input controls, as shown in the following screenshot, will consist of the keyboard and mouse:

Figure 1.1 – 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.2 – Keys 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.3 – Mouse mapping

The left mouse button will be our action button. We will need to ensure bullets are shot only when the player has one or more bullets remaining.

That's how we handle input, but sometimes we need to end the game session! 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.

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

• Number of remaining Waves
• Number of our Base Life
• Number of our Hero Life

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

Game 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. This is a character that we will import for use in our game. 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 him 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 antagonist will be the 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.

Information Box:

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

We will implement the following animations for the Enemy soldiers:

• Run: The Enemies will be able to run toward the Hero when they see him and will stop when they are near enough to the player to start attacking him.
• Attacking: This animation will play when the Enemy is near enough to attack the base or the player.
• Death: This animation will play when the Enemy is defeated by the player.

We will require careful planning and scripting to create the desired Enemy behaviors. The number and placement of the Enemies are decisions we will need to make.

That defines our characters' details. Now, let's discuss how the game will be played, looking at the specific details.

Gameplay

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 will have a starting number of 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 our base environment, which consists of large metallic floor tiles, walls, doors where the enemies will be spawning, and our base building at the bottom part of the screen, 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.4 – 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 as 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: Start Hero 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 in a gentle way.

Starting condition

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

• Number and placement of Enemies' Spawn Points (doors)
• Number of bullets held by the Hero
• Placement of the Base

Let's look at each of these starting conditions:

• The first starting condition is where to spawn Enemies. As you saw in our earlier mock-up, there will be several possible spawn points in the game (the doors). We will write a script to spawn waves of the enemies in random spots each time. Each wave will increase the number of enemies to increase the difficulty.
• The number of bullets held by the player must be carefully thought through. It needs to be big enough to defeat an enemy before they run out.
• Our third and final starting condition is the base placement. As you can see from the preceding screenshot, 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. Let's remember them—they are as follows:

• Remaining Waves
• Base Health
• Player Health

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.5 – End-of-game conditions

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

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 or we could also take away points each time an Enemy damages 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 any way to make informed decisions about those. 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 and 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.

Information Box:

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.6 – 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 visually 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.
• Remaining Waves/Enemies: Info 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. It's of sufficient size to let the player notice when the base is being attacked, and take action in that case.

Finally, we have a fully fledged game 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 it's never too soon to implement: balancing the game.

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 levels for users to select from. Other games have multiple levels, each with an increasing level of 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 on 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 run out of bullets?
• What will be the maximum number of Bullets the Player can have?
• How much damage will the bullets inflict on the Enemies?

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. So, let's do that here. Our first set of decisions focuses on the overall game concept, as follows:

• Implement one game level.
• Provide the user with three game difficulty settings: easy, normal, and hard.

Now that we've decided to create three game levels, we must determine how they will be different. This is easily managed by using a matrix. As we fill in the matrix, we will be able to document answers to most of the previously listed questions. Here is what we will refer to as the Difficulty Implementation Matrix:

Figure 1.7 – Difficulty pass per level

There will also be a set of decisions that will not change based on the user-selected difficulty level. Here is a list of those decisions:

• The aggressiveness of the Enemies will not change. We will script them so that if they are aware of the Hero, they will attack him.
• 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.
• Respawning will be randomized between the spawn points previously identified in the game's mock-up.

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.

Now, we can say the game design is completed or can we? Actually, the game design never ends; 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.

Documentation

Now that we have covered all the main aspects of our game, it is important to prepare them to be shared with others. Through this book you will probably work alone, but in real-life productions you will likely work with others, so sharing your vision is a crucial skill you need to earn in order to create successful games. You will not be sharing your vision only with your teammates, but also with potential investors that want to put money into your game project (if you convince them to do so). In this section, we will give recommendations about how to properly format your game info into comprehensible documents.

Game Design Document (GDD)

This document is basically the Bible of your game. It contains a breakdown of all the aspects of it, each one with detailed explanations about how the different game systems should work. Here, you will put the questions and answers we previously answered in the Implementation Plan, and you will deep dive into them. Remember that you have an idea in your head, and making sure that others grasp that idea is complicated, so don't underestimate this important task.

Maybe you are making a game all by yourself and are saying you don't need a GDD because all the ideas can fit in your head, and that can be true for very small games, but any size of game and team can benefit from a GDD. It will serve as your notebook to put down your own ideas and read them. This is important because in your head everything makes sense, but once you read your own ideas and review them, you will find lots of blind spots that can be easily fixed instead of discovering them when coding the entire game.

Let's start talking about how a GDD can be structured.

GDD formats

Sadly, there's no standard or unique way of creating a GDD. Every company and team has its own way of doing this, not only in terms of which tool they use to create it but also the content of the document. This varies a lot according to the size of the team (or teams), the type of game, and the general culture of the company behind the game. As a matter of fact, some companies actually believe that there's no need to create a GDD.

A good idea to start creating them is to check out existing published GDDs of several games. There are lots of them out there, including big, well-known games (such as DOOM). Most of them are, generally, Word documents with sections explaining the game systems (such as weapons, inventory, and so on) and a list of all characters, while some can be just a list of bulletpoints explaining certain facts of the different pieces of the game. After that, you can start experimenting with different GDD formats that fit well with your project and your team.

Once you have decided on a good format, you must actually decide how you will write that format, and besides using pen and paper, a better idea is to use all those great digital tools out there. Let's see some of them.

GDD creation tools

After reviewing the existing GDDs, the next step is to pick a proper tool to write it. The first matter you need to take into account is that the GDD will change a lot very often all the time. In the process of creating the game, you will validate or discard ideas you wrote in the GDD, so using a dynamic tool is a good idea. This can be accomplished with any text processor you are familiar with, but there are other problems you need to tackle, and maybe text processors won't be enough.

Your GDD will be big I mean, BIG, even for simple games, so it will have lots of sections, and you will find cases where whole sections will refer to other sections, generating a big net of links between several parts of the document. A good tool for managing this instead of a text processor is using any kind of wiki, those being extremely useful tools that I strongly recommend using in these cases. They allow you to break down the whole GDD into articles that can be easily edited and linked to others, and, also, lots of wikis allow you to edit articles collaboratively. There are other additional features, such as comments that allow a whole conversation about a feature inside the GDD, with this recorded for future reference. The Wikipedia page relating to GDDs can be seen in the following screenshot:

Figure 1.8 – Wikipedia site

Moreover, you can also use other tools, such as Google Drive, which allows you to mix different types of documents—from regular text documents to dynamic slides—to create presentations, communicating complex aspects in a simple yet powerful media. Also, Google Drive has lots of great collaborative tools that improve the way several people work on the GDD.

All the tools we described are generic solutions to writing documents in general, and they can work like a charm, but there are other tools specifically crafted for games.

Now, let's start writing our GDD. I know I said there's no standard format, but let's at least see what every GDD should have, starting with the elevator pitch.

Elevator pitch

Imagine you are in a building taking an elevator, and on the next floor, an important game investor just gets in. They push the tenth-floor button, so you have eight floors of time to convince them to throw money into your pocket to help you create the game. I know this is an improbable case, but in real life, when you are in front of an investor in a round table, you won't have too much time to convince them. Remember that behind you there's a queue of maybe thousands of developers wanting to do the same, so you must be quick and visceral, and that's why having a good elevator pitch is so important.

An elevator pitch is probably the first sentence you will find in your GDD, and the most important one. It needs to describe your game in no more than two lines and convince the person reading the GDD that your game is a great idea—you need to make them want to play your game right now. Yes—it sounds super ambitious, and it is, but this can separate you from the whole crowd of developers wanting to get some funding for their game.

Again, there's no standard formula to create a successful elevator pitch (we all would be rich if such a thing existed), but here are some tips to take into account:

• You must make your pitch in no more than 10 seconds. Any longer, and you will lose the interest of the person you are trying to convince.
• You must sound convincing about your own idea; nobody is going to invest in a game you are not sure is the next big release.
• Don't use any technical words (I'm looking at you, programmers).
• Include what differentiates your game from all the other games out there.
• Iterate it until you can convince any person close to you to play the game, trying to test it with the most honest person you can find—a person that won't be bothered about shattering your idea into pieces (if your idea really deserves that).
• Practice it, over and over again, in front of a mirror, until you can say it nicely, clearly, and in one shot.

Here are some examples of an elevator pitch:

• Imagine yourself slaughtering giant Greek gods with just your arms and your strength until you become the king of Olympus. You will feel that power in [INSERT NAME OF TOTALLY NOT EXISTING GAME HERE].
• Civilization has fallen. A horrendous infection turns people into zombies. You have the only cure, and must traverse the whole country to deliver it, or humankind will collapse.

Okay—nowadays, those pitches are not super original, but a few years ago they were. Imagine the power that those pitches had at that time; you must find something similar. I'm not saying it's easy, but look how just two lines can be the start of amazing experiences, so focus first on writing those two lines, and then the rest of the game.

Now that you have gained the attention of an investor, it's time to show all the gameplay systems and the little details to them to hype them up further well, no—not right now. You just gained their attention; you haven't already convinced them. It's time to start talking a little bit about your game, and a high concept is a good way of doing so.

A high concept

A high concept is a series of statements that further describe your game, but, again, in a simple and concise way. Even if you are not trying to convince an investor, those statements will outline the way your game will be defined.

A good high concept can include sections such as the following ones:

• Elevator pitch: As we explained in the previous section.
• Genre: Maybe you are creating something new that has never been seen before, but it will probably be inspired by several other games. Here, you will specify the type of games on which you are basing your idea, so the reader of this document can start imagining how the game will be played. Later, you will specify the differences, but it is better to put a well-known idea forward first to start constructing the concept in the mind of the reader. Also, you can specify here the point of view the player will have in the game and the setting—for example, Top-Down Medieval Roguelike role-playing game (RPG).
• Platform and demographics: You need to be very clear about who will play your game. It is not the same creating a game for adults in North America as creating a game for Chinese teenagers, or games for business people who want to spend a few minutes distracted on their way home, on the bus. Those profiles will want different experiences, with different levels of challenge and game session length. They will even use different devices to play games. Taking this into account will help you find the game mechanics and balance that best fit your target audience. It's very common to say that you are creating a game for yourself, but remember that you won't be buying that game, so also think about your wallet when creating the game—for example: Casual Players of Mobile Platforms.
• Features: Create a shortlist of no more than three or five features that your game will have. Put the features you will be using from the genre you choose—for example: you will shoot waves of enemies with a giant array of weapons. You will level up your ship to improve its stats.
• Unique Selling Points (USPs): This is similar to the features list, but here, you will include the features that differentiate your game from the others out there (no more than three or five)—for example: you can traverse the scene using parkour-style moves. You can craft brand new weapons using looted materials. Think about how unique those features were years ago.

Again, there's no ideal high concept. Maybe you will find some other aspects of your game that can be highlighted here and added to the document, but try to keep this all on just one page.

Now that we have discussed what every GDD should have, let's talk about what a GDD may have.

Tips for creating GDDs

Now, it's time to define what the whole game is. We said there's no standard format for GDDs, but at least we can take into account several good practices when creating them. The following list highlights a few of them:

• Readability: Your GDD must be prepared to be read by anyone, including people without game development knowledge. Don't use any technical words (guess who I'm still looking at), and try to keep things simple. A good test of your GDD readability is to give it to your granny or anyone that you see as being as far from gaming as possible, and that person must be able to read it.
• Setting and introduction: Before you start describing the game mechanics, put the reader inside the game. Describe the world, the player character, their backstory, their motivations, and what the main problem is that the player needs to struggle with. Make the reader of the GDD interested in the setting of the game and want to keep reading, to see how they will be able to play the game and tackle all the quests the player will face in the game.
• Gameplay sections: These are sections that break the game into several systems and subsystems linked to each other. Some examples can be Inventory, Quests, Crafting, Battle, Movement, Shops, and so on. You will want to be super specific about every aspect of how those systems work because—remember—this document will be used by the team to craft the code and assets of your game. All the previous analysis we did in the previous sections of this chapter will be here and will be further explained and analyzed.
• Content sections: You will want to also create content sections, such as the ones we previously designed. These can be—but are not limited to—Characters, Story, World, Levels, Aesthetics, Art Assets, Sound and Music Assets, Economics, and Input.
• Share your idea: Before immortalizing your ideas on the GDD and making everyone start crafting them, discuss the different GDD sections before marking them as finished. Discuss with your team, people on the internet, friends—everyone can give you valuable feedback about your idea. I'm pretty sure you are thinking that your idea will be stolen by some random person on the internet who will release the same game before you—and that can happen—but I'm not saying share the whole GDD, just some details about certain implementations you are not sure about.
• Keep control: Everyone in the team is a game designer—some more than others. Everyone will have ideas and things they will do differently. Listen to them—doing so will be useful, but remember you are in charge and you will have the final say. You need to be open, but set some limits and don't deviate from your original idea and concept. Prevent the famous feature creep: know when enough is enough. Again, not an easy task—you will learn this the hard way, believe me, but remember this when that happens: I told you!
• The game will change: I already said that, but I like to stress this as far as I can. The game will change a lot due to many reasons you will find in the process of creating it. You may find that X mechanic is not that fun, you created a better way of handling Y system, you think it's worth the time to change already existing parts of your game after a test showing that the players don't understand how to use a brand new key feature in your game, and so on. Be open to change and pivot your game idea. If you do this the right way, your game won't be as you originally imagined, but will be a better version of it.
• Graphics: Use graphics, diagrams, charts, and so on. Try to prevent huge text walls. Remember that an image is worth a thousand words. You are communicating, and nobody wants to spend valuable minutes trying to understand what you want to say. Improve your visual communication skills, and you will have a focused team.
• Paper prototypes: You can test some ideas in your head on paper before putting them in the GDD. Even if your game is a frenetic "beat 'em up," you can have little paper characters moving around a table, seeing how they can attack the player, and which movement pattern they will have. Do some math to look at the perfect timing, damage and health values, and so on.
• Regular prototypes: While your game is being developed the GDD will constantly change based on players' feedback. You must test your game, even if it's not finished, and get feedback from players as early as you can. Of course, they will tell you lots of things that you already know, but they will see lots of problems you don't see because you are creating and playing your game every day. They have the advantage of playing the game for the first time, and that is a real change.

Game design and GDD creation is a complex topic that can be explored in several chapters, but there are lots of books out there that do exactly that, and game design is not the main topic of this book.

After this, we can start creating our GDD, and remember: you will need to find out what the format that works best for you is.

Summary

In this chapter, we fully designed our Super Shooter game, and we plan to use our design to drive our development efforts. Our game design includes functionality, the player character, the non-player characters, game assets, animations, and more. We used screen mock-ups to help document our game's design. In addition, we planned our game's difficulty balance to help ensure the game is appropriately difficult based on user selection. We talked about what a GDD is, how we can create it, and how it and the game design will change during game production.

Remember that this is important because you want to answer all the questions you can before coding your game. If you don't do this, you will pay for it by having to recode parts of your game over and over for each unforeseen problem. You cannot prevent all possible complications, but at least a good amount was sorted out with this analysis.

In the next chapter, you will learn how to start using Unity. You will gain knowledge of why Unity is a great option to start creating games. You will be creating your first game project, and analyzing how it is composed.