THE RULES BEHIND THE SOFTWARE
Dungeons & Dragons
A turn-based Java dungeon engine separating board interactions, character abilities and enemy behavior.
ONE MOVE. THREE OUTCOMES.
Code-native explanation of the implementation. Illustrative data.
- CONTEXT
- University coursework
- MY ROLE
- Sole developer
- TIMELINE
- 2022
- EVIDENCE
- Source reviewed · illustrative diagrams
AT A GLANCE
What happens when a move meets a tile?
A command-line dungeon assignment models movement, combat and progression through an object hierarchy. Four character classes use different ability resources, while monsters, bosses and traps react on game ticks. Visitor-style dispatch connects an attempted move with the behavior of the tile it reaches.
My contribution +
I developed this project as university coursework. This case covers my implementation and the engineering decisions behind it.
WHAT THE SYSTEM HANDLES
The interesting parts.
One move, different outcomes
Moving into empty ground swaps tile positions; a wall blocks movement; reaching an opposing unit starts combat. Dispatch separates these outcomes from the directional movement commands.
Implementation details
- The board stores a tile grid and synchronizes positions during swaps.
- The manager processes player input, enemy ticks and player resource updates.
Four ways to spend an ability
Warriors use cooldowns, mages spend and regenerate mana, rogues manage energy, and hunters replenish and spend arrows. Preset heroes share progression rules while specializing their attacks.
Implementation details
- The character menu defines seven presets across four classes.
- Experience can trigger level-ups, stat increases and resource changes.
Different threats on the same board
Monsters chase within vision range and otherwise choose random moves. Bosses add timed special attacks, while traps cycle between visible and concealed glyphs and attack nearby players.
Implementation details
- Chasing uses a simple dominant-axis choice, not a general pathfinding algorithm.
- Defeating the remaining enemies loads the next level from an external map directory.
STRUCTURE & JUDGMENT
How the parts fit.
CLI input
Movement and ability commands
→ ManagerManager
Turn order, maps and progression
→ Player classes / Enemy classesBoard + Tile
Grid coordinates and tile swaps
→ Visitor-style interactionsVisitor-style interactions
Empty / wall / opposing unit
→ Board + Tile / Enemy classesPlayer classes
Cooldown, mana, energy and arrows
→ Board + TileEnemy classes
Monster, boss and trap ticks
- Java
- Object-oriented design
- Visitor-style dispatch
- Command-line interface
- JUnit 5 test source
Put interaction behavior on the types involved
Tiles implement Visitor and Visited; accept and overloaded interact methods route movement into empty, wall, player or enemy behavior.
WHY IT MATTERSA small three-outcome diagram can explain how polymorphism replaces a single large movement conditional. This design rationale is inferred from source.
Share progression, specialize ability economics
Player implements experience and level progression; Warrior, Mage, Rogue and Hunter override ability and tick behavior using different resources.
WHY IT MATTERSThe same game loop supports four distinct play styles without requiring a different board engine for each.
Drive enemies through a common tick
Manager advances each enemy, allowing monster pursuit, boss ability timing and trap visibility to run through the same turn sequence.
WHY IT MATTERSDifferent behavior can be compared at the shared lifecycle boundary instead of described as a generic enemy AI system.
Scope, limitations & what I would revisit
- The tracked repository has no level text assets or Maven/Gradle build configuration. Main requires a map-directory argument, so an out-of-the-box playable run is not established.
- Map loading uses a Windows path separator and treats a missing level file as victory, including a missing initial map. Do not show that outcome as evidence of a completed campaign.
- Shared static board, manager and enemy state couples instances. The implementation is a local coursework engine, not an isolated multi-session service.
- Combat uses unseeded random rolls, and some tests assert outcomes affected by those rolls. The test source was reviewed but not rerun or certified deterministic.