Subtitles section Play video Print subtitles 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.