When the algorithm depends on the game¶
There is a tempting belief, and almost everyone new to game AI holds it for a while: that "hidden-information AI" is a single thing you learn once and apply everywhere. You read about the algorithm that plays poker, or the one that plays a bluffing card game, and you file it under the way computers handle hidden information and move on.
This catalog was built to disprove that belief, mostly by accident. It contains games that all involve some kind of hidden or uncertain information, and no two of them can share the same AI. Not "should not" -- cannot. The algorithm that makes a strong opponent in one of them makes a confidently wrong opponent in the next. The single most repeated design lesson in this whole project, stated plainly in one sentence, is this:
The hidden-information AI algorithm is chosen by the game's structure, not by the author's preference.
That sentence lives, in spirit and nearly word for word, at the top of the overview docs, the design-reference doc every agent reads before writing AI code. The retrieval card there ends with a blunt instruction: "Do not assume ISMCTS is universally correct." ISMCTS is the algorithm most people learn first for hidden information, and it is exactly the one you are most likely to over-apply. This post is the long version of that one card -- the worked catalog behind the rule.
If you are learning to build software with an AI assistant, this is also a transferable lesson about you, not just about game bots. The failure mode -- "I know one good tool, so I will use it for everything" -- is the same failure mode an LLM has when you ask it to design a system. It will happily reach for the algorithm it has seen most often. The job is to make the structure of the problem pick the tool, and then to know enough to check the answer.
The temptation, and what it costs¶
Picture the wrong version of this project. One AI engine, one algorithm, wired into every game. It would pass a surprising number of tests. It would even play some games well. And it would ship at least one opponent that is plausibly terrible -- terrible in a way that looks like a strong move until you understand the game it is playing.
That is the dangerous case. A bad opponent that plays obviously random moves gets caught immediately. A bad opponent that runs a respected algorithm on the wrong game shape produces moves with the shape of competence and the substance of nonsense. Nobody on the team notices, because the algorithm has a famous name and a paper behind it. The players notice, eventually, by losing interest -- which is the most expensive bug there is, because it is silent.
So the catalog does the opposite. It treats "what is the structure of this game?" as the first question and "which algorithm?" as a consequence of the answer, never the reverse. Here is what falls out when you actually do that.
Four games, four shapes, four algorithms¶
Turn-based, hidden hand: ISMCTS¶
Start with Bluff, the catalog's canonical hidden-information game. Players take turns. What is hidden is the contents of other players' hands and whether a given claim is a lie. The turns alternate; the uncertainty is about opponent state.
That exact shape -- turns alternate, hidden info is opponent state -- is the home territory of Information Set Monte Carlo Tree Search (ISMCTS). Instead of searching over single, fully-known game states (which the AI cannot see, because it does not know your hand), ISMCTS searches over information sets: the whole family of states that are consistent with what the AI actually knows. The real implementation lives in the relevant AI module; if you open it, the docstring describes "single-observer ISMCTS rooted at player_id's information set," sampling one compatible full state per iteration and using availability counts for subset-armed selection. Those are the moving parts the foundational ISMCTS paper (Cowling, Powley, Whitehouse, 2012) introduced, and the reason it exists at all is that the naive shortcut -- "just guess everyone's hidden cards and run ordinary search" -- has known failure modes the paper calls strategy fusion and non-locality. The card on this in DESIGN_RESOURCES.md tells you to understand why that shortcut fails before touching the implementation.
ISMCTS is also the planned upgrade path for Rail Routes once it reaches its harder tiers -- a turn-based game with hidden destination tickets, the same structural family as Bluff.
Simultaneous betting: CFR (and what actually ships first)¶
Now change one thing about the structure. In Texas Hold'em, players do not take strict turns over private state -- they make betting decisions in rounds, with continuous, large bet sizes, and the strategic content is in committing chips under uncertainty. That is a different shape, and it has a different right answer: Counterfactual Regret Minimization (CFR).
CFR is regret minimization over abstracted betting sequences, and it is not a stylistic preference -- it is the family of algorithm that actually solved the game. Heads-up limit hold'em was effectively solved with CFR (Bowling et al., 2015), and the systems that beat professional players at no-limit (Libratus, DeepStack, 2017-2018) are CFR variants. The DESIGN_RESOURCES.md card is explicit that swapping ISMCTS in here is a mistake: "Do not substitute ISMCTS for CFR on poker; the game tree structure is different enough that ISMCTS is the wrong tool." Same hidden-information umbrella, opposite algorithm.
Here is the honest part, and it is worth dwelling on because it is the kind of thing AI assistants gloss over. The shipped Hold'em product does not contain a CFR solver today. What ships is the deterministic equity panel -- a plain Monte Carlo enumeration over the remaining deck -- plus a bring-your-own-key LLM that talks you through a decision. That whole split is the subject of its own post, The equity panel is the AI, which is blunt that "there is not a model anywhere near" the equity number. CFR is the algorithm the game's structure calls for and the forward-looking plan names; it is not a thing you can point at in the repo and run right now. Saying "CFR is correct for poker" and "CFR is shipped here" are two different claims, and only the first one is true today.
Social deduction: no search algorithm at all¶
Werewolf looks, on paper, like more hidden information: hidden roles, secret night actions, players lying about what they are. By the over-applied logic, it should get ISMCTS too -- it is turn-structured and the hidden thing is opponent state.
It gets nothing of the kind, and this is the beat that proves the whole thesis. DESIGN_RESOURCES.md files Werewolf under "No search AI -- social deduction games," with the warning: "Do not wire a search algorithm to a Werewolf bot; the AI design question is LLM persona and moderation, not search." There is no tree to search in a way that means anything, because the action space is open-ended human conversation and there is no rollout that can simulate a person deciding to believe a lie. You cannot even score "quality of play" the way you can for Bluff or Hold'em.
So the answer to "which hidden-information algorithm does Werewolf use?" is none. The intelligence in Werewolf is the server acting as a silent moderator plus an LLM that runs personas and, after the game, reconstructs how the deception actually unfolded. A hidden-information game whose correct algorithm is "not a search algorithm" is the single clearest demonstration that structure picks the tool. If you took the rule "hidden info implies ISMCTS" seriously, Werewolf is where it shatters.
Fully observable: vanilla AlphaZero¶
For contrast, take the hidden information away. Battleland is a hex-based tactical wargame where the board is shared and visible. Both armies are on the map; resolution is dice on known stats. There is randomness, but there is no hidden opponent hand to reason about -- the position in front of the AI is the whole position.
When the game is fully observable, you no longer need information sets, and you can use the famous learned-model approach directly: vanilla AlphaZero -- a combined policy/value network trained by self-play, with Monte Carlo Tree Search using the network's hunches instead of random rollouts. The real pipeline is under the relevant AI module, and the dedicated post Battleland: the first game that trains its own opponent walks the four moving parts (network, self-play loop, model-guided search, trainer). The point for this post is the contrast: Battleland can use the textbook algorithm precisely because its structure is the simplest of the bunch. Take away the hidden information and the algorithm gets more standard, not less.
Open-ended adversarial helper: behavior trees and heuristics¶
The last shape is the one that breaks search entirely from the other direction. A planned D&D Combat helper has a near-unbounded, creative action space -- a player can try things no enumerator anticipated. DESIGN_RESOURCES.md routes this to tiered behavior trees (heuristic, then persona-scripted, then LLM-guided), with MCTS reserved only for narrow sub-problems like grid movement, and the warning: "Do not use pure MCTS for D&D monster AI; rollouts cannot simulate creative player actions." When you cannot simulate forward meaningfully, tree search has nothing to stand on, and you fall back to authored behavior plus a model for the open-ended parts.
The map, on one page¶
| Game | Structure | Algorithm the structure selects | Status in the repo |
|---|---|---|---|
| Bluff | turn-based, hidden opponent hand | ISMCTS | shipped (the relevant AI module) |
| Rail Routes | turn-based, hidden tickets | ISMCTS (harder tiers) | planned |
| Texas Hold'em | simultaneous multi-round betting | CFR | CFR forward-looking; ships an equity panel + LLM advisor today |
| Werewolf | social deduction, hidden roles | none -- LLM persona + server moderator | shipped (LLM, not search) |
| Battleland | fully observable hex combat | vanilla AlphaZero | shipped, experimental (the relevant AI module) |
| D&D Combat | open-ended, creative actions | behavior trees + heuristics | planned (design-doc only) |
Read that column of algorithms top to bottom. ISMCTS, ISMCTS, CFR, none, AlphaZero, behavior trees. Six games, and the only repeat is the one pair that shares a structure. There is no row where "the algorithm I already knew" was the right answer for a game it did not match.
The honest edge¶
It would be easy to read the table above as "six games, six finished AIs." It is not, and pretending otherwise would be the exact confident-wrongness this post is warning against. So, plainly:
- D&D and Rail Routes are design-doc-only. Their algorithm assignments are forward-looking decisions recorded in
ROADMAP.mdand the design docs, not running code. They are in the table because the structure already determines their answer, not because you can play them. - Hold'em's CFR is not built. As above: the structurally-correct algorithm is named and planned; what ships is deterministic equity math plus an LLM advisor.
- The base MCTS is perfect-information only. The general-purpose search at the relevant AI module -- the one the three personalities (Steady Eddie, The Prodigy, Old Reliable) run for the simpler perfect-information games -- assumes it can see the whole state. It is not correct for Bluff on its own; ISMCTS is the upgrade that adds information sets on top of that same search core. The personality layer is described in AI opponents that play like people, and the useful thing to notice is that personality sits above the algorithm choice: Eddie can run plain MCTS for a perfect-information game or ISMCTS for Bluff and still be Eddie. Structure picks the search; personality picks the character.
None of those gaps weaken the thesis; they are the thesis. The repo is honest about which choices are shipped and which are committed-but-pending, and the algorithm-by-structure rule is what makes the pending ones already decided.
Why this is the lesson, not just a fact about board games¶
If you are new to building with an AI assistant, here is the part to carry out of the games entirely.
The mistake "one algorithm for all hidden information" is a special case of a much more common mistake: letting the tool you know best define the problem. An AI assistant does this constantly and convincingly. Ask it for hidden-information game AI and there is a real chance it offers you ISMCTS for everything, because ISMCTS is what its training data associates most strongly with the phrase. It will be articulate about it. It will not be right about Werewolf, and it will be subtly wrong about poker.
This project's defense is to write the structural distinction down as a rule the assistant has to read -- the "Choosing the right hidden-information AI algorithm" section of DESIGN_RESOURCES.md -- and to anchor every AI ticket on the named game shape before any algorithm is mentioned. The structure goes in the acceptance criteria; the algorithm is downstream of it. That is the small, boring discipline that keeps a confidently-wrong opponent out of the catalog, and it generalizes far past games: name the shape of the problem first, let it select the tool, and treat any tool that arrives before the shape with suspicion.
The six worked examples are linked above, each in the post that takes its one game seriously: Bluff for ISMCTS, Hold'em for the CFR-vs-reality split, Werewolf for the no-search case, Battleland for AlphaZero, and the personalities post for the layer that sits on top of all of them. Read any one of them and you get a game. Read the column of algorithms across all of them and you get the rule: there is no universal hidden-information AI, and the project is the proof.