Baldi Basics Classic Remastered — Gameplay Overview
Mild Horror Educational Game Prototype | 4-Week Production | 2026
This prototype is a gameplay-focused recreation of the core experience of Baldi’s Basics Classic Remastered, developed in Unreal Engine. The project centers on translating the game's primary gameplay loop into a functional first-person prototype, with an emphasis on player movement, exploration, item interaction, inventory management, stamina, progression, and escalating enemy pressure.
Players navigate the school environment to locate and collect notebooks while managing their movement and stamina. As progression continues, Baldi becomes an increasingly persistent threat, creating greater pressure on the player to make efficient decisions, navigate the environment strategically, and balance exploration with survival.
The project was developed as a hands-on exercise in gameplay system implementation and iteration. The prototype focuses on how individual systems work together to support the larger player experience, including movement, interaction, inventory and item usage, progression, enemy behavior, and the fail-and-retry gameplay loop.
The gameplay video below demonstrates the prototype in action, while the accompanying postmortem provides a closer look at the development process, technical challenges, iterations, and lessons learned throughout the project.
Project Post Mortem: Baldi's Basics Classic Remastered Prototype Introduction
For this project, I recreated a mild horror educational game prototype inspired by Baldi's Basics Classic Remastered in Unreal Engine 5. The goal was to deconstruct the original game and rebuild its core gameplay loop based on research and documentation. My prototype focuses on exploring the school, collecting seven notebooks, answering math problems, interacting with doors and items, managing an inventory, and eventually reaching the correct exit after completing the objective.
This project involved much more than simply recreating the appearance of the game. I had to break down how each system connected to the overall gameplay loop and then implement those mechanics in a way that worked together. Throughout development, I ran into several problems that required me to rethink my original approach, debug my Blueprint logic, and make adjustments as the different systems began interacting with one another.
What Went Right
1. Notebook Collection and Inventory UI
One of the biggest successes of the project was getting the notebook collection system and inventory UI working together. The notebooks are the primary objective of the prototype, so I needed the collection process to clearly communicate progress to the player.
When the player collects a notebook, the game updates the collection logic and the notebook is represented in the UI. This was important because the notebooks are not just collectibles. They directly control the progression of the entire gameplay loop. Building this system helped me better understand how gameplay events, variables, and UI elements need to communicate with one another instead of being treated as completely separate systems.
2. The Win Condition
One of the biggest successes was implementing the complete win condition. After collecting all seven notebooks, the player is able to reach the correct set of exit doors and complete the prototype.
I wanted the ending to feel connected to everything the player had been doing throughout the level. Instead of simply ending after the final notebook was collected, the notebooks act as the requirement that unlocks the final objective. This created a complete gameplay loop: explore the school, collect all seven notebooks, and then make it to the correct exit.
Getting this working was especially important because it gave the prototype a clear beginning, objective, and ending rather than just being a collection of individual mechanics.
3. Door Interaction Throughout the Gameplay Loop
The doors ended up becoming one of the most consistently used mechanics in the prototype. Since the player is constantly moving through classrooms and hallways, the door system needed to work reliably throughout the entire experience.
I was able to get the doors operating as intended for the player, which made exploration feel much closer to the original gameplay loop. This also reinforced the importance of thinking about how often a mechanic will be used. A door may seem like a simple interaction, but when the player is opening doors throughout nearly the entire prototype, even a small problem with that system becomes very noticeable.
4. Math Widget and Player Feedback
The math widget was a mechanic that came together successfully. When interacting with a notebook, the player is presented with math problems and can submit an answer. The system then provides feedback based on whether the response is correct or incorrect.
This was important because it recreated more than just the act of collecting an object. The notebook interaction became its own gameplay moment. The player has to stop, interact with the notebook, respond to the questions, and then receive feedback before continuing.
I think this helped make the prototype feel more like a functioning recreation of the gameplay loop instead of simply placing notebook pickups around the level.
The tension surrounding the math problems also helped recreate the mild horror intended in the original game. While the player is answering basic math questions, they can hear Baldi's footsteps moving through the school. As his footsteps become louder and feel closer, the player is placed under more pressure to finish the questions and continue moving.
The math itself is simple, but completing those problems becomes more stressful when the player knows Baldi could be getting closer. Combining the educational mechanic with the growing tension from Baldi's presence helped make the experience feel closer to the original gameplay loop.
5. Connecting Multiple Systems into One Gameplay Loop
The biggest thing that went right was seeing all of the individual systems come together. By the end of the project, the prototype included exploration, doors, notebook collection, math interactions, item pickups, an inventory system, NPC interaction, and a final win condition.
Each of these systems had to communicate with others in some way. For example, collecting notebooks affected the win condition, items needed to appear in the inventory, and the quarter needed to be available when interacting with the Bully. Working through these connections helped me grow as a designer and developer because I had to think beyond whether an individual mechanic worked on its own. I had to consider how it fit into the larger gameplay experience.
What Went Wrong
1. The Bully and Quarter Interaction
One of the more interesting problems involved the interaction between the Bully and the quarter. My original logic treated the quarter as something the player possessed once it had been picked up. However, that did not properly connect with the inventory system I had created.
As a result, the Bully originally would not accept the quarter. I had to go back through the logic and change the system so that the quarter was checked through the inventory item pickups rather than through the player the way I had originally designed it.
This was a good example of how an assumption I made early in development caused a problem later. In my mind, picking up the quarter meant the player automatically "had" it. However, the game needed a more specific way to determine where that item existed and how other systems could access it. Once I changed the logic to work directly with the inventory system, the interaction worked correctly.
2. Items Were Collected but Not Displaying in the Inventory
An issue I encountered involved the inventory system. The item pickups were being collected correctly, and the underlying inventory logic was working, but the items were not displaying properly in the inventory UI.
For example, if the player picked up two quarters, both quarters were actually being added to the inventory. However, the inventory UI would only display one quarter. To the player, it looked like they only had one quarter, even though the actual inventory contained two.
The problem turned out to be that I was not setting the necessary variable. The system had most of the information it needed, but because that variable was never properly updated, the UI was not displaying the inventory correctly.
This was one of those problems where the mechanic appeared much more broken than it actually was. The items were technically being collected, but the visual feedback made it look like the inventory was not working correctly. It reminded me how important it is to check the entire chain of a system, especially when gameplay logic and UI are communicating with each other.
3. Baldi's Collision with Doors
Baldi's collision and interaction with doors also required more adjustment than I originally expected. At first, I used a Begin Overlap approach, but when Baldi walked up to a door, it would not open consistently.
I eventually changed the setup so that Baldi's collision was handled as a component of the door interaction. This gave me a more reliable way for the door to recognize when Baldi was present and respond appropriately.
This problem taught me that collision and overlap logic can work differently depending on what is interacting with the system. The same door logic that worked for the player did not automatically work the same way for Baldi, so I had to adjust the implementation instead of assuming one interaction setup would handle every situation.
4. Building the Hallways with Perfect Angles
One of the more time-consuming parts of the project was constructing the school hallways using planes as walls. The challenge was placing them precisely enough to maintain clean 90-degree angles while also making sure the player could not see into the void outside of the playable level.
Because the prototype is based on a very recognizable layout, even small gaps or slightly misaligned walls could become noticeable. This required a lot of adjustment and checking from the player's perspective.
While this was not necessarily a complicated Blueprint problem, it was a reminder that level construction requires precision. A level can look correct from one angle in the editor but reveal gaps or alignment issues once the player begins moving through it.
5. Assumptions Between Systems
Looking back at the project, several of these problems came from making assumptions about how one system would connect to another. The quarter issue is one example, but the inventory display and Baldi's door interaction were similar situations.
In each case, I initially had the individual pieces working in some form, but I still had to adjust how those pieces communicated. The project taught me to spend more time thinking about the flow of information between systems rather than only focusing on whether each mechanic works independently.
This is something I will carry into future projects. When designing a mechanic, I now think more about what information it needs, where that information is stored, and which other systems will eventually need access to it.
Conclusion
This project gave me the opportunity to take a recognizable gameplay experience and break it down into individual mechanics and systems that I could recreate in Unreal Engine 5. By the end of development, I had a complete gameplay loop where the player could explore the school, interact with doors, collect items and notebooks, answer math problems, manage an inventory, interact with the Bully, and complete the objective by collecting all seven notebooks and reaching the correct exit.
The project was not without problems. Several systems required me to revisit my original logic, particularly when it came to inventory communication, item interactions, collision, and connecting multiple mechanics together. However, working through those issues was one of the most valuable parts of the project.
The biggest takeaway I have from this prototype is that a game is more than a collection of individual mechanics. Each system has to communicate with the others to create a complete experience. Solving the problems that came up during development helped me better understand how to approach that process, and I will be taking those lessons into my future Unreal Engine projects.
Call of Duty: Modern Warfare Zombies— Gameplay Overview
FPS/Zombie Survival Prototype | 4-Week Production | 2026
This prototype recreates the core survival experience of Call of Duty: Modern Warfare Zombies in Unreal Engine, with a focus on first-person combat, player interaction, and surviving increasingly dangerous waves of enemies. Players use firearms and melee attacks to eliminate zombies while navigating the environment and managing the immediate pressure created by the advancing horde.
A major focus of the project was developing the first-person gameplay presentation and combat mechanics from the ground up. Rather than modifying a template character, I created the first-person arms and gloves specifically for the prototype, giving me greater control over their movement and animation. This allowed me to develop custom firing, reloading, and punching interactions that could be tailored directly to the gameplay experience.
The prototype brings together multiple gameplay systems, including weapon firing, reloading, melee combat, zombie waves, enemy damage and ragdoll reactions, and a clear objective and completion condition. Each system was developed to contribute to a complete gameplay loop in which the player must actively use the available mechanics to survive and progress.
The gameplay video below demonstrates these systems working together in the prototype, showcasing the first-person combat experience and the mechanics developed throughout the project.
Save the Snowman — Gameplay Overview
Blockmesh Prototype | 4-Week Production | 2026
Save the Snowman is a single-player, first-person winter level built around time pressure, exploration, and player choice. The goal is simple: collect six survival items before the snowman melts, using optional objectives to strategically delay the timer.
Created as a blockmesh prototype in a 4-week production cycle, this project focuses on core level design skills—clear pathing, readable objectives, and tightly integrated mechanics—over final art.
This gameplay highlights key systems including snowball interaction, icy traversal, and parkour, demonstrating how players balance speed, risk, and exploration under pressure.
Target Tumble Trail Level Design Overview
FPS Prototype | 4-Week Production | 2026
Target Tumbleweed Trail is a target-driven traversal level that blends precision shooting, resource management, and puzzle-solving into a tightly paced player experience. Players must carefully manage a limited bullet supply to activate targets, unlock gates, and control their progression through the level.
Each phase introduces a new layer of challenge—starting with efficiency-focused target gameplay, shifting into high-risk platforming with meaningful fail states, and culminating in a logic-based number puzzle that gates the final path forward. The design encourages deliberate decision-making, rewarding accuracy, planning, and adaptability.
The result is a focused, mechanic-driven level that balances tension and progression while showcasing strong pacing, system integration, and player-first design.
Platformer Level Design Overview
Platformer Prototype | 4-Week Production | 2026
Platformer is a precision-driven experience built around mobility, combat, and layered puzzle interaction. Players control a fox with a double jump and ranged fireball attack, navigating a hazard-filled environment where timing, positioning, and decision-making define success.
Core systems work together to drive progression—levers and pressure plates dynamically control doors and pathways, encouraging experimentation and route planning, while spikes and a limited life system introduce meaningful risk and reinforce careful execution. Combat is integrated into traversal, allowing players to eliminate threats or outmaneuver them through skillful movement.
The level follows an Introduce, Practice, Master structure, gradually building player confidence before increasing complexity and precision demands. Platform spacing, enemy encounters, and projectile behavior were refined through playtesting to ensure fairness, responsiveness, and player agency.
The result is a tightly tuned platforming experience that blends movement, combat, and puzzle-solving—demonstrating strong gameplay balance, intentional difficulty scaling, and player-focused design.
Magical Mayhem Adventure Game Overview
Adventure Prototype | 4-Week Production | 2025
Magical Mayhem is a systems-driven adventure game focused on combat, mobility, and player survivability within a modular framework. Built as part of a class assignment, the project emphasizes how interconnected mechanics create a cohesive and engaging player experience.
Players utilize a spellbook system featuring health restoration, enhanced leaping, and ranged fireball attacks—supporting multiple approaches to traversal and exploration. A mage NPC delivers contextual dialogue that explains each spell and guides players on when to use them in upcoming puzzles and scenarios, reinforcing learning and smooth progression.
A checkpoint system maintains forward momentum, while a lightweight inventory system supports pickups and interactive items, encouraging exploration and strategic decision-making. Health management ties these systems together, creating tension and rewarding efficient play.
The result is a focused adventure experience that blends exploration, progression, and guided learning—demonstrating strong system integration, gameplay clarity, and player-centered design.
Space Shooter Gameplay Systems Overview
Arcade Prototype | 1-Week Production | 2025
Space Shooter is a top-down arcade experience built in Unreal Engine as a class assignment, focused on wave-based encounters and responsive player feedback. I implemented core systems from scratch, including projectile shooting, a wave spawner, and tracking for score, lives, and progression.
A Game Mode-driven flow handles menu, gameplay, pause, and reset states, supported by a custom HUD for clear, real-time feedback.
I elevated the project with added polish—an intro sequence with audio, layered sound effects for key actions, a countdown tick between waves, and refined UI styling. The player ship features dynamic visual feedback, shifting from blue emissive to flashing red on damage.
The result is a tight, feedback-driven arcade loop that highlights strong system design, clean UI integration, and impactful gameplay polish
Blockmesh 2 Adventure Exploration Level Design Overview
Arcade Prototype | 1-Week Production | 2025
Blockmesh 2 is an adventure exploration level built around clear player guidance, vertical traversal, and intentional pacing. Structured into Start, Focal Point, and End, the level uses sightlines and camera framing to naturally pull players forward and upward.
A rhythm of prospect and refuge spaces creates tension and release, encouraging exploration while teaching climbing and navigation through play. Gates and one-way valves control progression and prevent backtracking, reinforcing purposeful movement and flow.
The result is a clean, vertically driven experience that emphasizes readability, momentum, and guided exploration—showcasing strong fundamentals in player flow and spatial design.
Connect with Me
© 2035 by My Site. Powered and secured by Wix