This sprint involved a lot of debugging and iteration.
Looking back, I could improve by testing collision setups earlier when integrating assets. However, solving these problems helped stabilize the enemy system and I was able to finalize the enemy setup and start adjusting gameplay values.

The hard part is here: At first the enemy could not receive damage, and when I changed the collision settings so it could take damage, it stopped attacking. After spending a lot of time debugging, I rebuilt the enemy’s collision setup and resolved the issue.

I imported the final models for all enemies into the project.
Most models worked smoothly with the existing blueprints, and the enemies could immediately use the new visuals while keeping their behaviors.

This helped make the encounters feel much more complete visually.

The second enemy behaves differently from the first one.
While it can still retreat to maintain distance, it always faces the player and keeps firing, which makes it feel much more aggressive and threatening during combat.

This creates a different combat dynamic compared to the first enemy type.

This sprint I focused on expanding the enemy system. I implemented a second enemy type with different behavior and integrated new enemy models into the game. I also started balancing enemy values and testing their interactions in the level.

After importing the final model, the elite enemy stopped taking damage while the boss and shield generator worked normally.

I spent time investigating and documenting the issue so it can be fixed without breaking other systems next sprint

Implemented stop-and-fire logic.

Once at the correct distance, the enemy stops, faces the player, and fires in timed intervals.

This made the encounter feel readable — players can recognize attack windows instead of reacting randomly.

Added the chase behavior.

If the player moves too far away, the elite advances to bring the fight back into its intended range.

With both retreat and chase working, the enemy now actively controls the combat space.

Implemented the retreat behavior.

When the player gets too close, the elite backs away to re-establish distance instead of standing still.

This immediately changed how the player engages — rushing forward no longer works and positioning starts to matter.

Sprint update!
This week I focused on building the Elite Enemy behavior for the boss encounter.

The enemy now chases when far, retreats when too close, and holds an ideal combat distance. Even with a placeholder model, the combat already feels more intentional.

Reflection:
The main challenge was managing state transitions and edge cases in the boss logic. Preventing repeated triggers and unintended phase resets required careful gating. Next, I would refine timing, feedback, and clarity to improve pacing and player understanding.

At 50% health, the boss transitions into Phase 2 and becomes invulnerable again. Shield generators spawn in the environment, and all must be destroyed before the boss becomes permanently vulnerable, shifting focus from DPS to spatial control.

In Phase 1, elite enemies act as gating mechanics. Defeating them temporarily allows the player to damage the boss. This creates short damage windows, encourages target prioritization, and prevents players from dealing constant boss damage.

The boss encounter is structured as a two-phase fight focused on mechanics rather than raw DPS. The boss starts invulnerable, requires specific player actions to unlock damage windows, and transitions into a second phase with environmental objectives.

Sprint recap

My main focus this sprint was enemy tuning and boss encounter mechanics.
I worked on two separate but related systems:
• Enemy stat balancing using spreadsheet-based design
• A multi-phase boss encounter with conditional damage windows and state transitions

Sprint Reflection

The weapon and ammo system went through several iterations this sprint, evolving from a traditional setup into a simplified structure through team feedback. Going forward, I plan to validate system ideas earlier to reduce revision time.

I conducted market research focusing on mechanic-driven FPS encounters and puzzle-oriented execution under pressure. This helped ground the project’s design direction and ensured our systems aligned with existing player expectations while remaining appropriate for a single-player experience.

Boss Encounter Design

I designed a two-phase, mechanic-driven boss encounter inspired by raid-style structures but adapted for a single-player experience. The fight emphasizes invulnerability phases, buff-gated damage windows, environmental objectives, and clear wipe conditions.

Weapon Roles & Combat Intent

I defined the roles and intended use cases for standard and heavy weapon modes, including time-to-kill expectations for normal enemies, elites, and bosses. These decisions help control combat pacing and reinforce the importance of situational weapon choice.

I designed the core weapon system, focusing on a simplified ammo economy and clear combat roles. The system balances unlimited standard weapons with limited high-impact heavy weapons, encouraging strategic decision-making rather than constant resource management.

During this sprint, my primary focus was on system-level design, including weapon structure, ammo economy, boss mechanics, and market research. My goal was to establish clear, mechanic-driven frameworks that the rest of the team could build on during later development stages.