Recently active topics in Poker Copilot

Continuing on with my analysis of V2 requirements, some thoughts on data handling. The first piece of the puzzle is a data hub, the table(s) containing the raw, parsed input. In some scenarios there could be multiple hub tables, such as one for cash games and another for tournament games. While a single table is simple to implement, splitting things out might be more efficient in terms of downstream query processes.

Some aspects of tournament play require additional columns for data like starting stack size and blind speed parameters and all that might best be stored in a tournament-specific table. Additionally, should you decide to add Omaha Hi and Omaha Hi/Low games in V3 you would definitely need to keep the raw data in distinct tables. So it makes sense to me to begin implementing that base architecture for the parse slurp now. The complication comes when you want to analyze profitability across all games, but that's really a rather trivial join across several summary views or tables.

Parsing comes in three flavors: program data initialization, game play hand addition, and data import from other sources, such as the files you can buy from Player Table Ratings. One caveat about supporting the import of external data files is that it may create an issue with Full Tilt and Poker Stars. Both sites' terms of service specify that a player may only use data from their own play sessions.

The program data initialization mode should begin with a simple parse and write process. The user should be warned at initial program startup to close all active game sessions and shut down FT / PS before continuing. From my experience with V2 so far, it appears that triggering a mass data update at the same time as you are capturing changes to active hand files causes the system to overload and freeze.

After all the files have been parsed and imported you then begin the query process to build the HUD stat table or tables. Separate data sets for cash and tourney stats (and play money stats if you choose to support it) should be implemented. During any mass load process those tables should only be updated after the data slurp is completed. During game play those tables update after each new hand parse, with the user having access to frequency settings in a preference pane similar to that of V1. Warn the user not to start playing until the process is complete whenever you find a bunch of new hand files to import during startup checks.

Data handling for Game Analysis should use a similar incremental build approach. The process steps are selecting the Game Analysis Tab, which triggers a load / update sequence for the core analysis tables. Again, separate core tables for tourney, cash game, and play money data. Then, as each second-level Game Analysis tab is selected a query process runs to populate a reporting table for that specific screen. A table is generally better than a view for the reporting tables in the sense that a user would only have to wait for a specific query to run once during each analysis session. These sort of view / table data architecture decisions would be best made during alpha testing, using a data set of at least 100,000 hands. Be prepared to go to the well multiple times to get a really good handle on it lolz.

As for Hand Replay, that seems to me to be entirely different in terms of scope and process. Rather than using the static database it seems better to throw up a standard file selection popup and have the user select the hand history file they want to review. If you use that architecture then you do very quick slurp of the file and then trigger a video playback sort of screen to step through the session and hand. With that approach you avoid all the mess of having tied yourself to a static data architecture, which may in fact be modified from time to time thus is not really static at all. What you would lose with that approach is a more free-form data selection process, the ability to queue up all the hands played with a specific player, for example. Personally I would save those sorts of deep data hooks for V3, because I guarantee you that after working with V2 in production for a year you're going to significantly re-architect the data layer for V3 lolz.

Thanks for all your hard work!

I have several ideas to share in regards to the core program architecture. It seems to me that there are three distinct modalities for V2: Game Play, Game Analysis, and Hand Replay. I'll discuss what that means in terms of Data Handling, Game Analysis and Hand Replay in other posts, for now I want to focus purely on the user experience during Game Play. I'll refer to each mode as a tab and the sections within them as sub-tabs, thinking of the program as a Safari-style interface, however with two layers of tabs rather than just one.

In game play mode the player should have access to three tabs: a Current Player or "hero" tab, a Game Selector tab, and an Opponent Data tab. The Current Play tab should have rows for every possible HUD stat for the current player in spreadsheet mode, with multiple columns for trend and current action. This would be similar to the Advanced Statistics of V1, but rather than splitting numbers to the left and right there should be multiple columns to the right of the descriptors, with headings for All, 360 Days, 90 Days, 30 Days, and Today. If a tournament mode has been chosen in the Game Selector tab, then there should be slightly different rows and an additional column for Current Tournament. I don't believe that drawing little mini-charts, like the ones on the left in V1, is necessary or particularly useful. Winnings-related rows on the top, as in V1, and every available HUD stat listed below.

The Opponent Data tab is basically a the same as the hero tab, with a one-player lookup, and should list rows for the full list of HUD stats. Date-related columns should be included to give a full view of the trends of that opponents' strategy. Rather than having a list of all players, which is very process-intensive, there should be a search field to find and query the data for one specific player. Type-ahead lookup into an indexed player name list would help to find the player you want to review. This serves two purposes, first to find info for players before you choose a table to play at, and secondly to look more carefully at a player's actions while playing.

The Game Selector tab is the first place you go, prior to making a game selection the Player and Opponent tabs are greyed-out. When you activate Game Play mode, by making a game selection, the HUD turns on. When you switch to Game Analysis or Hand Replay mode the HUD turns off. You should not be able to enter Game Play mode until after all mass-updates of new data have been completed. For example I play on several computers and transfer hand history files between them. Each time I turn the program on all three main mode tabs should be greyed out whle a "data loading" progress message is displayed in the main program window. The trigger for turning on the three main tabs is that all files in the hand history folder created more than thirty minutes ago have been processed. Note that the timestamp may not be an accurate indicator, particularly when I have just downloaded a bunch of files from another computer, you need to look at the date embedded in the file name and the hand times embedded in the history file.

The data on the Current and Opponent Play tabs should be filtered according to the settings on the Game Selector tab. That's where all the selections listed in my prior post should be shown, things like table size, stack size, blinds speed, cash or tourney, etc. If some players want to see data across several table sizes or starting stack sizes, then a check box array would work best for that sort of multiple-choice filtering. Drop downs would probably be fine for me as I generally want to see data that exactly matches the type of game I'm playing. Once all choices have been made a Go button triggers the queries and HUD start, and the Player and Opponent tabs switch from greyed-out to active.

Thanks for all your hard work!

It would be great to be able to look up a player's HUD stats with the program. When I'm considering sitting at a table I'd like to know what's in my database for some of the players there, particularly VPiP, PFR and Steals, before I select a seat and sit down. Thanks!

Starting from the top init sequence ;-)

Turbo load should be the standard init process. The program is basically useless until all the hands are loaded, so just put up a "Loading Hands" message with a countdown. Get 'r done, then show the main screen.

The Turbo load message should disappear after all hands are loaded.

Full Tilt hand times that are invalid should automatically be corrected by default. If they aren't, your HUD screws up. Why would I ever not want that fixed? If you feel you must include a preference setting, don't call it "Obscure", call it "Full Tilt Anomalies".

Window clutter:

Kill the "Recent Games" window, it should not be separated from the table. "Show Cards from Last Hand" should be an option in one of the the HUD preference panes. If checked, the last hand shows up a line below the HUD stats. I shouldn't have to look back and forth at other windows trying to match names to seats when I'm playing. This is critical for multi-table play.

Kill the "Head-up Display" window, it contains two preference sets which should be tabs in the program Preferences pane. Starting of the HUD should be automatic. If a poker program is running and MyPlayer gets a hand at a table, then start the HUD and turn off the HUD startup polling process. If you must have an Off switch for the HUD put it on the program window header, but I don't believe we need one.

Program options:

Cash vs Play money? Will someone really buy this program and not play for real money? Seems like a total waste of space and code to me lolz.

Game Types:
Fixed Limit Cash
Pot Limit Cash
No Limit Cash
No Limit Cap Cash
No Limit Deep Stack Cash

Tournament
Sit & Go

Tourney, S&G Speed Options: Standard, Turbo

Tourney, S&G Structure Options: No Limit, Pot Limit, or Fixed Limit

Table Size Options, Cash and Tourney: Full Table, 6 Seated, Heads Up

Players should be using a significantly different strategy for every one of these games and table sizes. The HUD display should reflect only those hands that fit the selected game structure.

Statistical analysis is something completely separate. While I will need to analyze stats from a specific game structure, I will also need to analyze consolidated stats across game types. A Game Type and Table Size check array for which structures to include in the stats would work for me.

Now I'm going to try to use the program lolz ...

The HUD worked. I generally don't use labels, but checked to see that they appear when selected.

Hero stats for current table option seemed to work properly, but I've played at several tables today so I'm not sure if the numbers are correct, I have nothing to check them against. I can't imagine ever using Opponent stats for current table, and did not check that function.

Using table cells for each stat instead of stringing each line together really adds to the space needed for the HUD display. I would prefer that a space be added between each stat on a line, instead of having columns. When you include "#", i.e. number of hands played, the HUD display looks really bad if you have thousands or tens of thousands of hands on some players.

Note on Hero stats: in addition to "current table" and "all" you should be able to choose "today, "current tournament" and "current sit & go". The "today" setting would be particularly appropriate for multi-table cash play.

I didn't look at stats, no time today. I've posted in other messages here that what really matters to me is ROI on hands played, by position, for each game structure. It would also be nice to know how much I have won or lost from each player at the table, as one of the possible HUD stat choices.

Thanks for all your hard work!