Matthew Stracey
Depth Charge
Developed as an Collaborative second year project, I worked on the core mechanics for Depth charge. This was to develop more in depth experience working in a team, which included working with designers, artists and other programmers.
Made for: ARU 2nd Year – Trimester 2
Duration: 4 Months
Engine: Unity
Language: C#
Position: Main Gameplay Programmer
Radar and fog:
Fog
The idea for the fog design in our game had originated from myself, as a design that would complement the theme of ‘into the dark’. Although fog itself does not necessarily correlate to darkness, it follows the trait of poor vision. This would later complement our level design of going deeper, which was the focus when it came to the theme as the levels would get darker the deeper you went. When we had started developing Depth charge, we had realised that the fog also made the effect of being underwater, which was great as we were struggling to find ways of effectively showing that the mech is in the ocean.
The fog played an important part when it came to one of our main mechanics, the radar, which would reveal obstacles that are covered by the fog. The fog would end up being the characters main enemy in Depth charge, as it would make later depths much harder when the obstacles get faster due to poor vision.
Learning how Fog worked within Unity at the start seemed like an easy task to achieve, but when I started testing it, I realised there were some complications. I originally thought fog would cover up any object outside the range of the player’s vision no matter what the colour of the fog is, but it turns out that solid colour backgrounds actually end up revealing what’s inside the fog in the fog colour. It took me a while to understand this, but I eventually figured out that the objects could be hidden in the fog if you change its colour to the same as the background. I did not know this at the time but I would later find out that this would later help in making the radar mechanic, as I now knew objects could be revealed by changing the fog colour.
Without Fog
With Fog
Radar
The radar was also another mechanic in the game designed by me. If we were going to give the player lower visibility with what’s heading towards them, there needed to be a way for the player to be able to combat this. The radar is a permanent ability for the player but requires time to recharge after use.
Even though I was the one who had come up with the idea for the radar, I originally didn’t really know how I could program it into the game. Fortunately, I came up with an idea when I developed the fog. The radar would reveal objects by changing the fog colour to a luminescent green, which would reveal objects because of the contrast in colour in the background as previously discussed.
To sell the radar effect, I wanted to create a scanner line. The scanner line didn’t interfere with any functionality for the radar, and was more of a visual representation of the mech scanning the area for oncoming obstacles.
The scanner consisted of 3 objects:
RadarBlipEnd: the point in which the scanner line ends.
BlipDestination: the point in which the scanner line is trying to reach.
RadarLocation: the starting location of the line (at the mechs centre).
The way that the scanner line worked was by rendering a line from the RadarLocation to the end point. Then, the end point would rotate around the player until it collides with the destination. The end point would then rotate the other direction, and the destination would move to the opposite side where the process is repeated. This created a green scanner line which bounce back and forth in front of the mech.
Click Image to view code
Post processing:
Shortly after finishing the radar, I wanted to do some post processing effects for the radar and also some general effects.
For the radar, I made it so the screen is tinted in a green colour, and I also added some static grain.
Movement adjustments
My teammate had already made a basic movement script for the mech, but the mech felt very ridged and responsive for something that was meant to be underwater. After discussing with the team, I decided to work on making the controls feel slightly more floaty.
To do this, I changed the values of the mass in the mech’s ridged body component. Within the movement script, my teammate was moving the player via updating the vector, but I changed it so the rigid body was being affected. When the player presses WASD, force is applied to the mech, this force makes the controls more floaty as you are moving with Unity physics rather than updating the vector.
Click Image to view code
Boost
With the way that I had achieved the movement for the mech, the boost was really simple to make as it could just follow the same functionality but just with a bigger multiplier to the force on the mech’ rigid body.
Click Image to view code
Obstacle procedural generation and obstacle optimization
Obstacle procedural generation:
While developing Depth charge, the way that I engineered the obstacle spawns is something that I am particularly proud of. Randomization of obstacles is a key mechanic in most endless runners. Randomizing obstacles spawning is not too hard but making them spawn so its fair on the player is where the difficulties arise.
To begin with, I originally had six spawners that were in front of the player. These spawners would spawn objects randomly and the obstacles would go in a straight line and would disappear if it hit the player, or the wall behind the scene to stop the obstacle from swimming off. After some feedback from lectures, this was changed slightly. The reason for this change was because it did not look like the player was going deeper, but rather going across the ocean. This was because of the angle in which the obstacles were coming at the player.
The way that this was fixed was by moving the spawners to a lower position, and have the obstacles move towards a target behind the player. The target is assigned depending on what lane the obstacle is on. The sea creatures were also rotated slightly to make it look like they were swimming up towards the player.
Move towards player:
Click Image to view code
Obstacle optimization
now that I had the base, it was then time to add some complexity to the random spawning.
Here is a list of things that I had spent time on to make the randomization more complex and optimized.
Limited already in scene Obstacles:
I made it so rather than instantiating new objects randomly, the game could just pick out random obstacles that were sitting in the scene behind the player. This made it so the amount of objects within the lanes would be limited, and would avoid unfair spawning such as two big unavoidable whales spawning at the same time. This also optimized performance, as it stops the game having to add new objects to the scene and destroying them.
If the object needs to disappear from the lane, it returns to its resting position behind the camera and stops moving.
Click Image to view code
Obstacle Chance and smart spawning:
Obstacle’s chance of spawning was now dependant on how big the object was, if the object was large like a whale, the chances of one spawning was less frequent than a fish spawning. I also made it so the game wouldn’t try to spawn in an object that was already in a lane, if it was running, it was locked out of choice to be picked again until its returned to rest.
Rolls the chance of each animal type each frame:
Click Image to view code
The chance of each animal spawning changes depending on what level the player is on:
Click Image to view code
Gets a random object from the list and sees if its resting:
Click Image to view code
Also gets a random destination depending on which spawner the object is going to spawn at:
Click Image to view code
Lane discipline:
This is some code that I had wrote that I’m proud of as it was a really creative way of solving a problem that had occurred with the obstacles. Each obstacle had different speeds to them, some were slower than others, and some were faster. This caused issues as the difference in speed meant obstacles would end up passing through each other. This would cause scenarios like a shark(fast) would spawn in the same lane as a whale(slow), and the shark would go straight through the whale, making it unfair for the player as they could not see the shark coming.
I created some code which implemented lane discipline, which consisted of holding information on what animal was on what lane, and stopped any animals that were faster than anything on that lane from spawning. This continued to allow more than one animal on each lane, but made it so anything spawned behind an animal would be slower than what’s already on the lane.
Click Image to view code
Mech damage
Flicker and temporary invincibility:
When the player hits a object, we wanted to make it so the player would be invincible for a short amount of time. This would allow the player to reposition themselves so they can carry on with the run, we wanted to implement this to its fair on the player, and they don’t end up getting hit more than once.
Along with the invincibility, I also added a visual flicker effect, which gave an indication to if they were still invincible or not. I really like this design, its feels very polished and well done.
Click Image to view code
Falling off limbs
We wanted to add a bit more depth to the damage on the mech, so I made it so when the player lost health, limbs would fall off the mech one by one. The game would be over when the player loses all its limbs.
Click Image to view code
Powerups
I was in charge of setting two core powerups for our game, the two powerups were a shield powerup and a health powerup. The shield powerup makes a protective bubble around the player, the shield would then be broken once it has been hit. The health powerup returns a lost limb to the player, returning some of their health.
This was the base script for the two abilities, each powerup had this script with would check for collision:
Click Image to view code
Health
The health orb powerup would randomly pick a lost limb to give back to the player:
Click Image to view code
Shield
Would create a protective bubble around the player that allowed them to get hit once:
Click Image to view code
Levels and depths
For the levels in Depth charge, I decided on using scriptable objects. These scriptable objects held multiple values that would determine things like difficulty and depth.
All information of what each scriptable object values do are commented below:
Click Image to view code
The level that the player was on would be held inside the game manager, so it could be easily accessed from other scripts through the use of a singleton.
Inside the game manager also included some functions to make the levels and transitions work.
Click Image to view code
Bubbles
Overall, I am satisfied with the quality of the work I had produced in this module. Mechanics such as the limbs falling off the mech and damage flicker were mechanics that I thought were going to be quite complex and hard to achieve, but I took on the challenge and managed to successfully produce them bug free. I liked working with this group as they allowed me a lot of creative freedom, many of the core mechanics came from my ideas and I personally think I produced them efficiently and with good time. A goal that I set out to achieve as a programmer was to make my code clear and clean throughout the development of the project. I think I managed to achieve this, with clear comments of what each function is for.
Thoughts on the game:
Looking back on our game, there are definitely some parts to the game that stand out to me, both positively and negatively. For me, I think the way that we had developed the obstacle spawning was a positive outcome. We had manage to engineer it so the obstacles would have a resting point out of view of the player, and would be called randomly when needed. I personally like this as I am always finding ways to optimise my games, and this avoids instantiating new objects that slow down processing.
One thing that I don’t like about the game is the background visuals, as the game looks very bland because of it. I think we should have spent more time thinking about how we could have made the background, perhaps adding schools of fish and random events. These wouldn’t have needed to be interactable, they would simply make the ocean back drop feel more alive. As the game stands right now, the backdrop consists of just a singular colour, which changes depending on the depth.
What Changes were made:
“The game is quite boring once you play through it a few times”.
During development, we made sure to take in any feedback we had got. One problem we had come across was that the game was not very enticing to come back to after playing it before. We started researching why this was the case for our game and narrowed it down to how the game feels to control. Many endless runner games feel very quick paced, and the controls are always fast and responsive movements. We designed our game to be underwater, so we made the controls feel more floaty to give of the effect of moving in water. The floaty controls ended up making the game feel very slow, so to combat this, we increased the players speed but tried to keep our original feel of being underwater.
“The game is fun but too easy”.
Alongside this, we also increased the speed of the obstacles and made the difficulty curve ramp up more quickly. This made the game feel much faster and a bit more engaging than it did originally.
What could have been improved:
I think there is room for improvement for depth charge. I personally would like to see some more variety when it comes to obstacles, perhaps some obstacles that target you. Adding more functionality to the animal obstacles could add a whole new element to the gameplay, which would overall make the game feel more enjoyable. If I had more time to work on depth charge, I would have liked to try to find a way to make the mech feel more engaging. The assessment does not allow us to use any complex animations, but I would have perhaps added some small movements to the mech depending on which direction it was moving. This would give some visual feedback, which would once again make the game feel more engaging. Despite these few things I would add to the game, there is nothing that I would remove from the game that would improve the quality.