Mekyra
EARLY-STAGE · ENGINE PROTOTYPE

From rulebook
to playable game.

An AI-native platform for building, testing and playtesting rules-heavy games.

Your rules, made structured.
Your game, made executable.

Explore how it works View roadmap
Working engine prototype. Authoring layer next.
RULES WORKSPACECONCEPT VIEW
01 / HUMAN RULE

“When this creature enters play,
deal 2 damage to an opposing creature…”

rulebook.mdNatural language
TriggerTargetEffect
Game Rules DSL
STRUCTURED. CONNECTED. EXECUTABLE.
Deterministic runtimeRules decide the state.
action deal_damage(target, 2)
result target.hp → target.hp − 2
Same state + same actionSame result
BUILT FOR COMPLEXITY
Tabletop systems
+
Card game mechanics
+
Rules-heavy worlds

01THE PROBLEM

One simple rule.
A hundred interactions.

Digitizing a rules-heavy game means translating hundreds of interacting rules into behavior that holds up under real play.

A coding assistant can generate code. A game also needs a persistent formal model, deterministic execution, reproducible QA and a runtime you can inspect.

A RULE SOUNDS SIMPLE…
“Deal 2 damage to an opposing creature on an adjacent lane.”
What if there’s no valid target?What if the target disappears?Who chooses in multiplayer?Can the same target be selected twice?What if control changes?How do simultaneous effects resolve?

And does the written rule match the implementation?

02THE WORKFLOW

A pipeline.
Not a prompt.

From the rules you write to the game you can test.
A formal model connects every step.

STEP 03 / 07

Give every rule a structure.

Translate approved mechanics into a constrained Game Rules DSL, ready for deterministic execution.

FORMAL REPRESENTATION
01TRIGGER ENTER_PLAY
02TARGET OPPONENT · ADJACENT
03EFFECT DAMAGE 2

The platform workflow is the product vision. A working internal engine prototype is the foundation.

03RULES COMPILER

Human intent.
Machine-readable rules.

AI interprets the language. A constrained Game Rules DSL gives it structure. You stay in control of what the rule means.

Written ruleINPUT
“When this creature enters play, deal 2 damage to an opposing creature on an adjacent lane.”

Interpret with Claude / an LLM.
Resolve ambiguity with the designer.

Structured ruleIllustrative DSL
TRIGGER: ENTER_PLAY

TARGET:
  TYPE: CREATURE
  CONTROLLER: OPPONENT
  POSITION: ADJACENT

EFFECT:
  DAMAGE: 2
Constrained mechanics, ready for validation
FUTURE VISUAL EDITOR
WHENCreature enters playCHOOSE1 opposing creatureWHEREAdjacent laneDODeal 2 damage
ONE FORMAL MODEL

Triggers · Conditions · Targets · Choices · Costs · Effects · Duration · Ownership & control · Zones · Positioning

THE RUNTIME CONTRACT
Same state
+
Same action
=
Same result
state_004action_005state_005

Replayable by design.

04DETERMINISTIC ENGINE

AI helps build the rules.
The engine runs them.

Match state is decided by formal rules, never by an LLM at runtime. A known state and action always produce the same result.

This makes multiplayer synchronization, persistence, replay, debugging and automated testing possible on a shared foundation.

Deterministic transitionsReproducible testsTraceable behavior

05AI QA & TESTING

Find the edge cases.
Before your players do.

AI helps identify ambiguity and generate test scenarios. The engine executes the tests against known state, so results are reproducible.

Cover source or target removal, control changes, simultaneous effects, multiplayer, interrupted choices and reconnects.

See the verification roadmap
Interaction test explorerConcept
SCENARIO 01

No valid targets

GIVEN
No opposing creature occupies an adjacent lane.
RESOLVE
Is the effect skipped, or is entering play prevented?
ASSERT
The engine follows the designer-approved no-target policy.
Define the policy → generate a test → run on the engine

06PLAYTEST & DEBUG

A playable game.
An explainable state.

The planned Studio brings multiplayer sessions, match logs and a rules debugger together. See what happened, and exactly why.

Mekyra / Playtest StudioPlanned interface · illustrative data
MATCH STATETURN 04
OPPONENT
LANE 01
LANE 02
CreatureHP 5
CreatureATK 6
LANE 03
PLAYER
Effect resolvedstate → state′
Rules inspector
Final ATK6
Base ATK
4
Hero passive
+1
Building effect
+2
Enemy aura
−1

Every modifier has a source.
Every result has a reason.

Persistent matchesReconnectServer-side validationInspectable state

07THE PLATFORM VISION

One connected system.
From first rule to final runtime.

The engine is the foundation. These are the planned tools around it, designed to share the same formal model.

01

Rules import

Rulebooks, card lists, CSV, FAQ and errata. Build a model and flag unclear rules.

Planned
02

Rules compiler

Natural-language mechanics into a constrained Game Rules DSL.

Next layer
03

Visual rules editor

Author triggers, choices, conditions and effects without manually editing code.

Planned
04

AI QA

Find ambiguity, conflicting rules, missing behavior and multiplayer edge cases.

Planned
05

Test generation

Generate reproducible, executable tests for normal play and unusual interactions.

Planned
06

Multiplayer playtest

Browser sessions with persistent matches, reconnect and server-side validation.

Planned Studio
07

Rules debugger

Inspect state, trace modifiers and understand why an action is legal.

Planned
08

Simulation & balance

Explore dominant strategies, weak or overpowered cards, loops, win rates, underused mechanics and game length.

Future
09

Collaboration & versioning

Track rule changes. AI summaries connect each change to affected tests.

Future
10

SDK / API

Bring validated game logic into web applications and game engines.

Long-term
VERSIONING CONCEPTv0.8 → v0.9

Fireball: damage 4 → 3 · Warrior: cost 2 → 3

Trace changes to affected tests.

08WHERE WE ARE TODAY

Working engine prototype.
Building the next layer.

Mekyra is an early-stage project. A working internal deterministic rules engine has already been used to implement an internal rules-heavy multiplayer card-game proof of concept.

We’re building the AI-native authoring and verification layer next. The prototype is internal and has not been commercially released.

Follow the product direction
Internal proof of conceptWorking
  • Structured card effects & triggers
  • Target selection & sequential choices
  • Persistent multiplayer matches
  • Reconnect & multiple player configurations
  • Deterministic state transitions
  • Automated tests & complex interactions
Engine capabilities demonstrated in one complex ruleset.
A general-purpose platform is the next step.

09THE ROAD AHEAD

Build the foundation.
Then open the possibilities.

A phased product direction, without fixed release dates. Each layer builds on the one before it.

  1. 01First focus

    Generalize the engine

    Turn the existing proof-of-concept engine into a game-agnostic rules runtime.

  2. 02Next

    Rules compiler

    Translate natural-language rules into structured Game Rules DSL.

  3. 03Planned

    AI QA

    Add ambiguity detection, interaction analysis and automated test generation.

  4. 04Planned

    Studio

    Bring together the visual rules editor and browser multiplayer playtesting.

  5. 05Future

    Simulation

    Automate playtesting and help designers analyze balance.

  6. 06Long-term

    Platform

    Expand into collaboration, versioning, APIs and SDKs.

10WHO WE’RE BUILDING FOR

For people who
think in game systems.

Whether you’re testing a new mechanic or exploring a digital version of a tabletop game, Mekyra is being designed for your rules.

  • Indie tabletop designers
  • Card game creators
  • Small game studios
  • Tabletop publishers
  • Rules-heavy game developers

LET’S BUILD BETTER GAME SYSTEMS

We’re building the infrastructure
between a rulebook
and a playable game.

Designing a rules-heavy game? We’d like to hear about it.
Get in touch to discuss the project or express interest in early access.

Start a conversation contact@mekyra.comEarly-stage project. Public access is not available yet.