By the time Chris Moneymaker really blew out the poker scene in 2003 by winning the WSOP main event televised on ESPN, my friends and I were already well versed in the game. We caught the poker bug a few years prior when playing cards to fill the downtime in our high school classes. Cavalier enough to play cards in full view of our teachers but not so bold to break out poker chips, we kept track of every bet using a written ledger. A player in the game would settle their debt when reaching the egregious level of $10. Poker has had a hold on me ever since.

I cooked up How Many Outs as a quick hands on introduction to Python with the side benefit of sharpening my poker skills. The game gives you and your hypothetical opponents a randomly generated Texas Holdem hand with only one shared card, the river, left to reveal. If you are ahead in the hand, your job is to figure out how many cards from the remaining deck would allow your opponent to win. If you are behind in the hand, your job is to figure out how many cards from the remaining deck would make you the victor. The faster you make this calculation, the more points come your way.

To help create the game, I chose Python as the backend, Flask to serve a simple API, jQuery for the UI, and SQLite to store the high scores. These technology choices were made around 2011, and jQuery is the only one which needs reconsideration should I touch the game again. I’m no Javascript guru, but the ECMA standard is likely more than sufficient at this point for my simple UI.

All the real work happens on the Python side. The Flask API and Javascript UI only serve as a means to pass user input and game state back and forth. This is nice for two reasons:

1. The game itself is completely isolated to one part of the code and independent of the UI. This made it easy to test the game with automation and from the console.

2. Any browser game relying on the client to act with integrity opens the door wide open to cheating. To prevent cheating, How Many Outs does not let the client mutate data or receive any extraneous data. Modifying the Javascript code on the client side would net you no advantage. While a user could write a bot to solve any of the presented puzzles, at least the bot would perform the same work as a human player. Just faster.

All these years later, a few interesting challenges from creating the game still stand out:

1. If you generate random poker hands with only the river left to come, a disproportionate number of the hands have 0 cards which could change the outcome. This makes for a pretty dull guessing game. As a solve, I retry generation up to 3 times to avoid the 0 card scenario. This works since dealing a new random hand and checking the answer is incredibly quick, but I wonder if there is a more eloquent approach to scenario generation to arrive at more interesting and fun distributions.

2. Speaking of fun, the game did not turn out as enjoyable in reality as in my head. It’s too tedious working through all the outs in a hand. And since the scenarios are random, they feel too divorced from real poker which negates some of the supposed skill sharpening of the game. If I ever revisit, I would play around with the number of choices the player has to reduce some of the tedium while remaining true to the spirit of outs calculation.

3. I still do not know if there is a better than brute force way to check and compare the results of poker hands. If you look through the code, you will see I go through each hand possibility from a royal flush down to high card in a very straightforward manner and stop when a match is found. Even more elusive to me is if all the poker tools calculate the hand percentages in an algorithmic fashion. The only way I can think up is again brute force. There must be some math I’m missing!

You can peruse the source code on Github.

Back to fun things