Android implementation of the Reversi board game
An Android implementation of Reversi built as an academic project for a mobile computing course. The focus was on real-time multiplayer, persistent stats, and a clean mobile-first UI.
Stack
Built to course specification - Kotlin and Firebase were mandated. Firebase was a natural fit regardless, handling both auth and real-time data without requiring a separate backend.
| Layer | Technology | Why |
|---|---|---|
| Platform | Android + Kotlin | Course requirement |
| Auth | Firebase Authentication | Credential management without a custom backend |
| Database | Realtime Database | Real-time lobby and game state synchronization |
| Storage | Firestore | Persistent user data and game history |
Features
| Feature | Description |
|---|---|
| Online Multiplayer | Real-time matches against other players |
| Game History | View past games, win/loss record, and performance stats |
| Leaderboards | Global ranking across all players |
| Favourites | Bookmark specific games for later review |
Architecture
Both the backend and frontend are a single Android app. Firebase handles all data storage and syncing, with Firestore for persistent user data and Realtime Database for game state. The app uses a simple MVVM architecture, with ViewModels managing UI state and Firebase listeners for real-time updates.
Game state is managed through Firestore listeners, allowing for real-time updates across clients. Moves are validated client-side, with Firestore rules ensuring data integrity. Lobbies are implemented as separate nodes in the Realtime Database, where players can join and be matched for games. The app uses ViewModel and LiveData to manage UI state, with Compose for a modern declarative UI approach.
Challenges
Keeping the app state synchronized - ensuring that I didn’t have any non-deterministic bugs in the game logic or Firebase listeners that could cause clients to get out of sync or make the app crash.
Both backend and frontend in one app - managing the complexity of having all game logic, data management, and UI in a single codebase without a separate backend to handle game state and validation was a challenge, especially under a tight deadline. The codebase became quite complex and feature implementation was slower than expected due to the need to manage both client and “server” logic in the same app.
What I’d Do Differently
Light backend for move validation - I would implement a simple backend service to handle move validation and game state management instead of relying solely on client-side logic and Firestore rules. This would reduce the risk of clients getting out of sync or making invalid moves, and would allow for more complex game logic without overcomplicating the client code.