USE CASES
Small games, big rulesets,
and the space between.
Mekyra isn’t only for huge collectible card games. Anything where the rules are the hard part fits: a one-afternoon game for a workshop or hackathon, a tabletop design in progress, a card game with hundreds of interacting effects.
Four examples of the range, not a list of everything Mekyra is for. They’re scenarios we’re designing for, not customer stories.
- 01QUICK PROTOTYPE
A small game for a workshop, a hackathon or a game jam.
You’re running a university workshop, a community event or a game jam and need a rules-based game people can play in a browser by Friday: a dozen cards, a turn structure, a scoring rule. You describe the mechanics in a few paragraphs, answer the questions Mekyra raises, and share a link.
- Write rules in plain language
- No game client or server to build
- Change a rule between sessions without breaking the rest
The simplest case we’re designing for. The authoring flow it depends on is in development.
- 02ORIGINAL TABLETOP GAME
From printed prototype cards to remote playtests.
You’re designing a card or board game on paper. Every playtest needs people in one room, and every rules change means reprinting. Model the rules once, and playtesters join from a link. When you change a rule, the previous version is still there to compare.
- A playable digital version early in the design
- Rules questions surfaced before playtesters find them
- A history of what changed between versions
Depends on the rules compiler and the browser Studio, both on the roadmap.
- 03RULES-HEAVY CARD GAME
Hundreds of effects that all have to agree.
Every new card interacts with every old one. Timing, targeting, control and simultaneous triggers decide whether the game works. This is where a formal model, a deterministic engine and regression tests matter most, and it’s the case the engine was first built for.
- One vocabulary for every effect
- Regression tests that run on each change
- A debugger that explains how a rule resolved
The engine side already runs a ruleset like this in the private prototype. Authoring and QA tools are next.
- 04DIGITAL ADAPTATION
Try a tabletop ruleset digitally before committing to a full build.
A studio or publisher wants to know how an existing tabletop game behaves on screen: which rules need clarifying, where players need prompts, how long a turn takes. A Mekyra prototype answers that before anyone commissions a full game client.
- A playable prototype instead of a design document
- Rules ambiguities listed explicitly
- A tested rules model to hand to the production team
A longer-term scenario. It needs the full authoring and Studio layers.
A GOOD FIT, A BAD FIT
Where Mekyra makes sense.
A good fit is a turn-based game whose interest comes from its rules: cards, effects, targets, zones, resources, timing. The more rules interact, the more a formal model and a deterministic engine help.
A poor fit is a game built around real-time physics, reflexes or open-ended simulation. Mekyra doesn’t try to be a general game engine. It handles rules, and leaves graphics and real-time play to the tools built for them.
CONTACT
Working on a game
with a lot of rules?
Tell us what you’re building and where the rules get difficult.
Early conversations with designers decide what the general engine supports first.