CUT TO:
INT. PROJECT ARCHIVE — STORYBOARD ROOM
The USER opens Dungeon Mania.
DIVAKAR DESSAI
Let's run through the shots.
CASE FILE / COMP2511 / Design Patterns / Refactoring
Dungeon ManiaRefactoring & Evolving a Java Game Engine
Refactored and extended an existing Java dungeon game using design patterns, SOLID principles and object-oriented architecture.
01–02 / OPENING SEQUENCE
Establishing the world
01 / Establishing Shot
The Problem
The existing game engine contained duplicated behaviour, tightly coupled responsibilities and architectural choices that made new requirements increasingly difficult to introduce.
02 / Wide Shot
The Context
The project involved working with an existing Java dungeon-game codebase rather than starting from scratch. New gameplay requirements had to be implemented while improving the underlying architecture.
03 / CHARACTER NOTE
DIVAKAR'S ROLE
Subject
Divakar Dessai
Production
Dungeon Mania
Take
03 / Role
Role notes
DIVAKAR DESSAI
I analysed the existing design, identified code smells, refactored behaviour using object-oriented design patterns and extended the game with new mechanics.
04 / CLOSE-UP
THE ENGINEERING CHALLENGE
The difficult part was changing architecture without breaking existing behaviour while also preparing the codebase for evolving requirements.
05 / TRACKING SHOT
THE APPROACH
A plan emerges.
I separated interchangeable enemy movement behaviour through Strategy implementations, reviewed existing Observer relationships, improved responsibility boundaries and explored Composite and Factory structures for extensible goal evaluation.
06 / INSERT SHOTS
KEY FEATURES
The system takes shape.
07 / DIRECTOR'S NOTES
DESIGN DECISIONS
Things we decided along the way
01
Replaced duplicated movement logic with interchangeable strategies.
02
Reduced unnecessary inheritance where behaviour did not belong in the parent hierarchy.
03
Moved responsibilities toward the entities that owned the behaviour.
04
Used compositional patterns for compound goals.
05
Refactored before implementing major requirement changes.
design decisions
somewhere mid-build
08 / RETAKES
WHAT WENT WRONG
Naturally, not everything cooperates.
09 / FINAL SHOT
THE OUTCOME
ProblemBuildOutcome
01
Improved extensibility of the game architecture.
02
Reduced duplicated behaviour.
03
Implemented additional gameplay functionality on top of the refactored system.
04
Gained practical experience maintaining and evolving an existing software system.
10 / PRODUCTION NOTES
TECH STACK
The tools behind the scenes.
JavaGradleJUnitDesign Patterns
11 / BEHIND THE SCENES
LINKS
FADE OUT.
USER closes the file.
One project down. A few more stories left.
DIVAKAR DESSAI
Pick another?