MEKYRA

DevelopersUnder the hood

Rules as code,
with receipts.

Rulespec is the structured form of a rulebook. The kernel executes it deterministically, logs every event with the rule that caused it and replays any match from its seed. Here is what that looks like, what is already built and what we learned building it.

Runtime reference on GitHub
pocket-tactics.rulespecSyntax in design
# pocket-tactics.rulespec  (syntax is illustrative)
game pocket_tactics v0.4
players 2 · lanes left center right · zone keep[player]

rule §2.3 "Play units from your hand by paying their cost."
action play(card, lane)
  require card.owner == active
  require card.cost <= energy          # §2.1
  require lane.empty(active)           # §2.3

rule §4.1 "When Spark Imp enters play, deal 2 damage to …"
when   spark_imp.enters
target 1 enemy.unit where lane in adjacent(self.lane)
do     damage(target, 2)

rule §5.3 "A heal that removes no damage still counts …"
open   A-1                              # ledger question, literal reading
guard  K.1 chain <= 64
engine/pocket.ts · the kernel on this sitePlayable now
import { createMatch, check, apply, replay, stateHash } from './engine/pocket'

const state = createMatch(rules, 2026)          // seeded setup
const verdict = check(state, rules, action)      // { ok } or { ok: false, ref: '§2.3', message }
const { state: next } = apply(state, rules, action)

// A match is its seed plus its actions.
const states = replay(rules, 2026, actions)
stateHash(states.at(-1))                         // same hash on every machine

NoteThe demo kernel is a compact TypeScript port written for this site. It mirrors the runtime’s approach: pure state transitions, a first-in-first-out trigger queue with a chain guard and xorshift32 randomness from a recorded seed. State hashes use FNV-1a.

FoundationWhat is already built

The engine
came first.

MEKYRA started as a demanding multiplayer rules engine for a card game. Every part below is built and covered by automated tests; the game-agnostic engine is being extracted from it.

  • Built

    Deterministic rules runtime

    Same state and same action always produce the same next state.

  • Built

    Structured effects and triggers

    Card effects are data the engine interprets, including triggered abilities.

  • Built

    Authoritative legality and targets

    Legal actions and targets come from the engine, and one legality system is used wherever the server checks an action.

  • Built

    Persistent player decisions

    Each pending decision has an owner and a version. Answers from the wrong player, or to a stale decision, are rejected.

  • Built

    Reconnect and persistence

    Match state lives on the server. A player can drop out mid-choice and rejoin to the same decision.

  • Built

    Seeded, reproducible randomness

    The seed lives in match state and random operations are logged, so a replay confirms the same draws.

LessonsWhat a rules engine teaches you

Hard parts,
solved once.

A choice outlives a connection

A player can drop out while choosing a target, with an effect half-resolved and others waiting.

What the engine does: Pending choices are match state, not UI. On reconnect the same decision is waiting, and the effect resolves once.

Targets go stale

Between choosing a target and resolving the effect, another effect can remove it.

What the engine does: Legality is checked when the target is chosen and again at resolution, under a rule the designer sets.

Triggers pile up

One action can set off several triggered abilities, some of which ask players for choices.

What the engine does: Triggers that fire together go into a deterministic queue and resolve one by one, so the result never depends on network timing.

Whose decision is it?

In a multiplayer match the player whose turn it is isn’t always the one who has to decide.

What the engine does: Every pending decision has an owner. The server rejects answers from anyone else, and answers to a decision that is no longer current.

InterfacesOn the roadmap

APIs, MCP
and the Claude adapter.

Building on MEKYRA? Tell us what you need first and get early access: [email protected].

  • Rulespec compiler

    In development

    Rulebook text in, typed Rulespec out, with source citations and ledger questions.

  • Claude adapter

    In development

    Server-side only. Keys, limits and logs live on MEKYRA’s server; the browser never holds a key.

  • Match API

    On the roadmap

    Create rooms, submit actions, stream events over WebSocket, fetch replays by seed.

  • MCP server

    On the roadmap

    Let Claude and other agents read a ruleset, ask the kernel whether a move is legal and run Lab batches.