Second week; Enemy Creation

The enemies, called Offspring as they were created by the now loose Gods, were easier to create in some ways, and harder in others. For example, having experience in hooking up the animations to scripts and creating an animation controller; that part went much quicker. The only setback for this was the enemy character model has four arms, one of which is a blade, and an oddly shaped head with prongs sticking out from it in many different directions. As you may recall, Accurig doesn't like non-human models... In order to get around the arm issue, I left the back set of arms unrigged, though luckily they seem like they move since they still deform with the shoulder blades. I also had to create a skeleton with zero fingers, despite the front arm that had a hand having three fingers. This was due to the fact that the blade arm, if given fingers, totally deformed during animation; and Accurig also didn't like the idea of the hands having a different number of fingers.

Aside from that, the oddly shaped head lead to a minor issue of the head movements becoming extremely jerky and random; but I felt that added to the unsettling "This thing isn't quite right" feeling and decided to leave it in place.

The enemy itself, now that it's been rigged, uses a navmesh agent and a sort-of pseudo-state machine. By this I mean that it has states of following the player based on distance; attacking the player based on a smaller distance; and stopping it's pursuit if the player gets too far; but it does not use the state machine methodology of calling separate states based on the parsing. Instead it uses if statements for quick and easy prototyping purposes. I'd like to adjust this to a true state machine at some point for a refactoring overhaul of the majority of this projects code.

Currently, if the player enters the range for the enemy, the nav agent destination becomes the players transform. If the enemy is within range to attack, it's destination becomes itself (this was done to avoid an issue where the enemy slid side to side against the character as it attacked trying to reach it's destination). If the enemy is a diving enemy, it's destination is set to two units behind the player during the dive; then itself again once on the ground and finally the player after it stands back up. 

Next was creating a small sense of variety despite the single enemy model. This was done by adding a script that would give an enemy a number of either one or two on it's spawning which would decide whether or not it would begin the fight by diving at the player or not. There's also a script that uses the random.range method to select one of five attacks for the enemy to use, which then creates a sense of randomness and realistic behaviour. 

Following this, I decided it was important for the player to have an idea of when they were within range of a fight (aside from the music switching to combat from exploration music and the fighting stance taken on by the character) and added a roaring animation and sound effect to the enemy. This was triggered when the player entered the enemies range initially which would trigger the animation, the sound effect, and swap a bool to true that meant the enemy wouldn't roar again. On top of this, a secondary script was written that would have each of the enemies within the range of the roaring enemy take notice of the player and begin closing in as well without doing their own roar. This kept from having three roars erupt at once. It also ensured that if an enemy was close but not close enough for the player to enter their follow radius they would join the fight instead of standing idly by while the initial enemy fought the player.

However, combat proved unstable to say the least. The player didn't always face the enemy, and lining up hits was difficult. So a targeting system had to be made. 

I made a simple arrow png and created a worldspace UI canvas that would be moved by the script. Only activatable when combat was in progress, the method was to check a sphere for colliders on the target layer "LockOnLayer" and adding them to an array on being found. If the array was not null, the player could then lock on and the targeting arrow would appear over the enemies head at array [0]. Once the targeting mode was set, the player can use Q and E to cycle through the array, switching the arrow over to the other enemies at the arrays positions.

This then created a second issue. When locked on, the player always faced the enemies, but the animation didn't match. Walking backwards meant they walked forwards while sliding back. Walking sideways meant essentially the same. And dodging turned into a weird spin and roll away before snapping back to the enemy. So a new set of animations had to be implemented for side stepping and walking backwards, as well as a backwards dodge. Ideally there also would have been sideways dodging, but no animations for such a thing existed on Mixamo.

Finally was adding Oliver's work in creating a random item dropper onto the enemy to be triggered upon death. Implementing it was nice and easy, he did a wonderful job of commenting on his script and making it scalable. The only adjustments I had to make was to have the dropped item become it's own parent to avoid it being destroyed with the dead enemy; as well as changing it's scale to the prefabs original size rather than the scale matching the dead enemy's.