One browser-first home for quick play, deeper study, and durable sessions.
Cardthropic brings Chess (Classic, Chess960, Atomic, King of the Hill, Anti-Chess, Pressurescope), Solitaire (Klondike, Yukon, Freecell, Scorpion, Pyramid, Forty Thieves, Spider), Theorisation (Deduction, Triclidean), Checkers (8x8, 10x10), Go (9x9, 13x13, 19x19), and Reversi (6x6, 8x8, 10x10, 12x12, 14x14, Anti-Reversi) into one fast browser app with replayable starts, shared session memory, controller support, and deeper tools like Branching Move History with move notes, PGN workflows, Web Analysis, Move Palette, and solitaire winnability helpers where they fit.
Cardthropic is built to be welcoming on first launch and useful over time. You can begin in seconds on nearly any device with a web browser, keep your place across game families, and gradually discover deeper tools instead of being asked to learn everything up front.
The point is not just speed. The point is being easy to enter without becoming shallow after the first few minutes, and easy to return to later through shared session continuity, replayable starts, and installable progressive web app support with offline use in mind.
Games, analysis, and session data run locally on your device, not on a remote server.
When you do want continuity beyond one browser profile, Cardthropic also supports deliberate clipboard-based transfer paths instead of requiring an account-backed sync layer, including Copy/Paste All Cardthropic Settings for carrying your setup on purpose.
Cardthropic does its work on your own device, inside your browser. Your device runs the game and analysis directly, instead of waiting on a remote server.
8x8 and 10x10 rulesets with mandatory captures, continuation, and exact session restore
The goal is not to be a pile of unrelated browser toys. Cardthropic is meant to feel like one home for several different kinds of games and longer-lived sessions.
Cardthropic is built around a fairly strict technical philosophy, not just a content bundle. Each game is meant to have one canonical rules source, one shared session meaning, and one honest execution path, even when that same game later appears through dialogs, command surfaces, automation, web delivery, or accessibility layers.
Cardthropic is designed headlessly where possible: the core game truth is meant to exist independently of any one visual shell, so different interfaces can expose the same system without redefining it. That is why the engine and the interface are intentionally separated. Pure gameplay state, legality, scoring, and deterministic move application live in engine-side owners. Shared app-state orchestration, keyboard semantics, and persistence live in a separate layer. Rendering, dialogs, async UI helpers, Home, and the command palette sit above that instead of redefining the rules locally.
In practice, this is why Cardthropic leans so hard on exact restore, replayable starts, shared session continuity, and command-driven surfaces. Those are consequences of the architecture, not separate add-ons. The goal is not just to accumulate more modes. The goal is to keep adding capability without losing coherence, so the product can grow in depth while still behaving like one system.
In supported games, Cardthropic can keep alternate lines in a dedicated Branching Move History instead of asking you to choose one line and lose the rest. That makes it easier to study a fork in the game, come back to an earlier idea, and keep the comparison readable.
Cardthropic is meant to be usable as a local study surface, not only as a launch-and-forget board. The app includes inspection windows, repair tools, and file workflows that stay inside the same product shell instead of forcing a handoff to a separate desktop lab.
The point is not file support in name only. Large PGN imports are meant to stay locally searchable and browsable in the browser, and SGF-oriented Go workflows are meant to stay faithful to Go's own review culture instead of being forced through chess-shaped tooling.
Chess in Cardthropic is meant to cover ordinary play, local engine-backed inspection, and file-driven study in one place. The built-in engine, Cardthropic Chess Engine Micro (CCEm), is there for fast local evaluation and automation, not as a claim of final chess truth.
CCEm, plus Computer Player sparring in supported competitive sessionsOne of Cardthropic's signature board-play features is Destination Move. In Chess and Checkers, you can often play by touching the square you want to arrive on instead of touching the moving piece first.
The board can show a # movers overlay on legal destination squares. That tells you how many pieces can reach each square right now, so the destination itself becomes the first thing you can inspect and choose.
If exactly one piece can reach that square, the move can resolve immediately. If more than one piece can reach it, Cardthropic opens a destination-candidates popover that lists the available source pieces for that destination. You choose from the candidates there instead of backing up and hunting across the board for the original piece.
# movers overlay to see how many current legal arrivals each square hasThe practical effect is simple: in many Chess and Checkers situations, you no longer need to touch the moving piece directly at all. You pick where you want to land, and Cardthropic helps resolve the rest from there.
Cardthropic does not center remote play around accounts, matchmaking, or a hosted relay. In supported families, Clipboard Remote Play lets two copies of Cardthropic hand turns back and forth through the clipboard.
The practical flow is simple: open another Cardthropic instance if you want, match the same seed or position, turn sync on, read the incoming turn from the clipboard, and let your next move auto-copy the reply. If browser clipboard permissions get in the way, manual paste still works.
CTGN turn text locally instead of depending on a server-owned move formatWhen Cardthropic's local engines and helper tools are enough, you can stay inside the app. When you want a stronger or simply different second opinion, supported modes can build a compact prompt from the current position, move history, and runtime state and send it outward deliberately.
Cardthropic has assist tools, but it tries to name them clearly instead of hiding everything behind one vague AI button. The difference between a nudge, a sparring partner, and full automation is real, so the commands stay separate.
Blind Access Mode is an in-product spoken control and review layer for blind users. It currently supports Checkers, classic Chess, and early Solitaire slices in Klondike and Yukon inside Cardthropic itself. Checkers is still the fuller current path, while classic Chess, Klondike, and Yukon are narrower but real slices.
This is not meant as a decorative accessibility checkbox. Blind Access Mode is one of the clearest long-term reasons Cardthropic exists. The project is trying to build a truthful spoken path inside the same app rather than assuming a separate accessibility stack will always reconstruct board meaning correctly after the visual layer is already finished.
The current supported path centers on playable board flow rather than full-site parity. In Checkers and classic Chess that means orientation and current-state summaries, legal move discovery and move activation, and repeated focus, latest-change, and recent-history review. In Klondike and Yukon it means overview, legal-action discovery, move-list-first activation, latest-change replay, recent-history review, and section-by-section full-state readouts.
Blind Access Mode also includes a spoken current-rules reader across manual-backed game pages, and supported BAM slices can step through full game state section by section without depending on a visual board scan.
On supported web browsers, Blind Access Mode uses browser speech APIs and the operating system's built-in voices rather than depending on traditional screen reader integration. That gives Cardthropic one end-to-end spoken workflow that behaves consistently across its supported platforms. Because those voices come from the browser and operating system, Blind Access Mode can also work offline when Cardthropic is installed as a progressive web app and required browser voice support is present. Some browser and operating system combinations do not currently provide the voice support it needs, so availability is not identical everywhere.
Part of the motive is also straightforward future-proofing: building a durable blind-access path inside Cardthropic itself instead of hoping accessibility can always be outsourced later. That is why the work is being done as a real product system with shared commands, shared narration rules, repeatable phase trackers, and honest fail-closed boundaries when a game or surface is not ready yet.
Solitaire here is not just one disposable deal after another. You can replay the same setup, restart fast, keep longer runs in the shared library, and use the same calm shell across seven distinct solitaire variants.
Theorisation brings a seeded hazard-grid deduction puzzle into the same product shell as the rest of Cardthropic. You can restart the same board, return to unfinished runs later, and keep the same calm session flow whether you want a quick puzzle or a longer deduction session.
Checkers in Cardthropic is built around exact engine-backed play instead of a simplified board toy.
Multiple 8x8 and 10x10 rulesets live in the same family, with mandatory captures, continuation, crowning behavior, undo/redo, and save/restore staying consistent across the whole app.
8x8 and 10x10 rulesets in one shared product shellOne of the best parts of Cardthropic is that it is built to be returned to. Your active sessions, paused games, and finished runs can all live together in one place.
Cardthropic also spends real effort on the less glamorous parts of a repeat-use app: how it feels to live with over time, how easy it is to open a second window, and how readable or calm the surface stays during longer sessions. That is partly a matter of engineering, but it is also a matter of taste.
Cardthropic is local-first in the technical sense, but also in the product sense. It prefers exact restore, deliberate export, clipboard-based transfer, and readable file exchange over trapping play history or study work inside an account silo. The app is trying to keep your game state legible and movable on purpose, not merely convenient while you stay inside one hosted session.
It is also a project about recursion and reuse. The shared shell is not there just to look tidy. The goal is to make one truthful system that can keep extending across more games, more study tools, and more accessibility surfaces without having to reinvent its own meaning each time. That is why Cardthropic keeps leaning on one canonical rules source, deterministic replay, headless-capable game truth, and shared command surfaces.
Design judgment matters here too. Birthstone themes, calmer shells, explicit tool naming, and the refusal to fake parity across every mode are all part of the same taste decision: Cardthropic would rather be specific and honest than broad and blurry.
Even the name carries that attitude. Cardthropic is close enough to cardiotropic to catch the joke, and the Ace-of-Hearts logo leans into that with an anatomical heart. It turns an easy search collision into part of the identity instead of treating it as branding noise. That is a small example of the broader pattern: Cardthropic tries to turn constraints, collisions, and edge cases into structure rather than pretending they are not there.
Cardthropic is a local-first browser game and study app that combines multiple game families, reproducible seeds, exact restore, and shared continuity tools in one place. Rather than treating sessions as disposable, it is designed to support both quick play and longer study in the same product.
The current families include Chess, Solitaire, Theorisation, Checkers, Go, and Reversi. Inside those families there are multiple modes and variants, including solitaire variants such as Klondike, Yukon, Scorpion, Pyramid, Spider, Forty Thieves, and FreeCell, plus Theorisation branches such as Deduction and the Triclidean modes.
Cardthropic was created by Emily Tiffany Joy. It is a single-author project with a very specific product identity, which is part of why the app tries to keep one coherent language across very different game families instead of feeling like a bundle of unrelated tools.
It is currently funded through optional donations. The app is free to use, with no account wall, no subscription gate, and no “premium analysis” split between basic and paid users at this stage.
The long-term direction is not just “more games.” It is a stronger local-first product shell: deeper shared continuity, better study tools, more polished families, and more thoughtful game-specific systems that still feel like one home instead of a pile of separate apps.
The project is built in Rust, with egui as the UI framework, glow-backed rendering in the graphics stack, and WebAssembly for the web build. That combination is what lets the same core product run as a full-featured browser app instead of a traditional server-rendered website.
The important work runs on your device. The browser loads the app, but gameplay, analysis, and normal session logic execute locally rather than waiting on a remote server to drive every move or computation. That is a major reason the app feels direct once it is loaded.
Yes. On supported browsers, Cardthropic can be installed as a progressive web app, which gives it a more app-like return path while still keeping the same browser-based foundation underneath.
It is designed to be offline-friendly once the app is already available on your device, especially through the installable progressive web app path. Normal local gameplay and session work fit that model well, while first loads, updates, and outward-facing actions such as external analysis naturally depend more on connectivity.
Yes, as long as the device has a capable enough browser. Cardthropic is meant to be useful across touch-first devices, keyboard-and-mouse setups, controller-friendly setups, and large-screen browser surfaces rather than assuming one ideal input style.
Yes. Controller support is a real part of the product, not an afterthought, which is one reason the app works unusually well on TVs, couch setups, and other browser-ready devices where a gamepad is more natural than a mouse or touch-only workflow.
Yes, if the TV has a reasonably recent smart-TV browser. Controller and remote-friendly workflows are part of the design, but older or weaker TV browsers are often the least forgiving environment, so the best results come from more recent smart-TV browsers or connected devices with stronger browsers.
A recent browser is the main requirement. Modern desktop and mobile browsers generally do best, recent smart-TV browsers can work well, and older embedded browsers are the most likely place to see rough edges first because they tend to lag on browser features and performance. Cardthropic also expects WebGL-compatible graphics acceleration; there is no non-WebGL fallback for the main app.
It does not require an account. You can use it without signing up, which fits the project’s local-first design and its preference for quick entry over building a hosted identity system around the whole experience.
Normal session continuity is stored locally in your browser or installed app context rather than being centered on a server-side account. In practice, that means your sessions and preferences usually travel with the browser profile or installed instance you actually used.
No account is required, and Cardthropic is not built around cloud sync. Progress and continuity are usually stored locally on the device or browser profile you used, unless you deliberately move game data through one of the supported export or sharing paths. Full preference carryover can also be handled intentionally through clipboard-based Copy/Paste All Cardthropic Settings.
Not as the default workflow. Core gameplay and study are local. Data leaves your device only when you deliberately use an outward-facing path such as external analysis or another sharing mechanism that is explicitly meant to send something somewhere else.
If the same browser profile or installed app context is still there when you return, Cardthropic is designed to restore meaningful in-progress state instead of treating your session like a disposable tab. Exact behavior varies by family, but continuity is a core product goal rather than an afterthought.
Family-specific file workflows are meant to stay local-first too. When you load or work with local game files, the design goal is to let you inspect, replay, and study them in the browser without automatically turning that into a server upload workflow. The exact file tools vary by family.
Cardthropic uses its own engines, rules logic, and local automation systems. The built-in analysis layer is part of the same project rather than a thin wrapper around a stack of bundled outside engines.
No. Cardthropic’s built-in analysis and automation are native to the project. When stronger outside analysis is useful, some modes can open Web Analysis in a new tab instead of bundling heavyweight third-party engines directly into Cardthropic.
Cardthropic’s built-in analysis is designed for readable local study, not for competing with top standalone engine stacks. Its engines are aimed more at practical, intermediate-strength, human-like study inside a browser-based local app than at maximum engine strength.
It means Go records, review, and branching study are handled in a way that fits SGF-style game trees instead of flattening everything into a chess-style move list. In practice, that means Go study flows are meant to respect SGF-style review, move trees, and board analysis rather than treating every game like PGN.
Many families already support repeatable study sessions through seeds, history, exact restore, replay, and family-specific file or library tools. More structured challenge systems and authored study surfaces exist in some parts of the app and are still growing in others, so the answer is increasingly yes, though not yet as one uniform feature across every family.
It is built to support both without forcing you to pick one identity for the whole app. You can open a game quickly, keep the session simple, and leave, or you can stay with the same run and use seeds, restore, history, replay, and deeper tools to turn it into a longer study loop.
A seed is the reproducibility handle for a run. In supported families it recreates the same opening state, and in some modes it also governs future randomness such as refill or deal order, which makes retries and comparisons meaningful instead of turning every restart into a different problem.
It means returning to the real in-progress state you left, not merely reopening the same family or mode. The current position, relevant setup choices, and family-specific runtime context are restored so the resumed session still means the same thing.
No, and that is intentional. Cardthropic tries to keep unsupported tools visibly unavailable instead of faking parity. Some families already support deeper shared surfaces such as Robot, Move Palette, import/export, or analysis bridges, while newer families are narrower until those surfaces are genuinely ready.
Cardthropic can remember active sessions, finished runs, recent work, local preferences, and some game-family-specific progress such as locally cleared starter challenges. Because the app is local-first, that continuity usually lives with the browser profile or installed app instance you actually used.
They are related but not interchangeable. Magic Wand is a one-step assist, Robot is continuous automation, and Computer Player is a side assignment in supported competitive games where the computer takes White, Black, or neither as an ongoing role.
Yes. That is one of the clearest Cardthropic patterns across families. Seeds, undo/redo, restart, history, and exact restore make it practical to retry the same situation and see how different early choices change the branch instead of forcing you to accept one line and lose the rest. In supported games, Branching Move History goes further by preserving alternate lines directly and letting you attach short move notes to the exact moves you want to remember.
In many parts of the app, yes, but the exact path depends on the family. Some modes expose PGN-style import, Copy/Paste Game, Clipboard Remote Play, Web Analysis, or other game-specific export flows, while newer families may intentionally defer those surfaces until they are truly supported. Clipboard Remote Play is the lightweight option when you want two copies of Cardthropic to hand turns back and forth through the clipboard without a dedicated network service.
It is generally approachable on modern devices, but the app still depends on your device because the work is local. Lighter play surfaces are easy to run almost anywhere with a decent browser, while heavier local analysis and larger browser sessions naturally ask more from weaker devices or older TV browsers.
The browser is a great portability layer, but it still imposes limits around performance ceilings, storage behavior, file APIs, and the uneven quality of embedded browsers on some devices. Cardthropic leans into the strengths of the browser while accepting that a local browser app is not the same thing as a heavyweight native desktop engine lab.
No full network-play layer is planned. Cardthropic already has Clipboard Remote Play for lightweight clipboard handoff between two copies of the app, and that fits the project much better than taking on a full online networking stack, which would add a great deal of complexity without matching the current roadmap.
Cardthropic is for people who want a game app they can open quickly, enjoy immediately, and return to later without starting over.