One-Week Sprint Prototype with Boss Battle
FPS Dungeon Crawler was a one-week rapid prototype that marked my first playable project beyond pure level design work. The assignment challenged a six-person team to create a complete gameplay experience from concept to demo in just seven days, forcing aggressive prioritization and rapid iteration.
The game features a linear five-room dungeon populated with roaming enemies that fire projectiles on detection, environmental trap systems, and a climactic Beholder boss fight. Players wield a fireball weapon with limited ammunition, navigating through increasingly challenging encounters that require strategic resource management and spatial awareness.
Combat emphasizes precision and resource conservation. Enemies die in one hit, but ammunition pickups are strategically placed to create tension between aggressive playstyles and careful progression. The Beholder boss represents the culmination of these systems, featuring a dramatic pool entrance, rotation-based tracking, and a cornea-only vulnerability that requires four precise hits to defeat.
The compressed timeline forced functionality over polish. While the game lacks visual refinement, the core systems demonstrate solid understanding of AI behavior, player feedback loops, and paced difficulty progression. This project served as proof that a small team could deliver a complete vertical slice under extreme time pressure.
The design philosophy prioritized delivering a complete gameplay arc over feature depth. Rather than building complex systems that might not reach playable state, I focused on creating a coherent experience from start to finish where every mechanic served the core loop of exploration, combat, and resource management.
Enemy AI follows a hit-and-run pattern that creates predictable but engaging encounters. Enemies wander randomly until detecting the player, fire a telegraphed fireball, then retreat to create breathing room. This design respects player reaction time while maintaining threat pressure, avoiding both bullet-sponge frustration and mindless rushing.
The Beholder boss battle exemplifies dramatic presentation within technical constraints. The pool entrance creates anticipation and establishes scale, the stationary rotation tracking simplifies AI while creating a challenging targeting scenario, and the cornea-only vulnerability transforms a simple damage system into a precision challenge. Originally planned snapshot-fireball attacks (capturing three player positions and firing simultaneously) were cut due to time, but the foundation supports future expansion.
Environmental hazards complement rather than replace combat. The kill floor trap in the second room offers multiple solution paths: beam-walk across, jump between pillars, or shoot the disable button. This design philosophy of providing options rather than forcing single solutions respects player agency and encourages experimentation.
Enemies wander randomly, detect players, fire telegraphed fireballs, then retreat to create tactical combat encounters
Dramatic pool entrance, rotation-based tracking, cornea-only vulnerability requiring four precise hits
Limited ammunition system with one-shot enemy kills and strategic pickup placement for resource management
Progressive difficulty from tutorial library through trap hallway, arena combat, jumping challenge, and boss lair
Established the Beholder boss concept as the project's centerpiece and divided responsibilities among team members. Set up version control infrastructure and established daily check-in schedules to maintain coordination under the aggressive timeline. Benjamin Valley contributed initial concept work before departing the project.
Built the foundational boss animation system and dramatic pool entrance sequence. Implemented enemy AI using Behavior Trees and Blackboards for wander, detection, shooting, and retreat behaviors. Focused on establishing functional systems rather than polished presentation, prioritizing playable mechanics over visual quality.
Migrated HUD implementation from Level Blueprint to Player Character Blueprint for proper encapsulation and portability. Gavin completed the ledge grabbing system, enabling vertical traversal in the jump challenge room. Integrated player feedback systems for health, ammunition, and damage indication.
Finalized room layouts and populated environments with enemies and pickups. William completed the kill floor trap system with multiple solution paths. Built the choice room architecture, though planned powerup implementations were cut due to time constraints. Balanced enemy placement and resource distribution across all five rooms.
Populated the boss lair with four guard enemies and strategic pickups. Implemented the spawn trigger that activates the Beholder's emergence from the central pool. Built the boss rotation system that tracks player movement and established the cornea vulnerability mechanic requiring precision shots. Tested and balanced the four-hit victory condition.
Frank worked night shifts to provide 24-hour development coverage, focusing on performance optimization and bug fixes. Conducted final balancing passes on enemy damage, player health, ammunition counts, and resource placement. Recorded demonstration video showcasing the complete gameplay loop from entry to boss defeat.
Safe tutorial space with two ammunition pickups and a pressure plate door. Introduces basic controls and fireball mechanics in a non-threatening environment.
Kill floor trap with two roaming enemies. Offers three solution paths: walk the beam, jump between pillars, or shoot the disable button. First strategic decision point.
Four central pillars with two enemies and multiple pickups. Focus on combat fundamentals with health and ammunition rewards for successful engagement.
Central wall requiring drop-down and ledge grab navigation. Two enemies patrol the area with two ammunition and two health pickups as vertical traversal rewards.
Architectural framework built for three exclusive powerup options. Implementations cut due to timeline but structure remains for future expansion.
Four guard enemies with one ammunition and one health pickup. Defeating guards triggers the Beholder's dramatic pool emergence. Cornea shots required for victory, exit unlocks upon defeat.
With six team members and aggressive timeline pressure, communication quickly became chaotic. Work concentrated heavily on Alecsander and myself while other team members struggled to find clear contribution paths. Benjamin departed early, and coordination breakdowns caused redundant work and merge conflicts. The lack of structured communication meant team members were uncertain about project status without being physically present.
We powered through by emphasizing functionality over feature completeness and establishing daily check-in routines with clear ownership assignments. Frank's night shift work provided crucial 24-hour development coverage with defined handoff protocols. Rather than trying to coordinate perfectly, we accepted concentrated effort on core contributors and focused on delivering playable systems. This pragmatic approach sacrificed ideal team distribution for guaranteed completion.
The initial HUD implementation lived in the Level Blueprint, creating tight coupling between UI systems and level-specific logic. When health or ammunition updates failed to trigger properly, debugging revealed the architectural flaw: player state management belonged to the player character, not the level. This mistake created dependency chains that made the system brittle and non-portable.
Refactored the entire HUD system into the Player Character Blueprint where it properly belonged. This encapsulation meant player-related UI updates occurred within the player's own logic, eliminating cross-Blueprint communication failures. The refactored architecture became portable across levels and significantly easier to debug. This experience taught the importance of proper Blueprint ownership: player systems live in player classes, level logic lives in level Blueprints.
The Beholder boss design included ambitious snapshot-fireball attacks that would capture three player positions and fire projectiles simultaneously at those locations. While the pool entrance animation and rotation tracking systems worked properly, implementing the snapshot mechanic proved too time-intensive for the remaining development window. The pressure to deliver a working demo forced difficult priority decisions.
Prioritized functional mechanics over ambitious features. Polished the core rotation system and cornea vulnerability to ensure they worked reliably, then used the dramatic pool entrance to compensate for simpler attack patterns. This taught an important lesson about scope management: establish solid foundations before attempting complex systems. The working but simple boss fight demonstrated competence better than a broken ambitious one would have. In subsequent projects, this experience improved my ability to recognize when to simplify features rather than sacrifice stability.
This project marked the transition from level design work to playable prototype development, exposing workflow gaps that only appear when building complete gameplay systems. The pressure of a one-week timeline revealed the difference between understanding concepts theoretically and implementing them under production constraints. I learned to distinguish between perfection and functionality, recognizing when good enough truly is good enough.
The visual polish trap became apparent early. I initially spent too much time on asset placement and lighting before establishing core gameplay loops, forcing rushed implementation of critical systems later. This taught me to prioritize functional completeness before aesthetic refinement. Subsequent projects now follow a strict progression: functional systems first, then balance and feel, finally visual polish. This ordering ensures playable experiences even when time runs short.
The HUD refactor crystallized understanding of Blueprint ownership and encapsulation. Player-related systems belong in player classes, level-specific logic belongs in level Blueprints, and shared functionality belongs in function libraries or interfaces. Violating these boundaries creates fragile architectures that break under modification. This lesson now influences every Blueprint I create, questioning whether each piece of logic lives in the correct owner.
Behavior Trees and Blackboards proved remarkably powerful for creating believable AI within tight timelines. The modular nature of behavior nodes meant I could build complex behaviors by composing simple pieces rather than writing monolithic AI logic. The hit-and-run pattern emerged naturally from connecting wander, detection, attack, and retreat behaviors. This experience demonstrated that well-designed tools enable rapid iteration even for traditionally complex systems like AI.
Frank's night shift work highlighted that extreme time pressure requires infrastructure, not just goodwill. His 24-hour development coverage worked because we established clear handoff protocols and ownership boundaries. Without structured communication, even heroic effort degrades into confusion. This lesson about team infrastructure applies beyond game development to any high-pressure collaborative work: define clear responsibilities, establish handoff rituals, and document decisions explicitly.
The boss design evolution revealed my growth trajectory. The Beholder worked functionally but lacked the depth and polish of later projects. Comparing this early boss to subsequent enemy designs shows clear improvement in anticipating player behavior, creating readable attack patterns, and balancing challenge with fairness. Recognizing this progression validates the importance of completing projects rather than endlessly refining single systems.
Most importantly, this project demonstrated that functionality shipped beats features planned. A complete playable experience with simplified mechanics taught me more than a feature-rich but broken prototype would have. The discipline of cutting ambitious systems like snapshot-fireball attacks to ensure core stability served the project better than stubborn feature commitment. This pragmatic mindset now guides all scoping decisions: ship working systems, iterate based on feedback, expand complexity only after establishing solid foundations.
The immediate expansion would implement the originally planned snapshot-fireball system for the Beholder boss. This mechanic captures three sequential player positions over a brief window, then fires projectiles simultaneously at those locations, forcing players to constantly reposition rather than circle-strafe. Tying this to health-based phases would create escalating challenge: first phase fires one snapshot per attack cycle, second phase fires two, final phase fires three overlapping patterns.
Flanking behaviors, cover usage, and coordinated enemy attacks that force strategic movement rather than predictable circle-strafing
Multi-stage environmental puzzles requiring resource management decisions and backtracking mechanics
Three exclusive buffs offering build variety: rapid-fire projectiles, charged power shots, or temporary damage barrier
Health-based phases with distinct attack patterns including snapshot-fireball, sweeping beams, and summoned minions
Enemy AI improvements would add tactical depth through flanking behaviors, cover usage, and coordinated attacks. Rather than each enemy acting independently, groups would communicate through the Blackboard system to surround players or create crossfire situations. Advanced enemies could suppress player positions with sustained fire while others reposition, forcing dynamic movement rather than static cover shooting.
The choice room framework already exists but lacks the three planned powerups: Rapid Fire (increased projectile speed and fire rate), Charged Shot (hold to charge devastating high-damage projectiles), and Protective Barrier (temporary damage absorption shield). These mutually exclusive buffs would create build variety and replayability, encouraging players to experiment with different playstyles across multiple runs.
Environmental interaction systems would expand beyond simple traps to include destructible walls revealing shortcuts, elemental hazards that combine with player abilities, and moveable cover that enables dynamic positioning. The dungeon could feature branching paths with optional challenge rooms offering better rewards for higher difficulty, creating risk-reward decisions about exploration versus direct progression.
A scoring system and difficulty modifiers would add significant replayability. Time-based scoring encourages aggressive play, while modifiers like limited ammunition or increased enemy spawns create challenge variations. Leaderboards comparing clear times and perfect-run achievements would motivate repeated playthroughs. These systems transform a linear single-experience dungeon into a replayable arcade-style challenge.
Check out my other work to see different aspects of my game development skills, from horror level design to puzzle mechanics and collaborative team projects.