For controls I’ve generally used the standard for movement, attacking and interaction for better usability. The staff colour keys are less standard as they haven’t been fully implemented.

-A and D to move left and right

-E to interact

-Space to jump

-Left mouse click to attack

-ZXC to change staff colour (green, orange, purple)


When looking for good ways to implement combat I came upon a page by Gladstein (2018) that goes into depth about different types of hitboxes. This gave me a better understanding of 3D combat mechanics for fighting games and in implementing my own combat mechanics.

To attack, the player clicks and the player script checks to see if there is an enemy or destructible object (stalactites) inside of a hitbox (Figure 1 Red box) in front of the player. The script checks if the object in the hitbox is a stalactite or enemy then sends a command to the stalactite or enemy script to apply damage.

Figure 1: Player collision (Green) and hitbox (Red)


For the health, both the player and enemy have their health stored in a local variable which is referenced by the different controller script on each of them. If the enemy touches the player, the player is damaged by one point and becomes briefly invulnerable. 

When the enemy is hit by the correct colour they take one point of damage and die once they have lost three. If hit by the incorrect colour they take half the amount of damage.


Each enemy has a set spawn position, colour and starts to move when the game starts. In following versions I would have it so that the enemies respawn in the set locations but also have their colour partially randomised depending on the area.

Enemy Movement

For the thistle ball enemy movement I wanted them to be a basic enemy class that the player would encounter early on during the game, having a simple movement pattern and doing minimal damage.

For the movement the thistle ball moves backwards and forwards across a platform without falling off or getting stuck on terrain. 

To accomplish this movement I made a script that creates two raycasts from a point in front of the direction it’s moving in. One raycast points down and checks whether there is ground below it. If there is ground then the enemy keeps moving and if not, then it turns a full 180 and continues in the other direction. The second raycast works in the same way but projects outwards in the direction it’s moving, checking and turning around if there are walls in front of it.

Player Movement 

Player movement is velocity based where depending on what direction the player presses, either a positive or negative velocity is applied to move the character model. If the velocity is positive then the player moves right, or left if it’s negative. Velocity also controls the direction the player faces, turning the model 180 degrees when moving in the opposite direction to where they are facing. 

Similarly jumping applies velocity but vertically whenever the player is not on the ground. To make jumping more responsive and enjoyable for the player I implemented a couple of tricks which make the game feel better to control.

One trick is coyote time, which is when a player can jump just after leaving a ledge so they don’t simply fall down, feeling like the input was ignored. Similarly this can be done for jumping, when a player presses jump before hitting the ground, if done within a certain distance it stores the jump, causing the player to jump again once they touch the ground.

Animator Controller 

While an animator controller is used to control animations, it primarily uses variables pulled from scripts to transition between different animation states, making visualising and working with animations a lot easier.

Figure 2 shows the animator controller and how pretty much every animation state is linked back to idle, the default state when nothing is happening. For the player to be able to play the attack animation I set it so it can be played from any state, interrupting the current animation playing. Each white line shows a transition between states, generally requiring a variable condition to follow the arrow’s path.

Figure 2: Player animator controller


Gladstein, S. (2018) Hitboxes and Hurtboxes in Unity. Gamasutra. 14 May. Available online: [Accessed 16/01/2021].

Leave a Reply

Your email address will not be published. Required fields are marked *