Retirement Rumble Fabled Fogies
Vancouver Film School | Game Designer & Programmer | June 2024 ~ December 2024 | itch.io page​
Retirement Rumble: Fabled Fogies is a 3D isometric slap-fighter featuring six retired high-fantasy legends competing with each other for the late Raging Rita’s Big Room. In honor of Raging Rita’s Rambunctious life, travel to her favorite vacation hotspots to duke it out! Knock out your three opponents and throw them off the arena to be the last fogie standing.
​​
For this project, I had incredible teammates who made working on the entire project a joy. From early design meetings buzzing with creative discussions to hunkering down to bring in the final bits of polish, there wasn't a single step of the way that wasn't enjoyable or educational.
​
​
Accomplishments
Observer pattern implemented with UniRx, for increased scalability and rapid iterations
Ragdoll Physics
Bone transforms of the first frame of the animations are saved in Awake before being used in the ResettingBones method for the ragdoll.
THE ISSUE
Initial reactions of laughter to watching our characters fly across the screen cemented ragdoll physics as a core part of our game. But there was a problem with how characters weren't necessarily dead when they did get ragdolled. How could we get our characters to stand back up again in a natural manner? Having our floppy ragdolls abruptly snap into an animation for getting up was not an option for me.
​
THE SOLUTION
To solve this I added an intermediary state, between being KO'd and getting up, interpolating the transform of the character bones to the position of the bones in the first frame of the getting up animation. I had to make some adjustments for the animations themselves given our character's unique proportions compared to a standard human model, but I was quite satisfied with how things turned out. The result can be seen above, with characters smoothly transitioning back to their original animating state to start slapping again.​​​
Level Hazards
Interfaces were used extensively along with UniRX for interactions between objects. In this example, the tentacle checks for the ITargettable interface of objects that get hit, with additional checks for player stats if the target is a player.
OVERVIEW
Every level contains a unique level hazard meant to emphasize one of our core gameplay pillars "Controlled Chaos". Controlled in the sense that each action in the game would be simple and easy to follow, but chaotic in that there would be so many of these actions going on at once that it would be difficult to keep track of them all. ​​​​​
​
My time implementing these level hazards was not only a great test of my knowledge of Unity, juggling state machines, animation events, and physics systems, but also proved to be a great design workout as our initial ideas for each hazard ended up playing out very differently in the build. ​
​​
DESIGN CHANGES
Among the hazards, the one that went through the most changes is the dragon. The initial design was for it to exhale a gust of wind to nudge players off the arena. While we tried to stick with the idea for as long as possible to stay in line with our "elderly people" theme, playtests quickly revealed the cracks in our paper design. The problem was twofold:
​
-
Compared to our other level hazards, which directly threatened to KO our player at all times, the dragons' roundabout method of pushing people off the map was much more difficult to pick up and immediately understand.
​
-
The threat itself felt too weak compared to others. A direct hit from stage hazards in our other levels was a prime opportunity for players to snag a point, but here players just had to play a waiting game.
​
The solution I came up with was to have the dragons instead shoot out projectiles which would directly KO players, and potentially fling them off the stage if the collision lined up right. On paper, this solved both of the gameplay issues from above while maintaining the theme and flavor of our game. Playtests ended up proving this idea as players immediately understood the implications of the bones being shot at them, playing around the projectiles in an actively strategic manner similar to the other stage hazards.
Reactive Event System
UniRx was extensively used for communication between game objects, like the cannon warning indicators above, the code snippets below show how it was implemented
Adding to the event stream was as simple as passing in a custom struct into a static method defined in MainEventHandler when the players were loaded in​​​​​
​
The indicators only need to listen to the event hub for the corresponding events passing through. Further filters can be added for more specific reactions.
UniRX was also used extensively for various types of stat tracking which we used for player cards at the end of each match.
WHY RX?
Initially, we were using actions and directly subscribing and unsubscribing methods, creating tight coupling between game objects. While not a problem at first, the signs of cumbersome iteration cycles and serious clean-up work for major changes were already beginning to show. Thankfully, we were introduced to Reactive Extensions for Unity (UniRx) and were shown an event-handling system based on reactive programming that solved these issues for us almost immediately.​
​
The gist of the event system is that we would subscribe methods to listen for a specific event from a centralized event handling hub which received data whenever an event was added to the stream.
​​​​
​THE END RESULT
Thinking of events as data streams to listen into was a paradigm shift but it was worth the effort it took to adjust. It not only saved us a ton of overhead whenever we wanted game objects to have specific interactions with each other, but it also granted us great flexibility for iterating on features. We didn't have to worry about null references whenever objects were deleted or changed, and the customizable nature of the data streams gave us much greater control over how the game objects reacted. I look forward to what more I can learn from mastering reactive programming and hope to continue using it to great effect in future projects!
​
Interactive Props
OnEnable is used here for the Object Pooling system to increase performance. PrimeTween Sequences were used extensively for smaller animations involving positions, rotations, and shakes.
The two methods referenced in the above PrimeTween Sequence. localPosition is reset to zero so that the fragments return to their proper location to be called the next time an object gets shattered. Otherwise, the displaced fragments return to the pool in their destroyed state. ReturnToPool is an inherited method from the PooledObject class which this script inherits from.
OVERVIEW
Interactive props came as a result of playtesters trying to use the decorative placeholder props. Instead of taking the props out to try and encourage the players to play "correctly", I decided to expand on this feedback resulting in the various destructible game environments and the cannons.
​​
While the ideas and execution were mine, the journey was deeply collaborative—I worked closely with our environment and vfx artists to ensure the visuals aligned with the game’s aesthetic and partnered with our level designer to refine these features based on further player feedback.
​​
This feature set felt like the culmination of everything I’d learned over the year, blending technical and design skills to create dynamic and engaging gameplay. Seeing it all come together was as rewarding as watching a party of playtesters burst out in laughter as they interacted with these features!
​