Recently I’ve been prototyping a timed hits RPG. It has no art, but it demonstrates the intended core mechanics quite well. Click here to play it.
This is a unique subgenre of the JRPG genre, so to help explain it I’ve embedded a video of one of the more refined examples made by Nintendo.
Combat in the game is turn-based and fairly standard for eastern role-playing games, but it has a unique twist. Each attack performed by the player or enemies has a quick-time event associated with it. The player can use well-timed button presses to increase the party’s damage, and also decrease the damage taken from enemy attacks.
Basic attacks only require a single button press, but special attacks can get extremely complex, as shown in the video. The action keeps the player engaged, and allows for a skill curve because optimal play preserves the player’s consumable healing and attack items.
While making the prototype in the Unity 3D Engine, I decided that hard-coding every attack would be a bad idea. Unity’s animation syatem wasn’t quite complex enough to handle the branching involved, and I wanted a workflow specific to building interactive attack events. This system also needed to work both ways, for both player skills and enemy skills. I had several ideas for attacks, such as:
- Ramming into the target, but bouncing off if blocked.
- Attacks that would be repeated until the player successfully blocked.
- A projectile attack with an animated crosshair to indicate when to press the button for the timed hit.
- Throwing a bomb at the player which they could block to bounce back and damage the enemy.
I decided to build a graphical system that could store complex attacks as prefabs and visually show attacks as branches.
Each node in this list is a GameObject with a script that stores the next items in the graph. Red connections are fired immediately, and blue connections are fired after the node’s action ends. The green and yellow connections fire in response to the player successfully pressing the button at the correct time. See this article for details on the system I based this on. The root is fired by the combat system, and it keeps track of all the active nodes in the graph. When all nodes are inactive, the combat resumes.
Having wrapped up the prototype, here are a few things I would like to have done better.
- I wanted to add another enemy that throws bombs at the player. With a successful timed block, the bomb would bounce back into the enemy and damage them. Implementing this would also have required me to add a few new node types to make spawned effects (seen in the player’s Wind Slash attack) more robust. I ran out of my time alotted for this project so I cut the feature.
- An attack that used UI elements would have been a good test for the prototype. Ideas included a ranged attack with a crosshair moving over the target, and an attack where a falling object is “caught” (or, rather, sliced in half) by the timed hit button press.
- The overworld movement controls are not nearly as tight as I would like them to be. I spent a lot of time fiddling with them before I figured out that Unity’s physics material already did what I wanted to do. I would probably scrap and rewrite the character controller.
- Characters do not react to being hit. Some particle effects and a small animated knockback would have helped “sell” the hits better.
- A move node for making an enemy walk at a set speed (rather than specifying a number of frames and lerping them to their target) would make rows of enemies walk up to the player to attack much more convincingly.
- I wanted to add a couple more characters to the player’s party. This was not that necessary for the prototype to prove that the core gameplay works, and I would rather start making art assets than add that feature.