Unity systems and tools
I built a level editor with 26 prefab types so I could test dungeon layouts without rebuilding the game. Save a layout as JSON and the game rebuilds the level and its enemy navigation. I also designed the combat and adaptive healing used in my first-author ICEC 2024 paper.
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.
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.
During playtests, people took damage and couldn’t tell where it came from. They also picked up potions without knowing what had changed. I added attack effects and sounds, then gave potions a pickup sound, particles and a HUD label for the effect.
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.
I started by typing layouts into files. That got awkward once I wanted to rotate objects and build across floors, so I made an editor inside the game.
Pick from 26 selectable prefab types and snap an object onto a free grid cell. I save its ID, position and rotation in JSON. When the level loads, the game looks up those IDs, places the objects and builds the NavMesh so enemies can find their way around. Each saved level keeps its own high score.
A 35-second recording. Jump to the part you want to inspect.
Place objects on the editor grid and assemble the dungeon.
Save the authored layout so it can be reconstructed outside the editor.
Select the saved level, then play the layout rebuilt at runtime.
Save the run result against that level and find it in the high-score list.
Build the layout
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.
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.
Of 38 computer-science students who played, 83% did not notice the adaptation. That tells me how visible it was to this group. I’d need a separate study to measure whether it made the game more enjoyable.
First author · Félix, T., Mourato, F., Morais, J. · ICEC 2024 · Springer LNCS 15192 · pp. 323–330
I released Windows and WebGL builds with the editor-to-runtime workflow, combat and per-level saves. The recorded browser download fell by about 74%, from 149 MB to 39 MB. The adaptive-healing implementation also supported my peer-reviewed ICEC 2024 paper.
Keeping layout data separate from scene objects let me test more than one dungeon with the same combat code. The Mage iteration also taught me to check what a player can read before adding more enemy pressure.