ROADMAP

One product,
built in order.

Six phases, without release dates. Each depends on the one before it: there’s no point compiling rules for an engine that only runs one game, or simulating balance before rules can be tested.

  1. 01

    Generalize the engine

    In developmentCurrent focus

    Zones, objects, turn structure and resolution rules move out of engine code and into the game model. The engine keeps what every game needs: state, actions, choices, effects and validation.

    WHY HERE
    Every later phase needs an engine that isn’t tied to one game.
    DONE WHEN
    A second, structurally different game runs on the same engine without engine changes.
  2. 02

    Rules compiler

    Planned

    The DSL becomes the authoring format, and Claude helps translate written mechanics into it. Every ambiguity becomes a question for the designer instead of a guess.

    WHY HERE
    Hand-writing rule definitions doesn’t scale to hundreds of cards.
    DONE WHEN
    A designer goes from rule text to a running rule without writing engine code.
  3. 03

    AI QA

    Planned

    Static checks on the model, Claude comparing the model with the rulebook, and test scenarios generated from the rules and run on the engine.

    WHY HERE
    With a compiler, rules change fast. Changes need a safety net.
    DONE WHEN
    Changing a rule tells you which tests broke and why.
  4. 04

    Studio & browser playtesting

    Planned

    Visual rules editor, browser multiplayer sessions for any modelled game, and a debugger that explains how each rule resolved.

    WHY HERE
    Designers need to play the game, not read test output.
    DONE WHEN
    A designer shares a link and playtests remotely on the current ruleset.
  5. 05

    Simulation & balance

    Planned

    Automated players, batch matches and reports on strategies, card usage, loops and game length, compared across ruleset versions.

    WHY HERE
    Balance questions need more games than a playtest group can play.
    DONE WHEN
    A designer compares two versions of a ruleset with data from simulated matches.
  6. 06

    Collaboration, SDK & API

    Long-term

    Versioned rulesets, shared workspaces, and access to validated rules logic from other clients and game engines.

    WHY HERE
    A rules model that’s been tested this hard should be reusable.
    DONE WHEN
    A game client built elsewhere runs its rules through Mekyra.

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.

Email Mekyra [email protected]Mekyra is in private development. Every email is read by the founder.