Featured Team Project

Persistent Waters

Multi-phase Battleship-style web application with backend-authoritative gameplay

Persistent Waters lets players run a turn-based naval strategy match in the browser with persistent game state, firing feedback, and phased deliveries from backend foundations to a playable app. It is interesting because the project grew into a live system without moving core game rules into fragile client-side logic. The key architecture decision was keeping turn validation, firing outcomes, and match persistence on the backend so the frontend could stay focused on presentation and player input.

View Live App View Code Back to Featured Work

Phase Links

One project, three clear checkpoints

Reviewers can move from architecture to implementation to live behavior without hunting around for the right version.

Phase 1

View Code

Backend API and game foundation

Initial Flask routes, persistent match data, and backend rules for creating games and resolving turns.

Phase 2

Open Live Build

Playable frontend and live match flow

Browser gameplay, board updates, firing controls, and a full player loop backed by the server.

Phase 3

View Code

Polish and final presentation

Refined the project explanation, contribution framing, and demo flow into a cleaner final presentation.

My Contributions

Organized backend route responsibilities so match creation, move submission, and game retrieval stayed aligned with server-owned state.
Implemented or supported gameplay logic that validated turns, resolved shots, and returned consistent match updates to the interface.
Connected the board interaction flow to backend endpoints so the frontend did not bypass core rules or duplicate game-state logic.
Helped preserve a demoable project path across multiple checkpoints while the system evolved from API-first foundations to a playable application.

Architecture Decision

Keep game rules authoritative on the backend

Treating the backend as the source of truth for match state, turn order, and firing outcomes made the system easier to test, easier to explain, and less likely to drift as frontend features expanded. That separation also made the live demo more credible, because the interface reflects server-validated results rather than client-only assumptions.