Dialogue System Rewrite
In anticipation of upcoming level / narrative changes, I wanted to have a safer / more robust way of storing dialogue. Up until now, dialogue was entirely written out in each controller actor across the level, which often made it hard to find a particular line to change etc. It also had the risk of losing dialogue if an actor was deleted.
The way the current dialogue struct was set up was also a bit unintuitive to enter data into, with quite a few occasions were lines ended up being displayed alongside the wrong character portrait etc.
I decided that a better approach would be to store the data for dialogue in one large Data Table. Instead of containing all of the data themselves, the dialogue controllers throughout the level now reference the row names of their starting and ending panels, and will increment through them.
I also took the opportunity to simplify the dialogue struct, using a single multi-line text variable instead of the previous 6 (one for each line).
Combat Changes
I also spent some time this week making changes and additions to the combat system.
Firstly, I wanted to give the player some more options in their attack combos, so I designed and implemented a new combo attack, a "Spin Uppercut". The player character spins into the air, launching any nearby enemies with them. From here, they can continue their combo with some air attacks, eventually launching their target away with a finisher.
The player can perform this by pressing the heavy-attack input after the first or second attack in the light-attack combo, or in terms of inputs: LMB + RMB, or LMB + LMB + RMB
The idea was to give the player more control over the positioning of enemies, allowing them to single-out certain targets and separate them from the crowd. The decision is now between a longer single-target combo into the air, or a shorter one on the ground that will likely hit multiple-targets.
Another change I made was to the lock-breaking ability. Previously this was a Wolf-Ability, requiring Yin to be summoned in to break the current target's lock. In practice, I was unhappy with how this version of the ability worked:
I didn't want the ability to require any energy meter, but this made it inconsistent with the rest of the wolf-abilities.
There was very little impact or feeling of weight, no connection between the action and result.
The lack of physical connection in the action made it feel awkward and strange when targeting an enemy to use the ability on.
That last point is hard to describe, but with melee attacks, the player tends to naturally be moving the stick in the direction of their target, so the auto-target matches up without much thought. However, the lack of physical connection in this action meant that players would often stand back from the enemy and try to manually line-up the auto-target. It's subtle, but slows the pace of combat down and felt awkward to use.
For these reasons, I decided to change the lock-break from a wolf-ability, to a regular action. The player now lunges forward toward a target, breaks their lock, and either leaps backward or remains in place depending on how the input was held.
Now that there was one less wolf-ability though, I decided to prototype an idea I had for a replacement:
Enemy Attack Manager
As mentioned in the previous blog, I had spent some time reading a chapter of Game AI Pro that described a particular approach to managing enemy attacks and positioning in combat. While I was unsure at first if it would be worth trying to implement a similar system in Unreal, I ultimately decided to go ahead and give it a shot.
After two weeks of work and so, so many bugs, I've ended up with a system that works as follows:
When approaching the player, enemies request a slot on the inner "grid" (or in this case, a circle). Each enemy has a grid "weight" of 2, which gets compared against the player's "grid capacity". If the total weight of all enemies currently assigned slots on the grid is already at the grid capacity, the new enemy will join a queue and wait until there is space.
When assigned a slot, enemies will move towards it and request permission to launch an attack at the player. Similar to the "grid capacity" concept, the circle also has a maximum "attack capacity", so only a certain number of attacks can occur at once. Again, enemies will join a queue to wait if they can't currently attack the player.
Any enemies that haven't been assigned slots on the grid, but are standing within the circle, will try and move out of it.
I ended up spending far more time getting this to work than I expected, and overall I'm not sure if the results were worth it. While it has made combat a lot more structured and controllable, I think enemies now almost feel too rigid and predictable. There are definitely additions I could make to partially fix this issue, some of which were outlined in Game AI Pro itself. However, at this point I'm reluctant to spend much more time on this system. There are a lot of other aspects of the game that have already been left behind quite a bit from the time I've already spent on this, so I don't think it would be wise to continue anymore.
Reducing Scope
With under 3 weeks left before the project's deadline, our team decided that we would need to drastically reduce the scope of what was left to do.
In a meeting, we went over a list of certain features that were left to implement and tried to come to a decision on whether or not they should be kept or cut.
There are still a few features that we didn't reach a decision on, and whether they make it into the game will depend on how much work gets done in the next week or so. In hindsight, I think I definitely overestimated the amount of work I could do in the project's timeframe.