Texas Hold'em Poker Bot
A Full Game Engine Inside Discord
A 4,200-member gaming community wanted a polished, visual Texas Hold'em experience running entirely inside Discord — with canvas-rendered cards, multiple concurrent tables, configurable rules, turn timers, and elimination. Here's the full story from request to delivery.
Step 1 — The client submits a detailed request
This client knew exactly what they wanted and wrote a thorough product requirements document. More detail = faster delivery with fewer questions.
Discord Poker Bot — Product Requirements
We need a Texas Hold'em poker bot for our gaming Discord server (~4,200 members). Members have been asking for an in-Discord poker game for months. We want something polished — visual cards, proper game flow, and the ability for multiple tables to run at once so people aren't waiting around.
Game format: Texas Hold'em (No-Limit), elimination style (last player standing wins), up to 10 players per table, multiple concurrent games per server.
Configuration options per game:
- Starting Chips — Default: 1,000. Should accept any reasonable value.
- Ante Increase — Amount the ante goes up each round. Default: 0 (flat ante). Keeps longer games from stalling.
- Turn Timer — Seconds a player has to act before auto-fold. Default: 0 (no timer). Max: 300 seconds. Critical for keeping games moving.
Visual requirements: Community cards and player hands should be rendered as actual card images (canvas-based rendering is fine). The game board should show community cards, pot size, current player turn, and each player's chip count. Private hands shown via ephemeral messages.
Edge cases: Late join (enter folded until next hand), elimination at 0 chips, auto-fold on timer expiry, and correct side pot handling for all-in situations.
Hosting: Fully managed — we don't have a dev on the team. We just need the bot invited, running 24/7, with bug fixes if anything comes up. Option to get the code handed over if we ever want to self-host.
Notes: Our server is a gaming community so the vibe should be fun, not corporate. Casual bot personality welcome. We might request a leaderboard as a follow-up.
This is a more detailed request — the client wrote a proper PRD with sections for format, configuration, visuals, and edge cases. More detail upfront means we can build with fewer questions and deliver exactly what's expected. Both styles work. Write five sentences or five pages — we adapt to you.
Step 2 — We build the game engine
A complex build like this involves multiple interconnected systems. Here's how the delivery unfolded:
Architecture & game state engine
Designed the core game state machine: lobby creation, player tracking, hand dealing, betting rounds (pre-flop, flop, turn, river), pot management, side pot calculations, and elimination logic. Built to support multiple concurrent games per server.
Hours 0–16
Card rendering engine
Built a server-side Canvas renderer that generates visual card images. Community cards displayed on a felt-green table layout. Private hands rendered as separate images sent via ephemeral messages. All 52 card faces rendered with proper suits, values, and styling.
Hours 16–32
Slash commands & game flow
Implemented all 7 slash commands: /poker create, join, start, end, action, status, quit. Each command validates game state, handles edge cases (acting out of turn, invalid raises, etc.), and updates the game board embed.
Hours 32–56
Turn timer & auto-fold
Implemented configurable turn timers with visual countdown in the game embed. Players who don't act in time are auto-folded. Timer resets on each action. Handles edge cases like timer expiring during a disconnect.
Hours 56–68
Edge cases, testing & deployment
Tested all edge cases: side pots with multiple all-ins, late joins, single remaining player wins, ante increase across rounds, concurrent games in different channels. Deployed to managed hosting with monitoring.
Hours 68–90
Step 3 — The delivered product
Here's everything the client received:
All 7 commands
Canvas-rendered cards
All 52 cards rendered as images using server-side Canvas. Community cards shown on a felt-green table layout. Private hands displayed as ephemeral card images only the player can see.
Multi-table support
Multiple games can run concurrently in the same server. Each host creates their own table with independent game state, settings, and players.
Configurable rules
Starting chips, ante increase per round, and turn timer are all configurable per game. Defaults work out of the box, but hosts can tune for quick or marathon sessions.
Turn timer & auto-fold
Optional turn timer (up to 300 seconds) keeps games moving. Players who don't act in time are automatically folded. Critical for keeping distracted gamers honest.
Side pot handling
Correct side pot calculations when players go all-in with fewer chips than others. Multiple side pots tracked and resolved properly across complex multi-way all-in situations.
Late join support
Players who join after the game starts enter in a "folded" state and are dealt in on the next hand. No waiting for a new game to start.
Key takeaway
- Complex builds are our sweet spot. This bot involves a game state machine, image rendering, real-time multiplayer, and dozens of edge cases. It's the kind of project where freelancers typically under-scope and over-charge. With DiscordGenius, it's just another request card.
- Detailed requests = faster delivery. The client wrote a proper PRD with configuration options, visual requirements, and edge cases. We didn't need a single follow-up question. The build started immediately.
- Follow-ups are easy. The client mentioned wanting a leaderboard as a future request. When they're ready, it's just another card on their board — no new project, no new quote, no scope negotiation.
- You own the code. Even though we host and manage the bot, the client can request a full code handover at any time. No lock-in, full IP ownership.
Casual vs detailed — both work
Compare how different clients write requests:
| Video Contest Bot | World Map Bot | Poker Bot | |
|---|---|---|---|
| Request style | 5 casual sentences | Conversational paragraph | Formal PRD with sections |
| Complexity | Simple | Moderate | Complex |
| Commands | 2 | 3 | 7 |
| Delivery time | <48 hours | 72 hours | ~96 hours |
| Follow-up requests | 0 | 3 iterations | Leaderboard (future) |
| Outcome | Approved first try | Evolved through feedback | Approved first try |
There's no wrong way to submit a request. Write it however comes naturally. We'll figure out the rest.