itch.io

If you've been following the Veiled Dominion side of things, you might know about Duet — a small standalone browser demo (screen-reader-first, coordinate-notation) of the Rebirth/Death mechanic from the bigger 4-player variant. Standard 2-player chess, same board, same pieces — just the Queen and King are reskinned as Rebirth and Death.

A few people asked what it'd take to actually build this on a physical board, so here's the list:

1. A standard chess set — any 2-player set works. 8×8 board, 32 pieces, 16 per color. Nothing specialty needed.

2. Marking Rebirth & Death (optional): Since Rebirth = Queen and Death = King exactly, you don't have to change a thing. If you want the reskin visible at the table, a small charm, sticker, or paint mark on the 2 Queens (Rebirth) and 2 Kings (Death) does it — only 4 pieces total.

3. Veiled status tokens: Small translucent markers for anyone caught in the Radius of Ruin. Since the effect refreshes each turn rather than stacking, 6-8 tokens is plenty.

That's the whole build. No Boon Tokens, no Leadership Points, no Graveyard — those belong to the bigger 4-player game, not Duet.

Try the digital version first

Link: ibloud.itch.io/veiled-dominion-duet 

Hey everyone — 

Duet is a free, 2-player chess variant, playable entirely in-browser, built screen-reader-first from the ground up rather than as an accessibility add-on. Standard algebraic notation for moves (e2e4), a square-query command to hear what's on any square, and a procedural audio cue (real oscillator/gain synthesis, not AI-generated) that tells you how close a piece is to the game's signature "Radius of Ruin" mechanic without needing to see the board at all. 

Two new pieces beyond standard chess: Rebirth (queen movement, but anything that lingers near her gets Veiled — reduced to pawn-only movement) and Death (king movement, uncapturable, and a safe zone around him that blocks Rebirth's effect). 

No download, just a browser tab. 

Built for the Making Games Accessible jam 

— feedback from anyone playing it with an actual screen reader is genuinely wanted, not just welcomed.

The accessible path (typed notation + screen reader narration) isn't changing — that's the actual point of this build, and it already works the way established tools like Lichess's Blind Mode do. What I'm adding is a second, purely additive way in: click-to-select on the visual board for sighted players, plus a visible legend so the notation isn't a hidden secret. Neither of those touches or slows down the screen-reader path — they're just a faster on-ramp for people who don't need it.

## Duet build update: architecture alignment pass

Duet (the 2-player, screen-reader-first jam variant) is still its own standalone HTML/JS build — 

it doesn't share code with the main C#/.NET/Unity engine, and that's staying true. But I wanted its internal structure to at least follow the same *shape* as the real engine's documented architecture, so anyone moving between the two codebases later isn't relearning a totally different mental model.

**What changed:**

- Replaced the single flat move-handling function with the same Ordered Engine Sequence the main engine's ARCHITECTURE_OVERVIEW.md defines: PlayerIntent → OnValidateIntent → OnApplyMove   → OnResolveCapture → OnResolveSystems → OnCheckEndState → Snapshot → UI Refresh. Each stage is  its own function now, instead of one function doing everything at once.

- Added an actual Snapshot layer — the UI (board render, audio cue) now only ever reads from a cloned snapshot of state, never touches live game state directly. Matches the engine doc's "consumers should react to snapshots" rule.

- Named the Radius of Ruin / Veiled logic as explicit systems (RadiusOfRuinSystem, VeiledStateSystem) instead of inline loops.

**Bug fix this surfaced:** the original build only set a piece's Veiled status on *first* entry into the Radius of Ruin. If a piece was already Veiled and re-entered the aura, nothing happened 

— the timer just kept counting down on its original schedule. The engine doc is explicit that re-entry should *refresh* the duration, not get ignored or stack. Fixed to match spec, and checked it with a small headless test (tick down to 1 turn remaining, re-trigger, confirm it resets to full duration).

**What didn't change:** the rules, the board, the accessibility architecture (ARIA live regions driving your own screen reader), the audio cue, or the fact that this is plain HTML/JS/Web Audio 

— no build step, no engine dependency, no GenAI anywhere in it.

Same game. Cleaner internals, and one real correctness fix. Full build's up on the itch page now.

Greetings 

I am  working on an entry for this jam and would love some help from this community, since the whole point of the project is to actually get this right rather than guess at it.

What it is: Veiled Dominion: Duet is a scoped-down, 2-player variant of a larger 4-player chess-variant project. It's standard chess plus two extra mechanics:

• Radius of Ruin — one player's piece emits a danger zone; anything that ends its turn nearby gets temporarily weakened ("Veiled").
• Sanctuary — a second piece creates a safe zone nearby that cancels the danger effect.

Everything else from the bigger project (four players, hidden pieces/fog of war, card/dice layers) is deliberately cut for this entry — full information, one board, one ruleset, so it's actually finishable as a fully non-visual game within the jam window rather than a tech demo of one cue.

What I'm looking to build for accessibility, specifically:

• Move input via typed/spoken algebraic notation, plus a "query square" command to read back board state on demand — no pointing or dragging required.
• Turn changes, checks, and captures announced via TTS.
• The Radius of Ruin communicated through a continuous proximity-to-pitch/volume audio mapping (not a static beep) — soft attack/decay, no sudden startling spikes.
• Sanctuary represented as ambient sound dampening near the safe piece, on its own independent volume channel from music/SFX.

What I'm looking for:

1. Blind or low-vision playtesters — willing to play a rough build partway through the jam and tell me honestly where the audio cues are unclear, annoying, too subtle, too startling, or just don't map the way you'd expect. Early feedback (not just at the end) is what actually shapes this, so even a short session mid-jam is genuinely useful.
2. Anyone who's built accessible chess/board-game input before — if you've solved move-input-via-notation or screen-reader board narration and have advice, patterns, or pitfalls to share, I'd rather learn from you than reinvent it badly.
3. Feedback on the audio design itself — even without playing, if you have thoughts on proximity-mapping conventions (pitch vs. volume vs. panning, what's felt too subtle or too sharp in other games) I'd love to hear it.