Combat Feedback Changes
Based on a variety of feedback from this week's playtesting session, I made a number of small changes to the game's combat:
Dodging Through Enemies
Enemy Counter-attacks
Extended Attack Combo
Forest Section Blockout
Another decision we made after the playtesting session was to make it a priority to design a proper starting section to teach the game's mechanics to the player.
Since the team's main level and narrative designer was already busy working on blocking-out the town section of the level, I took on the task of designing and blocking-out the new beginning section.
As a way of teaching the player the basics of attacking, I decided to block the player's path with some obstacles they would have to break with their attacks.
Finite State Machine
Due to the increasing number of different abilities and states the player character needed, the blueprints for the player logic were becoming more and more messy and hard to manage. For every ability, several boolean variables were required to keep track of when it was active, and if other abilities could be used at the same time.
For example, in the Jump event, before the jump function can be called we first have to manually check the booleans of every other ability to see if any are active that prevent jumping. The same type of checks have to be performed before every other ability as well, and any time a new ability is added, all of these must be updated.
I did some research to find better solutions for managing this situation, and found some resources on the “State” design pattern: https://gameprogrammingpatterns.com/state
This would suggest using a “Finite State Machine”, where player logic would be encapsulated into individual states objects that each handled their own logic.
For example, the player could have a locomotion state that allowed for moving, jumping, and handling inputs to transition to other states like an attacking state, dodging state etc. The advantage would be that neither the attacking state or dodging state would have to track whether the other was active or not, as there can only ever be one state active at a time.
Over the course of the week I moved the majority of existing logic for the player character into this state setup:
In future, this should make adding new types of player abilities a lot easier to manage, as I won't have to update any of the existing logic in other states to account for it.