Week 3 - Setup

This week was a very design-centric week, both for fleshing out concepts and designing the game's architecture. I focused on designing the final boss; its appearance and its moveset and animations, and then started implementing combat by setting up the hitbox system and enemy core.

Last week I ended things by coming up with one final boss concept sketch.

I mentioned how I felt this was too derivative of Hollow Knight and didn't really follow the design language of the player character very well. So I endeavored to come up with at least three more designs.

I used an AI prompt to come up with inspiration for the final boss design, though I ultimately never really stuck with any of them. Regardless, here are a couple that were generated using the prompt "The Ashen Vessel, dark fantasy, wielder of the flame."

From the initial sketch, I really liked the idea of giving the final boss a hammer, and the flame coming out of the mask was to keep it consistent with the player character's design, so those were the only two elements I kept consistent. I came up with three more designs.

We liked the third design the most as it felt the most imposing, so I took that design and reworked it somewhat to come up with the final concept sketch.

I wanted it to feel like a mix of Hollow Knight and Dark Souls boss design, while still having its own identity that fit thematically with our game.

Using this design, I then designed the boss' attacks based on its appearance. I wanted it to feel dynamic but powerful, so I came up with a mix of melee attacks using the hammer, and projectile attacks to keep the player spaced out a bit.

I drew the two key poses for each of the melee attacks so Matt and Herman would have a better idea of how to animate the final boss when it came time to. These melee attacks are supposed to highlight the raw power of the final boss, as it'd have to be very powerful to wield a hammer as big as this. I also incorporated shockwaves to the two attacks that hit the ground to highlight the sheer force, and also to act as an additional obstacle when avoiding these attacks.

The ranged attacks needed fire as a base. Flame Pillars was similar to one of the basic enemy attacks from the final area of the map, in which pillars rose up after the enemy swung down. This way, the player has some way to prepare for this attack, or at least they would already know how to avoid it. The fireballs with their slight homing pattern was inspired by the Nightmare King Grimm fight from Hollow Knight, in which he shoots bats that also slightly home in on the player, meaning they have to precisely avoid the attacks in order to not get hit. Overall these attacks should create for a very dynamic and challenging final boss for the player to overcome.

For one "ultimate" attack, once the boss' health reaches a certain point (I listed 25% here but that could change,) I created a sequence in which the boss would rise up to the middle of the stage, and let forth a burst of energy, creating a bullet hell-like sequence the player has to dodge, before striking the ground with his hammer, causing flame pillars to rise in sequence. The purpose of this is to act as an indicator that the player has almost defeated the boss, and also serves as a test of skill in avoiding the boss' attacks thus far. It should feel big and satisfying once the player reaches this point in the fight.

After designing the boss fight, I started to implement combat features, starting with the hitboxes. I used Unity's animator to set the hitbox to active or inactive without requiring any code, which allows us to very easily create frame data for active hitbox frames, to balance the attacks around.

Before implementing the hitbox logic, I needed an enemy to create hitbox logic for. So I created a basic enemy template. However, I needed this enemy template to easily create the final enemies off of, so I based its architecture off the player's finite state machine, but allowing for inheritance to create individual enemy classes from the base enemy class. In the future, since the enemy and player share a lot of the same logic, it could be possible to refactor the code so that both the player and enemy pull from the same base class, but it is not important for now.

The protected virtual functions can be called by the child classes of the base enemy class.

I also created a Unity scriptable object to store combat data, including damage values and health. This is so that I do not need to define each individual variable for both the player and the enemies, and can just create customizable scriptable objects that can be called by each base class.

This week's progress was slower than I expected because I ended up having more assignments and engagements to do than I anticipated, so I did not manage to implement the full combat mechanics like I had initially hoped. However, I do feel as if I created a good core for those mechanics, which should make them easier to implement in the coming weeks. I also realized, looking at how I scheduled things for the Trello, that I expected everything to be completed too quickly, as I didn't take into account how much work the others would have. When I came up with the Trello schedule, I allowed for some flexibility by setting the entire month of November to be relatively empty. I started pushing back some tasks by a few days to a couple of weeks so we actually have the time to meet the soft deadlines, however we should still be on track to complete the game in good time. The biggest time sinks for our game will be the art, so delaying the development tasks that myself and Nathan have should not impact things too much.

Until next time.