Week 5 - First Visual

In preparation for the first playable build this weekend, I worked on getting the player character to a state where we could start playtesting -- this meant finally implementing animations, health, and the timer.

I spend the majority of the week on implementing animations, as there were a lot of them and I needed to make sure they all transitioned to one another smoothly. One of the main issues I faced while implementing the animations was making sure they were all positioned correctly. Due to the huge variety of animations, and the varying sizes due to flame, cape, and attack effects, splitting up the sprites caused them all to have different pivot points. So when they were implemented initially, the sprites all moved around wildly.

For every single sprite, I had to manually set their pivot points to be pixel perfect, making sure nothing moved off by even a single pixel. This was quite a time-consuming process, though it was at least made easier by me being able to use the amulet on the character as a reference point.

Once animations were in, I adjusted the animation triggers and active frames of hitboxes for attacks and abilities, so that the effects of the actions matched what was happening in the animations. For example, for the attacks, I wouldn't set the hitbox to active until the first swipe. Or, for the fireball attack, the fireball wouldn't shoot out and the recoil wouldn't occur until the fireball is shot out. Once these were in, the player movement and abilities were finally fully complete and ready for testing.

Next, I implemented the health timer. Health was already implemented when I created the enemy/entity system for combat, but I hadn't implemented the timer yet. This was a simple addition, I created a time reduction rate variable in the player data scriptable object, and just counted down the health every frame according to the countdown rate. I set the rate to countdown from 100 to 0 HP in 10 minutes, though for the first playable I will be increasing this to be much faster.

One thing I realized I hadn't added yet was a way for the player to get damaged by the enemy. Since I haven't implemented enemy AI yet, I just added a function in the enemy script to damage the player if they came into contact with the enemy.

However there was an issue. In previous tests, whenever the player collided with the enemy, the enemy would get pushed back, as a result of using rigidbodies and box colliders. This isn't something we want for the final game. The solution was to implement layer-based collisions. Normally, the player and enemies are on their own respective layers. If the player collides with an enemy without layer-based collisions implemented, then they would apply forces on each other like regular physics objects. However, if I disable collisions between the enemy and player layers through the Physics2D collision matrix, then they won't apply forces on each other.

But, as collisions are ignored, they would have no way to detect if they collided with one another. So I created a separate layer called Hurtbox, and created a separate box collider as a child to the player, but set to the Hurtbox layer so that if it detects an enemy, it would apply the damage and knockback effects.

I also implemented a hit stop effect, similar to Hollow Knight, so that damage to the player feels more impactful. This is done by stopping time briefly whenever the player is hit, and then speeding it back up to normal after a short amount of time. With all of this implemented, the core player health and damage system was done.

This week's progress was slower than I had wanted. I also wanted to implement the upgrade screen, which I will be doing immediately at the start of the next week, but I wish I had been able to work on it sooner so I could move on to other features. The cause of this was the amount of time it took to implement animations. Going forward, I will try to ask Matt and Herman for animations that fit within certain bounds, though this will probably be very difficult while making them all look good. Considering the rest of the enemies and the boss don't have as many animations as the player does, it shouldn't be as big of an issue as it was for the player, but it being considered would be nice for efficiency. I also realized there were some bugs with the player attack animations after implementing them. The cause of them hasn't been identified yet, but I will be attempting to fix them alongside all the other bugs in the future.

From a managerial point, one issue I learned from Nathan was that having two different people do level design with completely different standards and then putting them together was very difficult for implementation. For the other three areas, I am going to have them do level design directly in Unity, which should be easier once Nathan finishes the level system. This way they can more quickly test and iterate level design so we can iterate prototypes much faster.

Until next time.