Devlog: Character Implementation

Hello! This is Will from Club Crash with another development log. My role in development is mainly focused on player character implementation: movement, animations, and attacks. With our goal of having four different playable characters, this can seem like a tall order at first. However, using object-oriented principles like inheritance and polymorphism, we can reuse code. 

In the early stages of development, there was a single implementation of a player, the PlayerBase. It housed everything related to the player, which was mostly movement controls at that point. It was our original plan to have each character type be a child of the PlayerBase, but because we only had one character in development, it wasn’t immediately clear what actually belonged in each derived class. When we started implementing the second character type, we recognized that some refactoring was necessary. 

I carved up the PlayerBase, making a separate component to house all universal input (e.g., moving, jumping) and created children of the PlayerBase for the different character types: Baker, Gardener, Roleplayer, and Scientist. Universal attributes such as health and stamina still live in the PlayerBase because those don’t depend on which character the player is playing as. When someone gets hit by another player, we can reduce the health of the actor who was hit without having to know which character they are playing. 

Each character also has their own component that derives from one of two attack bases depending on if they dual wield or have a single weapon. The Gardener and Roleplayer use a single two-handed weapon since all we need to check is if they have enough stamina to execute an attack as well as not already in the middle of attacking. The Baker and Scientist need more logic since they dual-wield weapons use them separately for their light attacks. 

Finally, each attack blueprint component holds a bit of code to create an instance of the attack’s hitbox. I originally had the player keep track of whether their hitbox was active, but that soon became a hassle when we started implementing heavy attacks because their hitbox is different. I have now created blueprints for each character’s attack hitbox that tracks who they hit, deal damage to hit players, and destroy themselves when their lifespan is up. This helps us follow the single responsibility possible.

That’s about it for the character implementation for now. We have visual improvements in the works for our characters now that they’ve all been implemented. The next step is making sure our characters feel unique while all being fun to play. That’s all I have for now; make sure to check back for our next development log!