GCMD — use cases

cards: games, and beyond games · 9 user stories, each with why a deterministic build wins and where it stands

Every story below leans on one or more of these. Generative output gives a plausible new answer each time; these give the same answer, with a record of why.

Status legendWorks today: built and tested. Small step: the engine is there; a focused addition is needed. Roadmap: a new profile, phase or service.

1Errata on a second print run

As an indie publisher, I want to fix the text on 3 cards and re-render only those, with the other 197 byte-identical to the proof the printer approved, so I don't pay for a full re-proof.

Why deterministic wins: a generative model redraws everything and nothing matches the proof. A hash baseline shows exactly which 3 cards changed.

Works todayWorks today.

2Live-ops for a digital card game

As a studio shipping 50 cards a season, I want every card rendered on demand from data with the same frame, rarity and type treatment, so the 1,000th card matches the first.

Why deterministic wins: generated images drift in style and cost money per image. A deterministic render is cached at the edge and costs about nothing on a cache hit.

Works todayWorks today (https://cards.triunalabs.com).

3A template the licensor approves once

As a licensee, I want every derived card guaranteed to keep the approved logo zone, legal line and layout, so brand approval covers the template, not each card.

Why deterministic wins: the skin cannot move zones by design; a generative model cannot guarantee placement.

Works todayWorks today.

4Prototype decks for playtesting

As a designer iterating twice a week, I want a print-and-play deck built from a spreadsheet, with every playtest deck rebuildable from its commit, so feedback always ties to an exact version.

Why deterministic wins: "the deck from last Tuesday" is a commit, not a memory.

Works todayWorks today in RGB (the Counterstack deck). CMYK and card backs are pending.

5Localised editions

As a publisher releasing in 6 languages, I want text fitted to each card, or a loud failure if it cannot fit, never clipped.

Why deterministic wins: a translator checks the exact layout before print, and a fix changes only that card.

Small stepSmall step. Text fitting exists; wider language coverage needs more bundled font glyphs.

6Cards beyond games

As a teacher or trainer, I want flashcards and trading-card-style learning sets generated from a list, consistent and printable every term.

Why deterministic wins:

Works todayWorks today (a new theme at most).

7Personalised backer cards

As a crowdfunding creator, I want each of 4,000 backers to get a card with their name in the credits box, unique per backer but exact to the template, and reprintable identically if one is lost.

Why deterministic wins: variable data in a fixed layout; a generated card per backer would be 4,000 slightly different designs, and a lost one could never be remade.

Works todayWorks today (cards are rendered from data).

8Accessible editions from the same data

As a publisher, I want a colour-blind-safe edition and a large-print edition produced from the same card data, with the same content and the same zones, so accessibility is an edition, not a redesign.

Why deterministic wins: the edition is a different skin over identical anatomy, so the rules text cannot drift between editions.

Small stepSmall step (new themes; the anatomy and semantic badges already carry meaning without colour).

9One card, everywhere: app, web and print

As an organised-play team, I want the card a judge prints, the image in the app and the page in the card database to be the same render of the same data, so a ruling never hinges on which version someone saw.

Why deterministic wins: every surface is a deterministic render of one source; a version mismatch is a hash mismatch, visible immediately.

Works todayWorks today (the Worker serves PNG, WebP and JPEG at fixed widths from the same source as print).