One of my other big contributions was the boss and all of his mechanics. This was very exciting personally because the challenge and satisfaction of beating a good boss is one of my favorite things in games.
The result became a boss with 3 distinct phases, 4 transitions, and 4 abilities that all had a plethora of modifiable variables in the accompanying boss tool created in a Dear ImGui window.
One of my favorite parts of the boss became the semi-randomized decision-making for each ability. It used different chance percentages per phase to let Level Designers decide if the ability is even in this phase and if it is, how often it should appear.
Below are some GIFs showcasing each ability and the boss tool.
I started by using multiple axis-aligned boxes set along the path toward the player to create the laser. This however made the collision sometimes feel wrong. Instead, I implemented an OBB collision to create a more realistic collision that also reduced the number of colliders per laser.
This started with just one explosion throughout all phases. That however felt too bland to me. So to create more distinct phases and a sense of challenge, I added one more explosion per phase with a delayed spawn and also made it follow the player at a slow speed.
Through development, this ability went through many changes. It started with 3 duplicates that surrounded the player at their location. With the development of combat pacing, this had to be updated at a later date to add more duplicates and surrounding the center of the boss stage instead of the player. With these changes, the ability had a more consistent difficulty and no possibility of awkward placement.
During development, I was also in charge of creating various
miscellaneous gameplay systems. Some more intricate than others, but it was a fun experience to figure out the best way to seamlessly integrate these systems into the already existing ones.
At the start of the project, I took it upon myself to create some basic collisions for our in-house engine's Entity Component System.
This was something I returned to throughout the entire development to add more intersections, shapes, and improve the workflow around the resulting contacts.
At the end of development, I had added intersections and basic physics between the following shapes,
The GIF above showcases the use of my event system to trigger a falling pillar to block the path backwards
The image shows the working OBB to Axis-Aligned collision used in the boss laser ability
The final big contribution on my part, as it was in Toys or Sus, became the implementation of FMOD's audio engine and the entire soundscape of the game. Using FMOD Studio I created effects and music from scratch with help from Soundsnap's library of sound snippets.
My favorite implementation of audio in this game was the soundtrack I put together, check it out to the left!
As our engine was built using an ECS as a foundation, everything in our game that was going to collide had an easy-to-access entity number. This made it easy to save every contact in a bit array and use the entity number as an identifier to take appropriate action during the collision handling later on.
To optimize the system I also implemented collision layers to skip checking for expensive intersections when it is unnecessary.
Through my implementation of a body component, I could quickly acquire the contact data and filter the resulting contacts to easy access functions that other programmers could use to determine what should happen to both parties in the resulting contacts.
Level 1 Theme
Level 2 Theme