Why?
My goal was to create a system where players could use their own phones as digital wallets, ensuring the game stays focused on strategy rather than counting paper bills.
I started this project right after my first semester of learning React at school and saw this as the perfect opportunity to practice:
- Managing complex states
- Handling real-time data synchronization between a frontend and a backend
- Solving the logic-heavy challenges that come with financial transactions
How?
I chose to build the front-end with React.js because of its declarative nature and component-based architecture. In a banking app such as this one, it’s crucial the the UI stay perfectly in-sync with the underlaying data states.
- State-Driven UI: Instead of manual DOM updates, I update the component state , and React handles the rendering.
- Backend Integration: When a transaction is confirmed by the PHP backend, the updated data is pulled into a central state.
- Efficient Updates: React’s architecture made handling balance updates easier and more reliable.
Challenges
Responsive UI & Role-Based Layouts
One of the hardest parts of this project was the UI. Since players would be using their phones as wallets while sitting around a physical board, the app had to be fully responsive. I had to ensure that the interface worked perfectly on small mobile screens without losing functionality. A specific challenge was managing the player list; as more people join the game, the layout would easily break. I implemented a scrollable player container and flexible layouts to ensure that whether there are 3 players or 8, the app remained accessible and the UI stayed clean and usable. Beyond just screen size, I had to manage two different layouts: one for the Banker and one for the Player.
State Persistence
I also had to account for "real-life" interruptions, like a player's phone screen timing out or someone accidentally refreshing the page. To prevent players from losing their session or balance mid-game, I used Cookie-based persistence. This allows the app to recognize the player upon reconnection and automatically re-sync them to the correct game state.
Possible Improvements
Switching from pull to push notifications
Currently, the app uses short polling, where every client sends an HTTP request to the PHP server every few seconds. Transitioning to the use of WebSockets would shift the game architecture from 'Pull' to ‘Push’ notifications.
This would reduce server CPU usage by maintaining a single open connection. Beyond speed, switching to WebSockets would allow for more robust concurrency control.
In the current polling system, if two players perform an action in the exact same millisecond, there is a tiny window where the UI might show stale data before the next poll. A WebSocket-based 'Message Broker' would allow the server to queue events and broadcast the new state to all clients simultaneously, ensuring that every player's screen is a perfect reflection of the data at all times.
Power-User Navigation
Another feature that would greatly improve the performance of the game, is to add a local key listener in order to implement keyboard shortcuts for player selection. This system will allow a user to type 'E' to instantly lock onto ‘Emma’, or ‘MA’ for 'Maxine' while ignoring ‘Mike’. This focus on keyboard-driven navigation not only speeds up the game but also makes the application more accessible to users who prefer navigating via keyboard.