Hands-On Unity 2021 Game Development E-Book

Nicolas Alejandro Borromeo

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 767

Veröffentlichungsjahr: 2021

Beschreibung

Learning how to use Unity is the quickest way to creating a full game, but that’s not all you can do with this simple, yet comprehensive suite of video game development tools – Unity is just as useful for creating AR/VR experiences, complex simulations, real-time realistic rendering, films, and practical games for training and education.

Hands-On Unity 2021 Game Development outlines a practical journey to creating your first full game from the ground up, building it step-by-step and applying your knowledge as you progress.

Complete with hands-on tutorials and projects, this easy-to-follow guide will teach you how to develop the game using several Unity tools. As you advance, you will learn how to use the Unity engine, create simple scripts using C#, integrate graphics, sound, and animations, and manipulate physics to create interesting mechanics for your game. You’ll be able to apply all the knowledge that you gain to a real-world game.

Later chapters will show you how to code a simple AI agent to challenge the user and use profiling tools to ensure that the code runs efficiently. Finally, you'll work with Unity's AR tools to create AR experiences for 3D apps and games.

By the end of this Unity book, you will have created a complete game and built a solid foundation in using a wide variety of Unity tools.

Leseprobe

Hands-On Unity 2021 Game Development

Second Edition

Create, customize, and optimize your own professional games from scratch with Unity 2021

Nicolas Alejandro Borromeo

BIRMINGHAM—MUMBAI

Hands-On Unity 2021 Game Development Second Edition

Copyright © 2021 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Associate Group Product Manager: Rohit Rajkumar

Associate Publishing Product Manager: Ashitosh Gupta

Senior Editor: Hayden Edwards

Content Development Editor: Aamir Ahmed

Technical Editor: Saurabh Kadave

Copy Editor: Safis Editing

Project Coordinator: Ajesh Devavaram

Proofreader: Safis Editing

Indexer: Pratik Shirodkar

Production Designer: Shankar Kalbhor

First published: July 2020

Second edition: August 2021

Production reference: 1190821

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80107-148-2

www.packt.com

To Dad, who spoiled me with computers to keep learning. I miss you. Also, to my wife, for reminding me of what I am capable of.

– Nicolas Alejandro Borromeo

Contributors

About the author

Nicolas Alejandro Borromeo works as a senior Unity developer at Product Madness, London. He was a game development career coordinator at Universidad Argentina de la Empresa (UADE) and has taught game development at many other Argentine universities, such as UTN, UAI, and USAL, and institutions such as Image Campus and DaVinci, since 2012. Nicolas has been a Unity Certified Instructor since 2019, teaching high-profile Unity clients all around the globe. He was an MMO client-side developer at Band of Coders in Argentina and has been a Unity freelance developer since 2012.

About the reviewers

Levent Alpsal is a senior software and game developer. In 2008, he started working on web-based projects, developing for the backend using PHP and SQL.

He started his focus on Unity and C# in 2015, working on many exciting simulation projects using Unity, VR, motion platforms, and other technologies at Sanlab Simulation. He has also developed many indie games and attended global game jams.

In 2020, he started his own company in the UK, Reenim Software LTD, providing software and Unity development services globally.

Levent likes to develop creative DIY solutions to daily real-life problems using 3D printing, thermoplastics, and K'Nex. He is the proud designer of a remote-controlled model tank. Currently, he lives in London with his lovely wife and wonderful son.

Sungkuk Park is a Berlin-based game developer. He majored in art studies at Hongik University in Seoul, Korea, but later became a software engineer in the gaming industry. He is interested in almost everything about gaming. He is now on his way to becoming a technical artist!

Here is a list of his publications:

Authored Seamless Society, 21 July 2020, in collaboration with an online exhibition platform DDDDAuthored Wallpeckers: Breaking down the barriers between media, an article for the Korean art magazine Misulsegye, in March 2019Authored The Possibility of the Impossibility of the "Art Games", an article for the Korean art magazine Misulsegye, in February 2017Translated and edited Game Level Generation Using Neural Networks, a featured post of Gamasutra

Table of Contents

Preface

Section 1 – Our First Level

Chapter 1: Designing a Game from Scratch

Game concept

Game idea

Input controls

Winning and losing

Game characters

Hero

Enemies

Gameplay

Game-world layout

Starting condition

Ending condition

Point system

HUD

The difficulty balance

Difficulty balance questions

Implementation plan

Documentation

Game Design Document (GDD)

GDD formats

GDD creation tools

Elevator pitch

High concept

Tips for creating GDDs

Summary

Chapter 2: Setting Up Unity

Why use a game engine such as Unity?

Past and present industry insight

Game engines

Benefits of using Unity

Installing Unity

Unity Technical Requirements

Unity installs

Installing Unity with Unity Hub

Creating projects

Creating a project

Project structure

Summary

Chapter 3: Working with Scenes and Game Objects

Manipulating scenes

The purpose of a scene

The Scene View

Creating our first GameObject

Navigating the Scene View

Manipulating GameObjects

GameObjects and components

Understanding components

Manipulating components

Object hierarchies

Parenting objects

Possible uses

Prefabs

Creating Prefabs

Prefab-instance relationship

Prefab variants

Saving scenes and projects

Saving our changes

Project structure

Summary

Chapter 4: Grayboxing with Terrain and ProBuilder

Creating a Landscape with Terrain

Discussing Height Maps

Creating and configuring Height Maps

Authoring Height Maps

Adding Height Map details

Creating Shapes with ProBuilder

Installing ProBuilder

Creating a Shape

Manipulating the mesh

Adding details

Summary

Chapter 5: Importing and Integrating Assets

Importing assets

Importing assets from the internet

Importing assets from the Asset Store

Integrating assets

Integrating terrain textures

Integrating meshes

Integrating textures

Configuring assets

Configuring meshes

Configuring textures

Assembling the scene

Summary

Section 2 – Improving Graphics and Sound

Chapter 6: Materials and Effects with URP and Shader Graph

Introducing shaders

Shader pipeline

The Render Pipeline and URP

URP's Built-in Shaders

Creating Shaders with Shader Graph

Creating our first Shader Graph

Using textures

Combining Textures

Applying transparency

Creating Vertex Effects

Summary

Chapter 7: Visual Effects with Particle Systems and Visual Effect Graph

Introduction to particle systems

Creating a basic particle system

Using advanced modules

Creating fluid simulations

Creating a waterfall effect

Creating a bonfire effect

Creating complex simulations with Visual Effect Graph

Installing Visual Effect Graph

Creating and analyzing a Visual Effect Graph

Creating a rain effect

Summary

Chapter 8: Lighting Using the Universal Render Pipeline

Applying lighting

Discussing lighting methods

Configuring ambient lighting with skyboxes

Configuring lighting in URP

Applying shadows

Understanding shadow calculations

Configuring performant shadows

Optimizing lighting

Understanding static lighting

Baking lightmaps

Applying static lighting to static objects

Summary

Chapter 9: Fullscreen Effects with Postprocessing

Using PostProcessing

Setting up a profile

Using basic effects

Using advanced effects

Advanced effects

Summary

Chapter 10: Sound and Music Integration

Importing audio

Audio types

Configuring the import settings

Integrating and mixing audio

Using 2D and 3D AudioSources

Using an Audio Mixer

Summary

Chapter 11: User Interface Design

Understanding Canvas and RectTransform

Creating a UI with Canvas

Positioning elements with RectTransform

Canvas object types

Integrating assets for the UI

Creating UI controls

Creating a responsive UI

Adapting object positions

Adapting object sizes

Summary

Chapter 12: Creating a UI with the UI Toolkit

Why learn UI Toolkit?

Creating UIs with UI Toolkit

Installing UI Toolkit

Creating UI Documents

Editing UI Documents

Creating UI Stylesheets

Making a Responsive UI with UI Toolkit

Dynamic positioning and sizing

Dynamic Scaling

Using relative positions

Summary

Chapter 13: Creating Animations with Animator, Cinemachine, and Timeline

Using Skinning Animations with Animator

Understanding skinning

Importing skeletal animations

Integration using Animation Controllers

Creating dynamic cameras with Cinemachine

Creating camera behaviors

Creating dolly tracks

Creating cutscenes with Timeline

Creating animation clips

Sequencing our intro cutscene

Summary

Section 3 – Scripting Level Interactivity with C#

Chapter 14: Introduction to C# and Visual Scripting

Creating Scripts

Initial setup

Creating a C# Script

Adding fields

Creating a Visual Script

Using events and instructions

Events and instructions in C#

Events and instructions in Visual Scripting

Using fields in instructions

Common beginner C# script errors

Summary

Chapter 15: Implementing Movement and Spawning

Implementing movement

Moving objects through Transform

Using Input

Understanding Delta Time

Implementing spawning

Spawning Objects

Timing actions

Destroying Objects

Summary

Chapter 16: Physics Collisions and Health System

Configuring Physics

Setting shapes

Physics Object types

Filtering collisions

Detecting collisions

Detecting Trigger events

Modifying the other Object

Moving with Physics

Applying forces

Tweaking Physics

Summary

Chapter 17: Win and Lose Condition

Creating Object Managers

Sharing Variables with the Singleton design pattern

Sharing Variables with Visual Scripting

Creating Managers

Creating Game Modes

Improving our code with events

Summary

Chapter 18: Scripting the UI, Sounds, and Graphics

Scripting the UI

Showing information in the UI

Programming the Pause menu

Scripting feedback

Scripting visual feedback

Scripting audio feedback

Scripting animations

Summary

Chapter 19: Implementing Game AI for Building Enemies

Gathering information with sensors

Creating Three-Filters sensors with C#

Creating Three-Filters sensors with Visual Scripting

Debugging with Gizmos

Making decisions with FSMs

Creating the FSM in C#

Creating transitions

Creating the FSM in Visual Scripting

Executing FSM actions

Calculating our scene's Pathfinding

Using pathfinding

Adding the final details

Summary

Chapter 20: Scene Performance Optimization

Optimizing graphics

Introduction to graphic engines

Using the Frame Debugger

Using batching

Other optimizations

Optimizing processing

Detecting CPU- and GPU-bound

Using the CPU Usage Profiler

General CPU optimization techniques

Optimizing memory

Memory allocation and the garbage collector

Using the Memory Profiler

Summary

Section 4 – Releasing Your Game

Chapter 21: Building the Project

Building a project

Debugging the Build

Debugging Code

Profiling performance

Summary

Chapter 22: Finishing Touches

Iterating your game

Testing and feedback

Interpreting feedback

Releasing your game

Pre-release

Release

Post-release

Summary

Chapter 23: Augmented Reality in Unity

Using AR Foundation

Creating an AR Foundation project

Using tracking features

Building for mobile devices

Building for Android

Building for iOS

Creating a simple AR game

Spawning the Player and Enemies

Coding the Player and Enemy behavior

Summary

Other Books You May Enjoy

Preface

I still remember that moment of my life when I was afraid of telling my parents that I was going to study Game Development. At that time, in my region, that was considered a childish desire by most parents, and a career with no future, but I was stubborn enough not to care and to follow my dream. Today, Game Development is one of the biggest industries, generating more revenue than Film.

Of course, following my dream was more difficult than I thought. Anyone with the same dream as me sooner or later faces the fact that developing games is a difficult task that requires a deep level of knowledge in different areas. Sadly, most people give up due to this difficulty level, but I strongly believe that with the proper guidance and tools, you can make your career path easier. In my case, what helped me to flatten the learning curve was learning to use Unity.

Welcome to this book about Unity 2021. Here, you will learn how to use the most recent Unity features to create your first videogame in the simplest way possible nowadays. Unity is a tool that provides you with powerful but simple-to-use features to solve the most common problems in Game Development, such as Rendering, Animation, Physics, Sound, and Effects. We will be using all these features to create a simple but complete game, learning all the nuances needed to handle Unity.

If you have read the 2020 edition of this book, you will find that not only have the contents been updated to the latest Unity and Packages versions, but also new content has been introduced in 2021, such as coverage of UI Toolkit and Visual Scripting.

By the end of this book, you will be able to use Unity in a way that will allow you to start studying in depth the areas of Game Development that you are interested in to build your career or simply create hobby games just for the joy of doing it. Unity is a versatile tool that can be used in both Professional and Amateur projects, and is being used every day by more and more people. It is worth mentioning that Unity can be used not only for creating games but for any kind of interactive apps, from simple mobile apps to complex training or educative applications (known as Serious Gaming), using the latest technologies such as Augmented or Virtual Reality. So, even if we are creating a game here, you are starting a learning path that can end in lots of possible specializations.

Who this book is for

People with different backgrounds can take advantage of the whole book or parts of it thanks to the way it is structured. If you have basic OOP programming knowledge but have never created a game before, or have never created one in Unity, you will find the book a nice introduction to Game Development and Unity basic to advanced concepts. You can also find most parts of this book useful even if you are a seasoned Unity Developer who wants to learn how to use its latest features.

On the other side, if you don't have any programming knowledge, you can also take advantage of the book, as most of the chapters don't require programming experience to learn from them. Those chapters will give you a robust skillset to start learning coding in Unity, making the process easier than before reading them, and once you learn the basics of coding, you can take advantage of the scripting chapters of this book. Also, with the introduction of Visual Scripting, you will have an alternative language if you are more comfortable with node-based scripting.

What this book covers

Chapter 1, Designing a Game from Scratch, discusses the details of the game we are going to create in the book before even opening Unity for the first time, outlining the Unity features to use.

Chapter 2, Setting Up Unity, teaches you how to install and set up Unity on your computer, and also how to create your first project.

Chapter 3, Working with Scenes and Game Objects, teaches you the concepts of Scenes and GameObjects, the Unity way to describe what your game world is composed of.

Chapter 4, Grayboxing with Terrain and ProBuilder, is where we will be creating our first level layout, prototyping it with the Terrain and ProBuilder Unity features.

Chapter 5, Importing and Integrating Assets, teaches you how to improve your scene art by importing graphics into Unity, as Unity is not a tool for creating graphics but for displaying them.

Chapter 6, Materials and Effects with URP and Shader Graph, shows how to use one of the latest Unity Render Systems (Universal Render Pipeline) and how to create effects with the Shader Graph feature.

Chapter 7, Visual Effects with Particle Systems and Visual Effect Graph, teaches you how to create visual effects such as water and fire using the two main Unity tools for doing so, Particle Systems and VFX Graph.

Chapter 8, Lighting Using the Univeral Render Pipeline, looks at lighting, which is a concept big enough to have its own chapter. Here, we will deepen our knowledge of the Universal Render Pipeline, specifically its lighting capabilities.

Chapter 9, Fullscreen Effects with Postprocessing, teaches you how to add a layer of effects on top of your scene graphics using the Postprocessing feature of the Universal Render Pipeline to get that film effect most modern games have today.

Chapter 10, Sound and Music Integration, covers a topic that is underestimated by most beginner developers; here we will learn how to properly add sound and music to our game, taking into consideration its impact on performance.

Chapter 11, User Interface Design, looks at the User Interface (UI). Of all the graphical ways to communicate information to the user, the UI is the most direct one. We will learn how to display information in the form of text, images, and life bars using the Unity UI system.

Chapter 12, Creating a UI with the UI Toolkit, looks at UI Tookit, which, since Unity 2021, is a soon-to-be successor of Canvas, the UI system we learned about in Chapter 11, User Interface Design. We will explore it to get ahead and be prepared for Unity's use of this HTML-based toolkit in the future.

Chapter 13, Creating Animations with Animator, Cinemachine, and Timeline, takes us further than the static scene we have created so far. In this chapter, we will start moving our characters and creating cutscenes with the latest Unity features to do so.

Chapter 14, Introduction to C# and Visual Scripting, is the first programming chapter of the book. We will learn how to create our first script using C# in the Unity way, and then we will explore how to do the same with Visual Scripting, the new node-based coding language of Unity. The rest of the programming chapters will show how to code the game in both languages.

Chapter 15, Implementing Movement and Spawning, teaches you how to program the movement of your objects and how to spawn them. General programming knowledge is assumed from now on.

Chapter 16, Physics Collisions and Health System, teaches you how to configure the Physics settings of objects to detect when two of them collide and react to the collision, creating a Health System, in this case.

Chapter 17, Win and Lose Condition, covers how to detect when the game should end, both when the player wins and loses.

Chapter 18, Scripting the UI, Sounds, and Graphics, covers how to make the UI show the current information of the game, such as the Player's Health and Score. Also, sounds will be played when necessary, and visual effects will reflect the actions of the Player.

Chapter 19, Implementing Game AI for Building Enemies, covers creating a basic AI using several Unity features for creating challenging enemies in our game.

Chapter 20, Scene Performance Optimization, discusses how making our game perform well is no easy task, but is certainly needed to release it. Here, we will be learning how to profile our game's performance and tackle the most common performance issues.

Chapter 21, Building the Project, teaches you how to convert your Unity project into an executable format to distribute it to other people and run it without Unity installed.

Chapter 22, Finishing Touches, briefly discusses how to move forward with the development of our game after finishing this book, discussing topics such as how to iterate and release the game.

Chapter 23, Augmented Reality in Unity, teaches you how to create an AR application with Unity's AR Foundation package, one of the most recent ways to create AR applications with Unity.

To get the most out of this book

You will be developing a full project through the chapters of this book, and while you can just read the chapters, I highly recommend you practice all the steps in this project as you advance through the book, to get the experience needed to properly learn the concepts demonstrated here. The chapters are designed so you can customize the game and not create the exact game shown in the book. However, consider not deviating too much from the main idea.

The project files are split into a folder per chapter and are designed in a cumulative way, each folder having just the new files introduced by the chapter or the changed ones. This means, for example, that if a file hasn't change since Chapter 1, you won't find it in Chapter 2 onward; those chapters will just use the file introduced in Chapter 1. This allows you to see just what we changed in each chapter, easily identifying the needed changes, and if for some reason you can't finish, for example, Chapter 3, you can just continue with Chapter 4's steps on top of Chapter 3. Also note that Chapters 15 to 19 will have two versions of the files, the C# ones and the Visual Scripting ones.

While we will see how to use XCode 12, is not required for most of the chapters. Also, there are alternatives to Visual Studio in Linux, like Visual Studio Code.

If you are using the digital version of this book, we advise you to type the code yourself or access the code via the GitHub repository (link available in the next section). Doing so will help you avoid any potential errors related to the copying and pasting of code.

Download the example code files

You can download the example code files for this book from GitHub at https://github.com/PacktPublishing/-Hands-On-Unity-2021-Game-Development-Second-Edition. If there's an update to the code, it will be updated in the GitHub repository.

We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!

Download the color images

We also provide a PDF file that has color images of the screenshots and diagrams used in this book. You can download it here: https://static.packt-cdn.com/downloads/9781801071482_ColorImages.pdf.

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: "Set its shader to Universal Render Pipeline/Particles/Unlit."

Bold: Indicates a new term, an important word, or words that you see onscreen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: "Create a new empty GameObject (GameObject | Create Empty)."

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you've read Hands-On Unity 2021 Game Development Second Edition, we'd love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we're delivering excellent quality content.

Section 1 – Our First Level

In this section, you will learn about the fundamental concepts of Unity, such as scene creation and asset management, to create your first playable prototype game level.

This section comprises the following chapters:

Chapter 1, Designing a Game from ScratchChapter 2, Setting Up UnityChapter 3, Working with Scenes and Game ObjectsChapter 4, Grayboxing with Terrain and ProBuilderChapter 5, Importing and Integrating Assets

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 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:

Game concept Game characters Gameplay The difficulty balanceDocumentation

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 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 WavesThe health of the Player's BaseThe 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.

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. 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.

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 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 conditionPoint 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.

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.

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.

Game Design Document (GDD)

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.

GDD formats

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.

GDD creation tools

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:

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 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.

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:

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 like you believe in 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.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 your pitch 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 NON-EXISTENT 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 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.

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, a Top-Down, Medieval Roguelike Role-Playing Game (RPG).Platform and Demographics: You need to be very clear about who will play your game. Creating a game for adults in North America is not the same as creating a game for Chinese teenagers, or games for business people who want to distract themselves for a few minutes on their way back home from work. 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 fits 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. Select features according to the genre you have chosen—for example, you will shoot waves of enemies with a giant array of weapons, or 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, or 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 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.

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 analysis we did in the previous sections of the chapter will be part of the GDD and will be further explained and analyzed.Content sections: You will also want to 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 in 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—anyone and 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, which consists on lots and lots of game systems unnecessarily, and know when enough is enough, especially considering the limited amount of resources we will have when beginning to create games. 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 much 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 could have created a better way of handling Y system, or maybe test sessions with players prove that Z level needs to be completely redesigned. Be open to change and pivot your game idea when needed. 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 a picture 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 how to perfect timing, damage, health values, and so on.Regular prototypes: While your game is being developed, the GDD will constantly change based on player 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.

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.

Summary