The Project

Problem: Many student projects work until you add one more feature. Then the code becomes hard to change because responsibilities are mixed. For this project, the goal was to build a Risk-style game that stayed maintainable as gameplay rules evolved, not just something that runs once. What I built: I implemented a desktop strategy game in Java, structured around MVC so UI concerns, domain rules, and data flow stayed separate. The gameplay involved phases, orders, reinforcements, and state transitions, which can easily become tangled if handled with large conditionals. How I designed it: I used the State pattern to model game phases and make transitions explicit. I used the Command pattern to represent player actions as objects, which made actions easier to validate, queue, execute, and log. Instead of scattering print statements, I added event-driven logging to capture game flow and key decisions, which helped with debugging and also made behaviour easier to audit. Engineering approach: I treated it like a real codebase. I kept modules small, used clear interfaces, and refactored when duplication or long methods appeared. I also leaned on tests where it mattered most, especially around rule enforcement and state transitions, because those are the parts that break quietly. Outcome: The result was a feature-rich game that was easier to extend. Adding new rules or improving existing ones did not require rewriting the whole system, because the patterns and boundaries made change safer.