Conjure — one schema, compiled for client and server

1 schemaclient, server, liveops

0 Bon the query hot path

µsper command, device and server

0trust required in the client

Why this is new

Four things that change.

Play offline. The server still checks.

The device runs the game with no connection and writes down what the player did; when the network is back, the server replays that journal with the same compiled logic and compares the state. Commands that need the server — real-money purchases, clans — travel with the journal and run against the verified state.

replay verificationprototype validated
determinismshipped

See the mechanism →

interactive · offline play, server replay

3 actions offline · 1 queued · 0 requests · illustrative timings

The phone is offline: three actions run on the device at once and go into a journal. Joining a clan needs the server, so it waits in the queue.

under the hood

schema

module Shop {
    command BuyItem(…)
    command OpenChest(…)
    command ClaimReward(…)
}
module Clans {
    command JoinClan(…)
}

Deterministic by construction — fixed-point math (Fixed64) instead of floats, seeded random in the schemashipped
Replay verification on the serverprototype validated
Microseconds per command, device and serverprototype validated

UI views update themselves.

Declare what a UI view shows and the compiler keeps that view model current by applying only the change. No OnChanged wiring, no refresh-order bugs, no stale UI.

view models · IVMshipped
reactive queriesshipped

Reactive queries →How IVM works →

interactive · UI view stays in sync

SubscribeChanged · per-row deltas

Replace · gold 220 → 420
Replace · row 1 · affordable

rows touched 1 / 6 · delta, not rescan

Gold changed, so the view model changed one row — the sword became affordable — and the UI view updated that one row.

under the hood

schema

materialized view ShopOffers {
    …
} = from Offer o
    | join Price p (o.Id == p.OfferId)
    | select { … }
 
reactive query Offers() -> OfferRow[] {
    from ShopOffers
    | sort Price
}

Meta and core in one architecture.

Inventory and progression live in persistent tables; units, projectiles and hit events live in per-frame tables, in the same schema with the same compiler. The weapon in the inventory is the weapon in the fight, without a second data model.

frame stateshipped
persistent + frame joinsshipped

Ephemeral tables →

interactive · meta and core, one schema

0 B per frame · one planner

Equipping a sword is an ordinary write to a persistent table: the inventory UI view updates, and the sword's stats are now game state.

under the hood

schema

// persistent — the meta
table Inventory { … }
table Progression { … }
 
// per-frame — the core
ephemeral table Unit { … }
event table HitEvent { … }
system Collision(phase: fixed_update)

Arena sample · 100 000 units · 171 µs per frame on IL2CPP + Burst · 0 B allocated methodology →

A feature is a schema, not a sprint.

A battle pass or a store is a module of the schema: tables, commands and queries in one place, for both sides. Carry it to the next game and point its declarations at that game's items and currencies — the compiler re-derives what depends on them. Change rules through liveops without a release, and let an assistant draft the first version — the compiler rejects what is wrong.

modules & overridesshipped
liveopsprototype validated
ready-made modulesplanned

Every part and its status →Vertical slices →

interactive · a feature from declaration to reuse

declare

module BattlePass {
    table Tier { … }
    table Progress { … }
    command ClaimTier(…)
    reactive query Track(…)
}

one file · one owner · both sides

compiled

UI view binds the Track view model

prototype validated

liveops

season length
tier xp
rewards

tunable after releaseprototype validated

adapted

Project B

module BattlePass {
  table Tier {
    Reward: int @relation(
-     references: Item.Id)
+     references: Card.Id)
-   Price: Gold
+   Price: Gems
  }
  command ClaimTier(…)
  reactive query Track(…)
}

compiler: re-checked 3 joins · regenerated view model + server command · ok

same module · 2 declarations changed · logic untouched

assistant: add a weekly reset to the battle pass+4 lines · module BattlePasscompiler: ok · 0 diagnostics

One file declares the feature: its tables, the one command that changes them, and the reactive query the UI view binds.

under the hood

schema

module BattlePass {
    table Tier { … }
    table Progress { … }
    command ClaimTier(…)
    reactive query Track(…)
}

Shipped

What you can use today

The data layer, frame state, determinism and the interpreter are in the docs now. The server and liveops are validated prototypes; the services are designed. The platform page keeps the whole list honest.

ConjureDB schema

module Leaderboard {
    table Player(
        persistence: local, capacity: 16384, type_id: 1001) {
        Id: int @id
        Name: string
        Score: int
 
        @@index(fields: [Score], name: "Player_ByScore", kind: sorted_set)
    }
 
    // every UI view can reuse this — written once
    query GetTopScorers(count: int) -> Player[] {
        from Player p
        | sort { -p.Score, p.Id }
        | take @count
    }
}

You write the schema. Conjure emits the C# — switch the tab and read it.

Compiled queries, commands and mutationsDeclared once, planned by a cost-based optimizer, emitted as plain C#.Docs →
UI views that update themselvesView models maintained by applying only what changed.Docs →
Frame state and systemsPer-frame tables and systems scheduled per phase, 0 B per frame.Docs →
Portable interpreterA no-JIT lane for queries that arrive after the build, bit-identical to compiled code.Docs →
DeterminismFixed-point math (Fixed64) and seeded random declared in the schema, held by tests.

57-query game workload · 50 000 players · 519× vs hand-written LINQ · 0 B allocated on 26 of 57 cases benchmarks →

Platform: every part and its status

Who it's for

Built for a team of three. Readable by a team of thirty.

Small studios

The infrastructure a platform team would build — client data layer, server, verification, liveops — compiled from one schema, without the platform team.

Tech leads

A deterministic, compiled model with explainable plans, generated code you can read, and limits stated out loud.

Gameplay programmers

Declare state and commands. UI views update themselves, the frame stays flat, and the same feature runs on the server without a second implementation.

See every part and its real status

The platform page lists what is shipped, what has been proven in a prototype and what is only designed.

Platform Read the docs