[brianmarc]

I recently completed an in-depth review of WinHoldem (“WH”), the on-line poker-playing “bot” that recently received much notoriety when they built their launch promotion on the basis of a “team” (read “collusion”) capability. Let me start by saying that I worked only with the $100-per-year Pro version which plays as a single, multi-table uncolluded automated player. The purpose of this review is to provide the online poker community with an objective, user-oriented assessment of the beginning of a trend that is here to stay: computerized assistance to the online player. I take no position on whether bots are right or wrong, whether it is “bad” or “good” for the game, or how the online casinos will respond.

WH Pro Team comprises two separate capabilities: First is a purely technical, operational capability that identifies game status and reports it to the player, and then relays the playing decision back to the game, either automatically or in response to the user’s selection. This decision is generated by the second capability: a programmable rules engine. Both operational and rules capabilities are accessed from an onscreen console.

The process begins by the logging into their online casino and taking a seat in the normal fashion at as many tables you wish to play. The only limitation is that each table must be completely unoccluded for the operational screen-scraping software to function, so screen real estate is an important constraint. A separate console then controls each table.

WH plays a single table very robustly, and will play automatically indefinitely. However, although WH claims to support multiple-table play – an essential capability in my view for an automated bot - this capability does not work with any consistency. While connecting correctly to as multiple tables was safely accomplished, the various casino windows eventually begin random motion on the screen and eventually become occluded with the result that the screen-scraper loses its targets and play to the tables gradually ceases. The only remedy is to relaunch the consoles. So, for all practical purposes, WH should be considered a single-table system.

However, with myriad limitations, omissions, typos and inconsistencies, the user interface (UI), documentation and technical support are terrible and not worthy of a commercial product costing $100 per year. The UI is reminiscent of a high school computer lab project, and the documentation reminded me of the self-assembly furniture instruction manuals written in the Far East! Although the list of problems is too long to fully identify, some of the most serious are as follows:
-No real-time feedback on the source of the playing decision and a limited, non-configurable playing log for subsequent analysis of playing decisions. This means there is simply no way to evaluate the playing session apart from standard downloads to services PokerStats.
-No capability to test or debug the playing decision module (see below for a description of how this works). While there is a “manual” mode that permits you to enter hypothetical game situations , it is so cumbersome and non-intuitive that I quickly gave up trying to use it. As an example, placing a bet in front of an opponent to indicate his participation on a hand does not increase the pot size-you have to enter this information elsewhere on the console. And since this is one of the many undocumented non-intuitive features of WH, there is truly o way to efficiently play practice hands to test decision rules.
-There is no way to save configuration settings, (such as the rake amount, the preferred mode of operation (manual, semi-automatic), number of simulations (see discussion below on the rules engine), hiding the WH window title (necessary to avoid rejection on some sites), colors, fonts, etc. This meant a painstaking re-entering of all user preferences each time the system was launched.
-You have to be connected to the Internet and in contact with the WH server in order to even open the console. This made it impossible for me to do any programming or testing on my laptop during my frequent business flights.
-Tech “support” was also of limited use. Due to the problems with the UI and documentation I had extensive email contact with the support group. And although they were fairly prompt in replying to my many queries and comments, the quality of the responses left a lot to be desired. They also provide no support on questions in coding decision rules, and do offer a user forum for the exchange of ideas among users. This problem was compounded by what appears to be a rudimentary knowledge of the game: for example, they were unfamiliar with terms such as outs, player position and game texture.

The second element of the system is its decision-making engine. And, frankly, if this were effective and robust I could have learned to live with the above-described frustrations of actually using the system.

The out-of-the-box decision-making mechanism is an undocumented, “black box” simulation engine that calculates the probability of winning the hand and then uses a simple formula to compute the associated EV of raising and calling. If EV Raise is positive, the “raise” command is given; if it is negative, and EV call is positive, the “call” command is given, otherwise you check or fold. The problems with this methodology are numerous: the win-probability calculation assumes all players hold their hands to showdown; it ignores position, game texture and the number of players remaining in the hand. This last problem is worthy of some additional comment: The way WH handles players in the game is to assume a static number for all probability analyses! This number is based on a user setting of how defense he wants to be:” max defense” uses 10 players in the calc; while “Minimum defense” uses 2 players. As far as I could tell from the limited information available, these decisions bear no relation to the actual game situation and whether the players assumes to be in the game have bet, called, raised or checked! As you would expect this creates many strange and totally illogical decisions, such as virtually always calling with 2nd or 3rd pair, never raising two-pair in a non-threatening board. Needless to say, strategic plays such as slow-playing, check raising and blind stealing are way beyond the bot’s pay grade.

I tested this default system on a major online site. The only game I did not rapidly lose my entire stack on were the $0.50/$1.00 and $1.00/$2.00 games. These games are classic weak/tight or loose/passive, so the kinds of mistakes WH was making were rarely severely punished, although I would often cringe when my player would re-raise on the river with 2nd pair against 2 or more opponents! I played about 2,000 hands at this level and ended up winning about 0.1 BB per hour.

I next moved up to the $2/$4 and $3/$6 games. It quickly became apparent that the bot had no chance now that opponents were displaying some degree of competence, and I quickly cut my losses, it being apparent to me that the default system is essentially useless. So I went back to the drawing board trying to modify the bot to play more intelligently.

This required using the WH “Formula Editor”, which the user can write his own specific playing rules, that could theoretically even avoid use of the simulation mechanism by writing from the ground up a “rules-based” system, in which every hand and board situation needs to be explicitly identified. (Those familiar with the Wilson TTH system will be familiar with one way of thinking about this is.) A rules-base system requires two distinct elements: a unique identification of the game situation, and the associated decision rule. (IMHO TTH provides an excellent baseline for the first of these - game-situation identification - but is weak on the way it makes the actual decisions.) Writing a rules-based system from scratch is a HUGE undertaking, even with sophisticated programming and development tools. In the complex and user-unfriendly WH environment this is an impossibility. For example, you need to be somewhat proficient in the C++ programming language; you need to develop this in an editor that provides no testing or debugging capability, and you need to do it with a rules se that is incapable of considering kicker rank, game texture, player position, kickers, bluffing, semi-bluffing, check-raising, slow playing and opponent recognition.

With this in mind, I set about reprogramming WH to incorporate a combination of simulation and rules-based systems. A word of caution: this is NOT an exercise for the weak of stomach and keep the headache pills handy! I have programmed an awful lot of code, but I was totally unprepared for the difficulties of this beast! As any programmer will tell you, the ability to segment your code into manageable segments and syntax and debugging tools are essential for productive coding. With none of these capabilities, WH requires you to work without sub-routine and function calls, without case or if..then statements, so the rules you write are essentially one long single statement for each of calling/checking and betting/raising decisions. There is no capability, so you need to write every condition as a concatenation of “or” and “and” statements. This means you need to repeat all the conditions for each element of your decision, and god-forbid if you make a syntax error, the only indication you get is, when you hit the Calculate button, the word “error” appears, with no indication as to the location or source of the problem!.

However, being a glutton for punishment, I persevered with the objective of replicating the HPFAP rules pre-flop for loose games, with some modifications from authors such as Lee Jones suggestions for low-stakes games.

Pre-flop was relatively easy since you can specify the hands you wish to play in one of 6 distinct tables and then reference these tables with simple code statements. This allowed me to specify what I wanted to play from each of five positions: SB, BB, early, middle, late.

Coding for post-flop was where the real headaches began. Since I could not calculate outs or identify the strength of my kicker I made many simplifying assumptions such as modify the EV calc so that the threshold for putting any money in the pot is significantly greater than zero, so be overly conservative when calling down a raise or raising without a killer hand. The only strategic option I included was to raise on the turn when on a nut or near-nut draw after limpers in a family pot.

The result of now more than 40 hours of work was several hundred lines of syntactically correct code.

I then took my “new and improved” bot back to the online sites I had played earlier. Remember, this is a totally untested in a playing environment due to WH’s lack of testing capability, so the real world was going to be my lab.

After a couple dozen hands it was apparent that somewhere my programming logic was flawed – there were playing errors everywhere: positions were not being correctly identified and folds, calls and raises were all over the lot. It was clear that additional work was needed, but there was simply no way to debug the code. Normally, I would have put “markers” in the code to identify the source of each decision. But this is not possible in WH, so, in effect, my efforts were at an impasse and I cut my losses and quit the effort.

Bottom line: Although clearly designed by competent technicians, WH is basically unusable if making money is your goal. Given the complexities of the code it will be a practical impossibility for any non-professional programmer to even hope to master the coding environment, and while there may be some of you out there that had more success in determining functional rules that can play profitably, I am conclude that we will have to wait until someone comes along with a poker bot that is both robust and flexible enough to be used by skilled poker players who are not also software programmers.

P.S. I’m interested in hearing from anyone out there who has their own experiences with this product. Feel free to respond here or by IM.