In this 3rd-person action, snowboard shooter, perform Stylish tricks in the Alaskan mountains while gunning down enemies with an arsenal of ranged weaponry. Shred down the mountain on your snowboard to get a high score while competing against your friends!
Embedded Files
Role: Combat Designer
Genre: Action, Third-Person Shooter
Platform: Steam (31 May 2024)
Size: 12
Duration: 32 Weeks
Tools: Unreal Engine 5.3, Perforce
Unreal Engine 5.3
Gameplay
My Contributions
Shred Off's concept was presented by a team member and I got to work making prototypes to show off the synergy between snowboarding and shooting. This created the hook of our game: Snowboarding with guns! From this, we picked up this simple gameplay loop and added tricks.
After conception, I worked with programmers to focus on the combat. I created the designs of the enemies & weapons and balanced them according to encourage the synergy between tricks and snowboarding.
Weapon & Enemy Designs and balancing them to be fun and to make the player feel STYLISH & POWERFUL
Constant collaboration with Programming & Design to build towards a cool action game
Collaboration with Level Design on creating combat encounters
Ranking System at the end of levels to encourage replayability
Feedback Systems when the player gets shot and damaged through UI effects and camera effects
Takeaways
Design systems & mechanics with game-feel in mind from the start. It's cool if something is functional, but if I had set a higher priority on the juice, I would be able to elevate the quality of the game sooner rather than later.
Cooperation with programming is vital for getting features in and getting them iterated on. On this project I was not able to get my hands on many of the features implementation-wise because it was in C++, so I talked a lot with the programmers who worked on the weapons & enemies' functionality, and they were able to create tools that allowed me to tweak and rebalance these aspects.
Enemies
What
In Shred Off there are 4 enemy types: Sniper, Gunner, Molotov Chucker & Snowmobile.
With programming, I discussed and drafted up behaviour for these enemies. I used Confluence to document the behaviour of these enemies so that my programming teammates could implement their behaviour.
Shred Off has a token system I was able to balance with. This controlled the amount of enemies that can actively attack.
Sniper: Stationary Enemy, shows a laser sight to the player and predicts where they go before locking in their aim direction and shooting.
Gunner: Moving enemy that snowboards around just like the player and they have a gun. They shoot a bunch with intentional misses to indicate to the player they're getting attacked by this instance of a gunner, and
This is canon fodder for the player that allows them to increase their combo multiplier per kill. They only become trouble if you let them group up
Molotov Chucker: These enemies, like the sniper, predict where you're going based on your speed * and direction. They show their Molotov and then throw it to the predicted location. You as the player need to shoot them before they throw it, otherwise you would need to move around.
Snowmobile: This enemy is the one that heavily challenges the player. Snowmobiles try to run over the player constantly by charging head-first into them with their saw blades. They have a lot of health and are the main foil to your path.
As a player, you need to spend the majority of your ammo on this to take this one down fast. It challenges the player's positioning, and their distribution skill with ammo.
How
I made the feature specs/technical design documents with the team's AI programmers.
It required discussions and feedback to nail down what was needed.
These feature specs are afterwards documented where I provide:
the context,
design summary
intended experience
flow diagram showcasing a step-by-step insight into the enemies' behaviour loop.
Why
Why did I make these feature specs? It's basically a collaborative plan or a mini-blueprint!
When working on a big, year-long project it is not feasible to keep all ideas and intents in your mind. This is doubly worse when you work on something together and hope to be in sync a day, a week or even a month later.
These types of documents help with collaboration, remembering what we started from and what the original intent was, and referring to it when working on the feature.
Lastly, making these feature specs for weapons also allowed me to get feedback very early on, questions could be asked or pitfalls I managed to avoid by just talking to people in my team about certain weapons.
Weapons
What
For Shred Off, the player can access 5 weapons: The Revolver, Lightning Gun, Mini-gun, SMG & Rocket Launcher.
I've designed feature specifications/technical design documents for these weapons on Confluence to get feedback and discuss feasibility with programmers, and the plan to get these weapons implemented into the game.
After the weapon gets fully implemented I get to balance this until it's just right by tweaking the damage, ammo, magazine size and fire rate.
These weapons are meant to evoke the feeling of being powerful while not being overpowered to provide a challenge to the player and to be able to strategise with their combos.
Every weapon, aside from the Revolver, is a pick-up that lets you swap to a new weapon.
Revolver: Standard, the player has by default. This gives the feeling you can easily overpower a single enemy, but you can't take on groups with this gun.
SMG: A fast-firing weapon with bullets that can track and home into their target. It's powerful due to its tracking so ammo for it is limited.
Mini-gun: An even faster-firing weapon with a ton of ammo but no tracking. It's fast and if you're not careful you could expend all your ammo before you know it. The trick on this weapon is to use it sparingly at close range to disseminate anything in your path.
Lightning-gun: A low-damage big AOE type of weapon. Its lightning can chain to different enemies from each other.
How
How I made these feature specifications by providing the context, in what scenario the player would encounter this feature, how they would acquire it or what the severity of this weapon is. It's very similar to what I did for the enemies' documentation & collaboration.
Then I give the specifications of the weapon itself. This step is important because it can give details on what exactly values need to be there, like max ammo, magazine ammo, type of projectile to be fired and if it needs a special feature.
Then I state the design intent, the feeling I want to evoke from the player and describe the intended experience.
After the vital systems are implemented and playtested, I get in there and mess around with damage numbers, ammo, projectile speed etc. to iterate on the weapons.
Why
The process of designing the weapons is very similar to the process of designing enemies.
For the weapons, I did want to make the weapons feel powerful, but not make them overpowered. So I played a lot around with the numbers for:
Damage balance
Ammo balance
Fire rate & ammo drain
Ranking System
What
I made a ranking system based on the score for the game. The higher the score you have, the better the rank you get.
The ranks you can achieve are E, D, C, B, A and S.
Each level has its score requirement for each rank.
The score is based on a few factors: the current combo you had when you finished the level, the total score and time.
Time plays an important factor in the scoring. If you complete a level fast, you get a nice bonus score to add on top of your current score.
But if you take too long to complete the level, you get a penalty in the form of a score reduction and this is exponential to avoid exploitation of the time.
This is shown next to the timer.
How
Before I determine the achieved rank, I first check the time in which the player clears the level.
The target times are put into a data table and the player's achieved time gets compared to this number with the corresponding level. This will be used later when the score will be calculated.
The penalty factor is a variable I use to balance the penalty severity for being over time.
Calculating the bonus/penalty score requires the current level, the time achieved by the player and overall score (which was the combo score that was ongoing & the total score).
Using the level name I select the time target of that level and its penalty factor. I then compare the target time & achieved time to dictate whether to reward or penalise the player based on their time.
Penalty for being over time. This uses a math expression to make the punishment more severe the longer you take as a player.
Reward for completing within time. You get your left over time between achieved & target * 500 points.
To determine the ranks, I created another data table.
Each row represents a level while the columns represent the requirements for each of the ranks. S Rank demands the highest score for its requirement while D rank requires a minimal amount of score.
The score requirements for each Rank were pretty simple to figure out, I just played to the best of my ability to achieve S rank, rounded down that number to be the S rank requirement, and then trickled down the numbers from there for lower ranks.
I visualised it in Excel to figure out the curve
I use the rank score to compare the final score with bonuses or penalties applied to it. I do this for each rank in the column which is a bit cumbersome, but it wasn't too much work because I created a macro to make it easier to implement.
Last but not least, if the player gets an S rank, it plays a little animation that changes the colour of the rank to pulsing yellow, and shakes and pops the S indefinitely, making it super rewarding for performing well.
Why
For Shred Off this system is perfect because it encourages replayability for our levels and rewards players who do well in our game. And to punish those who perform poorly or try to exploit time to their benefit.
It fits for the type of arcade action we're going for and it gives players bragging rights.
It was fun to make the ranking system because I got to play the game a lot and discover bugs or issues that I was able to report.
Page updated
Google Sites
Report abuse