Chipsy: a Discord Poker Bot with a control panel

Why I Built Chipsy

Chipsy didn’t start with a grand vision. It came from a simple personal need: I wanted to play poker with friends on Discord without the hassle of external websites or manual chip counting. I looked for existing bots, found them too complex or paid-only and decided to build my own weekend script to shuffle a deck and track bets.

That first script was messy, but it worked. Over time, as I added features like lobbies, persistent bankrolls and a small control panel, it naturally evolved into a more structured system. It wasn’t about building a “product” or a startup; it was just me pulling on a thread of curiosity — figuring out how to manage state in an async chat interface and keeping the game flow fair and readable.

---

The System in One Picture

I keep Chipsy deliberately modest, but it still has three distinct pieces:

• Discord bot (bot/) — owns slash commands, lobbies, game loops and MySQL reads/writes.
• Control API (api/) — terminates Discord OAuth, manages sessions and exposes the REST surface used by the panel.
• Web panel (panel/) — a Vue dashboard for admins: status, live logs, active tables and access policies.

The bot also exposes a tiny internal HTTP interface secured by an INTERNAL_API_TOKEN. The panel never touches Discord directly: it talks to the control API, the control API proxies to the bot when needed and a small WebSocket bridge streams status updates back to the dashboard.

That separation keeps each layer honest. The bot can focus on gameplay, the API on authentication and rate‑limited admin calls and the panel on being a clear, low‑friction control room.

---

Game Loops: Lobbies, Betting and Fairness

Running poker inside a chat channel is mostly an orchestration problem. Each table starts with a lobby phase: players discover the game, claim seats, pick a buy‑in and the bot waits for a minimum headcount. Once a hand starts, the game engine moves through a predictable state machine — blinds, pre‑flop, flop, turn, river, showdown — while timeouts and UI affordances keep it playable in an async setting.

Two design rules shaped the implementation:

• Make the state explicit. Every stage has clear prompts, available actions are whitelisted and the renderer includes enough context that players rarely need to ask “whose turn is it?”.
• Prefer deterministic fairness over magic. Card shuffles use cryptographically strong randomness when available, bankroll changes are derived from the same source of truth used for rendering and the main game transitions are covered by regression tests so a refactor doesn’t quietly change payouts.

Blackjack follows the same philosophy: small lobbies, strict action windows and simple rebuy rules so games don’t stall.

---

The Control Plane: Observability over Automation

Once you run more than one table, “just trust the bot” is not enough — you need visibility. Chipsy’s dashboard is intentionally small but high‑leverage:

• real‑time bot status (health, shards, guild count, feature toggles);
• live log console split between system activity and command executions;
• active tables view with snapshots of each game and safe remote actions like stop/pause;
• access policy editor for whitelist/blacklist/quarantine rules and role‑based permissions.

The panel’s job is not to automate everything. It’s there so owners can see what’s going on and intervene manually when a lobby gets stuck or a config needs to be nudged.

---

Economy and Persistence

Chipsy relies on a MySQL backend to keep the world alive between sessions. Instead of wiping state when a game ends, it tracks user profiles, cumulative bankrolls and unlocks, giving the server a sense of history.

This persistence supports a lightweight “RPG layer” with daily rewards and leaderboards, turning casual hands into a longer-running competition. It’s not complex data science, but it ensures that a lucky win on Friday still counts on Monday, adding a bit of weight to every decision.

---

Scope and Future Steps

Chipsy is scoped as a hobby project for small guilds, not a commercial SaaS. It deliberately avoids the complexity of real-money gambling, anti-cheat systems for adversarial environments or horizontally scalable clusters with built-in sharding. This constraint allows the codebase to remain readable and the UX friendly for its intended audience: friends deploying it for their own servers.

While there is no grand master plan, the project continues to evolve based on real usage. Realistic next steps include adding more edge-case tests around bankroll management, improving observability for RPC failures between the bot and API and introducing feature flags for experimental game types—starting with roulette tables that reuse the existing lobby scaffolding.

At its core, Chipsy was a way for me to better understand distributed state by building something my friends would actually use. It’s not a commercial product or a polished SaaS, just a dependable tool born from a specific need. I treat it as a sandbox: a place to experiment with API design, interface quirks and the small details that make a bot feel less like a script and more like a participant.

This project note was last updated on December 12, 2025 and refers to project version v1.0.0.