Project Slasher
Project Slasher is a First person action platformer game inspired from Ghostrunner. The level inspiration for us came from the movie Tron:legacy.
Traverse the environment by using different abilities like Wall running , Wall Jumping, Dashing and the grapple hook.
Slash through enemies using raw movement or by using Shadow Strike which allows you to teleport and instantly kill enemies.
This project was made with an aim of learning combat , movements , AI and general gameplay design.
Concept
Role | Combat and Enemy Designer
Genre | Action Platformer
Team Size | 2
Download | Link
Duration | 4 weeks
Engine | Unreal Engine
-
Designed and implemented melee combat, animations and 3Cs.
-
Implemented different archetypes of enemies using Behaviour trees.
-
Took ownership of Combat and Enemy design.
-
Designed and implemented the Shadow Strike system used by the player to slow down time and instantly teleport to enemies and slash them.
-
Took ownership of player movements and controls and implemented movement abilities namely Dashing, Wall Jumping/Running.
Responsibilities:
My Design Workflow
Combat Design
For the combat we wanted to make a fast paced action combat system inspired by Ghostrunner. We wanted the players to be in a flow state and slash through enemies without disturbing their momentum. But I also wanted to add a high risk high reward style of gameplay, which meant that the player can die by a single bullet by the enemy.
This meant that players would have to be careful as well and be cautious around the map and use all the arsenal they have been given effectively.
In addition with having normal attacks in our game the goal was to try to give the player an additional execution attack which we labelled as the Shadow strike attack. The Shadow Strike attack lets the player slow down time while locking on an enemy and then instantly teleporting to them and executing them. I wanted to combine this system with traversal mechanics such as wall running/jumping, grappling and dashing.
For the combat system, I wanted the players to utilize both basic attacks as well as a finisher system (the above-mentioned Shadow Strike Attack). To facilitate this we integrated it into the overall resource system, using basic attacks as a Builder and the finisher as one form of Spender.
Reason for designing this system:
-
We wanted the player to experience the high octane action combined with swift movement and a flow state where they would be zoned in to kill the enemies.
-
We did not wanted the players to not have the freedom of doing normal attacks. So then I decided to implement a 3 combo slash attack and then pair that up with the Shadow strike.
I wanted to challenge myself in doing this system as I was always working on fast paced combat and the feedback I would get would be for a flashy swift execution attack or a fast attack in general.
I had to divide the system into two parts, One was the regular combat and the other was how the flow would work for the execution system.
Slowing Down Time
For Slowing down time, I used time dilation function which marks the first step of using the execution system
Design Problems:
-
No stopping/limiting the slowdown mode.
-
Balancing resource? As important as it was to have a threshold on the resource, it was important that it should recover at a good pace as well otherwise the players won't even be able to use it.
Solutions:
-
The solution was to implement a energy system or a simple mana system. This system made sure that the slowdown will only work above a specific threshold and cannot be used to exploit in the game.
-
Added auto regeneration on mana but also added a slight recovery whenever the player kills the enemy. This gave the risk reward state in the game , where every kill rewards you with a bit of mana so that you can keep track on when you can use the execution system.
Detecting Enemies
For detection I added a normal sphere trace for aiming at the enemy.
Now why did I use sphere trace?
-
The radius of the sphere trace made it easier for the player to detect other enemies in their range when they move their mouse.
-
The radius will also give a leverage to the players while traversing and aiming at the enemies.
Problems:
-
Multiple enemies were not getting detected while using the trace.
-
No feedback when trace hits/ no cue for player to know if he has locked in on the enemies
Solutions:
-
Switching the detection trace to be in event tick solved the single detection problem.
-
Now, using tick means affecting performance, adding a bool check that only sets to true when the input action is pressed allows tick to only fire when the bool is true.
-
For actual visual feedback on if the player has aimed on the enemy, I made a simple overlay that activates when the trace hits.
Execution System
The idea behind the execution system was simple , teleport the player to the enemy in an instant and kill/execute them.
Steps for activating the execution attack:
-
First input activates the slow down and detection mode.
-
Second input is the attack which then activates the execution mode.
Steps of ability:
-
Trace for & Find Target
-
Verify Target requirements (Enemy view direction / etc)
-
Teleport player behind Enemy and perform Action
-
Provide player with feedback of action (blood splatter of confirmed kill / etc)
Technical Design:
-
To make the character smoothly teleport to the enemies location the use of motion warping worked which updates the character location using a target name and placing the a motion warp notify in the attack animation montage.
-
Now to determine if the enemy is looking at me or opposite of me I used the Dot product method to set the desired rotation and location of the player before the motion warp function.
-
Implementing a simple blood splatter UI which I animated and activated when the enemy is killed was a neat trick to let the player know he has confirmed the kill.
-
Also adding a audio cue of the enemy being executed was an additional improvement.
Prototype Stage
Combat Prototyping and Implementation
Lets now get into the nitty gritty of the system and how each part of the execution system works.
Enemy Detection modes
Slowing down time
Execution System
Final Stage
For making the enemies I studied how any fast paced games enemies behave. Played around some fast paced games like Doom and Ghostrunner.
Final design was that both the player and enemies will die by one shot , and then started creating some archetypes of enemies.
The enemies had to be responsive once they see the player other wise there would be no difficulty for the player to just swing through them. This meant more experimentation with both melee type and ranged type of enemies.
Enemy Design
Enemy Prototyping and Implementation
Melee Enemies
The first design in my mind was to create same archetypes as of the player which meant to have melee enemies.
Reason was to see how the same archetype as of the player would feel with the arsenal the player has.
We wanted to integrate a simple behaviour for the enemies which is shown below:
-
The melee enemies at first seemed fine , but after playing a bit it felt a lot easier and there was no challenge with them because of the fast paced nature of the game the player could easily get close and use the shadow strike to kill these enemies.
-
Noticed that with the movement of enemies they were lagging a bit before attacking or you can say there were no windows for the enemy to attack
-
Had to discard the idea of having melee enemies and change the archetype to ranged enemies.
While designing the Ranged enemies the first idea was to try having them surround the player and shoot . Using the EQS system in unreal to prototype the behavior seemed fruitful.
Here is the workflow made for the behaviour:
Ranged Enemies
Melee Enemies behaviour
Design Problem:
-
It felt slow from the get go. The enemies took a lot of time to get to a certain position to attack the player , which mean the players will get a big attack window and won't have to worry about being shot.
Solutions:
-
I had to come up with a good middle ground for the enemy behaviour and I created another set of behaviour but this time the enemies were made standstill , so no movement.
-
The perception system will detect the player and the enemies will have an instantaneous reaction when they see the player
First iteration of enemies using EQS
Prototype Stage
Final Stage
For the player movement we wanted to have a cohesion between the Combat system and the traversal mechanics.
In simple terms we did not want the momentum to break while doing any movement action or combining them with the attacks
Collaborating with my level designer we decided to go with a dash mechanic , wall running/jumping and a grapple hook mechanic.
These abilities went hand in hand with the combat and after repeated playtesting we managed to get the feel right for the movement as well.
Player Movement
Movement Prototypes and Implementation
Wall Running/Wall Jump
-
The Wall run/Wall jump mechanic were the crucial part of the game flow. It allows the player to find different ways to combine their direction of attacks based on where the enemies are placed.
-
We did not wanted the player to feel restrained with the level , so we approached on the decision to give the player free reign with this traversal technique.
Dash Mechanic
-
The Dash mechanic is a must have for a speed runner type of game. But we didn't want just a forward Dash for this game. I went ahead and researched some speed runner games and looked at how their Dash system worked. I ended up making a multi directional dash for the player.
Grappling Hook
-
The grappling hook was designed to not stop the momentum while traversing and as well giving the player multiple options to choose from even while using the Shadow Strike.
Learnings & Conclusions
-
This project helped me learn a lot about system design. Particularly combat , animations , AI and general gameplay systems.
-
Day by Day we went back to the drawing board and saw what features would fit our design goals. Would people have fun playing it, was the aim for us from the start.
-
This project also taught me to be ambitious, go for something you really want to create even if it feels tough.
-
I learnt to remove or cut system if they did not go together in the game, it was very hard to remove them but if they did not make sense there was no point in keeping them. Some of the cuts were sentry turrets, blocking bullets , enemy teleporting.
-
I had so much fun doing rapid prototyping which helped my teammate see the vision more clearer and easy to understand.
-
Playtesting is a very important part in making any game shine.
-
I will someday comeback to this project and add improvements , but for now I will keep it as it is and take all the learnings to my next projects.
Thank you for reading!