How I built a poker-bot
In this technical retrospective (2008), @run4yourlives shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Web 2.0 Genesis (2007–2013)
COMMUNITY SCORE 77 points
TOTAL DISCUSSIONS 37 comments
A few years ago, I wrote a program that would screen-scrape to read all cards showing and then do a Monte Carlo simulation to randomly complete the hand and compute what % of times my cards would win (along with pot odds). It took a second or so to do the simulation, so I could use it to make decisions in real time. It was a fun project, but I soon stopped using it. Your odds against random cards are not at all your actual odds, because most players fold weaker cards. What matters most is who you're playing against.
Anyway, the article, although it describes well the techniques for programmatically interacting with a poker client, is majorly misleading because this is not the hard part of making a bot. The hard part is figuring out whether, and how much, to bet. He alludes to this as "the million dollar question", but then omits to even mention it under "What skills will I need to write a bot?" Perhaps he'll address this in later articles?
If you look at the last screen shot, it's clear that he built a UI for an end-user to specify the actual logic for poker play. ("Call if it has not been raised, I'm later than 7th", etc.) His "bot" doesn't actually make decisions. It collects rules from an end-user, calls those to decide what to do, and passes the result on to the poker client. In other words, the hard part of the job - writing a program to play poker - has been passed to somebody else. Maybe that somebody else is the author, creating the algorithm through his UI... but then why not just code it?
There are serious researchers who have made credible bots (he links to them), bots which would (and, for all we know, do) make money on poker sites. But when I looked at it, the literature was not nearly detailed enough to code up their algorithms. (Also, they were working with simplified versions of poker, since full no-limit holdem is a hard nut to crack). What they didn't use were the "extensible rules-based systems" which this author claims "are a lot more powerful than you think". Count me skeptical. Good players eat such systems for snacks. Maybe they make money in low-stakes games against bad players, but I'd like to see evidence.
In short: never mind the dll injection, show us your bankroll over 100,000 hands!
That's a tough choice for a casino. Allow automation and you create a ghetto which discourages casual users. Disallow automation and you encourage an escalating "arms race".
Regardless, the techniques discussed could be detected using anti-virus techniques. I'm surprised that native clients don't perform integrity checks or is this the state of play in the "arms race"?
It would be fairly simple to disable integrity checks using methods to circumvent software DRM. Then it would be a matter of implementing distributed state to determine and ignore circumvented clients.
His rules engine doesn't appear to trend other players at all. There are good tools out there that gather data on players and with enough data, you can pinpoint a player fairly well. It also shows his bot playing no-limit tables which seems like a horrible idea for a bot. There is a lot more to take into consideration in no-limit poker and I'm not sure a bot that only takes 3 or 4 things into consideration for every move could ever win at worthwhile stakes.
If your bot can play 14 limit tables at a time with even the slightest % edge, you're going to make money. However, if you added more advanced player profiling algorithms into your bot, you're edge would likely increase and allow you to set it up at higher stakes.
It's interesting, but to be honest, if you're smart enough to make a successful poker bot, you're probably smart enough to write a program to trade stocks or other liquid instruments like government bonds or commodity futures. The potential winnings are much higher, it's perfectly legal, and due to the depth of the markets such programs are capable of making much more money than poker bots. It's also doable, as funds like Renaissance Technologies (http://en.wikipedia.org/wiki/Renaissance_Technologies ↗) and D. E. Shaw have demonstrated.
I was involved in a fairly elaborate pokerbot effort. Believe me, the mechanics of playing the game are the easy part. The hard part is writing the poker logic. Check this out if you want an intro to the "basic" concepts:
Lokibot: http://www.cs.ualberta.ca/~jonathan/Grad/papp/thesis.html ↗
The bot described in that paper lost about 8c a hand at the $1 tables. After extensive modifications, we got it to the point where it was losing about 2c a hand. This when Bush made poker illegal in the US, and we killed the project.