Unity 4.3 - 2D Game Development Walkthrough

In Unity 4.3 we're launching our first set of 2D features.

To compliment this we have constructed a

demo project with these tools.

Our 2D platformer is nicknamed 'Tower Bridge Defence'

It depicts London's Tower Bridge in the midst

of an alien invasion.

It's a completely sprite-based, physics driven

2D sample level that we hope will help you

understand how 2D games are put together in Unity.

This video will discuss the background and

foreground construction, characters, effects,

camera tracking, animation and scripting

used in the demo.

To begin with, let's discuss the basics

of working in 2D in Unity.

Firstly, when working in 2D, you should set the

Editor Behaviour Mode to 2D

for various settings.

This can be done when making a new project

using the drop-down on the project wizard

or during a project by choosing

Edit - Project Settings - Editor from the top menu.

This means that by default textures

will be imported as sprites and the

Scene View will default to 2D mode.

This new mode gives you a completely orthographic

view in which to construct 2D games.

It also hides the usual 3D gizmo

in the top right of the view, giving you more space

to work in. Aside from these settings the work

flows for 2D have been designed to mirror

existing Unity approaches to 3D game creation.

So if you already know a little about Unity

you'll be in a great position to start making

2D games right away.

It's worth noting at this stage that you can

still mix 2D and 3D in Unity,

so if you want to add 3D elements to your 2D game

or vice versa you can do that with no worries.

Let's take a look at the demo project itself,

and how we built it up one stage at a time.

We began by sketching out the level design

for this sample level and then went about

recreating the layout in Photoshop.

Creating and exporting the layers,

we were able to import these in to Unity

using the new Sprite type.

In order to create parallaxing in our background later,

we kept some of the background elements separate

and placed them on to a Background Sorting Layer.

Yet another new feature of 2D development in Unity.

Having assigned all of our backgrounds to this layer,

we could then use the Order In Layer property

of the Sprite Renderer to sort them.

Once we were happy with their positions

we could lock the Background Sorting Layer

so that when we added foreground elements

we didn't need to worry about accidentally

dragging background elements around.

This is done using the Layers pull-down in the

top right of the interface.

Because the background elements are purely decorative

we did not require any additional components

on the sprite game object.

They were parented to an empty game object

that has a simple script to handle parallaxing

called BackgroundParallax.

For more information you'll find this script

fully commented in the Scripts folder.

Next up came the creation of the foreground elements

that our characters would actually traverse.

We designed London's Tower Bridge with a UFO

landed in the centre.

The character has the run of the environment

as enemies spawn from the skies and begin

to navigate around the level.

As such, each piece of the foreground required

a collider for characters to walk upon.

For most of the environment we used 2D

box colliders for efficiency,

but the UFO itself has a more complex shape.

Unity's Polygon Collider allowed us to

automate creation of the collider itself

based on the shape of the sprite.

It even meant that we could tweak the shape of

the collider later.

Moving, adding or subtracting points

of the collider shape to make it more

appropriate to walk over.

To sort these foregrounds we created a

Foregrounds Sorting Layer, which was drawn

above the backgrounds in the Tags And Layers manager.

Next, let's take a look at our hero.

Our player character was yet again designed

in Photoshop, and for this demo

we chose to make a character with independent

limbs and features in the style of

2D hits such as Rayman.

Our other option would have been to design

a sprite sheet-based animation and design each

each frame in Photoshop,

an approach we use later for the background Swan,

which we'll discuss later in the video.

Because our character had independent elements

that we wish to animate we finalised the design

and then moved his bodily elements in to separate

spaces on our canvas to allow Unity to isolate them

as separate sprites in the Importer.

This meant that we could then arrange all of

our sprites as separate elements to be animated.

We placed these on to a new Character Sorting Layer

that we created, and then used Z values in the

transform to sort their rendering depth.

All of these sprites are then arranged under an

empty game object, which has all of our

controls scripting, colliders, physics, excetera attached to it.

Once we'd done this we were able to use the newly

upgraded Animation window to create

Idle, Run, Jump, Shoot and Death animations

by animating each of the character's sprites over time.

With the new Dopesheet View in the Animation window

this is easier than ever.

We simply add animation to the parent object

and then create keyframes for any of the child objects.

Moving the playhead to where we want

and then moving the various parts of the character

to automatically keyframe the animation.

The ability to switch between Curve and Dopesheet

representation of our animation makes it easier than

ever to adjust timing and design.

With these animations created we can

then design a state machine for our character

so that when called upon in code, differing animations

could be played.

the animator controller for the character is

not driving a 3D biped, so we simply deselect

Apply Root Motion and select Animate Physics

in order to drive our animations in time with

the physics engine.

In order to traverse the environment our hero has a

circle collider at his feet and a box collider

to cover the rest of his body outline.

This means he can smoothly walk up and down hills

and when he jumps his head will hit the ceiling.

In order to control the character and it's animations

we wrote a script that moves him via 2D physics forces.

This means that we can apply physics to him

and the enemies during the game for more

dynamic game play.

In our PlayerControl script for the character

we check for player input.

We use this to apply physics forces

for movement and also send the value of the input

to the animator, which in turn defines which

animation should be playing and smoothly transitions

between the different animation clips that

we've created as states.

The great thing about using the animator to

create states from animation clips is

that we can go and tweak speeds of animation

to match our physics velocities

without having to reanimate anything

The FixedUpdate function evaluates with

each physics step, and the first thing we

do with this is to feed the value of Horizontal

input in to the Speed parameter of our animator.

The transition between Idle and Run

in our simple state machine requires

that the Speed parameter is above 0.1.

When it is, the animator blends from Idle

in to the Run state.

We then go on to add forces to the player's

2D physics component, the rigidbody2D,

in order to move him around.

We also handle which direction the character is facing

based on the value of Horizontal input,

checking whether it is above or below 0.

This is because in Unity, holding the left input key

returns a value of -1, where right returns positive 1.

Depending on input, we then call a simple flip function,

which reverses the X scale of the character,

giving him the appearance of facing the opposite direction.

To decide whether the player is grounded

we added a layer in Unity called Ground

and applied it to all of our walkable foreground surfaces.

We then used the Linecast function in 2D

to check whether something on the Ground layer

is below the character's feet.

To customise this more easily we created

an empty game object to use as a point

at which to check for the ground.

By adding a gizmo to this empty object

we are able to manipulate how far below

the character we'll check for the ground.

From a gameplay perspective this means that

the character can only jump when grounded.

Check out the rest of the comments in the script for more

information on the control of the player.

We will discuss the player's weapon

later in this video.

Next, let's take a look at how the camera

tracks the player in our demo.

In 2D games, much like 3D, the motion of

the camera tracking the action can make

or break your game.

For a classic 2D platformer, we looked at the mechanics

of one of the most interesting camera in 2D gaming history,

the camera from Super Mario World on the Super Nintendo

or Super Famicom.

In Super Mario world the camera tracks

horizontally, but uses a dead zone

or margin in the centre of the viewport

in which the character can move a little

without the camera tracking.

Once the character moved beyond this margin

the camera tracks back toward the player.

The Super Mario World camera used particular heights

to snap to vertically, but we didn't need this

kind of detail for our game as we

do not have a long level in the X axis

but more of a stage on which the action takes place.

For this reason our camera employs

similar tracking vertically as it does horizontally.

Take a look at the CameraFollow script on the

mainCamera game object to see comments

on how it achieves this effect.

There are several effects in the game,

but most important is our heroes ability

to slay the alien onslaught he's faced with.

Our hero shoots a bazooka which has animated recoil.

This action is made up of several parts.

First we listen for key input and when the Fire key is

pressed we instantiate a rocket,

play an audio clip and trigger an animation state to play.

Let's break this down even further.

in order to play the Shoot animation while other

animations such as Run are playing we

created a separate layer within our animator

called Shooting.

By setting the Weight property to 1 here

we can totally override motion in the base layer

on any parts of our character that are animated

by clips on the shooting layer.

In this layer we switch to the Shoot animation

from any state, when the Shoot trigger

parameter is called from code.

Let's take a look at the Gun script in charge of this.

Here you can see that we address the animator

and set that trigger to True.

Triggers simply act as a switch and reset themselves to false

on the next frame so that they can be called again,

which is perfect for actions such as shooting.

In addition to setting the animation we fire the

rockets themselves from this script,

playing an audio clip and dependent upon

the direction that the player is facing

we instantiate a rocket and give it a velocity

that's positive or negative in the X axis.

This script is attached to the Gun empty game object

in the hero's hierarchy.

We place code like this on to an empty game object

as it allows us to easily position

where the rockets are created.

We do this by placing the empty object

at the end of the barrel of the bazooka

and then we use it's own position as the

point at which to spawn the rockets.

The rocket itself has a 2D rigidbody

and we assign a velocity to that in order

to make it move.

It has a sprite swap flame exhaust

plus a particle system for smoke.

The particle system also accepts the new sprite type of graphics

so by adding a sprite sheet of smoke puffs

to a material we can assign it to the

texture sheet animation module of the particle system

and we get instant animation of our

sprites for the particle emission.

When our rockets hit an enemy or part of the environment

the rocket itself is destroyed and

an explosion is spawned.

The explosion is simply a sprite game object

that animates through a sprite sheet that we have created.

Yet again using sorting layers to render this

at the lowest layer order of our foreground objects.

When adding sprite-based animation like this

we setup the sprites themselves by

selecting the file in our Project Panel

and choosing the Sprite Mode Multiple.

This gives us access to the sprite editor

which allows us to slice manually or automatically.

Once happy with the selection of sprites from our file

we simply hit Apply and Unity

generates the sprites as children of that file

to be used in our project.

So that's our rocket in a nutshell.

We will discuss the mechanics of killing the enemies

later in this video in the section about enemies.

Let's return to the player character now and look at

how we handle health and taking damage.

Health is stored as a float and

with each interaction with a tagged enemy

we call the TakeDamage function.

This is only allowed to occur after the

repeatDamagePeriod has passed

to avoid the player being killed very quickly.

To allow the player to escape enemies more easily

and to show the player that they are being hurt

we make the act of taking damage

repel the character physically.

To achieve this the TakeDamage function briefly

stops the player from jumping

and finds a vector from the enemy to the player

and repels him in that direction

by adding a physics force.

The hurtForce variable is exposed in the Inspector

as public so that it can be tweaked

to adjust this element of game play without

returning to the script.

In addition to repelling the player,

we of course subtract from the player's health.

and update the player's health bar.

To signify the decrease in health we subtract

from the width of the bar and use a colour lerp

to transition it's colour between green and red,

both by finding the percentage that the current health is

of the full health amount.

The health bar simply comprises of two sprites,

one for the outline of the bar and the other

for the bar itself.

This was again designed in Photoshop and then

the two separate elements were exported.

In the import settings for these sprites

we set their pivot to the middle left of the graphic

so that when it scales down it shrinks towards the left.

These two sprites are placed under an empty

parent game object which has a simple script

on it which makes it follow the player.

We do this by setting the position to the

same as the player object's position

plus an offset that we've made public to allow

for adjustment in the Inspector.

When the player has 0 health remaining

we allow him to fall through the level by

setting his colliders to triggers,

and we move him to the very front of rendering

by placing his sprite renderers on the UI Sorting layer,

one we've made to render in front of everything in the game.

We have 2 animations for when the player dies.

1 called Death, where he loses his hat and gun

and another called Falling.

We naturally transition in to Falling once

the Death animation completes by using the Exit Time

as our transition condition in the animator.

Finally, to stop the player moving the character

or shooting during the Death sequence

we disable the PlayerControl and Gun scripts.

Because the Die function is made as public

we can call it from elsewhere, such as if the player

falls in to the water.

To reset the game once the player does hit the water

we have a KillTrigger object, which simply

comprises of a trigger collider and a script.

For most of the game the purpose of the Remover script

is to remove our enemy objects that fall in

to the river, and instantiate a splash animation

and sound effect.

However, when the player is detected by this trigger

we call the Die function in the PlayerHealth script

and also disable CameraTracking

whilst moving the player off screen

and calling a co-routiene that pauses for 2 seconds

and then reloads the level.

But let's not dwell on the death of the player,

let's look at his survival and the tools that we give

him to do that.

Our game features 2 airdropped crates that

assist the player, 1 containing a bomb,

the other a med kit to boost health.

These crate drops are made up of 2 parts.

The crate itself and a parachute.

These 2 elements are nested beneath an empty parent object

to allow us to animate them as a group.

We position the 2 sprites so that the parachute's

centre is at the centre of the parent.

This way the animation can swing left and right

as if the entire parachuting crate is floating to the ground.

We then simply add a rigidbody to cause

gravity to pull the object down

and add colliders to the crate so that

we can detect when it lands and when

the player picks up the crate.

Upon landing we transition to a second

animation state which scales the parachute down.

Like other parts of our game, the animator handles

the states of the object.

We can see that by default it plays the

floatDown animation state

but then switches to a landing state

when the trigger Land is set to true.

In our script we do this using an onTriggerEnter function,

which detects the ground via a tag.

We also detatch the crate itself from the parent object

and give it a rigidbody of it's own

so that it can interact with the environment

resting realistically on a slope if it lands on one.

Let's focus on the bomb first of all.

Picking up the bomb crate is handled on the

BombPickup script, attached to the crate.

We pickup the crate by destroying it and adding to

the count of bombs that the player has

in the script attached to the player called

LayBombs

The LayBombs script simply checks if

the player is carrying a bomb

and then instantiates an instance

of the Bomb prefab.

The Bomb prefab has a timed fuse

which waits by using an yield within the

BombDetonation co-routiene

before calling the Explode function.

The Explode function performs several actions.

First it resets the bombLaid variable

to allow another bomb to be deployed,

it tells the pickup spawner it is allowed to

spawn a new crate drop and kills

enemies within a defined blast radian.

Let's take a look at how this last part works.

Because bombs are lethal to enemies regardless of

their remaining hit points we use the

Physics.OverlapCircleAll to collect all objects

tagged Enemy within a certain radius of the bomb.

We then run a foreach loop for every enemy found

setting their health to 0 finding a vector from where the bomb was

to where the enemy is, in order to apply

a force in the direction of that vector.

Once the foreach loop is complete

we play and instantiate visual effects,

play an audio clip for the explosion

and of course destroy the bomb itself.

The visual of the explosion is twofold.

The main part is a simple circle that appears

briefly and is then destroyed

and the second part is a particle system of

stars that reuses the same sprites

as our rocket explosion.

For efficiency we keep this particle

system in the scene at all times

and when it is required we use code

to move the system to the desired position and play it.

This keeps the particle system in memory

and makes the game more efficient.

It's worth noting that we can do this

because we know we will only have 1

single explosion in the scene at any one time

as the player can only throw 1 bomb at a time.

This is why keeping our particle system in the

scene and replaying it is more

efficient than creating instances and then removing them.

With the rocket explosion however,

we can have many at once so we do

need to spawn and remove them.

Now let's take a look at what happens when our player

kills an enemy and scores points.

This is done in 2 parts,

a scoring animation that plays showing 100 points earned

and the score UI at the top of the screen

that increments.

The score animation is made up to 2 number sprites,

a 1 and a 0.

We place this in the scene under an empty parent object

and animated them using a simple destroyer script to

remove them from the scene when the animation is complete.

We call the destroyer function in the script

by placing an animation event

at the end of the timeline.

The ScoreUI itself is a simple GUI text component

with a custom font and script that manages

the score for the player.

The Score variable is public, meaning that we can address it

from the Enemy script when they are killed

and add 100 points to the value.

Speaking of the enemies, let's take a look

at them more in depth now.

In our game we have 2 types of alien enemy,

a green slug-like monster and a smarter

alien that brought his ship with him for

protection during the invasion.

These characters share the same script

as the behaviour is very similar

and we allow for differing movement speeds

and amounts of hit points by setting

these as public variables in the Inspector.

Each enemy has it's own Walk animation.

The slug has a moving tail, whist the

ship-based enemy rocks back and forth as it approaches.

For the slug we used the sprite importer

to define the tail section of the graphic

as a separate sprite element,

meaning that we could animate it individually

and avoid having to scale the entire sprite.

By setting the pivot to the right

we are able to animate the tail expanding and contracting

from that point.

For added character we then move the eyelid up and down

and we use the Z value to sort the sprites

amongst one another, the eye being below the eyelid

so that we could animate it over the top.

The second enemy's animation was much simpler

and just meant that we rotated it back and forth.

For the mechanics of moving the enemies

we drive them by setting the velocity of the rigidbody.

When they encounter an obstacle such as a wall

they detect this by using a Physics.OverlapPoint function,

which checks for a point in space overlapping a collider.

Our walls, the towers at each side of the level,

are tagged as obstacles.

When this function detects them it calls the Flip function,

it reverses the X scale of the enemy

sending them moving in a different direction.

To kill the enemies, each time a rocket collides

with them it's script calls the Hurt function on

the particular enemy that it's hit.

In this function we subtract 1 from the

hit points of the particular enemy.

We then keep tabs on the enemy's health

inside the fixed update function.

If it drops to 0 we call the Death function.

When they die we perform a number of functions.

Firstly we disable all sprite renderers

as our 2D characters are made up of a

number of sprite objects that are animated.

This is because we simply want to swap out the

animated elements for a single sprite

of the dead character

We do this with the main sprite renderer by

setting it to use the sprite assigned to

the deadEnemy variable.

We then add to the score using the public

variable in the Score script

and we add some visual flare to the enemy's death

by adding torque to spin them as they die.

Because we need the enemies to fall through the

environment and land in the river when they die

we find all colliders on the object

and set their IsTrigger parameter to true.

This means that they will pass through the

environment colliders.

We then choose from an array of death audio clips

and play one of them back, before creating

an instance of the Score animation we showed you earlier.

To remove the dead enemy from the scene

we rely on the killTrigger object

It performs the same function as discussed earlier

as any non-player object touching it

will cause a splash animation and remove that object.

The sound effect of them hitting the water is

an audio clip attached to the animated

splash which plays on awake

so that when we create an instance of the animated

object we hear the sound right away.

To finish the game level re decorated the

background with a number of moving props

in order to make our game environment feel more dynamic.

We added flying swans, plus buses and taxis that drive

along the river bank.

First was the swan, which was created from a sprite sheet,

drawn in Photoshop and imported using

the Multiple Sprite Mode import setting

in the Inspector.

By choosing this approach Unity automates choosing

each frame in the sheet and importing

it as a separate sprite under the parent

hierarchy of the asset.

Because this is a linear set of animation frames

we could simply drag all of these sprites in to the

scene to let Unity animate them for us.

Et voila, our animated swan is ready to add

as a background element.

The swan was then given a rigidbody2D

so that we can use velocity to send it

across the screen.

As with the bus and the cab, the swan is saved as a prefab.

For the bus and taxi prefabs we

simply separated the bodies and wheels of

the vehicles in the sprite importer

and made a simple bobbing animation.

Applying a 2d rigidbody to these as well,

we were able to drive them across the screen

using velocity.

For all 3 props, the bus, taxi and the swan

we created a script we could reuse

which is in charge of spawning them.

The BackgroundPropsSpawner script

also handles the frequency, a speed to give them

and where on screen to spawn them.

This meant that we could make 3 creator objects

with the same script on.

Changing which prefab will be spawned

and what properties to give it.

Take a look at the comments in the script to learn more.

Finally, for more background dynamism,

we added rolling clouds, panning river details and fog.

We did this by adding 2 instances of the background sprite

to a parent object and simply used animation to slowly

pan them across the screen.

Because this animation loops our animation will

continue indefinitely.

And that's how we made our game.

We hope this overview has given you some idea of

how we create 2D games in Unity,

and we'll be creating more simply projects and

tutorials in the future.

We look forward to your feedback on Unity4.3

and we can't wait to see the great 2D titles

that you'll come up with.

Thanks for watching.