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 explore the look and feel of a good game. Later, we will learn how to get everything moving through the use of scripting. 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 also use screen mock-ups 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 design work we will be doing throughout this chapter.
Specifically, we will examine the following concepts in this chapter:
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:
So, let's look at each component in more detail.
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:
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.
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:
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:
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:
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.
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:
From this short description, you can tell that there will be several things to keep track of, including the following:
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.
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:
That's our player. Now, let's discuss our enemy character.
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:
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:
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.
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:
There are four basic things illustrated in the preceding mock-up, listed as follows:
With our base-level design finished, let's discuss how the player will enter that world.
When our game is first launched, we will have several starting conditions set. Here is a list of those conditions:
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.
So far, we have established that we will track several components in the game. They are as follows:
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:
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.
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.
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:
As you can see, there are several components to our HUD, as follows:
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.
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.
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:
Consider the following questions regarding the Enemies in our game:
The next set of questions listed here refers to our playable character, the Hero:
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:
And now, let's talk about questions in the case of Bullets, as follows:
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.
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:
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.
Now that we have covered all the main aspects of our game, it is important to prepare them to be shared with others. Throughout this book, you will probably work alone, but in real-life production, you will likely work with others, so sharing your vision is a crucial skill you need to learn in order to create successful games. You will not only be sharing your vision 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 information into comprehensible documents.
This document is basically the Encyclopedia 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 looked at in the Implementation Plan, and you will deep dive into those. 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 you think you don't need a GDD because all the ideas can fit in your head. This might 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 easily be fixed before discovering them when coding the entire game.
Let's start by talking about how a GDD can be structured.
Sadly, there's no standard way of creating a GDD. Every company and team has its own way of doing this, not only in terms of which tool to 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 when starting to create GDDs 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 the list of all characters, while some can be just a list of bullets explaining certain facts about 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 decide how you will actually write that format, and besides using pen and paper, a better idea is to use all those great digital tools out there. Let's look at some of them.
After reviewing existing GDDs, the next step is to pick a proper tool to write your GDD. 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, so maybe text processors won't be enough.
Your GDD will be big… I mean, BIG, even for simple games. 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, which I strongly recommend in cases like this. 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 these recorded for future reference. The Wikipedia page relating to GDDs can be seen in the following screenshot:
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 medium. 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 (for example, Articy Draft).
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.
Imagine you are riding in an elevator, and on the next floor, an important game investor gets in. They push the tenth-floor button, so you have eight floors' worth of time to convince them to throw money into your pocket to help you create a game. I know this is an improbable case, but in real life, when you are in front of an investor at a round table, you won't have lots of 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 would all be rich if such a thing existed), but here are some tips to take into account:
Here are some examples of an elevator pitch:
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 you have gained the attention of an investor, it's time to show them all the gameplay systems and the little details to hype them up further… well, no, not right now. You have just gained their attention; you haven't convinced them yet. 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 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:
Again, there's no ideal high concept. Maybe you will find some other aspects of your game that can be highlighted here and add them 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.
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:
After this, we can start creating our GDD, and remember: you will need to find out what format works best for you.
Game design and GDD creation is a complex topic that could 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.
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 gameplay, 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 one, 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 will be 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 also create your first game project and analyze how it is composed.
18.220.16.184