Các bước học lập trình game unity từ đơn giản đến phức tạp

Book Description
Unity is a comprehensive yet simple suite of tools for developing video games. You can use
Unity to not only create video games, but also AR/VR experiences, complex simulations, realtime realistic rendering, films, and practical games for training and education. With this book,
you will get to grips with creating a 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.


What you will learn
●

Explore both C# and Visual Scripting tools to customize various aspects of a game, such
as physics, gameplay, and the UI

●

Program rich shaders and effects using Unity's new Shader Graph and Universal Render
Pipeline

●

Implement postprocessing to improve graphics quality with full-screen effects

●

Create rich particle systems for your Unity games from scratch using VFX Graph and
Shuriken

●

Add animations to your game using the Animator, Cinemachine, and Timeline

●

Use the brand new UI Toolkit package to create user interfaces

●

Implement game AI to control character behavior


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 Scratch

●

Chapter 2, Setting Up Unity

●

Chapter 3, Working with Scenes and Game Objects

●

Chapter 4, Grayboxing with Terrain and ProBuilder

●

Chapter 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 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 information to go on? Would they create a
great game, but not the game you had in mind? All we are doing with our game design is
documenting as much as we can in the beginning so that the development process is
purposeful. Without question, you will continually modify your game's design during
development, so having a strong base from which to start is critical to your success.

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

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

●

Game idea

●

Input controls

●

Winning and losing

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



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

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

Figure 1.1 – Our hero shooting bullets at enemies

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


will control the character.


Input controls
It is important to consider how players will interact with our game. Players have an expectation
that the industry norms for user controls will be implemented in games, which is why, for our

example, the player will control our Hero using the standard set of controls.

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

Figure 1.2 – Controls scheme

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


Figure 1.3 – Key mapping

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


Figure 1.4 – Mouse mapping

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

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


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

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

●

The first losing condition is when the base life becomes 0.

●

The second losing condition is if the Hero's life becomes 0.

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

●

The number of remaining Waves

●

The health of the Player's Base

●

The health of our Hero

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

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 condition

●

Point system

●

Heads-Up Display (HUD)

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


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

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


Figure 1.5 – Base layout

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

●

Wall: Impenetrable barriers that prevent the player from going outside the play area.

●

Door: Impenetrable, like the walls, but will also serve as the Spawn Position of the

Enemies. The Enemies will spawn behind them and can penetrate them to enter our
Base Area.

●

Player Start: This is the Hero's start position.

●

Base Building: Our Base. The enemies must be close enough to attack it.

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


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

●

The number and placement of Enemies' Spawn Points: As you saw in our earlier mockup, 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.