A mobile AR game that pits you against a virtual opponent.
A mobile AR game that pits you against a virtual opponent.
A mobile AR game that pits you against a virtual opponent.
A mobile AR game that pits you against a virtual opponent.
DR. BOUNCE
Dr Bounce is a fast-paced, single-player FPS centred around Throwing, Bouncing and Catching your weapon to defeat foes in style.
You play as a child scientist who accidentally covers their mother's lab in jelly during an experiment gone wrong. Left with a building full of gooey enemies, you must dash, bounce and shoot through the lab on a quest to save your mother!
Dr Bounce was my third-year project that I developed alongside team Jelly Brain, made up of 12 different people. My role in the team was to program and refine the player's movement, in addition to working on enemy AI.
Movement Options:
Jump:
A simple jump that has varying heights based on how long the player holds the jump button for. A minium jump height was set to prevent the player from pressing the button so quickly that they barely leave the ground.
Crouch:
For the player to reach their crouching height smoothly, I needed to lerp the player's height between their original and target height. A check hitbox is also placed above the player so they can't un-crouch while underneath low geometry.
Dash:
A burst of momentum granted in whichever direction the player is going.
For precise platforming and a weightless feel, the player's gravity is set to 0 when performing this move.
Slide:
Only performable on the ground while moving forward, this move continues as long as you hold the slide button. Your velocity is retained as long as you hold the button down, which opens up strategic options like strafing and aiming mid-slide.
Creating & Iterating:
Dr Bounce's movement was much different in its initial conception compared to how it turned out - the idea was for there to be a basic jump that was always at a set height, with a similar dash and slide that would always send the player at a set distance at a different speed. Each action would act as a forward dive for the player, as the core challenge of the game would be to catch the gun after throwing it and having it bounce back to you, making
However, as we experimented with the game and developed it further, we realised that catching was much too tricky - no matter how we changed the movement, catching the gun at multiple different angles was far too difficult. So we gave the player a magnet to pull the gun toward the player, provided it's within a set range.
After this change, we realised that the player's movement could be far more open and intuitive - no longer limited to the angles and distances best suited to catching the gun after a throw. So, I got to work making the movement of Dr. Bounce snappier, more responsive, and better befitting the platforming-heavy nature the game was taking on.
The first change was to the jump - similar to most platforming games, I changed the jump to vary in height based on how long the jump button was pressed for - with a minimum height (or 'short hop') set for quick presses of the button.
Next, the slide was changed from a set distance to continue as long as the player held the button. So long as they were sliding, they could move the camera around and shoot while still sliding in the same direction. The player can also strafe, giving them a bit of control during this action, but was primarily designed with speed over precision in mind.
Finally, the dash was kept mostly the same, but with a few tweaks. I changed it so while the player was dashing, gravity would be set to 0, so they would travel straight forward in the air, rather than in a slight downward arc.
Each of these changes were made with control in mind - most gameplay scenarios require the player to evade enemies or chase after their gun once it starts flying - and for each of these the player would need to keep great forward momentum without allowing it to stop by hitting a platform, or getting bounced away.
After constantly upgrading and iterating on the movement over the course of a few months, this is the result!
How this was achieved:
Dashing is initialised in a function that sets 'isDashing' to true for an amount of time specified in the Unity editor by me and the designers.
While this is true, several things take place:
The player's velocity is set to 0, so the player stays at the same elevation during a dash to make aiming and positioning easier.
Any directional input is read before dashing using Unity's new input system, which is then used to propel the player in that direction for the duration of the move.
If no input is detected here, the player defaults to moving straight forward based on the camera's rotation. Finally, this direction is multiplied by the strength value of the dash and Time.Delta time to create a half-second move that fires the player at any desired angle in one big burst.
Momentum can be gained by using the slide or hitting a bounce pad and is kept by moving in the same direction as the momentum without hitting the ground. This allows the player to do things like slide to gain momentum, and then quickly jump to receive a boost in jump distance.
In the first two if statements, the script checks if the player's movement input is the opposite of the direction of their velocity. If this is the case, then the movement value (which has a peak of 1 when moving the control stick to the maximum) is subtracted from velocity every frame, to allow the player to quickly brake.
Momentum is calculated by multiplying my own velocity value by the one specified by the player's Rigidbody component - allowing all momentum to be killed when the player hits a wall. The value also has 'bounceForce' added, which uses the velocity gained from bounce pads created by another programmer. This will always be 0 if the player hasn't touched one or hit the ground.
Crouching was a unique challenge, as the player can only crouch when touching the ground, which is determined using 'GroundCheck' - a location directly beneath the player at which a sphere collider is temporarily made - and will return true if the collider overlaps with a surface.
The player's height is lerped to the target controller height once they crouch, with a small bit of script making it round up to the target height number when it gets close enough. The player is simultaneously moved down at the same rate as the crouch by measuring the height they lose from crouching each frame and moving them down gradually by that amount, to give the player a smooth transition to the ground.
As the groundcheck is a child of the player, and the player's transform moves down as they crouch, the groundcheck would naturally move down with the player, causing it to go under the ground, which is problematic as it wouldn't detect ground any longer, causing the script to act as if the player is in the air. To remedy this, I move the groundcheck inversely to the player's transform when they crouch so it always remains in the same position relative to the player.
My Experience with Movement:
Creating the game's movement was a hugely enjoyable experience, as with my other team projects I've created a mechanic relatively separate from the rest of the game. But in creating Dr. Bounce's movement, I was markedly more involved in discussions regarding the game's core design and played a more pivotal role in the game's creation. I also found that creating movement was a challenging but engaging balancing act, with every tiny tweak and improvement made to it in turn requiring changes to other parts of the system.
While I've worked on player movement in previous projects, this one has been the most in-depth - Dr Bounce is extremely movement-focused by design. I've had to be extremely thorough, and quite experimentative with how different moves function.
Project Reflection:
What went well:
I'm very proud of the improved communication skills I displayed and developed over the course of Dr. Bounce's development. As my previous two projects have had me working on a small section of the game independently, working on something as integral as the player's movement has given me much more opportunity to actively communicate with each member of the team on the movement's direction, feel, and implementation.
What could've gone better:
Time management with this project could have been improved, though still being of a decent level. I and the rest of the programmers agreed to get other, more vital parts of the project finished before moving on to enemy AI. We planned to start in November, however as this time was close to another deadline, everyone had to work on said deadline instead, leaving AI unfinished for some time, blocking the designers from fully building the 1st level.