AQUAGGEDON
Game Designer & Gameplay Programmer
Play with your friends online and knock them away with goofy underwater Heroes in this chaos induced mix between Battle Royale and Hero Shooter.
DESCRIPTION AND RESPONSABILITIES
This goofy 3rd Person Battle Royale / Hero Shooter is the high and final point of my Game Design student years:
-
General Game Design (documentation, implementation, experience)
-
Technical Design (code architecture, programming documentation)
-
Programming (3C, GPE, GPE Properties, code architecture)
-
Animations (placeholders, documentation and reviews)
-
Music (documentation and reviews)
DEVELOPPED SKILLS
-
Long production allowed me to fully embrace iterative prototyping through many playtests
-
Adopted the Wiki-style documentation to help keeping a strong focus on each aspect of a feature, while easily providing cross-disciplinary resources
-
Correctly applying SOLID principles helped maintaining, tweaking and scaling our design, as well as facilitating feature-focus development in isolated environments
Unity
5
5 Months
YEAR
2022
GENRE
Battle Royale / Hero Shooter
Online Multiplayer
PLATFORM
PC / itch.io
EXPERIENCE DESIGN
Zoom On - Shrimpossible's Railgun
KNOCKING PROPERTY & PLAYER INTENTIONS
ESTABLISHING GOALS
Physics-based gameplay is fun, watching the physics engine do its work is fun, but in the case of translating players' intentions, things can paradoxically feel random without any tweaks and design influence.
In our situation, what helped anticipating the intentions and typical players actions were:
-
Inexperienced players => inaccurate shots
-
Knocking opponent in void => alignement with opponents and void
-
Knocking opponent in GPE => shoot at opponent edges to get angled knock
Those dynamics were the fundations for how I designed the fundamental rules for determining the output force.
DEFINING INTERACTIONS
For Shrimpossible's Railgun Shot, I tried to build accessible and system-assisted interactions so that players who are starting off can have immediate but limited successful plays, and players who are experienced can take advantage of the system to create highly successful plays.
-
Predictible interactions => it makes sense in the gameplay loop context
-
Manageable variations => a tiny difference in input doesn't result in a widely different output
These were the critical input parameters to take into account:
-
Shot Direction => to emphasize player positioning and game plan
-
Contact Point between Shot (KE+) and KE- => to allow angled knocks and higher level of play
-
Proximity of KE- with another KE+ => to assist in chain reactions and induce chaos
BREAKING DOWN INTENTIONS
To streamline our design, development, and allow for future modifications and upscaling of the project, I started to break down our dynamics (knocking things around) into small, separated Properties that could be implemented (possibly differently) throughout different Gameplay Elements and Mechanics.
In the case of the Knocking dynamic:
-
Knocking Element (KE+)
-
Knockable Element (KE-)
Any KE+ can always interact with a KE- in order to trigger common and predictable behaviors. Each KE+ and KE- can however implement additional and unique behaviors (through C# Interfaces) that give flavor and diversity to the GPE / Mechanic it is tied to.
Here we get the opposite vector of the contact point normal. Just like two billard balls would interact.
Players want to knock things in the Shot Direction => Shot Velocity has Weight Players can be inaccurate => Weight is relatively high
Here we get the opposite vector of the contact point normal. Just like two billard balls would interact.
POLISHING
Once everything was in place and working as intended, a new issue arose: Shots were big enough to hit things from afar, but too big so that their hitbox would collide with the environment, getting disabled before hitting the intended element.
So I separated the collision responsabilities between two colliders
-
A big one that fits the size, visuals and gameplay intentions => to collide with Knockable Elements only
-
A tiny one at the center of the object => to collide with the environment
This way, shots could be aimed precisely without having to worry about colliding with the environment.
CLICK TO FULL DISPLAY
ANIMATION, THE ULTIMATE FEEDBACK
IDENTIFYING PROBLEMS
During (very) early stages of development, it was really hard for playtesters outside the dev team to get a feel for what was going, and with placeholder models and no animations, everyone was frustrated that they could not shoot without aiming first (hipfire).
Among the culprits:
-
Early Design allowed Railgun Skill only as offensive Mechanics
=> Left Click wasn't doing anything when Not Aiming -
Concept Arts showed Shrimpossible in shooting stance
-
Placeholder was always in shooting stance
REVISIONS USING REFERENCES
That's when I remembered what they did during Journey's prototyping phases: they wanted full cooperative gameplay without grifting behaviors but players kept trying to push each other. Besides physics collisions, another aspect caught their attention: the character had arms and as such it implicitely fostered such behavior. That's when the character design shifted to the one we now know with the arms completely hidden under the robe.
TESTING SOLUTIONS
When approaching Feedback, the question of partial or total information is usually one that pops up quickly. What emphasis needs to be put on this cooldown? How will this affect player's attention and mental load? How to signify states?
Here we initially went down the spell it out route and so we turned towards non-diegetic and extremely explicit UI to signify that you could not shoot so that they know exactly what is going on.
Shockingly, it felt awful, disruptive, and didn't really alleviate the want for hipfiring.
ITERATION AND VALIDATION
And that's what we did with Shrimpossible. I initially wanted to completely separate the railgun from the arm so that it could be placed in the character's back when Not Aiming, but the sculpting was already in too deep for modifications. So we opted for a resting pose with the canon aiming at the ground to communicate that the Railgun could not be used in that state.