Build 2 - Enemies, Player Animation and Updated Player Movement

3 years ago by ow514073

Share this post:

The Second Build

The second build for the game demonstrates the beginnings of how enemies will behave, which will be expanded upon in the future. There is also animation for different states the player is in, as well as some updates to how the player moves through their environment.

Enemies

In this build, I have added an enemy which has some very basic functionality. While the player cannot currently attack or be attacked by the enemy, the enemy will attempt to chase the player. This is due to a "chasing player" boolean variable on the enemy, which when true, they will try to move to the player's position, stopping a short distance away and toggling off the boolean. It is at this distance that the enemy will begin to attack the player, and they will try to move away if the player gets too close.

In this build, manually toggling on the chase player boolean will make the enemy try to move towards the player, stopping before it reaches them.

This implementation of enemy movement is very simple at the moment and not very engaging, as there is currently no way for the enemy to automatically begin chasing the player, and the player must also manually make the enemy jump. I am currently working on using raycasts to make the enemy check the path in front of for obstacles, meaning that it will jump over short gaps and walls to reach the player. I will also make use of raycasts so the enemy can automatically detect and begin chasing the player.

Player Animation

Player animation is another thing that I have worked on this week. While it is not flashy at the moment, I have set up an animation system using Unity's built in animator, demonstrating some of the different animation states that the player will be in during the game. Currently there are 6 different states which are coloured depending on what type of movement it is, as well as arrows indicating that it is a left or right movement. The idle player animation is yellow, when the player is moving while grounded they are blue, and when they are in the air they are green.

Demonstration of most of the animation states that are currently implemented, forgot to show off jumping without moving but it is just a green square without a directional arrow on it.

In the future I will obviously need to update the graphics with an actual player sprite, as well as integrate animations for the various attacks and abilities that the player will be able to perform.

Current image of the animator window in unity. There are many different connections between the nodes allowing for responsive change of the animation that is currently playing.

Updated Player Movement

Since the last build, the player movement has been changed, and there are now a few key differences. First of all, the player is limited to only 2 jumps total (one on the ground and a mid-air jump), which is achieved by using Raycasts. On the player character, there are 3 different raycasts attached to the player. These raycasts originate from the left, centre and right sides of the player and extend downwards a short distance below the player. If any of these raycasts hit the ground, the player will be considered grounded. While the player is grounded, their mid-air jumps will be refreshed up to their total jumps (currently 2) minus 1, meaning I can easily change the number of mid-air jumps the player can do in the future if I so choose. While the player is not grounded, their mid-air jumps isn't 0, and the jump key is pressed, the player will do a mid-air jump, and their number of mid-air jumps will have 1 subtracted from it.

The second update to the player's movement is an extension of the double jump that has been added to the player. After adding the double jump, I noticed that the game felt worse, as if you were even slightly too late to press your the jump key when going off of a ledge, it would look like you did a normal jump, but what you actually did was a mid-air jump and thus you wouldn't be able to mid-air jump again. This felt really bad to control and felt inconsistent, but I solved it by adding some additional raycasts to the player.

About one world unit's distance to the left and right of the player there is now an additional raycast being done, which like the other raycasts, checks for ground below the player. However, unlike the other raycasts, these will not consider the player grounded if they detect ground, but will instead allow the player to do a "grounded" jump as if they were on the ground. This means that the player's mid-air jumps aren't being refilled mid-air allowing for 3 total jumps, as the player is not actually grounded, but they won't have their original jump cannibalised by the mid-air jump, which resulted in a total of 1 jump. If the player falls too far down or moves too far horizontally before attempting a mid-air grounded jump, they will not be able to do it, but I can change the origin and length of the raycasts, making this window of opportunity more or less lenient.

The red lines on the left and right of the player are these additional raycasts. In all the jumps off of the ledge, the player is not actually on the ground when they jump, but can still perform 2 jumps if they jump quick enough after falling off of the ledge.

Next Steps