Ideas
Backlog of features and ideas being considered. These may shape how the app functions in future versions.
This page is a backlog of features and ideas under consideration for True Count. Nothing here is confirmed or scheduled, but some of these ideas would have significant implications on how the app works, from gameplay mechanics to underlying architecture. Think of this as working notes that inform future direction.
Some ideas come from reader feedback, others from internal brainstorming. Have a suggestion? Leave a comment at the bottom of any docs page.
Backlog
Level-Based Counting Systems
True Count currently uses the Hi-Lo system exclusively. One idea is to introduce multiple counting systems that unlock as players progress:
| System | Level | Description |
|---|---|---|
| Hi-Lo | Default | The current system. Balanced, requires true count conversion, clean edge modeling. |
| KO (Knock-Out) | Beginner | Unbalanced system that eliminates true count conversion. Simpler for newer players. |
| Omega II | Pro Unlock | Multi-level count (+1, +2, -1, -2) with higher accuracy. Rewards advanced players. |
This would create a natural progression path: onboarding simplicity for new players, depth for serious users, and meaningful leaderboard segmentation by counting system.
Source
Suggested by a reader on the Count Peek page.
Local Multiplayer
If two players are nearby and both have True Count installed, they could join the same table and play together against a shared dealer. Each player would pick their own seat, but the shoe, deck state, and dealer would be synchronized across both devices.
Key considerations:
- Dealer selection: Players agree on a dealer before the session starts (or the host picks one).
- Shared shoe: Both players draw from the same shoe, so card counting stays consistent and meaningful.
- Proximity: Requires some form of local discovery (Bluetooth, local network, or similar) to pair nearby players.
- Turn flow: Decide whether players act simultaneously or in seat order, and how that affects pacing.
This could change how the app handles game state, since it currently assumes a single player. Multiplayer would require real-time state synchronization and conflict handling for actions like hitting or standing at the same time.
Remote Configuration Dashboard
A dedicated dashboard for editing game mechanics variables dynamically, without requiring code changes or app updates. Table parameters (minimum bets, deck counts, shoe penetration, house edge), gameplay settings (starting bankroll, chip multipliers, split rules), and feature flags (Count Peek, Daily Challenge, Auto-Deal) could all be adjustable through a visual interface instead of editing JSON files and redeploying.
Key considerations:
- Live preview: See how parameter changes affect house edge calculations before pushing them live.
- Role-based access: Separate read-only and edit permissions so collaborators can review without accidentally changing config.
- Audit trail: Track who changed what and when, with the ability to roll back to a previous configuration.
- Per-table overrides: Edit parameters for a single dealer table without touching the others.
Currently, all configuration lives in a JSON file deployed with the docs site. A dashboard would make this workflow faster and less error-prone, especially for non-technical team members.
Double After Split Behavior
Double After Split is currently allowed at Jean-Luc, Czarita, and Jack's tables, and disabled at Lady Lux and Aunty. Reader feedback and a survey of other blackjack apps suggest the implementation may need closer examination. Some apps restrict doubling to only the first hand after a split, not all subsequent hands. Others apply different double restrictions per split hand depending on the resulting total.
Key considerations:
- First-hand-only restriction: Some apps allow doubling only on Hand 1 after a split, treating subsequent hands as hit-only. This simplifies the UX but diverges from standard casino rules where all split hands are eligible.
- Per-hand rule evaluation: Each split hand could independently check the active double restriction (any two cards, 9-11, or 10-11) based on its own total. This matches how physical casinos handle it.
- Split aces exception: Split aces already auto-stand after one card with no double allowed. Any DAS refinement should preserve this existing behavior.
- Table-level granularity: The current per-table toggle (allowed vs. not allowed) could be expanded with a third option for partial DAS (first hand only), adding another lever for difficulty progression across dealer tables.
- UX clarity: If DAS rules vary per hand within a single split round, the action buttons and Auto Hint need to reflect this clearly so the player is never confused about why Double is available for one hand but not another.
Source
Raised by a reader on the Hand Actions page (#53).
How is this guide?