RUSHDOWN

Rushdown is a game I made for the final semester of my first year of university. It is heavily inspired by SIFU, as well as some smaller inspirations from Insomniac's Spiderman.

Beat-em-up

May 2025

I created a hand-to-hand combat system based on SIFU’s that implemented combos (combinations of light and heavy attacks); special moves and finishers with dynamic camera movement; command attacks that take multiple inputs to execute; and structure – the resource that allows for blocking – opening up enemies to finishers when it runs out.

I also created AI that use the same combat system as the player, with the limitation that they only have access to regular combos. They are also built to attack the player one at a time to avoid overwhelming them.

Other features I created included the UI and minor VFX.

The current combo is tracked as a string of Ls and Hs – light and heavy attacks – with new characters appended to the string on each input. All the different combos and their relevant animations are stored in a data table. Since combos branch out from each other (LLLLL and LLLHH are the same until the first H), finding the next animation for the current combo is done by searching the data table for the first matching string. If no matching string is found, then the combo is reset.

Special moves are selected using a wheel. The point on the wheel is selected by moving the mouse in the direction of the point relative to the centre of the wheel. If the player has enough of the relevant resource, the attack will play alongside a level sequencer, which takes control of the camera to move it dynamically.

When an enemy is vulnerable to finishers, a button prompt appears; pressing it starts a random finisher. Like the special moves, the sequencer controls the camera.

Command attacks don’t take resources like special moves, but they differ from regular attacks as they have no effect on combos. They use Unreal’s combo inputs to take either a sequence or multiple simultaneous inputs to fire.

The AI are built around four states: Out of combat, for when the player hasn’t reached their encounter yet; passive, for when it isn’t their turn to attack; aggressive, for when they are attacking the player; and defensive, for defending themselves from a player’s attacks. Each encounter has a manager that coordinates the AI, deciding which one is attacking.

The combat system was implemented as a component, which was helpful since I wasn’t copying code between the AI and player, but my implementation meant I had to specify in many areas whether an object was a player or AI. Instead, I think it would have been more beneficial for the player and the AI to share a common parent that contained the combat logic.

I would also prefer to have the movement towards enemies when attacking handled by root motion within the animations, rather than motion warping. However, this was out of my control since the animations were sourced from Mixamo.

Changing how hitstop is implemented is also something I would look into. The current implementation uses a quick change in time dilation, which causes an issue where ragdolled enemies get flung by the physics engine overcompensating when trying to keep up with the change.