Flagship systems, tools, and gameplay project

Dungeon Wipe

A released Unity dungeon-survival game with a custom JSON level editor, runtime level reconstruction, combat systems, NavMesh enemies, scoring, and a health-responsive potion system used in published DDA research.

My role: Solo Programmer and Designer
Context: Solo Project · BSc final project · research prototype
Period: 2024
Status: Released Windows build · source available

View source on GitHub Play on itch.io Read the ICEC 2024 paper

Dungeon Wipe gameplay in a custom dungeon with enemies, hazards, score, and health UI — A playable dungeon reconstructed from authored level data.

Dungeon Wipe level editor showing a placement grid, prefabs, grid controls, and save actions — Custom editor used to author and save dungeon layouts.

01 · Overview

Project overview

Dungeon Wipe connects player-facing combat with a reusable content-authoring workflow. Players can build layouts in the editor, save them as JSON, load them at runtime, and retain a high score per custom level.

The health-potion system was the research implementation studied in the co-authored ICEC 2024 paper on power-up-based Dynamic Difficulty Adjustment.

Health thresholds control whether a health potion is created and which potion value appears. The interval itself remains fixed.

02 · My role

What I built

Built the grid-based editor, prefab placement workflow, JSON serialization, custom-level selection, and runtime level reconstruction.
Implemented sword, crossbow, and shield combat plus warrior, archer, and mage enemy archetypes using NavMesh navigation and conditional decision logic.
Connected collectibles, scoring, settings, menus, and per-level high-score persistence into the playable loop.
Implemented health-threshold logic that controls health-potion eligibility and selects the potion value used by the DDA research prototype.

Project scope

Project-wide capabilities

Custom level creation, editing, saving, selection, loading, and replay.
Melee, ranged, and mage combat pressure. The project also includes weapons, defence, pickups, hazards, scoring, and menus.
Data-backed levels, reusable prefabs, ScriptableObject configuration, and NavMesh pathfinding.
A health-responsive potion system that changes potion eligibility and value selection.

03 · Decisions

Research, level editor, and combat design

How the project structured its systems, interactions, and delivery constraints.

01Editor gridPlace and revise level prefabs
02JSON level dataSerialize objects and coordinates
03Runtime loaderRead and reconstruct the layout
04Playable systemsPrefabs, combat, and NavMesh enemies
05Iteration loopRun, edit, save, and replay

Levels as data

Layouts are stored as JSON rather than hard-wired scenes, allowing authored data to drive runtime reconstruction and replay.

Readable enemy roles

Warriors rapidly close distance and create melee pressure. Archers restrict safe positioning through sustained ranged pressure. Mages create high-priority long-range pressure with attacks that are intentionally difficult to avoid.

Health-responsive potion system

Health thresholds determine whether a potion appears and select its value. Spawn timing is not dynamically changed.

Weapon switching through enemy pressure

The enemy set discourages reliance on one weapon. Mage pressure gives the player a reason to switch to the crossbow instead of treating melee as a universal answer.

04 · Problem solving

Challenges and responses

Concrete constraints are paired with the implementation or design response used in the project.

Challenge

Turning arbitrary editor layouts into valid runtime dungeons.

Response

Serialised placed prefabs and coordinates to JSON, then reconstructed the level through a reusable loading pipeline.

Challenge

Creating enemy variety without hiding the combat rules.

Response

Separated melee, ranged, and unblockable magic pressure so each archetype asks for a different response.

Challenge

Adapting difficulty without making enemy behaviour feel inconsistent.

Response

Adjusted recoverability through health-based potion selection rather than silently changing enemy health or counts.

05 · Iteration

Implementation checks and known limitations

Iterated levels through the editor-to-runtime loop, checking that placed content serialised, loaded, and remained playable.
Checked health-threshold behaviour and potion selection during implementation.

What I learned

What the project changed

Tooling can be part of the game’s core value when it shortens the path from layout idea to playable test.
Adaptive support is easier to reason about when its intervention is concrete and player-visible.

Future pass

What I would improve

Add automated edit-mode tests around level serialization and malformed JSON handling.
Improve combat feedback, onboarding, and higher-resolution documentation of the editor workflow.
Add a diagram of the conditional enemy decision logic and NavMesh flow.

Related work

Exile

Solo Project · university projectReleased Windows build · source available

A released hybrid game that connects timed 3D resource gathering and village development with 2D top-down combat and persistent progression.

Role: Solo Programmer and Designer
Built: Developed resource nodes, shops, building placement, upgrades, interactables, and affordability rules for the preparation phase.

View Exile case study Play on itch.io View source on GitHub

Prince of Persia (1989) educational level replica showing the side-view 3D dungeon layout

Prince of Persia Level Replica

Solo Project · Educational ReplicaReleased Windows build · source available

A 3D recreation of the original first level focused on studying movement, pacing, gates, buttons, falling floors, and enemy encounters.

Role: Solo Programmer and Designer
Built: Studied and replayed the original level to identify its movement rhythm, spatial sequence, and interaction rules.

View Prince of Persia Level Replica case study Play on itch.io View source on GitHub

O2D top-down action gameplay on an alien planet

O2D

Eight-Person Team · GN! Game Jam #15Completed game-jam project · playable Windows builds

An eight-person Unity 6 jam project about defending an oxygen base from alien waves while gathering fuel, crafting upgrades, and using player abilities.

Role: Programmer
Built: Contributed as a programmer within an eight-person game-jam team and helped deliver the completed playable build.

View O2D case study Play on itch.io