What's up Game Developers? CouchFerret here,
and today we'll design our first level with the help of grids. We'll also make our sprites render in a correct
order, so the ones that are closer to us will render
in front. This will give our game a nice 3d effect. If it sounds fun,
then stay with me, and consider subscribing with the bell icon
so you won't miss any future videos of this game. Cool,
let's begin! Before we start building our world,
we need to import the new sprite we've created in the last episode. Let's use a new folder for the level's elements,
and drag and drop the sprite into it. We need to set the usual parameters on the
sprite's Inspector page, like the Sprite Mode,
Filter Mode, and Compression. Hit Apply so we can open up the Sprite Editor
to slice it. There's a clever little button in the Sprite
Editor which switches the sprite's visualization between colored or alpha only. If we toggle it to alpha only,
then it's easy to see where the individual elements are. Let's slice them one by one. I disable the current Archer to not bother
us, while I'm explaining today's task. Okay,
let's drag a pillar and an archer into the scene so I can demonstrate our problem. The thing is,
that it doesn't matter how I move the archer around the pillar,
he always stays behind the pillar. He should be rendered in front of the pillar
when he is closer to the bottom of the screen. This would give us a 3 dimensional feeling
in the game. But currently,
our game is flat. We can tell Unity which sprite it should render on top by giving the sprites a sorting order value. If I crank the number up he appears in front
of the pillar, which makes it look more like we have a 3d
space. However,
now he always stays on top, no matter how far I move him. We could dynamically change the sorting order
for each sprite based on their Y positions, but that's too much work. Unity has a pretty cool and somewhat hidden
feature, which handles the whole sorting for us without
writing a single line of code. By default,
Unity sorts the sprites based on their Z position, which is the direction into the screen. But we can change that to sort it based on
Y positions if we change the sorting axis from the direction into to the direction up. We can do that if we go to Edit/Project Settings/Graphics
and set Transparency Sort Mode to Custom Axis, so we can overwrite the axis below to the
up direction. Now if we grab the archer and move it around
the pillar, it will appear behind or in front of the pillar
depending on his position. How cool is that? It starts to look like our game has a 3 dimensional
space. But it feels somewhat imprecise. The sorting flips earlier than it should. The archer's position is behind the pillar
from our perspective but the sorting makes it appear in front of the pillar. The source of this problem is that Unity uses
the sprites' center point to sort them, which doesn't give us the desired 3d feel. We need to somehow tell Unity to sort them
based on where the objects touch the ground. We can do this multiple ways:
The first one is that we can change the Sprites' Sprite Sort Point parameter from Center to
Pivot, so Unity uses the Pivot point defined in the
Sprite Editor to sort them. Then we can define a custom pivot point for
each of the Sprites in the Sprite Editor. Let's move the pillar's pivot to the middle
point where our pillar would touch the ground if it was a 3d object. Hit Apply and do the same for the Archer as
well. For the purpose of this demonstration,
it's enough to change only one slice. If we test it now,
it should be more precise than it was. Yeah,
it looks fine. The colliders will help it a bit so the archer
won't be able to walk too close to the pillar, but we will see that in the next episode. This solution is fine,
but I have concerns with manually setting all the pivot points for the animation sprite
sheet. So I'll revert these changes,
and show you a better solution. The second way,
and in my opinion the better way, is to give custom pivot points to Unity with
Sorting Group components. Let me show you while I'm explaining. But first,
let's change the snapping tool's parameters to work on a pixel basis. If we go to Edit/Snap Settings and change
the Move X and Move Y to 0.005 then we can move the objects by half a pixel while holding
down the command or the Ctrl key. This will help us position the sprites and
their pivots precisely. Let's zero out the Sprite's position,
create a new empty gameobject, and name it Archer. Drag and drop the Sprite into this new gameobject
so it becomes its child object. Zero out both of their positions. The parent object's position will be the pivot
point so we need to move up the child object relative to the parent. Make sure that it's correct on both axes. To make the parent object into a pivot point,
we need to add a Sorting Group component to it. This will overwrite all of its child object's
sorting information. Quickly do the same to the pillar so we can
test it out. See,
it's working just like our first solution. Let's create gameobjects for the horizontal
and vertical wall pieces as well. The horizontal one is easy,
but the vertical is a bit tricky. However,
if we align it with the other pieces then we can figure out its pivot point. Don't forget to use snapping while aligning
them together. There's one last thing we need to fix before
we are done with this whole sorting thing. We have to change the original archer so its
pivot is also at the bottom of the sprites. Let's select the original Archer gameobject,
enable it and delete the dummy one. We need to reset its position,
create a new empty gameobject to act as a pivot,
and move it down to the correct position. Now we can move the two sprites into it. And don't forget to add a Sorting Group component
as well. Let's run the game and test it out! It works like a charm,
and it was quick and easy. But when we move and shoot at the same time
we got an error, let's find out why. Double clicking the error message in the console
window will lead us to the point where the error happens in the code. Okay I see it,
we moved the sprites one level deeper in the hierarchy so the Sync State Machine Behaviour
can't find the PlayerController script to access the bottomAnimator. We need to insert an extra .parent to fix
this. It works perfectly,
we can move forward to the level design part of this video. We can make our lives so much easier if we
use grids to position the level's elements. Unity has a component called Grid which will
force its every child object into a given grid. This will make every placement perfectly precise. Let's create a new empty gameobject and name
it Grid. To make it act as a real Grid,
we have to add a Grid component into it. Let's change its cell size to 0.1 by 0.04
so it matches our perspective from the last episode. I've also changed the tool handle's position
from Center to Pivot. Now if we make the Pillar gameobject into
a child of the Grid object, then it moves according to the grid. The smallest amount we can move something
in a grid is one half of the cell's size. Let's drag the HorizontalWall gameobject into
the Grid as well. It's not bad,
but we want the wall to be one pixel up in the Y axis. Because the grid forces its child objects'
position to be on the grid, it doesn't let us move it up just one pixel. We have to do a similar trick we did earlier
today, but now we will define a new pivot point for
positioning and not for the sorting. We can do this by creating a new level of
gameobjects in our elements. Let's create a new empty gameobject outside
the Grid. Let's name it HorizontalWall,
rename the previous HorizontalWall to Sprites and move it under the new gameobject. We need to reset both of their positions and
move it up by one pixel so it fits the Grid just how we wanted. If we move this new wall into the Grid,
we can test if we've done it correctly. Now it has a new positional pivot point. We need to do the same thing to the VerticalWall
as well, which is a bit trickier because its pivot
is way down compared to the actual sprite. I quickly tinker with these new positional
pivot points, so every element fits on the grid in a way
that their pivot point is on the grid's line and not in the middle of the cell. Now we only need to create prefabs out of
them and they are ready to populate our first level. Let's drag all of them into the Prefabs folder. And here comes the most fun part of today's
video: the level creation. Let's build a few walls to make our first
level. I want to make some kind of arena here. We can quickly build new walls by duplicating
existing ones with Command D or Ctrl D on Windows. As a final touch,
I'm adding some grass and flowers as simple sprites. I'm just dragging them into the scene and
then duplicating them in groups so I won't have to create them one by one. It’s starting to look like a real game. Let's take it for a spin! Okay,
this is awesome! Can you imagine this with 4 players and monsters
all over the place? I can't wait to try out the finished version. That's it for today folks! Next time,
we will modify our walls by adding colliders and rigidbodies to them so the archer won't
be able to run through them. We will also upgrade the movement script to
a physics based one with velocity. So be sure to subscribe and leave a thumbs
up! If you have any questions about what you have
just seen, feel free to ask and I'll try to answer all
of them. See you next time!
