~About this Game~

An adaptive-musical boss rush arena game where you play as a violinist battling against orchestral company-themed foes. Made in Unreal Engine 5.

My Contributions

About our team

As a passionate team of 14 collegiate students, we really were passionate on creating a 3D boss-rush arena game with adaptive music inspired by hack-and-slash games like Bayonetta, Furi, and Nier: Automata. Including me, our team consisted of 3 musicians, 4 artists, a designer, a writer and 5 programmers.

Awards

As of June 2023, We Got Compagnie! has been the recipient of two awards: 

SGDA's Mini-grant Award for Student Games Showcase

SGDAWeGotCompagnieWin.mov

IEEE GameSig Award for Most Innovative Audio and User Interface

RPReplay_Final1681698778.MOV

My Design Process

Quarter One

We Got Compagnie! came to be as sort of an alternate-back-up game idea for my Capstone project while I was listening to a French song by Michel Legrand. I decided that although development of my Capstone project would span throughout the length of two quarters, the game I had in mind initially (which was also my dream game) would've been too ambitious to make even with an extra quarter of development time. 

I then sat down in my dorm to quickly think of another game. A YouTube video came across my mind as I listened to Michel Legrand's song that I remember watching back in 2020, called the "Tuba Archmage Theme." Which, was a meme song that was made as a hypothetical boss theme in a hypothetical video game, and I thought, "Why hasn't anyone made this yet?"

And so I began sketching!

"Audio First... Gameplay Later?"

(Making Adaptive Audio Pt. 1)

We Got Compagnie! had to have audio as a primary focus and pillar to our game. The three game design pillars we followed mostly throughout the development of our game were: 

At the pre-production of development, I sat in my dorm room one night thinking about how this game idea should be played. Ever since my last game, The Cheat Code for Happiness Is..., I wanted to try to implement adaptive audio.  However, adaptive audio was a very unexplored and elusive aspect of video games at this time, and to my knowledge not many people had documented how adaptive audio just works so well, much less on how to implement it so that it not only sounds nice, but stays on beat and is adaptable to the player's choice of input.

The problem wracked my brain that night –I had the Michel Legrand song on loop in my headphones, and suddenly the violin part of the song intrigued me for a bit. Then slowly but surely the thought of having the violinist as the main character for the video game, soon snowballed into me remembering a cool easter egg from a weapon called the Pixelizer from Ratchet & Clank: Rift Apart. The music changed simply by pressing and holding the fire button so seemlessly that it felt like you had agency over the video game's music. You could be totally off beat, but the continuity of the way the theme of the weapon flows into the button press made me think back to how a violin plays. And as such a theory came to my mind: the violin could be the easiest way to have adaptive audio in a student made game.

This idea seemed very possible for a two quarter project. However, besides two semesters of piano lessons I had in community college, this was but a theory of a student who blasts music through their headphones on their way to school. 

That said, I expressed the idea to my roommate to which he said that he used to play in band at high-school and proceeded to show me some videos of well-known violinist prodigies on YouTube like the prodigies of the Menuhin competitions. 

And as I watched, the flow of the violinists and the mere confident yet whimsical swagger of the way they played really made me hooked to this idea.

It romanticized its way to the point of me sketching a female violinist as the protagonist of this game. Who would serve as the hero against the fearsome Tuba Archmage boss. 

As for how the game would play in my mind, I had loose inspirations towards games like Nier: Automata and Bloodborne and didn't think that much besides shooting projectiles at enemies, but also dodging and weaving attacks with the grace and fluidity of a pivoting violinist.

How this combat would be implemented, I had no single clue, but I continued to pursue the project and let the ideas for combat cross my mind when it got to it.

"Plan A vs. Scribble Plan"

(Making Adaptive Audio Pt. 2)

It was not only until after I had assembled a team with some UCI's Video Game Development club members that I then pitched the idea of making adaptive audio for We Got Compagnie! 

So, you could only imagine the surprise I had when our main composer, Nelson Mencos, immediately was onboard to try to implement adaptive audio for the game. Our main violinist at the time, Emily Chavez, even linked a video I had watched and thoroughly enjoyed back in 2020 as well. We also collectively agreed as a team that playing the violin should also shoot projectiles that damages the tuba boss.

The next few weeks then consisted of trying to theorize and soon implement a working adaptive audio system for the game. As such, from my past experience with The Cheat Code for Happiness Is... I was a huge advocate to try to prototype our system as soon as possible to prevent us from theorizing for the most of the quarter only to start implementing in Week 8 of 10, no matter if we get it right on the first time or not. 

Nonetheless, that unfortunately was the case. However, in the meantime we did have a placeholder for what we had in mind initially, which was a midi file of our violinist playing a scale with the violin in two different tempos. Why record two different tempos? Let me explain:

Through some of the videos that our audio engineers researched and provided, we learned how to use a audio middleware called FMOD and implemented it into UE5.

The way our system worked was the following:

The middleware, FMOD, is able to take two or more tracks layered over each other and switch between the two according to a certain state of the player's inputs by lowering the volume of one track so that it is silent and highering the volume of the other so that it is audible. 

As such we decided to have the violinist play two different tempos of the same song and layered them on top of each other, so that when the game tells FMOD to switch between the two it sounds cohesive to the theme of the overall tuba boss theme. These two different tempos would serve as two different firing modes for the violinist.

This all said, some of our team was very skeptical as to whether or not this system would work, and even was questioning whether or not the system was actually adaptive audio in the first place. 

And this made it even more complicated when we considered adding melee combat to the game, which isn't related to playing the violin at all, and would require the player to execute melee on beat. Which was not what we wanted the player to do. I already made a rhythm game, and I wanted this game to be accessible to a general player, which meant I didn't want to discourage the player's skills by forcing them to use their rhythmic skills which I know many average players do not have.

Two photos of the initial FMOD prototype bank. The top photo shows the two different tracks layered over each other (which were the same melody but different tempos). 

The bottom photo depicts how the FMOD would switch between the two by decreasing the volume of one track to be silent and increasing the volume track of the other to be audible, according to the currently state of the game/player input.

WeGotCompagnieFMODSample.wav

One page of our Audio Design Document for We Got Compagnie!: a formal clean version of Plan A, with a detailed outline of what it is.

Another page of the Audio Design Document for We Got Compagnie!: a continuation of the left photo, but with the initial sketch of Plan A.

As such, much of our theorizing to perfect our audio ultimately led to us laying out four plans, each increasing in complexity: Plan A, B, C, and the infamous one amongst our team called "The Scribble Plan." 

Plan A was the simplest which was to have the player be able to switch between the two tempos of playing the violin with the orchestra in the background. This ended up being the plan that we ended up implementing.

"The Scribble Plan" was asking our composer to implement a complex melee audio system where even when the player was mashing the button to attack with the violinist's bow, the audio would sound cohesive and sound like it still is a duet between the boss and violinist. And not only that, the Tuba boss would have different themes according to what attack he would do, one for slam, one for jump slam, one for charge, and one for projectiles. Which meant we were asking atleast 5 whole new tracks from our composer. Which wasn't gonna happen.

"But what about the Gameplay??"

(Designing the Gameplay Pt.1)

Although we had a mainly focused on the audio for the game and perfecting it, that did not mean that we had started implementing the actual game until Week 8, when we finalized our plan for the audio. Gameplay was developed in conjunction with the audio to the game. Our lead Game Programmer, Hung Dung Vu was responsible for this task. 

The base concept of our violin projectile shooting, as well as the movement controls was laid out by me and then implemented in the game by him in the midst of our 7-8 week long theorization of the music for the game.

The projectile controls initially consisted of the following:

Holding the left trigger would make you play the violin slowly and fire a beam of balls called the "legato beam." Pressing both triggers rapidly would make you play the violin rapidly and fire cubes called the "tremolo flurry."  The caveat for the flurry, however, was that you were required to press BOTH triggers rapidly to cause the violinist to fire the projectile. If you don't, it doesn't fire.

Riding off the high that was the success of the control scheme for The Cheat Code for Happiness Is..., I ended up being pretty stubborn with keeping the functionality of pressing both triggers rapidly to fire the flurry projectiles. I simply wanted to replicate the feeling of playing fast on the violin. But soon most players were complaining that it was too tiring to beat the boss this way, and I soon agreed. Still, it wasn't until the next quarter, that this was modified to a more player-friendly control scheme of just pressing the right trigger by itself.

Top photo: the very first layout of controls for our game. This also included lock on with the right analogue stick as well as weak and strong melee, as well as healing none of which made into the game.

Bottom photo: an outline of the main mechanics for the game. You may notice that this is roughly the same outline as The Cheat Code for Happiness Is..., and that's because it was. However, it didn't help much as I thought it would've with the rest of my team.

"Tuba-Rocket-Man"

(Designing the Tuba Boss)

My initial design drawings of both the Tuba boss and the violinist implied that we wanted to have full fledged 3D models for our game. That said, I didn't expect that we would've actually gotten them so early again through the help of our Lead Programmer.

We then agreed to model the Tuba Boss first, since much of the violinist's moveset would've been the toughest to animate, and we had to make sure that the model doesn't break. The tuba boss was also very easy to model with primitive shapes as well. Soon afterwards, our Lead Artist Matthew Shin, offered to make the violinist model, from his own design. In the meantime, as a placeholder, Hung used a stick figure in order to visualize the violinist, our player character, as soon as possible.

Our Lead Programmer also helped make the base animations for both the Tuba Boss and Violinist. Between this and the model for the Tuba Boss, I oversaw and gave feedback following my vision as to how both would move, such as the way both the tuba boss and violinist attacks, jumps, runs, and walks.

The design of the tuba boss was hugely inspired by some art online on ArtStation. I didn't want to completely plagarize how the original tuba boss looked wearing the tuba piece like a wizard hat, so I turned the tuba piece upside-down so that the exit of the tuba served as the face of the boss. To me, it looked more intimidating that way as well. 

The tuba boss also originally was supposed to have a trumpet plunger with a creepy smiley face "drawn" on it. And through entering Phase Two would spit out the plunger and kill the player instantly if it hit them, but due to time constraints and complexity we scrapped this idea.

Not much documentation went into deciding how the tuba boss would fight, which was partly my fault since the design of the Tuba Boss was thought up on the spot. That said, with the general anatomy of the boss and what we could do with the model we made, I quickly thought up of three moves that boss could do, which was:

I soon realized that this moveset for the tuba boss was a very bareboned outline of how the boss would fight, and didn't think much on how it would interact with the Violinist's (the player's) moveset –most of which I had thought about a lot more than the Tuba Boss's moveset. We would soon learn that it was very difficult to translate it into a cohesive boss fight moving onto the second quarter.

"State(s) of Play(ing the Violin)"

(Designing the Violinist's Moveset)

The design of the violinist was highly inspired by the Menuhin competition violinists. Ever since I watched the SUPER talented violinists of our time on YouTube at the beginning of this quarter, I knew that the violinist had to be an agile-and-graceful float-like-a-butterfly-sting-like-a-bee type of playable character. In the YouTube videos, you could see all these experienced violinists bob, weave, and pivot... All while playing the violin perfectly. 

From Ji-Hae Park's TedTalk of her epic struggle, frantically yet gracefully treading the turmultuous musical waters of her prodigal adolescence to becoming a violin savant, to Christian Li's cold-yet-cool 11-year-old swagger... Of him wiping off the sweat from the shoulder rest of his violin just before playing and acing the ending of Vivaldi's Summer of the Four Seasons. 

It was as if their movements added to the music they were producing. So powerfully and poignantly. The duet of taking turns in this high stakes struggle to perform was a song in of itself.

I knew that this was the direction I wanted to lead our game into, however actually developing such a character was an astronomical feat to get right at the level of our game developer expertise. 

That said, we were able to get a head start on implementing such a character through the help of our lead programmer. Through his help we were able to wrap our head around how to develop a character's moveset through Unreal Engine's Blueprint system. 

Within the first quarter we were able to learn about making states for our playable character, Maestro the Violinist. This consisted of a walking state, as well as run, jump, melee, play (violin), and hurt states. Programming these states, we learned, was a matter of making a switch statement with enumerators and event dispatchers to notify Unreal that the Violinist's player state was being changed.

We soon realized that there were some caveats and modifiers to code to make sure that the right state was being called when playing as the violinist, as it is not just a matter of switching on a state and leaving it at that. We had to consider situations like, what if you are running while switching between playing the violin slowly and quickly, and what if within this switch of playstyles you press the dodge button? –What if you press both the buttons for playing the violin slowly and quickly at the same time?

All of these situations required thinking about the states in a vigilant, paranoid and cautious matter, because you wouldn't know whether or not a state caused something that wasn't supposed to happen when switching the state itself, –not until you playtest and it frighteningly pops up. Sometimes a completely unrelated state would happen entirely, like the jump state animation playing when you are clearly staying idle on the ground.

Although the hurt states (being knocked to the ground) were not fully implemented by the end of the first quarter, and despite the melee being cut from the final version, by quarter two we were able to add the knockback states, as well as a well-animated dodging state so that the player can finally bob and weave and play violin with the grace of a Menuhin violinist, programmed by a team of 14 college students.

Top Photo: The UpdateLocomotionState event that updates the state of movement that the player is undergoing.

Left Photo: The switch statement of an enumerator that updates the Player's action state.

Middle Photo: The switch statement of an enumerator that updates the Player's Locomotion State through the UpdateLocomotionState node.

Rightmost Photo: The full logic of the player action state switch statement, containing all the caveats of switching between the different action states.

"Contortionist Violinist"

(Designing *and Animating* the Violinist)

Although we had our Tuba Boss's model and animations done, we had to transition over to the violinist's model and animations. The violinist's animations was all done under the stick-figure skeletons that our Lead Programmer made. So that was good to go... 

..Is what I would say if it weren't for the fact that due to the skeletons and meshes being obviously different between the violinist and stick-figure, I had to learn how to retarget a mesh from the stick-figure to the violinist model. 

It was a huge hassle for both me and the team to try to get the new violinist's model into the game, no one including our Lead Programmer had ever touched the Retargetting System before, and so much had to be learnt within the remaining 2-3 weeks of time we had left. We also had two major problems that occurred.

The first problem we had was that both the violinist model and the stick figure model would end up hugely contorted for some of the animations we wanted to port over to the new model. And we found out that this was because the axes were wrong when we imported the 3D models from Blender to Unreal Engine. Once that was done, most of the animations worked (like the idle, walk, etc.). However, several animations that we HAD to have in the game still looked weird, which was the soon-to-be-scrapped melee animations. 

Top Photo: This photo depicts some of the wackiness that occured with retargetting, here, the arms are flipped due to the limbs being mapped wrong within the IK Rigs of UE5.

Bottom Photo: This photo shows if you import the models with the wrong axes set inside the import settings, you get contorted 3D models. This animation in this photo was the idle animation, too!

This last problem proved to be the most problematic, and it wasn't until our Capstone mentor contacted one of the lead animators in their studio closer to the final week, that we got our answer. It was because the hierarchy of the stick-figure was slightly different to that of the violinist model. And it was because of this that we ended up having weird movements, specifically for the melee animations. After we found this out, we scrambled to try to get at least the violinist model into the game just in time for our first-quarter presentations.

Shooting Balls and Hadoukens

(Coding a Material Shader)

Before the end of the first quarter I also wanted to receive credit for my Computer Graphics course through this project. So I decided to get into an aspect of video games that was nebulous to me, which was to make a material shader effect for one of the projectiles as part of my final project. 

One of the tutorials that I followed was recommended to me by another collegue of mine who attended UCI's Video Game Development Club. The developer of the tutorial goes by Freya Holmér, and was super helpful in helping me understanding how shaders work in the larger gaming industry, and how it involves an understanding of mathematical art. 

The tutorial was SUPER informational and interesting to get into, but it was no less very intimidating at first glance. The video was originally a livestream turned into a three-hour VOD. However, the biggest problem was that she was making the shader through Unity with GLSL using C#. So I had to find a way to translate the typed code into Unreal Engine 5's Blueprint interface. Luckily I applied the same principles in the video translated relatively well, considering that I've had ample time to get used to Unreal Engine's Blueprint system.

I then had to figure out how to apply the shader as a projectile effect. So I looked up some more YouTube videos. What ended up being the end product of the shader effect I made, was a bright-specular-blue-"Tremolo Flurry"-Hadouken to accompany the boring "Legato Beam" gray balls.

And even though submitting this much was not a hundred percent on my Computer Graphics class, and even though my team agreed that it was too out of place that it not end up in the final version of the game (the final version of the tremolo flurry projectile is SO MUCH better), I still consider coding and creating this shader a HUGE win. 

Top Photo: This photo depicts the shader itself as made through Unreal Engine 5's Blueprint Interface.

Middle Photo: This is the Niagara FX Blueprint system which transformed the shader I made into a believable projectile (AKA a Hadouken).

Bottom Photo: This gif showcases the bright-specular-blue-"Tremolo Flurry"-Hadouken in action from an older build of the game.

Left Photo: This is the full snippet of "code" for UE5's Shader Material in Blueprint Form. As you can see I took many liberties of using hardcoded numbers to make the shader work. There really is a lot. But I feel if I look into it a bit –and check myself through Freya Holmér's tutorial– I could decipher what everything does.

Second Quarter

It was around this time that Microsoft shadow-dropped a little game called Hi-Fi Rush. A game that put adaptive music video games back into the mainstream conversation. Partly because of the holiday break, as well as the release of Hi-Fi Rush, which essentially beat us to the punch for an adaptive audio beat-em up game, spirits were somewhat low coming back to the game in the state we left it to work on it for a whole 'nother quarter. Also considering that everyone else in my team were VGDC members and not part of the capstone class, I was pretty nervous with who was going to stay with us and who was going to understandably leave the project. 

Luckily enough, most of the team chose to stick with the game going into the second quarter. In the end, several people had to sit out/not work full-time for the quarter due to the lack of bandwidth they had. Of these people two of them were our Violinist, and our Lead Programmer. And although it was really unfortunate to have them leave, we were all in good terms and moved forward to try to finish this project off strong.

We initially wanted to try to get 3D modelers to help us out in possibly making new bosses. We then pitched the game once more to the Video Game Development Club, for the second quarter. Once we did it soon became apparent, however, that we needed someone to keep track of our progress.

So spirits started up low for our team, when initially not many interested members approached our team on the night of the Second Quarter pitch. 

It wasn't until Week 3, the week where teams were formed within VGDC, that we recruited three new members, Anna Park, Edem Sedor, and Yen Chi Nguyen; a beginner 3D modeler, a 2D Color Pencil Illustrator, and a Producer. Chi got the lay of the land for our team, and helped a ton in getting us to understand what we needed to work on and how to split the tasks accordingly. As such, Chi set us up with Trello to keep track of our progress throughout this quarter.

After the pitch night however, I felt like I needed to remind my team of why our game has great potential.

So I began sketching again!

"OK, We Gotta Hunker Down on Gameplay!"

(Designing the Gameplay Pt. 2)

Once we had our final team for Quarter Two settled, I personally began listing the things that needed to be worked on that I felt needed to be addressed with our game. I then sat down with my team the next day and one of the first things that I told them was: "We gotta hunker down on our gameplay, because we focused to much on implementing our Audio, that we forgot about how the game would play."

I then presented the points to my team, only to completely forget that I had to have our new producer touch base with the rest of the team. This ended up being very valuable to start off our development, since it gave context as to what each team member felt about the game in its current state.

After touching base, I resumed presenting what I believed needed to be improved with our game, just as a start to picking away at what would make the game fun. 

The following is the six different slides that I showed my team to work on: Losing Lock on, Lock on referencing, Player Fluidity – Jump attacks and Dodge animations, and Recovery, and finally a list of all the animations we needed. 

These among other problems, like the need for a knockback state, and the need to polish both the Tuba Boss and Violinist's attacks, as well as the camera being centered on the violinist, which obstructed the view of the player to be able to see where the boss is, was our main starting points of polish going forth for the Second Quarter. 

And as much as I would love to outline all the complexities of our game, I gotta wrap up. So, here's two case-studies of polish we made for the Violinist and Tuba Boss respectively.

Polishing the Violinist's Camera 

(Designing the Lock-on system)

The lock on that had been implemented since Quarter One, was very fragile in the sense that it breaks contact with the Tuba Boss whenever the player pushes the right analog stick to look around even slightly. It also didn't help that the controller input to lock on to the boss was to press the right analog stick in the first place. This, along with the fact that we had a reference to the whole Tuba Boss within the Violinist's Blueprint set off a ton of flags. Which is why we had to focus a fair amount of our time polishing it, and finding out how a regular lock on system works. 

Darius, our main audio programmer was assigned the task to try to fix the camera, which included placing the camera over the character's shoulder to let the player see what is in front of them, as well as fixing the lock on of the camera towards the Tuba Boss.

However, as our Audio Programmer started work on making a over-the-shoulder camera for the game, it became apparent that he wouldn't have enough time to complete both tasks, so I offered to help implement the lock on for the camera.

The lock-on proved to be a huge undertaking during development as well, and it came to the point where our mentor showed concern with us having too much of a high priority on the camera rather than the actual gameplay.

Luckily, I managed to figure out how to implement a lock on system that doesn't easily lose focus from the boss, with enough time to spare for other levels of polishing. 

My initial thought process as to how lock on systems work where the camera would "fight" the player the farther they looked away from the boss. This diagram depicts how I believed at the time that the rate of the camera rotating is normal towards the center, but decreases exponentially as you reach a certain distance away from the center, rather than the angle.

By making the game keep track of how far the center of the camera view is from the focus point of the boss, I managed to clamp the camera so that if it reached a certain angle away from the boss it would simply slow the camera's rotate rate to a halt. We also changed the lock on input to be on the left shoulder button, so that it wouldn't interfere with the camera in any way.

Polishing the Tuba Boss's Attacks 

(An inside look into the JumpSlam)

From the Jump Slam, to the Projectiles, all four moves of the boss had to be tweaked and redesigned in a way that felt both fair and fun to the player. As Quarter One ended, the boss was just way too unfair. It had no downtimes, no stun states, no choreography of his moves, moved like a dog with zoomies, and the lock on would break whenever the boss would do its jump slam, which was literally EVERY time the boss chose to do an attack...

The jump slam in general was very broken since Quarter One, and lasted well into the latter end of the Second Quarter. The way the jump worked at the end of the first quarter was that the boss would travel in a rectangular path, jump straight up, wait for a time, and then start tracking the violinist's position. After a time, the boss would stop hovering, and then slam down onto the player if they were directly underneath them. This whole sequence lasted a good 10 seconds, during which you couldn't lock onto and attack the boss at any point during it...

This was why we decided to try to implement an instant jump slam that provides ample time and coordinates to the player where the boss would land AND produces a shockwave that the player must jump over to not get hit. 

This whole process also took quite a bit of time to implement. At first we tried to make it so the jump slam's shockwave would spawn at a location on the boss where we thought the ground would be when the boss slams down. Turns out sometimes the boss slams just before or right after he actually lands, so nine-times-out-of-ten the shockwave would spawn above/below the ground, where the camera wouldn't see it. The way we ended up fixing this was that we were given the advice from our mentor to spawn the shockwave at a hardcoded value above the ground for the vertical world coordinate so that it consistently was visible for the camera.

A short sketch made to our team to express the urgency to fix this bug.

The other aspect of the shockwave was the hitbox that it produces. It's supposed to be exactly where the shockwave is displayed so that you can dodge it sufficiently. However, within the first few implementations, the shockwave would hit you way before the actual marker of the shockwave. Fixing this was a matter of making sure the speeds of the shockwave growing was the same between the effect and the hitbox mesh.

And finally we needed to have telemetry on the ground to show where the tuba boss would jump to as well as how far shockwave would travel. 

This was around the same time we figured out how to consistently spawn the shockwave from our mentor, so spawning the indicator was just as easy, if not easier, to implement using the hardcoded coordinate of the floor.

After these changes the jumpslam was fully functional and added so much to the fun of We Got Compagnie! game overall.

Post-Mortem

As a whole, I am extremely happy with what our team accomplished throughout these 6 months of work. It was such a fun journey, and I would go further to say that this was a huge turning point of my life, as I'm writing this just two days after completing this huge project. 

Here's my main takeaways: