Point Game was born at Virginia Tech, where it quickly became a favorite in the poker community before spreading to the UT Austin Poker Club. Unlike traditional poker variants, the game focuses on point totals calculated using blackjack values, with your hand discarding hole cards, and the pot splitting into high and low sides.
I built this platform so I could play with friends online, but also to bring Point Game to the wider poker community. What makes the game special is that it's unsolved—no GTO solvers, no established playbook. Just pure poker theory applied to fresh problems. I wanted to give others the chance to experience that.
But this article isn't about the game. It's about the engineering.
Designing Before Coding
Before writing a single line of code, I wrote a 36-page Low-Level Design document. Most personal projects skip this. I didn't. The LLD meant instead of figuring things out on the fly, and getting confused with tons of moving parts, I was just following a well made blueprint.
The result is a system that handles real-time multiplayer gameplay, maintains state consistency across distributed clients, and scales automatically with zero server management.
The Architecture
Point Game is a fully serverless, event-driven system. Clients interact through REST APIs for account and table operations, and WebSockets for real-time gameplay. Here's the stack:
Infrastructure Overview
The key insight: DynamoDB is the single source of truth. Every game state, every action log, every connection mapping lives in DynamoDB. Lambda functions are stateless—they read state, process actions, write state, and broadcast. This makes the system horizontally scalable and resilient to failures.
Data Model
Eight DynamoDB tables power the system, each designed for specific access patterns:
The Hard Problems
Just spinning up a lambda is easy. The real engineering is in solving the problems that break multiplayer games at scale.
Optimistic Concurrency Control
What happens when two players act simultaneously? Without careful handling, you get corrupted game state. I implemented sequence-based versioning: every state mutation includes an expected sequence number. If it doesn't match, the write fails and the client resyncs, preventing corrupted states.
Turn Timer System
Players need time limits. But Lambda functions can't "wait"—they execute and terminate. The solution here is EventBridge scheduled events. When a player's turn starts, I schedule a future event with a timer sequence. When it fires, the timeout Lambda checks if that sequence is still current. If the player acted, the timer is stale and ignored. If not, auto-fold.
Privacy-Filtered Broadcasting
Every player sees a different game state. You see your hole cards; opponents see card backs. The broadcaster loads authoritative state, then generates player-specific views by filtering out private information before sending. Each WebSocket message is tailored to its recipient.
Inter-Round Action Queue
Players can join, leave, or change settings mid-hand—but those actions can't disrupt active gameplay. I built a queue system that stores these actions and processes them atomically between hands. This allows for a clear separation of game processes, and table processes.
Complex Game Rules
Point Game has a large number of rules and edge cases that make gameplay non-trivial to implement correctly. Translating real-world game rules into reliable code was a challenge in itself. One area that stood out was showdown logic: accurately tracking side pots, handling split pots, and resolving multiple winners without corrupting state.
Why This Project Stands Out
Most hobby projects never work with this breadth of technical depth and cloud infrastructure. The typical portfolio project is a single HTML or a CRUD app with a simple database. This is:
It’s a real-time distributed system that keeps clients in sync over WebSockets, an event-driven architecture that relies on scheduled triggers and async processing, and it enforces production-grade consistency through optimistic concurrency. On top of that, it implements domain-specific game logic with complex state machines and multiple simultaneous players and games.
I designed it. I documented it. I built it. And I can explain every decision.