2021 Public Beta: HRC Goes Postflop

A preview of the next HRC version is now available for download, introducing new features for deeper stacked calculations. This post will be updated throughout the beta phase to reflect the current progress and list known issues.

Overview

Since our launch in 2012 HRC has been a tool focused on Preflop strategies when stacks are shallow, shining especially in those push-or-fold phases late into tournaments or sit-and-goes. In this beta cycle we branch out into deeper stacked play where flat calling and Postflop equity realization are important factors.

Our goal is to provide a complete Preflop/Postflop solver combination by the end of this beta cycle, fully integrated with our existing tournament features.

Progress

Currently available:

  • Save/load support for Monte Carlo calculations.
  • Monte Carlo calculations with Postflop equity realization.
  • Fully customizable tree building via scripts.
  • General performance improvements for the Monte Carlo engine.
  • New Range editor with the option to bookmark/save custom ranges.
  • New display modes for the Range Viewer component.

Planned for the near future:

  • Simplified/improved handling of saved hands.
  • Rewrite of the bet sizing UI to allow better customization of the game tree.
  • Support for BB antes.

Expected later:

  • Graphical hand replayer with Quiz / Play Against the Solution capabilities.
  • Extended Quick Analyze functionality.
  • Dedicated Postflop solver and full interaction with Postflop strategies.

Installation

This version is for subscribers only. The beta version only accepts regular HRC licenses, trial users will not be able to participate.

The latest HRC beta can be downloaded here:

Only download this version if you are comfortable with testing beta features. This version may introduce stability issues and other bugs. Once the new features are sufficiently tested, they will be integrated to the stable version. You can run the stable and beta versions on the same system, simply use different install locations.

Postflop Equity Realization

This feature is the main addition of the initial beta version. In previous HRC versions any pots that weren't all-in Preflop were assumed to be checked down after the flop. Previously we advised against using limps/flatting lines, except for setting up previous actions. This new version introduces Postflop betting for Monte Carlo calculations. Calculations can now accurately model Postflop equity realization, even taking the various ICM/KO factors and full card bunching into account. This feature does not apply a static equity realization approximation but actually builds a Postflop game tree.

This means HRC can now calculate useful general purpose Preflop ranges for deep stacked play.

This feature can be found at the bottom of the betting setup dialog when selecting the Advanced Monte Carlo Mode. Explanations of these new settings are displayed as tooltips. Make sure to run additional sampling after the initial calculation completes by using the green Run Nash Calculation button in the toolbar, Postflop calculations require considerably larger sample sizes than a Preflop calculation.

Screenshot of Postflop Configuration Settings

The structure of the Postflop tree can be browsed in the regular strategy table. The table also shows the frequency of various Postflop lines being taken as an average over all boards. Board specific EVs or hand strategies can not be displayed at this time.

Screenshot of Postflop Frequencies

A note on Postflop positions: Hands calculated with exactly two players use HU positions by default: The SB is on the button and the BB is first to act after the Flop. Hands with more than 2 players use standard positions where the SB is first to act after the Flop.

How does this work?

Users familiar with Postflop solvers will be aware that solving Postflop trees requires an extensive amount of memory, especially when working with dozens or hundreds of different Postflop spots between the various players and Preflop sequences. HRC uses imperfect recall abstractions to make these calculations feasible with regular consumer hardware.

Instead of learning the Postflop strategies for each individual board run-out, HRC uses abstractions that place the various board/hand combinations into a number of buckets that contain similar situations. The solver no longer works out the strategies for specific hands on specific boards, but for groups of similar situations across a variety of boards. Conceptually the solver learns to play entire categories of hands e.g. "mid pair strong kicker on a low two-suited board", unaware of the specific hand/board combination that is currently sampled.

Abstraction sizes

The number of buckets controls how nuanced these categories are. A lower number of buckets means more hand/board combinations are placed into each bucket. As more combinations are added, the combinations within a bucket become less similar to each other and details of the situations are lost. For example, reducing the number of buckets we may go from "mid pair strong kicker on a low two-suited board" to a more general bucket like "mid pair on a two-suited board". Eventually this sacrifices the ability to play individual hands correctly if the buckets become too general.

The main benefit of this approach are vastly reduced memory requirements and faster convergence. Strategies converge faster because the solver is generalizing over the various hand/board combinations within the buckets. Even if a particular hand/board combination shows up in sampling for the very first time, a sensible strategy may have already been derived from seeing similar hand/board combinations of the same bucket earlier. It's no longer necessary to process a large number of samples for each individual hand/board run-out.

In the initial version we provide abstractions ranging from as few as 64 buckets all the way up to 16k buckets. The first instinct of users may be to pick abstractions as large as possible within the available memory. We strongly recommend giving the smaller abstractions a try first, especially when only interested in the Preflop EVs and ranges.

Larger abstractions do have a higher accuracy ceiling: Given enough training time, the additional detail of the abstraction will allow for more accurate strategies. On the other hand larger abstractions generalize less aggressively, which means more training is required before reaching even a decent level of accuracy. When running quick calculations with limited sampling, large abstractions typically perform considerably worse than small ones.

Additional information

It's important to mention that the raw number of buckets isn't the only factor for abstraction quality. Since hands within each bucket need to be played the same way, it's essential that only hand/board combinations that are strategically similar are grouped together in a bucket. Finding a metric that captures the strategic similarity of hands is actually fairly complex.

For example: When using the equity against a random hand as similarity metric, underpairs and weak draws can be almost indistinguishable on some boards. These hands would then be grouped together in the same bucket even though they are not actually strategically similar at all. Increasing the number of buckets wouldn't fix this general problem, this metric simply does not consider all important factors.

The abstractions used in HRC not only compare the equity of hands, but also how these hands realize their equity on future streets. We'll leave the details for another blog post, but interested readers can check the excellent 2013 paper by Johanson et al from the University of Alberta linked below for more information.

Evaluating State-Space Abstractions in Extensive-Form Games

Scripted Tree Building

With the introduction of the Postflop model, users started to really push the UI based tree setup in HRC to its limits. The tree creation could become very bothersome, with users supplying a large number of sizings to cover all possible situations and then manually pruning the tree after creation. That's a very time consuming and inefficient process.

Scripted tree building allows full customization of the tree building process with the help of simple scripts. This feature is only available for Advanced Monte Carlo hands. Ideally this will remove the need for excessive manual pruning after the tree creation. It also enables users to define their desired betting setup once and then re-use the script for any number of calculations.

Screenshot of Script Settings

The core idea is that users still configure the stacks, blinds and equity model via the user interface. However, instead of entering globally allowed raise sizes and flat calling options in the user interface, users can provide a script with spot-specific rules. The script has access to the full game state for each decision point, including all previous actions.

With access to the game state it's straightforward to:

  • Define opening sizes and calling options depending on the player's position
  • Define separate sizings for squeeze spots
  • Use special sizings for donk bets or even disable them entirely
  • Configure various sizings Postflop, depending on the effective stack-pot-ratio
  • etc.

Getting Started

Let's get the very first scripted build out of the way:

  • Start a new Advanced Monte Carlo hand.
  • Setup stacks in the 25-40bb range and select an equity model as usual.
  • Download the example script (Use right click: Save link as...)
  • Click Next to go to the bet sizing setup, click the Open Script button and select the downloaded file.
  • Click Finish to create the tree.

Nice, you have created your first scripted tree!

This example features a generic 25-40bb MTT setup:

  • No limps, except for the SB who can complete
  • Multiple sizings for opening, 3-betting and squeezing
  • All 4-bets are all-in
  • Separate sizings for the blinds

Customizing the example

Don't get discouraged by the code, customizing the script is simple and doesn't require any coding skills.

You can use any text editor to customize the script. We can recommend Geany as a free and lightweight option that is available for Windows, OSX and Linux. Using Window's default text editor is also fine, but you won't have the colored syntax highlighting.

You already downloaded the example earlier, now let's open it in Geany. You should see the syntax colored similar to the "Show example source" option below. Focus on the first few lines where the sizes are defined, it's no more complicated than changing those values and saving the file. Then simply load the modified version in HRC, that's it!

Show example source


Additional examples

In this section we'll provide a selection of scripts for some common tree configurations. Check back here for updates and additional examples.

These scripts were created in collaboration with the HRC Discord Community. Stop by if you have any scripting requests!

Advanced MTT example (no limping)

This script should be suitable for most stack sizes and is very flexible in the way it can be customized. The main restriction is that limps are generally not allowed, except for the small blind player who can complete.

Download mtt_advanced_20211029.js (Use right click: Save link as...)

View Source Code


Preflop:

  • Opening / 3-bet / squeeze sizes in big blinds
  • Configurable number of flats against opens / 3-bets / etc
  • Separate sizings for SB / BB
  • Sizing for 4-bets and 5-bets in relation to the pot IP & OOP
  • Option to disable cold calls against 3-bets+
  • Option to always allow flat calls if they close the action
  • Adding all-in if SPR is below a set value
  • All-in threshold like UI

Postflop:

  • Option to disable donk betting
  • Option to allow donk betting only if a player showed previous aggression
  • Option to force a checkdown for multiway pots after a set street
  • Option for additional pot-% sizings for all flop bets
  • Option for additional pot-% sizings only for flop c-bets
  • Adding all-in if SPR is below a set value

Advanced PKO example (with limps)

This is an extension of the previous example and has the option to allow one or more limps. This is likely to be most useful for bounty games.

The opening sizes can be adjusted based on the number of limpers and whether the raising player has position on all limpers. Since we are now dealing with a large number of possible opening sizes, using fixed 3-bet sizings is no longer suitable. Instead this script defines the 3-bet sizes as multiplicators of the previous raise.

Download pko_limps_20211103.js (Use right click: Save link as...)

View Source Code


Preflop:

  • Opening / 3-bet / squeeze sizes as multiplier of last raise
  • Configurable number of limps and flats against opens/3bets/etc
  • Option to allow SB completes in addition to the regular limping limit
  • Option to adjust opening sizes depending the number of limps
  • Separate sizings for SB / BB
  • Sizing for 4-bets and 5-bets in relation to the pot IP & OOP
  • Option to disable cold calls against 3-bets+
  • Option to always allow flat calls if they close the action
  • Adding all-in if SPR is below a set value
  • All-in threshold like UI

(Differences to the no-limp version in bold.)

Postflop:

  • Option to disable donk betting
  • Option to allow donk betting only if a player showed previous aggression
  • Option to force a checkdown for multiway pots after a set street
  • Option for additional pot-% sizings for all flop bets
  • Option for additional pot-% sizings only for flop c-bets
  • Adding all-in if SPR is below a set value

Writing your own scripts

To write your own scripts, some coding experience would be helpful. The scripts are written in JavaScript, but if you know any C-like language (C, C++, C#, Java,...) this should be sufficient. It's easiest to get started by adjusting / extending the example, we'll post additional ones soon.

Resources:

This is an experimental version of the scripting API, we need your feedback to understand what users are trying to achieve in their customized trees. Let us know what parts you are struggling with, so we can add additional methods to make things easier. Ideally post in the 2+2 support thread so other users can learn from your questions.

During the first few weeks there may be additional changes to the API that could potentially break your scripts. We'll try to stabilize the API as soon as possible.

Other Features

Viewer Mode

It is now possible to open saved hands in a quick read-only mode. Saved hands can be loaded almost instantly and only require very modest amounts of RAM. Hands opened in viewer mode will be marked as read-only [ro] in the hand tab.

Screenshot of Viewer Mode

This mode only transfers data that is required for display purposes and should typically need no more than a few MB, regardless of the total tree size. The process works transparently from remote locations, e.g. hands stored on a NAS, remote server or cloud storage. To load hands from a remote location, simply mount them into your local file system first. In Windows this can be done using the "Map network drive" option or by using various cloud storage clients.

When working with local files there should only be minimal delays when branches are expanded in the UI. For remote locations this can become more noticeable, depending on the connection speed and latency.

This mode is still highly experimental, please let us know if you experience any problems.

Range Bookmarks

The range edit dialog now includes a new bookmark sidebar that can be shown via the collapse button in the bottom right area. This provides a way to manage ranges within the program, including full support for weighted strategies and options for importing / exporting of saved ranges.

Screenshot of Range Bookmarks

Range Viewer

The hand grid component now has two additional display modes to better visualize nodes with multiple actions. The strategies can be displayed as pie/bar charts using the new buttons above the hand grid. The color scheme is still temporary.

Screenshot of Strategy Barchart

Instructions

Increasing HRC's memory limit

By default the beta version of HRC uses a memory limit of 4GB, this also limits the size of trees that can be calculated. If you see error messages about "Insufficient heap space" or "Out of memory exceptions" then either simplify your tree or increase the memory limit.

To increase this limit, open the hrc.ini file from the installation directory in a text editor and look for the line starting with "-Xmx", the default should be "-Xmx4G" (4GB). Increase this setting to a higher value, e.g. "-Xmx8G" (8GB), save the file and restart HRC. The effective memory limit is displayed in the Postflop section of the hand setup.

Screenshot of hrc.ini

Important: The -Xmx parameter tells the Java runtime how much memory it is allowed to allocate if necessary. Java will not check if other processes have enough spare memory. If you use -Xmx16G on a machine with 16GB physical RAM then you may experience severe performance drop-offs or crashes. Your overall requirements may exceed the installed physical RAM if Java tries to allocate the full 16GB, so the OS will be forced to either start swapping (slow) or killing programs ("crashes").

The suitable -Xmx value depends on the operating system and other programs running, but we'd recommend keeping at least 4-8GB of memory reserved for the OS and other tools. There's no significant performance benefit to allocating excessive spare memory, e.g. an 8GB tree will generally run at roughly the same sampling speed with -Xmx16G or -Xmx32G. Some rough guidelines for the maximum recommended Xmx values can be found below, you probably shouldn't go any higher than that.

Physical RAMMax. Xmx
8GB4G - 6G
16GB~ 12G
32GB~ 26G
64GB~ 56G
128GB~ 120G

You can monitor the live heap usage in the program by enabling Window: Preferences: General Performance: Show heap status. Make sure to restart HRC after changing this setting.

Upcoming: Subscription Changes

Some of the planned features go way beyond the feature set of classical ICM tools and cross over into the area of Preflop/Postflop GTO solvers. We intend to transition the Preflop functionality into a basic subscription tier and make some of the new features exclusive to a premium tier. Content that has already been available in the current stable version will NOT be moved into a premium tier, this is strictly for some of the new content.

For the duration of this public beta test all new features will be accessible for users with a regular HRC license (no trials). We currently expect the beta phase to run at least until Q4/2021, so there will be plenty of time to explore these features at no additional cost. But we'd like to make it clear from the start that some of the new content will require a subscription upgrade after the beta concludes.

We also haven't updated our pricing structure since the HRC launch way back in 2012 and some minor changes are overdue. We will be restructuring the subscriptions to be more in line with other products in this space. We intend to grandfather any existing subscriptions into the basic tier at their current pricing.

Feedback

Please leave feedback and ask questions if anything is unclear! Any general feedback on the current and planned changes is appreciated. We are especially interested about your experiences with the new Postflop mode, e.g. unexpected deviations from other solvers, your favorite abstraction settings, etc.

Also make sure to report any stability issues or user interface glitches! We need to know about them before we can fix them :)

The HRC Support Thread on 2+2 is the best option for general questions, feedback and discussions of new features. Preferably contact support@holdemresources.net with bug reports or issues that may be related to your specific hardware setup. In these cases please try to include the steps necessary to reproduce the problem and ideally mention any special properties of your computer setup that might affect the issue.

We will also add a Discord server for the beta in the near future to make it easier to get in touch directly.


Change History

  • 2021-04-22: Updated for Range Viewer changes.
  • 2021-09-07: Added instructions for changing the memory limit.
  • 2021-09-09: Added section for Viewer mode.
  • 2021-10-12: Added section for scripted tree building.
  • 2021-10-29: Added advanced MTT scripting example.