Kenechukwu Umelo
Technical Game Designer | AI • Gameplay Systems • Open World • XR
Lunchroom Rumble 3D
Area of Focus: Systems & AI Design
Time of Development: 2 Weeks
Goals:
-
Design an engaging experience that brings moment-to-moment gameplay to keep players active and moving.
-
Practicing implementing a reactive enemy tree to create high-intense gameplay that doesn't stop.
-
Improved prototyping with time constraints.
A single-player action-fighter prototyped in Unity in just under 2 weeks. The prototype takes heavy inspiration from the classic Ed, Edd n' Eddy Lunchroom Rumble, a 2D flash game originally from Cartoon Network. This prototype represents a 3D interpretation of the classic 2D game, featuring a new third-person player controller, dynamic leaderboard, and AI systems built from the ground up using NodeCanva's Behavior Trees.
Intention
The goal of creating Lunchroom Rumble 3D was to reimagine the classic 2D brawler game as a full-scale 3D experience. While revisiting nostalgic computer games, I played the original 2D game and developed a deep appreciation for it. I chose to take the game in a 3D direction because I wanted to explore creating the game systems, mechanics, and AI bots that could capture the fun of the original 2D version with a new light.
Designing this 3D brawler made me realize the importance of moment-to-moment action, especially in keeping players engaged. In Ed, Edd n Eddy's Lunchroom Brawl, the chaos begins immediately as the AI characters move around the arena with two main behaviors: restocking food and throwing food at the nearest target. I had several ideas for adding unique twists and additional content to this 3D version, at somepoint I tried utilizing Unity's Netcode for GameObjects to allow multiplayer functionality, but given the limited time frame, I decided to focus on delivering a polished experience that closely mimics the charm of the classic 2D game.
2 Week Development Process
With the design and blueprint for the project already established from the 2D game, it was easy to begin working on various aspects of the 2D experience that needed to be adapted for a 3D setting. In the first week, I focused on creating the third-person controller. Thanks to previous prototypes, I was able to use a custom template, make some adjustments, and incorporate additional features. I also developed the AI using Behavior Trees and systems to influence their decision-making. In the second week, I concentrated on designing a health-based dynamic leaderboard similar to the one in the 2D game, while also polishing the experience with a new test scene.
Feel free to review more technical details on the main areas of development and my design decisions with the dropdowns below:
Building the 3rd Person Controller
With a template controller established, creating the third-person felt more like an expansion than a complete revamp. For the direction I wanted to go, I went with a more camera-oriented controller as it best fit the type of on-screen action that players need to be aware of. I added a visual tray that displays the foods that players collect from the food station, thereby showcasing the types of food they can throw in order. This is a result of a dynamic link script between the foods on the player's tray and the UI that showcases their food ammunition. It updates as the player throws and empties their tray, keeping them informed of when their tray is out of food at all times.
With health and score components implemented, now for the challenging task, aiming and throwing the food.
Early Movement + Throwing Pass
Problem:
Aiming and throwing were a bit of a technical challenge; it wasn't as easy as just throwing on Unity's physics system (Rigidbody), since the player was offset with an aim down sight, and foods needed to be thrown at the aim sight direction, which couldn't be fixed with Unity's Rigidbody component, as it didn't support whether players were running around the scene as the food projectiles would always be offset or just be thrown at high speeds. It was clear that I needed to avoid using physics this time, and a more elegant approach for food gets thrown.
Solution:
To effectively aim and throw, I needed a projectile logic that not only accommodates player movement but also continuously tracks the positions where the player is aiming. I reviewed various aspects of 3D math related to projectile motion and simplified it into a straightforward formula. This formula involves subtracting the target position (the point hit by the raycast from the main camera) from the player's direction. Then, using this new vector, I multiply the throw power by the forward distance direction and the target's y-coordinate. This approach ensures accurate throws that account for both player movement and camera rotation at all times.
My custom projectile formula in which the food projectile follow
Behavior Tree and Systems for AI Bots
I believed the implementation of AI in the original 2D game was simpler, but I wanted to challenge myself by using behavior trees. My goal was to create a more adaptable and reactive AI that would truly challenge the player. I designed two custom systems that contributed to the AI's behavior tree, enhancing its decision-making. This way, the AI ensures that players do not feel safe if they stay in one place, keeping the action engaging from start to finish. With the custom targeting and ammunition check systems, it provides clear runtime updates to the tree's conditional tasks, causing immediate behavior tasks. It felt emergent at times, as it meant that the player can be hit from any direction at any time if they are accidentally caught in the crossfire.
Targeting:
In this game, targeting involves two types of radius checks: search and combative. The search radius helps the AI identify its closest opponent, while the combative radius determines whether the opponent is within range for an attack. At first, I questioned the need for a combative radius when I was prototyping the system. However, I realized that if the target is already nearby, the AI doesn’t need to move physically; it can simply rotate toward the target and throw food at them since they are within range.
Problem:
In certain situations, the AI sometimes ignored food thrown by opponents who were farther away because it was outside the designated combat or search radius. This occasionally resulted in moments where the AI would run past each other without reacting, as the polling checks failed to detect nearby opponents within the specified radius at that time.
Solution:
I implemented ownership checks for food projectiles, tagging the AI or player as the projectile's owner. This ensures that the AI immediately targets the opponent who threw it, capturing the same feel from the 2D version with
Assigning ownership to thrown foods
Finding the nearest target
Refilling Tray with Food:
The AI ensures that food is always on its tray before it detects targets. This creates a loop that tells the AI to rush to restock its tray immediately. I implemented a boolean condition task that guarantees the AI continually refills its tray at the bar when it has no food to throw. This condition task has the highest priority in the behavior tree, meaning it overrides other behaviors. As a result, this leads to a flee-like response from both the player and other AI bots during engagements.
Problem:
This approach was necessary to provide a sense of emergence to the game for the AI, but then it led to this issue:
Clustering issue: the AI remains close to food stations. Not utilizing the space.
Solution:
To address the clustering issues, I took several steps to ensure an effective solution. First, I implemented a short combat lockout timer that activates when the AI exits the station's trigger boundaries. This prevents the AI from immediately targeting players with food or other attacks. Next, I reduced the arena size so that the AI could consistently detect nearby targets, including the player, more effectively. Finally, I adjusted the combat and search radius limits to encourage the AI to explore the arena continuously. It was crucial for the AI to actively navigate the space at all times.
AI now explores the spaces while targetting opponents and the player.
Character Creation Tool:
Once the initial prototype was complete, I aimed to create seven different NPCs for the demo myself. However, due to time constraints, the process was time-consuming. To speed up the character customization for the prototype, I implemented a quick character-creation inspection tool that utilized Synty's Kids Assets to generate random designs for AI bots. I was gonna go for headshot captures, but that was out of scope within the time frame.
Health-Based Dynamic Leaderboard
The final piece of the puzzle for the project was recreating the dynamic leaderboard from the original 2D game, which was based on the health status of every opponent and player. With Unity horizontal alignment UI components and match manager scripts, I was able to accomplish the polaroids updating based on everyone's health. The dynamic update function does, unfortunately, take place in an Update loop, which I wanted to avoid for memory's sake, but for the time, it was a more straightforward solution than tracking through projectile hits for every single opponent in the scene.
Problem:
While I appreciated the showcase of how the dynamic leaderboard was the only way to view your current health in the 2D game, I felt that in a 3D setting, it could cause lots of confusion, especially with an arena full of flying food models distracting the player from viewing their health from the HUD.
Solution:
For the player's HUD, I added their own health bar to personally view. With this addition, it helps the player maintain focus on health and immersion rather than constantly eyeballing the leaderboard every few seconds. My original plan was to implement a spectator mode that would give players a look at the AI bots through the same perspective, with their health bars being present along their tray visual.
Code Samples
PlayerController.cs
Code below contains functionality for how I bulit the third person controller.
StudentAI.cs
Code below contains functionality for the AI bots including the search and combative checks.
Post Mortum
What went well?
-
Strong Foundation and Blueprint
-
Starting strong, I already had the reference to the game I wanted to recreate. It was more about dissecting the design of the 2D version to figure out what would work in 3D or not. This helped make the transition with certain mechanics easier to implement.
-
-
Rapid Prototyping and Implementation
-
Effectively working within 2 weeks to deliver a 3D arena action fighting prototype with a player and six AI bots. Turned out quite successful for me.
-
What went wrong?
-
Imposter Syndrome with Behavior Trees
-
I had previously misused Behavior Trees in the past by forcing them to manage random attack selection and transitions for complex AI. It was important to understand how tasks and priorities worked with simple behaviors for effective gameplay.
-
-
Attempting New Things with Short Time
-
At one point, I attempted to implement multiplayer and other complex mechanics. However, I quickly realized that I was straying from the necessary focus to complete the project within two weeks. Simplicity is key, and it’s easy to get sidetracked when trying to create features that introduce unnecessary complexity and extend the timeline.
-
Potential Next Steps?
-
Unreal Engine
-
With Ed Edd n Eddy's Lunchroom Brawl and this prototype as reference, I hope to expand the project to a higher quality using a more powerful engine that can bring out the best in the mechanics (Gameplay Ability System for Foods?) and graphical quality.
-
-
Multiplayer (Co-op & Online) Functionality
-
At one point, I wanted multiplayer in the game to help it stand out from the 2D game. This game is proven to fit that kind of functionality naturally, either as a couch co-op or online with other food fighters out there. I believe that the game's mechanics, arena, and battles are best presented with live players engaging in combat with one another.
-
Resources
