This article introduces the development process of the student project "The Unfallens: Awakening" from October of last year to May of this year.
"The Unfallens: Awakening" is an action game that focuses on boss battles. It is also my graduation project for the Master's program in Entertainment Arts and Engineering at the University of Utah. Together with two of my classmates, we completed this project within six months. Additionally, we received support from two students at the Berklee College of Music for audio development.
The game has been freely released on Steam, and as of now, it has been downloaded approximately 50,000 times and played 8,000 times. It has received overwhelmingly positive feedback with a "Very Positive" rating based on 100 player reviews. For a student project, I believe this is a commendable achievement.
Origin: Combat
In the beginning, I was the only developer for this project, and my vision for the gaming experience was a reactive action game with excellent combat mechanics. Therefore, all the focus was on the combat experience of the game. I aimed to achieve "AAA quality" with a "compact size," serving as a concept verification demo. As I mentioned in the first development log, I believed that the most feasible content scope to realize my idea was a boss battle similar to the ones seen in God of War 2018 with Valkyries. At that time, the design pillars of this project were only two:
Excellent control feel.
Exciting combat experience.
So, I began my development with a core focus on boss battles. In the end, the final product did indeed meet these two initial goals. In terms of combat design, it revolved around "reactive battles centered around player attack range and boss animation rhythms," successfully fulfilling these two objectives. I will elaborate on the specific details of how I achieved this in the following explanations.
And, the Valkyrie battles have another aspect of inspiration for developing student projects with unknown risks - the modular development approach. In the game, Valkyrie Queen serves as the leader of eight Valkyrie mini-bosses. These eight Valkyries share a consistent character skeleton, with some actions being similar across all characters, while others are unique to each one, highlighting their individuality. After challenging all eight Valkyries, players eventually face the Valkyrie Queen, whose action set includes all the unique moves of the other Valkyries. This development method allows for a highly "modular" approach, where the content can be developed to any extent, from a single mini-boss's action to the final boss containing the actions of all nine Valkyries, providing a great combat experience at any stage of development.
This flexible development scope is well-suited for student projects with significant uncertainties. My initial plan was to create at least three different mini-bosses and easily assemble a final boss with all their actions combined. However, spoiler alert, by the time of graduation, I only completed the action set for one mini-boss. Nevertheless, I still feel that it fulfills the purpose of creating a combat demo as I initially intended.
At the same time, the game's aesthetic theme was initially set as "Grim Reaper vs. Undead Abnormalities," which is why the protagonist's weapon was determined to be a scythe. This is also the origin of the project's early development codename, Code: Shinigami. For some of the conceptual designs in the early stages, you can refer to my zeroth development log.
Development: Framework
In the initial few weeks, the majority of my time was spent on building the framework for the combat system. At that point, I hadn't delved into the detailed design of the combat mechanics. I wanted to start by creating the framework and then decide on the subsequent design based on my implementation capabilities.
Instead of using any pre-existing complete combat framework or plugins, I chose to follow tutorials and build my combat framework code from scratch. I had several reasons for doing this: Firstly, I wanted to fully understand how a viable combat framework is constructed. Secondly, creating the entire framework by my own hands ensured that I could make feasible customized modifications later on. Additionally, this approach served as an opportunity to enhance my blueprint scripting skills.
The initial combat framework was quite simple and mainly consisted of the following elements, as taught in the tutorials:
Weapon Functionality: Players could acquire and equip/unequip weapons.
Combo Attack: When the player had a weapon equipped, they could perform combos by inputting a single attack command button consecutively.
Hit Reaction: When the player's weapon's collision hits an enemy, it triggered a hit reaction effect.
Dodge(Evasion): Players could input a dodging command button to perform the dodge action.
Initially, the combat framework did not employ any specific design patterns. Apart from the animation blueprint's locomotion, which used a state machine, the other functionalities such as attack actions, hit reactions, and dodging actions were manually managed through event-driven code logic, achieved by playing Animation Montages.
However, I made some modifications to the above systems. I aimed to enhance my combat framework in various aspects, ensuring it had the potential for perfection and provided a satisfying gameplay experience in terms of controls and responsiveness.
Combo input optimization:
Firstly, I introduced a response to the player's directional input during attack animations. In the initial frames of an attack animation, the character's orientation will be adjusted based on the direction the player inputs. This allows for orientation adjustments in each attack animation of the combo. I didn't want players to be overly concerned about their attack direction, similar to how it's done in Monster Hunter games. Therefore, I implemented a solution that allows for direction adjustments during each attack animation in the combo.
Additionally, I made some optimizations concerning interrupting and canceling animations during the combo. By default, when the player presses the attack button, an attack animation is triggered. If the player presses the attack button again while the attack animation is playing, without any intervention, it would immediately cancel and interrupt the previous attack animation, initiating the next attack animation in the combo. This would result in the player executing the combo too quickly and the animations appearing unnatural by being canceled so early.
To address this issue, I used animation notifies to set a specific timing window when players cannot cancel the current animation interrupted by a combo on each attack animation. This approach ensured that the player's input had a consistent fastest-possible effective canceling interval on each action of the combo, maintaining a stable rhythm for the attack animations. However, this method had its limitations. The player's effective input could only be slower than this threshold frame, with the actual effective input time being delayed by a random number of frames beyond the threshold. This meant that players couldn't achieve the fastest effective combo input by simple button mashing. I didn't intend for players to gain an advantage in executing the fastest combos through precise frame inputs, as that would make the controls overly difficult. To solve this problem, in the later stages of development, I introduced a command caching system. When the player inputs an attack command earlier than the allowed interrupt threshold, I would remember this input. Then, when the animation reached the point where the interruption was permitted, the attack command would be executed immediately, resulting in a combo. This allowed players to achieve the advantage of the fastest combos through simple button mashing.
However, there is room for improvement. Currently, for the convenience of implementation, all potential attack commands are saved if they happened during " the first frame of the animation to the allowed combo interruption threshold frame." This process seems too long, leading to some players' fast "double input" being considered as a valid combo input, resulting in two consecutive attacks. In reality, the players intentionally stop their key inputs around the combo interruption threshold, intending to perform only one attack. The current implementation misinterprets the players' intentions.
From a design perspective, the time allowed for combo command buffering should be "within the first X frames before the allowed combo interruption threshold." The value of X can be fine-tuned based on specific actions and the feel of controls, with the default APM (Actions Per Minute) resulting in X being approximately 5 to 6 frames. Despite the presence of dodge actions that can interrupt attack animations at any moment, the additional attack actions performed by players do not impose extra vulnerability. However, based on player feedback, it appears that players are not fully aware of this fact and feel risky when the second attack was launched. In conclusion, this issue needs to be addressed and modified.
Additionally, there is another bug that I intended to fix but haven't had the opportunity to address yet: When a player's attack command is buffered while in an attacking animation, and before this buffered command is executed in a combo, if the player interrupts the current attack animation with a dodging action, the buffered attack command will be still remembered and executed after the dodge. In a reactive combat experience, the priority of reactive actions should be significantly higher than that of active attack actions. Therefore, when the dodge command is successfully executed, the buffered attack command should be cleared.
In fact, this behavior was unexpected during the design phase, and it remains unaddressed in the code as it hasn't been debugged yet. I will fix it in the future.
Attacker Improvements:
At this stage, I have optimized the player's attack action by adding a trail VFX when swinging the weapon to clearly display the weapon's collision range. Additionally, when the player successfully hits any enemy, a hit VFX is played to provide feedback for successful hits. For the hit VFX, I used a placeholder effect from the UE5 Lyra project template, but I searched for other resources to update and improve it in the later development stage.
Hit Feedback Action Optimization:
In the initial framework, as there was no enemy AI, I focused on implementing the player's ability to attack and trigger hit reactions on enemies. For the hit reactions of enemies, I made them instantly turn towards the player when hit and then play a backward stunned animation. This is a simple hit feedback system that suffices for my current game.
Throughout the development process until the final product, due to the AI settings, the Boss faces the player most of the time, with the angle difference being less than ±45°. Hence, I didn't spend time creating more complex hit feedback action features, such as backstab reactions. However, if I decide to create more enemy types in the future, especially regular non-boss enemies, I believe implementing such features will become necessary.
Dodge (Evasion) Mechanic Optimization:
The dodge mechanic is designed to allow players to cancel attack animations at any moment by using the dodge action. This setup is inspired by the mechanics found in the God of War 2018. The main objective is to enable players to focus on reacting to enemy actions rather than having to consider the risk of committing to an attack before executing it. Since players can cancel their attacks with a dodge at any time, it creates a more user-friendly experience and raises the skill floor in terms of player control. Additionally, the ability to dodge at any moment provides players with more opportunities to find openings and perform well-timed attacks, elevating the skill ceiling in the game.
Animation, Distance, and Speed:
During the initial development of the basic combat framework, I chose the Twin Blades Bundle as the source of attack animations for the main character to meet the requirements of the scythe weapon's movements. This animation asset pack had a unique rigging structure where the weapon bones were attached to the UE Mannequin's IK bones, making retargeting inconvenient. Therefore, I decided not to make excessive modifications to these assets and directly used the distance and speed of these animations as my "Combat Metrics." The attack distance from this animation set served as a reference baseline for other spatial and temporal parameters in combat. As for speed and tempo, I found it relatively easy to adjust them, and I didn't entirely adopt the original animation's design. Instead, I developed my own frame data for the future.
In essence, during the early stages of the framework development, I deliberately focused on two points: "matching the forward-moving distance of attack animations with the backward-moving distance of hit reaction animations" and "ensuring that the interval between combo attack animations is smaller than or equal to the stun time of hit reaction animations." By meeting these two criteria, I could achieve a satisfying combo attack feel. Subsequently, the selection and modification of assets were all based on these two principles.
For more details of development during this stage, my development log #0 is for you.
Creative Character Design: BOSS Concept Design Document
After completing the initial framework, I gained great confidence in the project and began to work on the creative design. At this stage, the concept artist Yiyu Wang joined my team, and we decided to start the design with the main character and BOSS roles. We had multiple in-depth discussions and I listened to her suggestions. We decided to retain the idea of Grim Reaper vs. Undead Abnormalities in the worldview but left other aspects for her to freely explore. From a combat perspective, I provided two suggestions - both characters should have more flowing fabric or dynamic textures to showcase a sense of movement during battles, and extra attention should be given to the appearance from behind for the main character since the game is in third-person perspective, and players will often view the protagonist from that angle.
In the end, using Pinterest, we searched for a large number of reference images together and after confirming mutual agreement on the ideas, I created a character art requirement document on Miro.
Below are the Pinterest boards I used for reference images and the character art design document we worked on at that time.
A few days later, the talented Yiyu completed the first version of the BOSS concept design sketch, and I was pleasantly surprised with the result. Based on this sketch, my suggestion was to exaggerate the arm blades, making them the primary method of combat for the BOSS. Yiyu then proceeded to further refine the concept design based on this initial sketch.
Finally, Yiyu quickly completed the final version of the formal BOSS concept design, along with the three-view drawings based on the basic model. After this, Technical Artist Zeshi Chen joined our team, and he began the modeling and rigging work based on these designs.
Next, Yiyu was busy with several other projects, so the concept design for the main character would not be completed until a long time later. However, this did not affect the ongoing development of the combat framework and Zeshi's work on the BOSS modeling. Therefore, in the project planning, we agreed to wait for Yiyu until she has time to work on the concept design for the main character. This kind of uncertainty in the availability of development team members is a unique characteristic of student projects, isn't it?
Creative Combat Design: Modular Combat Design for BOSS
After Yiyu completed the BOSS concept design sketch, it immediately inspired me on how to design the combat to meet the "modular" development mode. The solution I came up with is to allow the BOSS's arms to transform, with different shapes representing different modes, each having its unique set of actions, such as melee mode, ranged mode, and defense mode. For mini-bosses, their arms may have only one mode each, or a few, like two or three modes, while the final BOSS would have all the modes' moves at its disposal.
The BOSS can actively switch between different modes using special moves, making it easier for players to distinguish and predict various actions, and memorize how to deal with each move. Alternatively, the BOSS could directly switch arm modes and execute a variation of attack moves, requiring players to pay close attention to and differentiate the BOSS's arm mode, further reducing the predictability of its actions. Technically, we can use the Blendshape method to achieve the arm transformation appearance.
As for the player's set of actions, because I aim to prioritize a reactive combat experience, I designed them based on the BOSS's actions. Following the complete BOSS design document, the player's actions include basic attack combos, dodging, blocking, and parrying. Additionally, I also considered incorporating ranged attacks and special big move attacks to provide players with a more diverse and engaging combat experience.
In the complete document, I have designed concepts for eight different arm combat modes. While I initially anticipated that it would not be possible to develop all of them, I believe this design document is still quite intriguing as a combat concept.
In the above document, only the actions for the Arm Blade mode and some actions for the Tri-blade mode were eventually implemented. For the player side, only the dodging mechanic was implemented, and blocking was not. The main reason for the difficulty in implementing more actions and features for other modes was the lack of animation assets. As we didn't have a dedicated animator to create assets, we had to rely on third-party assets from the marketplace, which came with significant limitations.
After completing the basic mode design, I showed Yi Yu the concept design documents for the different combat modes, and she found them to be very intriguing. As a result, she completed the visual concept designs for each arm mode. (Click the images below to view them in full size.)
The fascinating visual concept designs created by Yi Yu are so captivating, no matter how many times I look at them. Even though we haven't been able to fully realize these designs yet, I would love the opportunity to turn all of these concepts into playable games if given the chance in the future.
Rigging
(Being updated)
State Mode
(Being updated)
Full Combat System
(Being updated)
Comments