Fortress
Third-Person Combat & Level Design
Connect exploration to combat choices, then test whether players can find and use those choices.
- My contribution
- Level layout, ability and reward design, Blueprint implementation, visual guidance, and playtest analysis for this Unreal Engine coursework project.
- Playable work
- Four collectible abilities, combat encounters, a throne-room boss, and an optional prisoner-rescue puzzle with a relic reward.
- What the tests revealed
- Five of six testers finished the level. Mana scarcity and unclear navigation still limited the experience. The postmortem identifies the next changes; it does not claim those problems are resolved.
Four abilities. Different reasons to use them.
Fireball, healing, overshield and knockback give the player damage, recovery, protection and space. Mana costs and cooldowns limit how often the abilities can be used. Collecting all four also earns a relic, connecting a completion objective to the tools available in combat.
The first three testers struggled with mana. That exposed a dependency in the design: acquiring an ability does not guarantee enough opportunities to use it. My proposed next pass increases item-drop frequency and favors mana over health, followed by another test.
Three approaches to one main objective
The hall, barracks and tower/rampart routes converge on the throne-room boss. Ability collection, a special enemy drop and prisoner rescue give the player reasons to explore beyond that objective.
A puzzle that belongs in the keep
Three mechanisms correspond to symbols on the prison cells. Damage to one wall removes a symbol, letting the player infer the missing match from the other two. Releasing the prisoner connects the puzzle to dialogue, an escape sequence and a relic reward.
Guidance within the environment
The red carpet leads toward the throne room, chests encourage exploration through the barracks, and landmarks distinguish the routes. These were deliberate guidance choices, but several testers still got lost. Their presence alone was not proof that the level communicated clearly.
Completion did not mean clarity
Five of six testers completed the level, and several enjoyed the combat. Their experiences still varied: some missed objectives or struggled to navigate, and the first three reported mana problems. This small playtest sample helped identify issues; it does not establish a broadly balanced difficulty.
| Observed problem | Why it matters | Proposed response |
|---|---|---|
| Mana shortages | Players could acquire abilities but lacked resources to use them often enough. | Raise the overall item-drop chance from 2/3 to 3/4 and swap the health/mana weighting to favor mana. |
| Unclear routes and objectives | Enjoying combat did not ensure players understood where to go or found the optional objectives. | Improve breadcrumbs and objective cues through dialogue, audio and visuals. |
| Enemy navigation on stairs | A tester could attack from places enemies could not reliably reach. | Fix navigation coverage and test pursuit on the stairs. |
| Harsh fall damage | A five-meter instant-death rule blocked a roof shortcut but also punished falls too severely. | Reduce punishment for lower falls and prevent the shortcut through a different constraint. |
Scope was another lesson: combat, enemies, waves, abilities, pickups, UI, objectives, dialogue and cinematics exceeded what I could finish comfortably by the original deadline. The postmortem records that limitation alongside the working features.
Full project postmortem
The original reflection preserves what worked, what did not, and the changes I wanted to make next.
Read the complete Fortress postmortem
Fortress — Project Post Mortem
Introduction Fortress is a third-person fantasy combat level built in Unreal Engine. The player infiltrates an occupied keep and chooses a route through the hall, barracks, or tower and ramparts to reach the boss in the throne room. Along the way, they can collect four abilities, defeat a special enemy for its item, and solve a prison puzzle to rescue a prisoner. I wanted the keep to feel maintained and occupied, with guards at ease before the player intrudes.
Link to Gameplay Video https://www.youtube.com/watch?v=RfiypD2gATc
What Went Right
1. Combat
Several of my playtesters enjoyed the combat, even when they struggled with other parts of the level. The first tester found it difficult, while the second had no problem fighting the enemies or boss. Their different experiences gave me something useful to work with: the combat could be enjoyable, but the difficulty was not consistent for everyone.
2. Abilities and rewards
The project reached a point where the player could acquire and use fireball, healing, an overshield, and knockback. I chose different purposes for the abilities and used mana costs and cooldowns to limit how often they could be used. Collecting all four also awards a relic, so exploring the routes contributes to an optional objective as well as giving the player more options in combat.
3. The prison puzzle
I chose a simple matching puzzle with three cell mechanisms and corresponding symbols. One cell's symbol is missing because the wall is damaged. The remaining symbols let the player work out which mechanism opens the correct cell. The levers and gates work, and rescuing the prisoner connects the puzzle to dialogue, an escape sequence, and a relic reward.
4. Environmental storytelling
I wanted an occupied keep, not a fortress under siege. Plates and mugs on the guards' tables show a relaxed meal interrupted by the player. The prison's chipped wall, tools, and rubble suggest an escape attempt. These details let the environment communicate what was happening there before the player arrived.
5. Playtesting
The tests gave me useful feedback that I would not have gotten from only checking the level myself. Some players read the instructions and experimented, while another ignored the tutorials and ran into encounters. Five of the six testers finished the level. Comparing their results showed that enjoying the combat did not necessarily mean understanding where to go or finding the optional objectives.
What Went Wrong
1. Scope and time
I chose more work than I could finish comfortably within the time available. The level needed combat, enemy behavior, waves, abilities, pickups, UI, objectives, dialogue, and cinematics. I also had to redo the diagrams for the LDD. I did not finish everything by the original deadline, and I take responsibility for that.
2. Navigation and objective clarity
Several testers struggled to find their way through the level. The first had trouble locating the prisoner and understanding the objective, and other testers also got lost even when the combat was manageable. I want to improve the breadcrumbs and make the objectives clearer with dialogue, audio, and visual cues. Sound cues are especially important because the tested build did not have sound to help lead the player.
3. Mana availability
The first three testers struggled with mana. The drop system was not providing enough of the resource the abilities needed. I want to raise the overall item-drop chance from two out of three to three out of four and swap the health and mana probabilities so mana drops more often. I also want the player's knockback ability to push enemies farther.
4. Stair navigation
The stairs did not have reliable navigation coverage for the enemies. The first tester used that to attack enemies from places they could not properly reach. That turned an unfinished technical problem into an advantage for the player and needs to be fixed.
5. Fall damage
The five-meter instant-death rule was meant to stop players from jumping off the ramparts onto the barracks roof and returning to the courtyard. Playtesting showed that it felt too harsh. Jeremy and Legend both disliked the fall damage. I need a less punishing response to lower falls and a different way to prevent the roof shortcut.
Conclusion Fortress has working combat and optional objectives, and several testers enjoyed playing it. The tests also showed clear problems with navigation, mana availability, stairs, and fall damage. Those are the main changes I want to address next, along with stronger cues that help players understand their objectives and find the routes through the keep.
Tools: Unreal Engine 5 Blueprints and Figma. The LDD is a planning document. Screenshots show the development blockmesh; character meshes and base locomotion use Unreal Engine template assets. This page reflects the published October portfolio evidence, not a new gameplay test.