This two weeks, my main task was to complete the blueprint scripting for the gargoyle enemy. Before writing the blueprint, I first needed to finish the animation assets for the gargoyle. I created new folders to better manage them, which are: attack animations, hit animations, death animations, idle, and walk animations.
Below is a video showing my full workflow：
In this process, I first download suitable animation assets from the Mixamo platform and import them into UE5. Inside UE5, I use animation retargeting to transfer these motions onto my gargoyle asset.
Inside UE5, I use animation retargeting to transfer these motions onto my gargoyle asset.
However, I encountered a serious issue: the gargoyle’s neck bone gets distorted after being imported into UE5, even though this problem does not exist at all in Maya.
This distortion also affected my plan to implement the gargoyle’s flying chase behavior later on, and I eventually had to abandon it because the twisted neck bone made the animation unusable. I suspect this is due to some problematic in-between bones in the neck hierarchy.
As a result, if I apply the retargeted animation directly, the gargoyle’s head flies off unnaturally.
To fix this, I export the retargeted FBX from UE, adjust the neck joints by rotating them properly in Maya, bake the keyframes there, and then export the corrected FBX back into UE5. I also added some additional movement details to the wings and arms, and removed unnecessary keyframes to make the animation cleaner and more efficient.
This whole process was actually much more exhausting than writing the blueprint itself because I had to constantly export and import files between two different software. Also, since the gargoyle’s running animation looked rather awkward and lacked a sense of threat, I ultimately decided not to use the running animation asset in the final version of game：
Write gargoyle blueprints
The blueprint for the gargoyle is almost the same as the one for the zombie, except for the different animation assets and animation blueprint. However, due to the different attack hit detection, I will rewrite its blueprint from scratch：
While debugging the gargoyle enemy’s death blueprint, I met a tricky problem. My original plan was to have the enemy play a death animation first, and then switch to simulate physics so the body could fall naturally. However, in practice, this caused major issues. Even after the animation finished playing, the gargoyle would still retain its previous AI logic. It continued executing its “AI Move To” behavior and kept rotating to face the player:
I tried many solutions, such as forcefully disabling the AI Controller, disconnecting the movement logic in the Blueprint, and even delaying the state transition. But none of them worked well. The gargoyle always ended up in a weird “half-dead” state where its AI was still running, which clearly wasn’t right.
In the end, I decided to abandon the death animation altogether. When the gargoyle’s health reaches zero, I immediately enable simulate physics and turn it into a static mesh. It then collapses naturally, and I set it to be destroyed after 10 seconds. Although this skips the animation transition, the enemy now falls quickly and smoothly, avoiding all those awkward leftover AI behaviors. In fact, the overall effect feels more natural this way.
This reminded me that many games actually handle enemy deaths like this. In several games I’ve played, enemies don’t bother with long death animations—they just drop instantly, with ragdoll physics handling the fall. Boss fights are a bit different, often featuring dedicated death animations, but even then the corpses usually disappear quickly, often accompanied by some kind of special effect.
With that comparison in mind, I think my current approach is a reasonable one. For regular enemies, keeping the combat flow smooth is more important than playing a full death animation. And since the gargoyle is just a basic dungeon enemy in this case, there’s no need to spend extra resources on its death presentation.
Even though I had to let go of my original plan, I’m actually quite happy with how it turned out. In game development, we often have to balance ideal designs with practical realities.