Reading attacks and potions
Players could take damage without understanding its source, and potion effects were unclear. I added attack VFX and sound, plus potion VFX, UI information and pickup sounds to explain what was happening.
Unity systems and tools
Dungeon Wipe
Dungeon Wipe is a Unity dungeon-survival game with a custom editor. It saves JSON layouts, rebuilds them at runtime, and uses NavMesh enemies and a health-responsive potion system studied in DDA research.
- Role
- Solo Programmer and Designer
- Context
- Solo Project
- BSc final project
- research prototype
- Period
- 2024
- Status
- Playable in browser
- Windows build
- source available
Overview
I designed and programmed Dungeon Wipe as my BSc final project. It combines dungeon combat, a player-facing level editor and adaptive healing used in my first-author ICEC 2024 paper.
Visual assets in the public build are AI-generated placeholders. The systems, tooling and code are mine.
Combat and Enemy Roles
Warriors swarm the player to force movement around the level. Archers create ranged pressure that the shield or environmental cover can answer. Mages bypass the shield, so the same defence cannot solve every ranged threat.
Weapon switching was an original goal: when a Mage is too far away to reach quickly, the crossbow gives the player a way to deal with it. NavMesh navigation and ScriptableObject enemy data support these different roles.
Changes after player feedback
Dealing with the Mage
The original Mage attacked from too far away, even when unseen, and could survive a crossbow shot to cast again. I reduced its range and health and added clearer attack feedback. Current code checks sight at attack start, not again when damage lands.
Level Editor and Runtime Loading
Loading levels from files worked, but configuring them by hand became impractical. The original text/symbol format limited rotations and assets. I replaced it with JSON and built an in-game editor. Multiple floors then needed filtering so players could edit one floor at a time.
The editor validates grid occupancy and snapping across 26 selectable prefab types. JSON stores identifiers, positions and rotations. A runtime registry rebuilds the layout and NavMesh after loading. Each level keeps its own high score.
Adaptive healing
I wanted to support struggling players without making the adaptation obvious or changing the enemy threat. Healing potions adjust recovery support while enemy count, health, damage and behaviour stay unchanged.
Health bands were the simplest predictable, testable implementation. They select potion eligibility and value. Successful spawns use a fixed wait. The limitation is practical: support only helps if the player reaches and collects the potion.
- Read player health
- Check potion eligibility
- Select healing value
- Spawn potion, then wait the fixed interval
The paper describes the approach through anxiety, empowerment and expected health. This health-threshold implementation was used in the student study and formed the basis of the simulation. That does not mean the current source reproduces every equation or parameter in the manuscript.
Research and evaluation
Student study
In a convenience sample of 38 computer-science students, 83% did not perceive the adaptation. Detectability was low in that sample. This is not a finding about enjoyment, retention or measured player success.
Separate Monte Carlo simulation
Five levels, with 1,000 runs per level, compared modeled failure for a standard player: 40% with uniform power-up distribution, 56% with random distribution and 8% with adaptive support. These are modeled outcomes, not observed player-failure rates.
First author · Félix, T., Mourato, F., Morais, J. · ICEC 2024 · Springer LNCS 15192 · pp. 323–330