Pithy Pangolin Dev Blog

Input controls

We need to tell the Unity player input systems what buttons we want to bind to listen for dash. I always try to make my games keyboard and controller friendly so I am gonna by dashes to Q and E as well as the left and right bumper of a controller.

Note that my dash is built around wanting a back dash or a forward dash. You will need to change the process for a single input dash. I will explain that when we look at coding. This code also assumes you already have a working character controller capable of movement and ground checking. If you do not know that already please watch the unity tutorials on character controllers first:

https://learn.unity.com/tutorial/live-session-2d-platformer-character-controller

Project Settings -> Inputs

Coding

I tend to establish my code as sub classes to keep things nice and clean. This is not necessary but when you see screen shots of my controllers you will understand why I do it. Having code for specific actions in sub classes allows me to close the class > widget and hide their information when working on other parts.

Initial code deceleration (this is part of my overall character controller script)

https://pastebin.com/yRaWd6H1

Variable declerations

https://pastebin.com/nSveZaf5

Character Controller behavior

As you can see this Makes a nice header and a sub class on the behavior that can be closed to minimize visual bloat when I am done getting the dash coding working.

Listening for dash inputs during fixed update:

https://pastebin.com/17demyhi

Note this code is dependent on the fact that you already understand how to do a ground check with in Unity. If you do not look for grounded code using:

https://docs.unity3d.com/ScriptReference/Physics2D.OverlapBox.html Unity has good tutorials on this.

Basically my code listens if the dash inputs are pressed, if the character is not grounded and has air dash or if the player is grounded as well as if the player is not already dashing to stop multiple dash inputs.

The code then starts a couroutine that enables dash for the duration you establish in the dash class.

Dash couroutine:

https://pastebin.com/YD9y1yG6

We need to listen for canceling dash if input is now counter to the direction initially dashed in so we can do dash cancels.

Dash cancel during fixed update:

https://pastebin.com/G4evMyS4

The next thing we need is the courotuine to end dash and wait for cooldown. This is called automatically by dash if enough time passed or from the cancel inputs.

Dash stop and refresh cooldown couroutine: 

https://pastebin.com/MWj7zXrS

The last thing we need is for the dash to apply actual action to the character rigidbody2d. As you hopefully see so far we are storing speed in a variable from dash control but we are not applying it player controller.

Rigidbody velocity application:

https://pastebin.com/8R76ZhFG

Move X is established earlier in the controller from inputs of the Horizontal axis listener.

This it the highest level of my animation controller. Originally I set it up with an empty default animation with no keyframes. This is because I have different idles depending on the last direction that the player was facing. 

As you can see by looking at this default feeds into 3 key sub-state machines. Walk, Dodge, Idle. For the purpose of this tutorial I am gonna focus on Walk. The player controller script feeds a float to the animator that is “Move” this is a combined value of both my X and Y inputs since it is over head. This way if any directional input is sent to the input listeners (Keyboard or controller) then the animation tree will leave the default animation and enter the Walk controller.

This is the walk Sub state. While it looks confusing all you really need to understand is that the animator comes into the entry node from the higher level anytime move is > 0 and exits when move is <0 or the direction facing no longer matches the direction facing on enter. (This way when changing direction while moving we can interrupt the animation in one direction and loop back in for another direction)

I use a basic Iint called DirectionFacing on the animator feed from the script feed from the entry node to a specific directional facing. I happen to have a 6 directional state but you could have a 4 direction state. The key is you pair directions to an int you can remember. For example North = 0, East = 1, South = 2, West = 3.

Looking at the connection from entry to East we can see how this works. The substatemachine enters entry and entry moves on to Walk_E if the value of direction facing = 1.

I have 3 exit conditions from a walk animation because I have additional special action events like dodge. But the important 2 are if Move < 0.1 because the player is idle. Or if the directionFacing != the direction facing that the animator entered this animation in, for example 1 because it was east.

The script is very easy. You just need to pass the Mathf.Abs of Horizontal and vertical niput added together to the animator as Move. This will send a positive value for X and Y to the animator to let it know it is moving.

The variables:

https://pastebin.com/ArntXBQk

Room templates acts as the master seeder for a wing of my dungon. Most wrings only have one seeder except the main house which has four wings so it has a special controller to set off each seeder. Ordinarily a save data component pulls the data and feeds it to one of these seeders. If no previous play is recorded then the seeder does it’s own work if the player has not died and is returning to a wing then the save feeds the seeder from a binary pull the room locations and status. Looking at the variables you can see initially the set up of some cardinal directions which exist in my static persistence class.These define north south east and west as enums so I can more easily reference them with switch cases and not get lost.

Then we see some basic seed requirements like room size, current count, and the position of the start seed.

We have the declaration of arrays for possible rooms for each scale. As I create new rooms for a wing I simply drop their prefab into the list of rooms. Each room has an unique ID int for that size so when rebuilding from a save it can place the same type of room in the same place. For example the same 10x10 where it was previously and not just any 10x10.

Exit prefabs are for when the seed is done and needs and exit to a sub area or boss room.

A list of all spawned hallways and rooms are kept so the game can binarize their values out to a set of special save files I use.

Important code sections:

Starting off and spawning rooms:

https://pastebin.com/UbKFJLEA

The startSpawn() creates the initial hallway based off the spawning preferance of the seed and sends the attach point of the seed room to the hallway controller of the spawned hallway.

Spawning an inital hallway:

https://pastebin.com/LBP7Ge6a

This places a hallway based off the direction of preferance of the seed and tells the spawned hallway which direction form which it is being attached and to what. You can understand what hallways do by looking at their code which I will break down better in a later bit of tutorial.

But here is the overall code:

https://pastebin.com/4Lc4n4EG

Once a hallway has safely spawned and done a check of available room sizes to attach to it’s remaining exit then it send back to the seeder to spawn a room using that list.

Spawning Rooms:

https://pastebin.com/kJ4Jr7dX

The spawnNextRoom is called from a hallway and passed a handful of information (the previous exits from the hallway, and the acceptable safe spawns).

If there are safe spawns and the max room limit has not been hit then the room spawn randomizes the safe spawn list to ensure a little randomness and instantiates the next room from the array of rooms that matches those room scales.

Then the room is lined up based of the previous hallways. This all takes long enough for the room controller of the room to set off and remove any exits that have conflicts with existing rooms and the room controller is told to spawn it’s own hallway. Which completes the loop because this next spawned hallway will tell the seeder to drop a room off it’s exit. 

Importantly the room controller that calls for hallways to be built out of it can build up to 2 exits which means branching paths in the game.

Cleaning up and adding exits:

https://pastebin.com/LhVzbf3R

Once the last room has been built and the max room limit has been reached by a spawnNextRoom call then the seeder calls the clean up functions which is a hallway clean up and placement of the exit door.

Hallway clean up is done by checking each hallway to see that both exits have a door way and if they do not then the hallway is deleted and the exit in the previous room is turned to a door.

Once this is done a room is chosen based off the preferred direction of the seed and an exit (usually to a boss area) is attached to a  hallway spawned out of that room.