#unitytips

We already have a shader pass in this shader, so we just duplicate that for now. Because we’re writing the same information twice, this doesn’t change how the shader looks though.

The next change is to set up our properties and variables. This second pass will only write a simple color to the screen so we don’t need the texture. we just need the outline color and the outline thickness. We put the properties in the properties area at the top like usual. It’s important that we put the new variables in the second pass though.

The next step is to rewrite our fragment shader to use the new variable instead of a texture. We can simply return the color without any additional calculations in there.

Because we don’t read from a texture in this pass, we can also ignore the uv coordinates, so we remove them from our input struct, our vertex to fragment struct and we stop passing them between the structs in the vertex shader.

With those changes, we can see in the editor that the objects now simply have the color the outlines should have. That’s because our second pass simply draws over everything the first pass has drawn. That’s a thing we’re going to fix later though.

Before that we ensure that the outlines are actually outside of the base object. For that we simply expand them along the their normals. That means we need the normals in our input struct, then we simply add them to the position of the vertices. We also normalize the normals and multiply them with the outline thickness to make the outlines as thick as we want them to be.

With this we can now adjust the thickness of our hull, but it’s still hiding the base objects. The fix for that is that we don’t draw the front of the hull. Usually when we render objects we only draw the front because of performance reasons (you might have looked inside a object before and were able to look outside, that’s why). For this we can now invert that and only draw the backside. That means we can still see the object because we can look into the hull and we can see the hull behinde the object because it’s bigger than the object itself.

To tell unity to not render the frontsides of objects we add the Cull Front attribute to the hull pass outside of the hlsl area.

And with this we have the outlines how we want them.

It is pretty straightforward to also apply the outlines to a surface shader. Unity does generate the passes of the surface shader for us, but we can still use our own passes too which unity won’t touch so they operate as usual.

This means we can simply copy the outline pass from our unlit shader into a surface shader and have it work just as we expect it to.

The differences of outlines via a inverted hull shader to a postprocessing effect is that you can make the outlines on a material by material basis, you don’t have to apply it to all objects. Also it’s a different look than choosing outlines based on depth and normals. It’s best to inform yourself about both techniques and then choose which is better for your game.

I hope it’s now clear how shaders with multiple passes can work and how to use them to make outlines.

You can also find the source code for the shaders here: https://github.com/axoila/ShaderTutorials/blob/master/Assets/19_Inverted_Hull/UnlitOutlines.shader https://github.com/axoila/ShaderTutorials/blob/master/Assets/19_Inverted_Hull/SurfaceOutlines.shader

In these games, one tile is the same size as the user’s screen and the player will move their character to the edge of each tile (edge of their screen) to transition to the next.  Link’s Awakening was made for the Gameboy console which is why the tile is more square.  We are creating Reverie in a similar way.  Each tile is the same size as a Playstation Vita screen, which is 960x544 pixels. Our resolution for our pixel art is 318x180, so we then scale the images up to match the screen pixel size.  We can talk more about why we have done this in a separate art post if you want, let us know on Twitter or Facebook if you want!

Reverie does have a slight difference in our tile system as some of the tiles are double the Vita screen width or height, or even more.  For example, the home town which we have shown parts of in various Twitter images and GIFs, is two tiles wide and six tiles high giving the player more freedom to wander the town.

The interior spaces, like the different houses and the shop in the town, are handled a little differently as well.  They aren’t tiled like the overworld or the dungeons are.  This is because it would be super annoying to have a screen cut every time the player enters a different room in the building.  The only time there is a screen cut inside of a building is if the player is moving to a different floor.

Oh and we are using the Unity engine.  That part is important.

Each tile contains lots of different parts to it.  The walls, the floor, the obstacles and any enemies that are in it.  This is where we had to decide if we wanted to use Unity’s prefabs or scenes.  So let’s talk about those.

Prefabs

One the great things about Unity is the prefab system.  A prefab is an asset that stores any object complete with components and properties.

Here is an example of our HealthPickup prefab.  

Everything under the “Inspector” tab is a component with it’s own properties.  All of these components and the values of the properties are the same across all instances of the HealthPickup prefab, whether it is spawned at runtime or already created on startup.

Prefabs are convenient for easy world creation, as we can drag a prefab into a scene directly from the folder and it’s there with all of its values and sprites and animations (if it needs them).  While this is super useful for world creation, it didn’t really work well for our tile system.

Scenes

A scene in Unity is essentially a developer’s playground.  Scenes make it easy for a user to add or remove any object into the game world.  This is a basic scene in the Unity editor that is used by literally anybody who creates a game in Unity.  On the left there is a Hierarchy of everything in the scene.  We can click on anything in the hierarchy and manipulate it however we want. Anything in the hierarchy is classed as a game object or a prefab (hint hint).

A scene makes it easy for the user to edit an object in the game world and change their components and properties in the Inspector.

Another useful thing about scenes is being able to drag an object or prefab from a folder directly into the game world.  Here we drag the BeachUmbrella prefab into the HomeTown scene and place it on the beach.

As you can see in the hierarchy, when the BeachUmbrella prefab is added there and the Inspector shows its components with each of its properties.

Scenes over Prefabs

Now, we could have made the entire town a prefab along with every other tile we plan to have in the game, and have the world map be only one scene.  While this would have made the hierarchy really messy and confusing to use, the biggest issue is that nesting prefabs is impossible in the current version of Unity.  A nested prefab is a prefab inside another prefab.  For example, an enemy is a prefab that holds the enemy’s sprite, animations, and A.  This could be nested into a prefab that is a group of enemies.

As you can see here, the town alone has a lot of objects and prefabs in it… Like, a lot. 

Although a lot of these things are just 2D sprites, there is a lot of stuff going here.  There are colliders on the walls of buildings and cliffs, colliders on the base of every tree, bush, and umbrella.

In the end the main reason why we used Unity’s scenes rather than the prefabs is because prefab nesting isn’t viable at the moment and the hierarchy would be extremely messy.  Using scenes to represent each tile helps to make creation and management of the map easier. Here is how we load our tiles using scenes.

Ways to Load Tiles

Okay, so now I’m going to get into the nitty gritty technical stuff. I have tried to make it as easy to understand as I can, so hopefully I get my point across well.

Adjacent Tiles

All of the names of the scenes in Reverie are stored in a 2D string array for each map.

This is the part of how the map is set up:

This picture shows the initialisation of the first map as well as the assignment of some tiles. Every time a scene is loaded for a map we check the tile position on the map that we want, which then returns the name of the scene to be loaded. A scene transition is started when the player walks out of the width or height of the current scene.

Here is the code for checking if the player has left the current scene:

The normal way that we load tiles is to load the adjacent tile to the player by decreasing or increasing the x or y index for the map array, and then looking up the scene name by the x and y index. The MoveDir variable defines which way the player needs to move and how much of the map index is changed. We then transition the player in the direction of that tile and unload the previous scene after the transition is complete.

If that was too complicated here is what the transition looks like behind the scenes:

Only one tile is ever loaded at any time.  By using this system we don’t have to put premade triggers in every scene to determine which scene should be loaded next, which makes my job a lot easier!

Teleport Loading

The other way that scenes are loaded in Reverie is by teleporting the player to a specific position and loading a different scene by name. An example of this is any doorway that loads to the interior of a building. The screen will fade to black as the player needs to be teleported to a separate scene which is not a part of any map.

Here the player is teleported to the inside of a house:

This allows us to create interiors that are larger on the inside and aren’t counted as part of any map, which gives us the freedom to expand the map if we want to. Implementing each of these teleporters is more time consuming than using a map system.  This is because each scene and the position that the player ends up in must be manually typed into each teleport trigger, and this is then tested to make sure that the player ends up in the correct place. Testing this kind of stuff is pretty monotonous, but sometimes game development is like that.

This is the trigger to enter the player’s house:

Now to wrap things up