Third Person Combat Demo

Platform: PC

Engine Used: Unreal Engine

Team Size: 4

Role: Designer, Engineer

Overview

Arena is a combat prototype that includes a player character using a big sword and two different types of enemies. In this project, I am mainly responsible for the player character. Including the character's movement, jumping, dodging, perfect dodging, locking, normal attacks, normal skills, ultimate skills, etc. I designed and produced different effects for these abilities, and processed their transition logic through the GAS framework. The following is my development process:

Week 1

This week, we decided on our game's genre and the combat system. We want to make a third-person action game. The main combat loop of the game will be to use normal attacks to accumulate energy to use skills. In addition, we also discussed the perspective, camera, lock, dodge, and potential VFX of the game and had a preliminary plan. These plans may change at any time during the production process, but they can help us better understand our game framework.

During the production stage, we implemented the character's Run, Sprint, and Jump. The beginning of Sprint will be a Dash. It will be the Dodge action of our game, and the player will be invincible at this time. In addition, I also implement animations for run and jump. Sprint state does not have animation yet, but we will add it in the future.

Week2

In the discussion part, since we are going to use GAS to store the attributes of the Actor in our game, we first need to identify all potential attributes. We made a table to record all the attributes that may exist in our game.

 In the production part, as an engineer, I mainly completed two parts of work this week. The first is to replace the animation assets. The attack action of our previous assets does not have root motion, which does not meet our expectations. We reselected the attack animation with root motion and replaced it. In addition, I modified the logic of Dash in our game. The previous Dash was made using the Character Movement component, but this may not match the animation effect. I replaced it with a montage containing root motion. The other part is that I used GAS to configure the attributes for the player and enemy characters and made the damage of the attack. Furthermore, I used the Motion Warping plugin to create an attack-targeting effect, ensuring that players attack the closest enemy.

 

Week3

In the discussion part, we had an in-depth discussion regarding the trigger conditions and status requirements for character skills, as well as the various enemy types within the game.

In the production part, I reworked the character's blueprint.
I watched this video.

Through this video, I learned more about the GAS tag. I used GAS Tag to replace a lot of Boolean values in our game before and reworked all player behaviors except the camera into game ability.

Now it looks like this:

This is the previous Dash check:

Obviously, GAS is a more convenient method for management and later maintenance. I no longer need to modify the previous branch nodes; I only need to add new tags. This is more in line with the open-closed principle.

Week4

In this week's development, I have mainly completed three tasks. First, based on the feedback from last week's play test, I modified the interruption logic between actions. Now if the player continues to hold down the forward key during the dash, the dash action will be interrupted in advance, instead of waiting until the action ends to enter the sprint state. This modification makes the actions smoother and more coherent. Second, I added a new attack method. In addition to the normal attack of continuous clicking, our character now has a new charge attack of long pressing the attack key. Third, I did some research on the Game effect execution classification class and wrote a simple script. Now the damage judgment of our game can be dynamically changed according to the current tags on the player and the target.

Week5

This week, I mainly completed the following work.
First, the character's movement. I used animation notifications to add footsteps. This animation notification will detect the ground, and footsteps for different materials can be added in the future. In addition, I added a special effect when sprinting.

Second, I added some polish to the character's guard state. When the current defense is successful, the character will play a successful defense animation with corresponding SFX and VFX.

Guard State:

Finally, I changed the character's attack detection from using overlap collision to using ray trace, which can help us effectively obtain the hit position so as to better add VFX when the attack hits. Additionally, I added a motion blur effect to the attacks using the Post-Processing component. 

Week6

This week, I made the following improvements based on the feedback from playtests. First, lock. The previous lock is similar to the logic of Dark Souls. That is, the camera always locks the enemy in the center of the screen. However, according to the feedback from playtests, this lock method is not suitable for our game. Because the enemies in Dark Souls are generally larger than the player, there will be no situation where the player blocks the enemy, but the size of the enemies in our game is similar to the player, so if the player character locks the enemy head-on, it may block the enemy and affect the operation. The following is the old version of the demo:

Finally, we got inspiration from Ghost of Tsushima and Rise of the Ronin and changed the game's lock perspective to the side direction. That is when locked, the character is always on the left side of the screen, and the enemy is on the right side of the screen. We found that this not only avoids occlusion, but also strengthens the sense of confrontation in the game. The following is the new version of the demo:

In addition, another feedback we received was that the game's rolling and locking movement steps were a bit strange. Therefore, we separated the logic under normal and locked conditions. Currently, in normal conditions, the character rolls and rotates to the rolling angle immediately, and moves to the corresponding direction. In terms of animation, all animations are essentially forward. When locked, our movement and locking will be different animations in four directions. The following is a new version of the demo:

Week7

This week, I completed the ability to fire sword energy with normal attacks. This GA is based on a buff that lasts for 15 seconds. If the player holds this buff, they will fire additional sword energy with normal attacks. We hope to obtain this buff after using the ultimate skill, but our ultimate skill has not been completed yet, so I use the debug key to trigger this buff. My plan for next week is to improve the character further, add the ultimate skill, and improve the logic of being hit.

Week8

This week, I mainly implemented two UIs: the health bar based on the Enemy class and the UI that prompts the character to lock the target when locking.

Regarding the enemy health bar, I made a widget class and added a widget component to the Enemy base class character blueprint, which is then initialized at the start of the game and updated after each damage.

Regarding the lock UI, I also made a widget class and set it to be invisible by default. When the player uses the lock ability to lock a target, I will open this UI through the blueprint interface. When the locked target dies, or the player cancels the lock, this UI will be closed.

Week9

This week, I mainly completed the following three tasks.

First, I added damage detection to the sword energy I created last time. However, it currently only has damage detection without any hit effects; we will add those later.

Second, I added an SP gauge and an ultimate skill to the game. Players can gain SP from normal attacks and sword energy, and when the SP reaches 100, they can consume all of it to use the ultimate skill. After using the ultimate skill, for the next 15 seconds, each normal attack will additionally fire a sword energy. The ultimate skill currently lacks damage detection because we might modify the current animation in the future. In addition, we implemented an SP gain check for the sword energy because we want the initial activation to be slower, but once the ultimate skill is used once, its subsequent usage frequency will increase.

Finally, I developed a minor skill for the game that features two-stage attack detection. Each activation consumes one use. The skill starts with one use and can have a maximum of 3. If the current number of uses is less than 3, one use will be restored every 8 seconds. This design is intended to allow the skill to be effective early on, giving players a powerful attack option even before the ultimate skill is fully charged.

The current issue is that I haven’t created a UI for the ultimate skill and the minor skill, so their usage counts and current statuses are not very clear. I will complete these in next week’s iteration.

Week14

This week, I created a simple ability for our game. In our current design, the player's combo resets when they dodge, starting the attack sequence from the first strike. After acquiring this ability, the player retains their combo count for 1 second after dodging, allowing them to continue with the next attack in the sequence instead of restarting.

Week15

This week, I finished making the ultimate skill in the game. I used the level sequence made by Xiyuan. It provides a unique camera performance. I played a Gameplay Ability containing a montage after this camera performance as the actual animation of the move. There will be a unique camera performance, invincibility, and powerful damage during the ultimate skill. We hope to give this skill a unique performance and powerful power, so that players can release the emotions when accumulating SP energy and make them feel that the previous efforts are worthwhile.

However, this skill also encountered some problems. I tried to use Motion wrapping to ensure that the skill can hit the enemy, but this will cause the animation of the skill and the level sequence to be misaligned. I referred to the practices of some similar games, which usually give the ultimate skill a larger attack range to ensure that it can hit the player. This shows that we are not thoughtful enough in design, which is a good lesson for me.

Project Postmortem

All in all, the development of this project has been an invaluable experience for me. Throughout the process, I’ve learned a great deal about combat design—particularly in areas such as input buffering, ability chaining and transitions, priority handling between abilities, hit feedback optimization, and polishing skill presentation.

For example, regarding input buffering, I used to only understand it as storing the player's input during a specific animation window and transitioning to the next attack if the input was registered. But now, I have a much deeper understanding of how long the input buffer should last, how to define the transition window, and how to move into the next action smoothly.

These valuable experiences have significantly deepened my understanding of combat design, especially when it comes to player character mechanics, and have further strengthened my desire to become a combat designer. I will apply the lessons learned from this project, reflect on areas that need improvement, and continue to hone my skills in combat design and implementation—striving to create smoother, more impactful, and truly enjoyable combat experiences for players in future projects.