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
Rapid Fire
Dash
Bouncy Suds
Slick Suds
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)
Jason Ryan (Environment / Prop Artist)
Asher Chase (Producer)
Neal Wojtowicz (AI / UI & UX)
Nicholas von Friedeburg (Sound Designer)
Elliott Friedrichs