After having made a start on it last week, this week I continued developing the game’s combat system.
Enemy Health & Locks
Now that the player could use some basic attacks, the next priority was implementing some health for the enemies and setting the foundation for the lock system.
While we hadn’t decided how exactly we would be displaying enemy health information to the player yet, for testing purposes I added a simple health-bar widget above each enemy’s head. I also made a similar widget for displaying any locks the enemy currently has attached to them.
Since each lock would need to trigger its own unique effect when broken, I decided to implement them as Actor Component blueprints. This way, I have the freedom to use whatever scripting is necessary for each effect while keeping everything encapsulated.
The blueprint for the base Lock Component is itself very simple, only containing a “BreakLock” event, an overridable function for each lock’s unique effect, and an event dispatcher to update UI etc.
From the player character’s side, all that needs to be done is check for any Lock components attached to a target enemy actor, and then call the “BreakLock” event on the first one found.
You can see this in action in the video below, with the prototype for an expanding AOE lock effect:
Player Attack Changes
In our original group discussions on combat design, we had planned to give the player multiple weapons to switch between, such as an axe or a bow weapon. This week, after looking at the animation work this would require, we decided to go with the simpler idea of having one weapon that could perform either light or heavy attacks.
To get this working in Unreal, I had to rewrite a lot of the existing system to allow for multiple types of attack input and properly connecting attacks in combos.
Instead of having attack combos hard-coded into the blueprints, the system is now fully driven by data tables containing each attack’s info. It also allows for as many attack inputs as we end up needing in the future.
With this in place, I added a basic heavy-attack:
Auto-target Indicator
One of the features I added last week was automatically rotating the player to face their nearest target when attacking. Building off of that, I wanted to create a visual indicator of which enemy is currently their nearest target, so the player has some way of knowing in advance which enemy they’ll be attacking.
Getting this working involved two blueprints, a simple screen-space widget, and an Actor Component that tracks enemies within a certain radius.
On top of the regular auto-targeting functionality, I also added a “lock-on” feature to the component. Once a target has been locked-on, it will remain the current target regardless of distance or other nearby enemies being closer. The UI indicator also updates its appearance to reflect this.