Dead Ops Arcade-Inspired Procedural Level Assembly System
This single-player top-down shooter was developed in three weeks as a team project inspired by Call of Duty: Black Ops' Dead Ops Arcade mode. My primary responsibility was leading the design and implementation of the procedural room assembly system, which spawns and connects pre-built room layouts to create unique level configurations for each playthrough. The project also included player HUD development, player controller implementation, and overall system architecture decisions.
The room assembly system uses a minimal parent Blueprint (BP_RoomBase) that provides foundation structure: a platform, starting point, and scene component for the Exits List. All child rooms inherit from this parent but are individually hand-built with their own unique layouts. Examples include BP_StartingRoom (player spawn), BP_Hallway (straight corridor), BP_LeftHallway (left turn), and BP_MedBay (dead-end room with medical beds and no exits). The procedural element comes from which rooms spawn, where they connect, and how the system validates available exits.
Rooms generate by checking the Exits List, validating collision boundaries through collision boxes, and spawning connected child room prefabs that form cohesive level layouts. A counter-clockwise hole-plugging algorithm ensures clean level boundaries by sequentially placing fences and corner pieces that detect neighboring geometry and adapt accordingly. This modular approach allows rapid room variety expansion—designers can create new child Blueprints inheriting from BP_RoomBase without modifying core spawning logic.
The game currently features a single zombie type with AI pathfinding, one rifle weapon, and three deployable turrets. Players navigate the procedurally assembled rooms while fighting escalating zombie waves. Currently, the game reaches Wave 4 before encountering a crash bug that represents the primary target for future development. Time constraints significantly impacted scope—while I dedicated the full week to development, most team members contributed primarily during the final weekend before the deadline.
The core design philosophy centers on replayability through procedural room assembly rather than hand-crafted level memorization. Each session presents fresh spatial configurations by spawning different combinations of pre-built room prefabs and connecting them through the exit validation system. The BP_RoomBase architecture ensures that assembled levels maintain gameplay functionality even when visual variety is limited, prioritizing fair layouts and tactical options over aesthetic diversity given the three-week timeline.
The modular prefab approach trades pure procedural generation for reliable content creation. Rather than algorithmically generating room geometry that might produce unfair or broken layouts, the system spawns hand-built child rooms that designers have validated individually. This hybrid approach provides procedural unpredictability in level configuration while maintaining the quality control of hand-crafted spaces. Dead-end rooms like BP_MedBay add natural termination points that create variety in path flow.
The arcade mentality manifests through wave-based progression that eventually guarantees failure rather than offering victory conditions. Players chase "how long can you survive" rather than "can you complete the game," transforming each session into a score-chasing attempt. While the current implementation reaches Wave 4 before crashing, the underlying design supports infinite scaling where difficulty increases faster than player power, maintaining the arcade tradition of inevitable death driving replayability.
Technical constraints shaped design decisions throughout development. The single zombie type and rifle weapon reflect the reality of a three-week timeline with uneven team availability rather than deliberate minimalism. However, these limitations forced focus on core systems—the room assembly architecture, player controller responsiveness, and AI pathfinding—that provide a solid foundation for future content expansion without requiring system rewrites. Additional room prefabs, zombie types, and weapons could be added through the existing modular structure.
This three-week project faced significant time constraint challenges. While I dedicated the full week to development, most team members contributed primarily over the final weekend before the deadline. Despite these limitations, the core procedural room assembly system and arcade gameplay mechanics were successfully implemented. The game currently reaches Wave 4 before encountering a crash bug that would be the first priority in continued development.
Algorithm spawns and connects pre-built room prefabs with validated exit placement, collision checking, and strategic dead-end rooms for endless layout variety
Zombie waves increase in difficulty as players progress, with spawn rates and enemy counts escalating to create mounting challenge (currently functional through Wave 4)
Hand-built child room Blueprints (hallways, turns, dead-ends) inherit from minimal parent structure, enabling rapid content creation without modifying core spawning logic
Responsive top-down controller with rifle weapon, deployable turrets for area control, and clear HUD feedback for health, wave count, and remaining enemies
Researched Dead Ops Arcade gameplay mechanics and established the core vision for procedural generation-driven replayability. Designed the BP_RoomBase parent class architecture with standardized X=1 orientation for consistent spawn logic. Divided tasks among the five-person team: I would lead procedural generation and player systems, Frank would handle zombie AI, Alecsander would implement pickups, William would build turret mechanics, and Gavin would create menu systems. Established Perforce as version control and communication protocols for the distributed team.
Built the core room assembly algorithm using the BP_RoomBase parent system. Implemented the Exits List tracking and collision box validation to prevent overlapping geometry. Developed the counter-clockwise hole-plugging algorithm through extensive iteration, testing different approaches until discovering the sequential fence-then-corner checking methodology that reliably closed level boundaries. Created the modular room spawning system that allows new room types to be added without modifying core generation logic. Built hand-crafted child room prefabs: BP_StartingRoom, BP_Hallway, BP_LeftHallway, BP_MedBay, and others.
Developed the player controller with top-down camera following and shooting mechanics. Built the Player HUD to display health, remaining zombie count, and wave progression. Encountered the wave counter bug that displayed "Wave 0" persistently, initially treating it as a lower-priority issue to address after core functionality was complete. Integrated player movement with the procedurally assembled rooms, ensuring collision detection worked correctly across varied prefab layouts.
Frank implemented zombie AI pathfinding using Unreal's navigation system. Discovered that the nav mesh wouldn't update for procedurally spawned room prefabs. Developed the workaround solution: Level Blueprint moves the nav mesh bounds volume 1 point on the X axis and back after each room assembly completes, forcing Unreal to redraw navigation lines. This inelegant but functional approach enabled zombie pathfinding across generated spaces without manual nav mesh rebuilds or runtime generation systems.
Most team members completed their assigned components during the final weekend before submission. Alecsander implemented health and damage pickups, William built the deployable turret system, and Gavin created the menu interface. Integrated all systems into the unified project through Perforce, encountering some merge conflicts but resolving them through communication. The uneven time investment (my full week versus others' weekend contributions) meant some planned features like multiple zombie types and additional weapons remained unimplemented.
During final cleanup, attempted to delete unused assets to reduce project size. Deleted what appeared to be an unnecessary Game Manager Blueprint, which immediately broke the game and revealed the source of the wave counter bug. The HUD had been referencing wave data from the "unused" manager rather than the active player systems. Rebuilt the HUD to reference the Player Character directly, which resolved the wave counter issue. Submitted the project with functional procedural room assembly, working player systems, and zombie AI, though the Wave 4 crash bug remained unresolved within the deadline.
Built a minimal parent Blueprint (BP_RoomBase) that provides foundation structure all child rooms need: a platform base, starting point marker, and scene component for the Exits List. This parent contains no room layout geometry itself—it exists purely to define the interface that all child rooms must implement. Every child room inherits from BP_RoomBase and starts at the X=1 orientation, ensuring spawn locations are predictable in the X direction from world origin (0,0,0).
Each child room (BP_StartingRoom, BP_Hallway, BP_LeftHallway, BP_MedBay, etc.) is individually constructed with custom geometry and layout. BP_StartingRoom contains the player spawn point. BP_Hallway creates straight corridors. BP_LeftHallway provides 90-degree left turns. BP_MedBay represents dead-end rooms with medical beds and no exits. The procedural system spawns these pre-built prefabs rather than generating room geometry algorithmically. This modular approach allows designers to create diverse room types by building new child Blueprints without touching core spawning logic.
Each room maintains an Exits List tracking all possible connection points defined in that room's layout. When the system spawns a connecting room, that exit is removed from the available pool. Collision boxes validate exit availability before spawning, checking for obstructions or overlapping geometry. This prevents rooms from spawning inside each other or creating impossible spatial configurations. The system checks each potential exit, spawns appropriate child room types, and manages the connection logic between prefabs.
After spawning the core room structure, the system identifies exposed exterior edges (maximum 2 fields outward) and plugs gaps using a counter-clockwise detection algorithm. Fences spawn first, then check for neighbors. If a neighbor exists, skip action. If no neighbor is detected to the left, create Corner Left. Then check right: if no neighbor exists, create Corner Right. If Corner Left already exists, delete it and spawn Inside Corner instead. This iterative approach reliably closes level boundaries regardless of which child room prefabs the system selected during assembly.
Zombie AI pathfinding required a functioning nav mesh across the spawned room prefabs. Since Unreal's nav mesh bakes to static geometry, I implemented a workaround: the Level Blueprint moves the nav mesh 1 point on the X plane back and forth after each room assembly completes. This forces Unreal to redraw navigation lines, creating functional pathfinding across the newly spawned prefabs without manual rebuilds or runtime nav mesh generation systems.
The fence-spawning system uses neighbor detection to determine what geometry exists adjacent to each exterior edge. By checking counter-clockwise from each potential spawn point, the algorithm identifies whether to place walls, corners, or interior transitions. This context-aware approach creates clean level boundaries around the assembled room prefabs that feel hand-crafted rather than algorithmically generated. Dead-end rooms like BP_MedBay (which have no exits) naturally terminate paths, adding variety to the level flow.
The most significant technical challenge in the procedural assembly system was reliably plugging holes where room edges met empty space. Early attempts produced gaps in level boundaries, overlapping corner pieces, and inconsistent fence placement. Testing iteration after iteration revealed no consistent pattern until I fundamentally rethought the approach from simultaneous checking to sequential validation.
Developed a counter-clockwise checking algorithm that spawns fences first, then has each fence check for neighbors. If a neighbor already exists, skip action to prevent duplicates. If no left neighbor is detected, create Corner Left. After that, run right detection: if no neighbor exists, create Corner Right. If Corner Left was already detected, delete Corner Left and spawn Inside Corner instead. This sequential approach transformed an unreliable random process into a deterministic algorithm that cleanly closes level boundaries every time.
The Player HUD successfully displayed accurate health and remaining zombie counts, but the wave counter stubbornly remained stuck at "Wave 0" regardless of progression. After extensive Blueprint debugging yielded no obvious cause, the team moved on to other priorities, assuming it was a hidden engine bug. The real issue only surfaced during final cleanup when I deleted what appeared to be unnecessary project files.
While cleaning unused assets before submission, I deleted a Game Manager Blueprint we had decided not to use early in development. This immediately broke the entire game, revealing that the Player HUD had been referencing wave data from that "unused" manager. The wave counter wasn't broken—it was reading from an object that never updated because we weren't using it. Once discovered, I rebuilt the HUD to reference wave data from the Player Character instead, and the counter worked seamlessly. This taught me to trace all Blueprint references before assuming assets are truly unused.
Zombie AI required functional pathfinding to navigate procedurally assembled room prefabs, but Unreal's nav mesh system bakes navigation data to static geometry at editor time. Procedurally spawned actors don't automatically update the nav mesh, meaning zombies would path through walls or stand motionless because they couldn't calculate valid routes through the newly assembled room prefabs.
Implemented a workaround in the Level Blueprint that moves the nav mesh bounds volume 1 point along the X axis and back after each room assembly. This tiny movement forces Unreal to redraw navigation lines, effectively rebuilding pathfinding data for the new prefabs without manual intervention. The solution is inelegant but functional, trading architectural purity for practical results within the three-week timeline. A production implementation would likely use Unreal's Runtime Nav Mesh generation or C++ navigation API for cleaner execution.
Leading the procedural room assembly system taught me the importance of deep technical ownership. When I could explain exactly how the room spawning, exit validation, and hole-plugging algorithm worked while team members couldn't articulate the system's internals, it reinforced that true leadership requires mastery of the technical details, not just project management. Being the go-to person for questions about how room prefabs connected or why certain exits failed validation meant I had to maintain clear mental models of the entire assembly pipeline.
The counter-clockwise hole-plugging algorithm demonstrated that procedural systems require extensive iteration to discover reliable patterns. Early approaches using simultaneous checking produced inconsistent results that seemed random until I shifted to sequential validation. This taught me that "test over and over until you find the methodology that works every time" is not just acceptable but necessary for procedural systems. Elegant solutions emerge from persistent experimentation, not initial design documents.
The hybrid approach of hand-built room prefabs with procedural assembly revealed an important design insight: pure procedural generation isn't always superior to modular prefab systems. By building individual child room Blueprints and letting the system handle spawning/connection logic, I gained the benefits of procedural variety without the validation complexity of algorithmic geometry generation. This modular approach trades some unpredictability for guaranteed quality—a worthwhile tradeoff given the three-week timeline.
Time constraint imbalances created significant challenges that no amount of communication could fully solve. While I dedicated the entire week to development, most team members contributed primarily over the final weekend. This disparity taught me that project success depends on realistic capacity planning rather than optimistic commitments. The experience reinforced that sustainable development requires either matching time investment across the team or scoping features appropriately for available resources.
The HUD bug discovery revealed the danger of making assumptions about "unused" code. Deleting what appeared to be unnecessary assets exposed hidden dependencies I hadn't traced through the Blueprint reference network. This experience taught me to use Unreal's Reference Viewer extensively before removing anything, and to question whether an asset is truly unused or simply not obviously connected. In interconnected systems, nothing is unused until you've verified every possible reference path.
Finally, the modular BP_RoomBase architecture proved that well-designed parent classes enable rapid content creation. Because all room prefabs inherit the same structure and follow the same exit system, adding new room types required no core logic changes. This reinforced that investing time in solid foundational architecture pays dividends throughout development, even on short-timeline projects. Good systems design enables team members with varying skill levels to contribute meaningfully—anyone can build a new child room Blueprint and add it to the spawn pool without understanding the assembly algorithm's implementation details.
The immediate priority for continued development would be resolving the Wave 4 crash that currently limits playability. Once stability is addressed, the modular room assembly system's architecture enables numerous expansion possibilities without requiring fundamental system rewrites. The BP_RoomBase parent class structure supports adding new room prefabs, mechanics, and environmental variety through child Blueprints rather than core logic modifications.
Generic rooms spawn first, then 3 random exits transform into specialized wing entrances: Science Labs, Military Barracks, or Prison Cells. Each wing maintains thematic consistency while connecting naturally to generic spaces.
Add cooperative multiplayer support for 2-4 players with revive systems, shared score bonuses, and complementary weapon spawns that reward coordinated play over splitting up.
Special boss waves at milestone intervals (every 5 waves) with unique mechanics. Bosses could trigger room modifications, sealing exits or spawning environmental hazards specific to that encounter type.
Expand the room library with more child Blueprints: multi-level rooms, arena spaces, narrow corridors, and rooms with interactive elements like explosive barrels or destructible cover.
The wing-based assembly system would leverage the existing modular architecture. After spawning a core cluster of generic room prefabs, the algorithm would select three random exits and transform them into entrances to specialized wings. A Science Wing might feature laboratory equipment BP_LabRoom prefabs, narrow BP_ResearchHall corridors, and BP_ContainmentRoom spaces with hazardous materials. Military Barracks could provide BP_Armory weapon caches, open BP_FiringRange layouts, and BP_Barracks defensive fortifications. Prison Cells would offer BP_CellBlock tight corridors, BP_SecurityRoom locked doors requiring keys, and BP_RiotControl equipment rooms.
Boss encounters would require new room prefabs specifically designed for arena-style combat. When a boss wave triggers, the system could spawn a BP_BossArena prefab that seals exits, provides appropriate cover, and includes environmental hazards relevant to that boss type. A "Tank" boss arena might include destructible pillars that collapse after taking damage. A "Summoner" boss could spawn in multi-level BP_VerticalArena rooms where players must climb to high ground. These specialized prefabs would integrate into the existing assembly system without modifying core spawning logic.
Cooperative multiplayer would be a natural next step, as the Dead Ops Arcade inspiration inherently supports team play. The existing room assembly system already creates spaces that could accommodate multiple players. Implementation would require networking the room spawning (ensuring all clients spawn identical layouts using seed synchronization), adding revive mechanics, balancing zombie spawn rates for player count, and creating shared score systems that reward coordination. The modular architecture means these features could be layered onto existing systems.
The room prefab system's greatest advantage is rapid content expansion. Designers can create BP_ArenaRoom, BP_StorageRoom, BP_ServerRoom, or any other child Blueprint with unique layouts, populate their Exits Lists, and add them to the spawn pool. Each new prefab increases level variety without touching the assembly algorithm. This approach scales better than pure procedural generation, which requires complex validation systems to ensure algorithmically created spaces remain playable. Hand-built prefabs guarantee quality while procedural assembly maintains unpredictability.
Check out my other work to see different aspects of my game development skills, from horror level design to cooperative puzzle mechanics.