All Eyes On Me
- Loki Sanguine
- Jan 11, 2023
- 4 min read
Updated: Apr 21, 2023
Customary Table of Contents;
What is All Eyes On Me?
All Eyes On Me (AEOM) is a single player movement shooter, in which the player makes their way from room to room blowing bubbles at aliens known as Oculon. In this current stage of development there is a wide variety of abilities to choose from for a player to change their experience with their navigation of the room as well as dealing with the enemies themselves. I made this with a few other people who I will be linking their linkedin pages below as they consent. For this project I was primarily a gameplay programmer focusing on modularity of shifting kits and working with our designer to balance our skills with the goofy nature of the environment. One concept different from other movement shooters to us is your ammo and skills are on the same stamina resource which you will see in the bottom left as a bar in all displays.

Abilities
For AEOM there is a few abilities to cover, the way these are made by designer I will explain deeper in another post. The tl;dr for now on that is I made a Unity Editor tool for the designer to plug and play with the different arguments to make some abilities come together and resulted in other interesting behaviors in game. For these abilities we wanted to focus on a cartoony nature that. These are listed below with the dropdowns giving more technical information in case you have a specific question you may want answered! As well as some size issues with showing off all the images some will not have gifs accompanying them unfortunately.
Bubble Jumping
The first of our Combat Skills made, and only one we found balanced properly for the players, this skill is what moved me to want to delve deeper into movement. More specifically, rocket jumping. The way this worked was actually quite simple. On the Rocket Bubble's collision with something we run the following code;

We're taking the player object's Rigidbody component and applying AddExplosionForce to it. This case is much more readable but alternatively you could write out yourself finding if we are in range by the magnitude of the vector found from the Rocket Bubble to your player. From there we would need to find what percentage of the maximum range we are at to change our force to be lessened the farther away from the explosion the player finds themselves. Which may lead you to be wondering what is upMod in this case? upMod takes the point provided on our rigidbody (closest point to the center of explosion) and shifts the point down by the set amount provided in upMod to add an uplifting effect to our pop.
Rapid Fire
For our Rapid Fire combat skill, it originally was balanced having just the default bubble type. However as we made more bubble types it became a bit imbalanced so we opted not to have it be part of the demo. All this skill does is temporarily change your fire rate to be more rapid as well as instead of having to individually tap to shoot you can constantly fire by holding the mouse button down.

Dash
One of our several utility skills this was also made very early on. A directional dash providing ease of traversal over a large horizontal distance.

This was made with the following snippet:

Using the player object's rigidbody we get the direction the player is presently moving and multiply it by dashSpeed. Some things you can do for more consistency is make sure your moveDir is a normalized vector or always a consistent length. Inconsistent length will cause inconsistent behavior in this snippet. I chose VelocityChange as the dash needed a slightly larger impact then would be found with our other options. For more information on the different ForceModes check here.
Bouncy Suds
Bouncy Suds was one of the first Utility Grenade ideas, these wouldn't use stamina but find themselves having a longer cooldown. Flying through the sky it's nothing special but when it lands it leaves behind a bouncy puddle of suds. If the player jumps while in this puddle they'll find themselves reaching new heights! This is also shown in the video if you look out for it.
Slick Suds
Slick Suds is our counterpart to the Utility Grenade option in AEOM. Working similarly to the one above in the fact they both spawn some suds on the surface for the player to interact with.

As you can see a key difference in the two is as the Slick Suds travel through the air they spawn their trail until they finally settle and leave behind a final puddle of suds. By walking on this trail or even just on a patch the player gets an enhanced movement speed. This trail does disappear after a few seconds as well due to the prefab having one of our helper scripts that tracks lifetime.
I made use of Scriptable Objects for everything to be modular for the sake of the ability select. For information on those the documentation link is here.
Wands
So let's talk about the meat of the way our projectiles come together. These are once again made using scriptable objects for the lower end but high end. How do these come together? Wands comes up first on our list as without them we can't fire a bubble after all. In our manager we have reference to the Bubble Wand and our bubbles.

First when we call our function to interact with our wand we check if we have enough stamina and if we are within our fire rate. If one of these is wrong toss it out. Otherwise we set when the shot was used and call InstantiateBubbles which takes our known BubbleSO. Low level decoupling would have us switching it so the wand would have references to this SO by default. So let's take a peak under the hood what this calls.

Inside our wand's InstantiateBubbles function we check how many bubblesSpawned by our set wand. Based on this we alter the way we spawn the bubbles themselves to either be side by side or just a solitary center spawning bubble a little ahead of our player. The holder object is our initial instantiation so we can access it's information more cleanly for the second bubble to have it's instantiated offset. Now how does our bubble become bubbly?
Bubbles
By default they aren't very interesting. They get their starting movement direction and then shoot off with a velocity until their drag catches up with a minimized sin wave giving it some wave in the wind that's very minimal in practice currently. As well as our previous helper function for lifetime will kick in when the speed is below a threshold.

This function is where we get added complexity. In our switch case by default movementSpeed is normal & bounces are bounces. The sniper bubble gets an extra modifier to speed always and the Elastic type is bouncing around with a movement modifier for every bounce. How do these look? Let's start with how we track bounces to begin with.

Initial checks that we have bounces and the collision isn't with an enemy otherwise we destroy the bubble. Enemies by design have their own way of handling this collision provided by an associate so while making a whole other call isn't the greatest this avoided extra coupling.
(This assumes you know Vector Math to a small extent if you do not look here)

This bouncing behavior is currently inconsistent but gets the point across. I will explain how this would be done in a less inconsistent manner momentarily. So we found ourselves hitting the collider and passed it in. So we find the point from the closest point of the collider and subtract our bubble's position by it. then we multiply this direction immediately and plug the velocity in directly. So why is this wrong?
Say we have this line y = 2.

If we collide with say -x + 2.1

We'll assume movement in the negative x direction so our original vector p equals <-1,0>. Movement of the other line doesn't matter. Our closest point we interact with would be at (0,2). Let's assume our object is a sphere (we are working with a bubble). The radius of which is .2 for simplicity. When our object finds itself at say (0.2, 2.0). This then turns our movement direction into (0, 2.0) - (0.2, 2.2) = <-.2, -.2>. So mathematically it shouldn't work by just being replaced here... Thankfully this is corrected by default by Unity's collision system bouncing it soon after anyway so we don't have too many issues with bubbles getting caught. In order to correct this normally we change it our math to (0.2, 2.2) - (0, 2.0) to have us moving in the positive x direction of .2 and y direction of .2 as well. So going back to work on this I would correct that immediately.
There are many issues with which I found myself learning to move forward in my own reasoning and more properly finding my way to work things through. Now let's check out the video together.
Dev Contacts.
Loki (Writer of this post)
Skylar Chandler (Character Artist)
email: skylar.chandler@mymail.champlain.edu
Jason Ryan (Environment / Prop Artist)
Asher Chase (Producer)
email: asher.chase@mymail.champlain.edu
Neal Wojtowicz (AI / UI & UX)
Nicholas von Friedeburg (Sound Designer)
Elliott Friedrichs
email: elliot.friedrichs@mymail.champlain.edu
Comments