KeithX's dashboard

Seems to work well, played two cash tables at Full Tilt for several hours today without any problems. Someone else will have to test at PokerStars, their limit game is all nits lolz.

Definitely need "No Limit Deep Stack" added to the cash game list, will have to keep using V1 for that game until it's added.

When you click on Tournaments you get the same game list as cash, there's no such thing as a Cap No Limit tourney. Tournament game list should be: No Limit, Pot Limit, Fixed Limit, and No Limit Satellite.

I'll have to pick which tourney type I'll use V2 for and use V1 for all the rest. I mostly play deep stack, 10 minute blind tourneys so will probably use V2 for those.

Can't use V2 for single table SnG games until number of tourney players and blind speed settings are available.

Really hate having to hit refresh to update the $ won total. If you just updated that one screen on a 3-5 second clock it would be enough for my purposes. I also was wondering why there are two Statistics screens; why would anyone use the Basic view?

Seems almost good enough to give it a Beta 1 label now ;-)

The Game Selector screen is essentially the same for both Game Play and Game Analysis modules. It's the only filter needed for the realtime Game Play module. The Analysis module also requires hand and position filtering for ROI analysis. I've reviewed all the possible game options at Full Tilt, but have not taken as much time to look at PokerStars as I rarely play there, so you may want to spend some time reviewing Pokerstars game options. Please note that I've dropped the primary distinction between a tournament and a sit & go game, the crossover between the two at Full Tilt makes the distinction essentially meaningless at this point. They now have Sit & Go games with more than five tables, deep stacks and ten minute blinds; that's a tourney lolz. Also, the word "Turbo" can mean several things, depending on context, so Blind Speed is more meaningful.

Cash Games:
Fixed Limit
Pot Limit
No Limit
No Limit - Cap
No Limit - Deep Stack
No Limit - Deep Stack w/Antes

Tourney Games:
Fixed Limit
Pot Limit
No Limit

Tourney Chips:
Small (1000 or less)
Standard (1500)
Double Stack (3000)
Super Stack (5000)
Rebuy - Unlimited
Rebuy - 1R + 1A

Tourney Blind Speed:
3 min
5 min
6 min
10 min
12 min

Tourney Players:
2
3 - 10
11 - 50
51 - 200
200+

Table Size:
2
6
9
10

For those wondering why so many choices, I can assure you that a good semi-pro or pro player will have significantly different VPiP, PFR and aggression numbers for each game variation. Stack sizes play a big role in hand selection, and blind speed has a significant impact on aggression in a tournament. One size definitely does not fit all lolz.

Check box arrays are definitely the way to go for all these options, that should make your query-builder design fairly straightforward. Selecting a Cash Game should gray out the three Tourney option sets for the HUD filter in the Game Play module, but not for the drill-down filter in the Game Analysis module. There should be Check All and Uncheck All buttons as well.

Thanks again for all your hard work!

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!