DEV Community: Maliik Bryan

Turing Tables: a deckbuilder where the opponent might actually be thinking

Maliik Bryan — Mon, 22 Jun 2026 05:23:35 +0000

The longest day. Hold the light until dawn.

What I Built

Turing Tables is a roguelite deckbuilder with one twist: the opponent is Gemini.

You descend a ladder of machines on the solstice, the longest day of the year, the one day a machine's mind runs thin enough to be fooled, racing to reach the Mainframe before the dark returns. Each machine plays cards against you in a tight, Slay-the-Spire-style combat loop. But here is the catch, and the whole point of the game: on any given turn, the machine's move is either a real decision made by a live Gemini model, or a cheap scripted imitation. Roughly 70 percent real, 30 percent fake, mixed in unpredictably.

So your job is not only to win the fight. It is to play the interrogator. A button labelled Call Imitation lets you bet that the move you just watched was a fake, a script wearing the machine's face. Read it right and you are rewarded with energy. Read it wrong, because the script fooled you, or because the real Gemini move looked too dumb to possibly be real, and you pay bleed.

And the deception runs both ways. Every move is telegraphed a turn ahead, but a live Gemini machine can feint: show you one intent and then play another. The scripted imitation never bluffs, so a feint is itself proof you are up against the real thing, a mind reasoning about how to mislead you. You are hunting the machine's fakes while it quietly feeds you its own. The smarter machines feint more often, and only a Sever, a card that cuts a machine's link to the grid, forces the truth out of them.

That is the imitation game, turned into a card game.

Video Demo

Play it yourself in the browser, no install: https://maliik-b.github.io/turing-tables/

Two ways to play:

No key. Every machine runs the scripted brain. You get the full game, the full ladder, and a real fight. The "Call Imitation" reads are easier, because everything is the imitation.
With a key. Paste a free Google AI Studio key on the title screen and the machines wake up. From DAEMON-1 onward, most of their moves are real Gemini, and the reads get genuinely hard. Your key lives only in your browser's localStorage and is sent to Google and nowhere else. There is no backend, no proxy, no server logging your key. It is your key, your quota, your machine to interrogate.

Code

Maliik-B / turing-tables

A deckbuilder whose opponent is a machine - can you tell when it's really thinking? dev.to June Solstice Game Jam entry.

Turing Tables

A small web deckbuilder where your opponent is a machine — and the question is whether you can tell when it is really thinking.

Built for the dev.to June Solstice Game Jam as an ode to Alan Turing (his June birthday and the imitation game inspired it). The Machine's moves are decided by a real LLM (Google Gemini) most of the time and by a scripted "imitation" the rest — and you score by catching the imitation.

Play

Run locally:

npm install
npm run dev

Open the printed localhost URL. The game is fully playable with no API key — the Machine runs its scripted brain. To face the real Gemini opponent, paste a free Google AI Studio API key into the in-game field; it is stored only in your browser's localStorage and used solely to decide the opponent's moves.

Mechanics

Deckbuilder combat — energy, attacks, block…

View on GitHub

How it plays

You start with 50 hull, 3 energy a turn, and a small deck. Standard deckbuilder verbs: strike, block, apply Vulnerable and Weak, lifesteal, corruption that ticks over time, and a Sever that cuts a machine's link and forces it back to its scripted reflexes for a couple of turns. The machines hit back with their own intents, telegraphed one turn ahead (though a thinking machine may feint, telegraphing a move it never
means to make), and they escalate as you climb:

ELIZA-0 is generation zero. No AI at all, a rule-based automaton that opens every fight the same way and cannot feint, because there is nothing in there to feint with.(More on why this one matters below.)
DAEMON-1 is the first machine that wakes up: Gemini 2.5 Flash-Lite, reading your board, not your cards yet. It softens you with Weak, then shields so your blunted hits glance off..
ORACLE-2 is Gemini 2.5 Flash. It counts the cards it has watched you play, sets up Expose-then-strike, and starts to lie, feinting its telegraph.
THE MAINFRAME is the boss: Gemini 3 Flash. It knows your entire deck from turn one, remembers how you played in earlier runs, exposes you and then drains to heal it self, resists your corruption, and feints often. A telegraph you trust is a telegraph it wants you to trust.

The further you descend, the warmer and higher the dawn climbs behind the fight. Reach the Mainframe and beat it, and the screen breaks into sunrise. Lose, and the long dark takes you.

How I used Gemini (Best Google AI Usage)

This was the design rule I set for myself: the AI is not a chatbot bolted onto a menu. The AI is the opponent, and the uncertainty about whether it really is the AI is the mechanic.

Here is what actually happens on a machine's turn:

The game assembles a structured context for that enemy: its own abilities and remaining hull, your live board (hull, block, Vulnerable, Weak, Overdrive), and, for the higher tiers, what it knows of your deck. The Mainframe also gets a memory dossier built from your prior trials.
That context goes to a real Gemini model with a system prompt that frames it as a specific machine with a specific personality and job: pick the move that beats this board, and say one line in character.
Gemini returns a structured move (which action, how big, plus a line of dialogue) and a possible feint. The same reducer resolves it whether it came from the model or the script.

The ladder maps onto a real escalation of Gemini models, each step up in capability and in how much it knows about you:

DAEMON-1 → Gemini 2.5 Flash-Lite. Cheapest, fastest, just awake. Reads your board, not your cards, and telegraphs honestly.
ORACLE-2 → Gemini 2.5 Flash. Sharper. Counts the cards it has seen you play this fight, runs Expose-then-strike, and begins to feint.
THE MAINFRAME → Gemini 3 Flash. The boss gets the newest model, the most context, and the longest leash: its prompt carries your entire deck list from turn one plus a dossier of how you played earlier trials, so it anticipates and punishes your habits.

I chose fast models on purpose. The whole ladder runs on a free-tier key, so the climb is capability and knowledge, not a heavyweight model the free quota can't sustain. A fight makes several calls, so I tuned the call frequency, the per-model timeouts (a few seconds for the fast tiers, longer for the boss's heavier prompt), and the model choices so a judge can finish the entire run on their own free key. I would rather you reach dawn than gate the good part behind a paywall.

Two design decisions I am proud of:

The fallback is a feature. Every call has a per-model timeout and falls back to the scripted brain on any failure: no key, a rate limit, a network blip. That fallback is not just resilience, it is the 30 percent imitation. The same safety net that keeps the game playable for someone with no key is the thing you are trying to detect when you Call Imitation. The architecture and the theme are the same object.

Nothing cheap gives the test away. A naive version would let you cheat the read: spot the AI by its smarter dialogue, by which fancy combos only it can pull, or by how long it pauses. So the scripted brain runs the same setup-and-payoff combos the models do, a third of the real Gemini turns deliberately speak the scripted brain's flat canned line, and every tier's scripted turns are paced to match that model's real latency. The only honest signals left are behavioral: does this move actually answer
the board in front of it, and did the machine just lie to you with a feint? Only a thinking machine does either.

An ode to Alan Turing (Best Ode to Alan Turing)

The imitation game is not the theme of this game. It is the loop.

Turing's 1950 question was never "can a machine think." It was "can you tell." Turing Tables makes you sit in the interrogator's chair and answer that question, move after move, with something on the line. Every "Call Imitation" is the interrogator's verdict.

The references are deliberate, not decoration:

ELIZA-0 is generation zero on purpose. It is a nod to Joseph Weizenbaum's 1966 ELIZA, the program that imitated understanding with pure pattern matching and unsettled people anyway. It is the perfect thing to open on: imitation with provably nothing behind it. If you cannot beat the machine that is definitely not thinking, you have no business interrogating the ones that might be.
ORACLE-2 is named for Turing's oracle machine, the 1939 thought experiment about a device that can answer questions a normal computation cannot.
The inversion is the part I care about most. While you interrogate the machine, the Mainframe interrogates you. It keeps a dossier on how you play, carries it between runs, and uses it. Observer and observed, which is the genuinely uncomfortable centre of the test. The machine passes by reading you better than you read it.

And the solstice frame: the longest day, its light failing as the machines wake, a glow you are trying to hold until dawn. Turing's own story ended in the dark. Here, dawn is the thing you are fighting for. I will leave it at that.

How I built it

React 19+ TypeScript + Vite, Tailwind v4, Motion for animation.
Fully static. No backend, deploys straight to GitHub Pages. The only network call the game ever makes is the player's own browser talking to Google. A Content-Security-Policy restricts the page's connections to the app's own origin and that single Google endpoint, so the key has nowhere else to go.
A reducer-based engine. All combat is pure state transitions, which made the AI integration clean: the brain just returns an intent, and the same reducer resolves it whether it came from Gemini or the script.
Every visual is CSS or SVG, zero raster assets. A geometric solstice sun with rotating rays, escalating machine sigils (ELIZA is a bare hollow ring, the Mainframe a dense radiating core), a ruined-grid horizon under a fading star field, and a "dawn as an arc" background that warms and rises from indigo night to gold as you close on the Mainframe.
The sound is generated too, no audio files. A small Web Audio engine: a low ambient drone whose pitch and brightness rise with the run (the audio twin of that dawn arc), plus synthesized one-shots for card play, hits, the Call Imitation scan, the right and wrong verdicts, and the sunrise swell on a win. The visuals are generated geometry, the audio is generated tones, and the opponent is a generated mind. The whole thing ships with zero asset files.

What I would do next

More machines, each with a distinct play personality and tell. A proper interrogation log that scores your reads over a run. And a harder Mainframe that uses its dossier more cruelly, because the scariest version of this game is the one where the machine is clearly, demonstrably reading you, and you have to play against your own habits to win.

Prize Category

Submitting for Best Google AI Usage and Best Ode to Alan Turing.

The first because the model is the opponent, the doubt about it is the mechanic, and the whole design works to keep that doubt honest: the model picks real moves against your real board, it can lie to you with a feint, and nothing but its actual reasoning is allowed to give it away. The second because the imitation game is the loop, ELIZA and the Oracle are in the cast, and the machine is taking notes on you the whole time.

Thanks for reading, and thanks for the jam. Go hold the light.

Play: https://maliik-b.github.io/turing-tables/ · Code: https://github.com/Maliik-B/turing-tables

PostgREST can't upsert against partial unique indexes

Maliik Bryan — Mon, 15 Jun 2026 15:00:47 +0000

The bug

I split a 3-column unique constraint into two partial unique indexes to support a new nullable column. The next day, every .upsert() against that table started failing with:

there is no unique or exclusion constraint matching the ON CONFLICT specification

The upsert call hadn't changed. The data shape was identical. The error message was technically correct and completely useless: the constraint did exist, it was just partial.

This post is the unblock for anyone hitting that error on a Supabase table that uses partial unique indexes.

The schema change

The original table had a flat 3-column unique constraint:

CREATE TABLE profile_subscriptions (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  profile_id UUID NOT NULL REFERENCES profiles(id) ON DELETE CASCADE,
  category_type TEXT NOT NULL,
  subcategory TEXT NOT NULL,
  enabled BOOLEAN DEFAULT TRUE,
  ...
  UNIQUE(profile_id, category_type, subcategory)
);

I added a nullable source_agency column. The intent: NULL means "this subscription applies to all agencies" (a default mode), and a non-NULL value means "this subscription is scoped to a specific agency."

Uniqueness now had two cases:

For NULL-agency rows, unique on (profile_id, category_type, subcategory).
For non-NULL-agency rows, unique on (profile_id, category_type, subcategory, source_agency).

A naive 4-column unique constraint doesn't work because PostgreSQL treats NULLs as "always distinct" by default. You'd get unlimited duplicate (profile, category, subcategory, NULL) rows.

The right tool is two partial unique indexes:

CREATE UNIQUE INDEX idx_profile_subs_null_agency
  ON profile_subscriptions (profile_id, category_type, subcategory)
  WHERE source_agency IS NULL;

CREATE UNIQUE INDEX idx_profile_subs_with_agency
  ON profile_subscriptions (profile_id, category_type, subcategory, source_agency)
  WHERE source_agency IS NOT NULL;

This works at the database level. Both indexes enforce the right uniqueness. Direct SQL INSERT and UPDATE against the table behave correctly. The migration ran clean. Tests passed. Everything looked fine.

Why PostgREST breaks

The Supabase JS client builds upsert requests like this:

supabase
  .from('profile_subscriptions')
  .upsert(rows, {
    onConflict: 'profile_id,category_type,subcategory,source_agency'
  })

PostgREST translates that into roughly:

INSERT INTO profile_subscriptions (...) VALUES (...)
ON CONFLICT (profile_id, category_type, subcategory, source_agency)
DO UPDATE SET ...

This SQL is syntactically valid. It still fails. PostgreSQL's ON CONFLICT requires the inference column list to match an existing unique constraint or unique index exactly, including any WHERE predicate.

Your unique index has WHERE source_agency IS NOT NULL. The upsert's ON CONFLICT (...) doesn't include the predicate. PostgreSQL can't find a matching constraint. You get:

there is no unique or exclusion constraint matching the ON CONFLICT specification

PostgREST won't generate ON CONFLICT (cols) WHERE source_agency IS NOT NULL from the client API. There's no way to express the predicate through upsert's onConflict option.

The obvious workaround, "just put a COALESCE(source_agency, '') in the index and make it non-partial," also doesn't work. PostgREST can't upsert against expression-based indexes either, for the same root reason.

The fix: delete-matching + insert

Rather than fight ON CONFLICT, I dropped down to two operations: delete the matching row(s) by exact predicate, then insert the new state. From apps/api/src/routes/subscriptions.ts:248:

// PostgREST cannot upsert against partial unique indexes (no WHERE clause
// support in ON CONFLICT). Use delete-matching + insert instead.
const nullAgencySubs = subscriptions.filter((s) => !s.source_agency);
const agencySubs = subscriptions.filter((s) => s.source_agency);

const allResults: ProfileSubscription[] = [];

if (nullAgencySubs.length > 0) {
  // Delete existing matching rows first
  await Promise.all(
    nullAgencySubs.map((sub) =>
      supabaseAdmin
        .from('profile_subscriptions')
        .delete()
        .eq('profile_id', profileId)
        .eq('category_type', sub.category_type)
        .eq('subcategory', sub.subcategory)
        .is('source_agency', null),
    ),
  );

  const rows = nullAgencySubs.map((sub) => ({
    profile_id: profileId,
    category_type: sub.category_type,
    subcategory: sub.subcategory,
    enabled: sub.enabled,
    inferred: sub.inferred,
    source_agency: null,
    updated_at: now,
  }));

  const { data, error } = await supabaseAdmin
    .from('profile_subscriptions')
    .insert(rows)
    .select();

  if (error) { /* handle error */ }
  allResults.push(...((data || []) as ProfileSubscription[]));
}

// agency-set bucket follows the same pattern with
// .eq('source_agency', sub.source_agency!) instead of .is('source_agency', null)

The pattern in three steps:

Split the input rows by whether the partial-index predicate applies (null-agency vs agency-set).
For each bucket, delete the matching existing rows. Use .is('source_agency', null) for the null bucket, because .eq() will never match NULL in PostgREST.
Insert the new rows in one batch per bucket.

This avoids ON CONFLICT entirely. The trade-offs:

You're doing roughly 2N round trips instead of N. For a small batch (these payloads are usually under 30 rows) it's fine. For high-volume writes, move it into a PL/pgSQL function and call it through Supabase RPC.
The window between DELETE and INSERT is not transactionally protected at the client level. If your write pattern allows two clients to race on the same (profile_id, category_type, subcategory), wrap the whole thing in a Supabase RPC and let Postgres serialize.

For our use case the writes happen during a quiz wizard flow where the user is the only writer on their own subscription rows. The race window is negligible.

The deeper trap

ORM abstractions over Postgres leak whenever your schema uses anything beyond column-level constraints. Partial unique indexes are common in production schemas. Anywhere you have NULL-with-meaning, the natural answer is a partial unique index:

Soft-deleted rows where the unique constraint should only apply to live rows
Multi-tenant uniqueness where tenant_id is nullable for global rows
Draft-vs-published states where the slug is unique only among published rows
Versioned rows where the index applies only to the latest version

The moment you reach for one, you lose:

.upsert() against the index via PostgREST or any client that wraps it
Any framework that emits INSERT ... ON CONFLICT (cols) without a predicate (most of them)
Codegen tools that scan the schema for unique constraints. Partial indexes often get treated as not-a-constraint from the codegen's perspective.

The fix is rarely interesting. The trap is that the failure mode is silent in the most damaging way: the test suite passes, the local SQL queries work, the migration runs clean. The bug only fires on the first real client call, and the error message points at the constraint as if it were missing, not partial.

If you've added a nullable column with meaningful semantics and the upserts go quiet, check whether you migrated the unique constraint into a partial index. Then pick one:

Drop down to delete + insert, like above
Move the operation into a PL/pgSQL function and call it via Supabase RPC
Petition PostgREST to support ON CONFLICT ... WHERE. It's a known gap: PostgREST/postgrest#2123 tracks index-predicate and exclusion-constraint upserts in core, and postgrest-js#403 mirrors it on the JS client. Both are still open.

Notes

This post grew out of fixing a real production bug at Nibble, where the schema in question backs per-agency subscription preferences across 13 countries of recall data. The shipped fix has been in production since Feb 2026 with no observed race issues.

If you've hit the same trap from a different direction (PostgREST + composite uniqueness + nullable columns), I'd be curious to hear it: github.com/Maliik-B or on X @Don_adijah.