Games

The shape of game content

Most games end up reinventing a content pipeline: an Excel sheet of stats, a folder of sprites, a JSON file describing levels, a custom inspector for dialogue trees. Jaina collapses all of these into a single typed system.

Schemas you'll define

• Enemy — name, HP, attack, sprite, AI tag, drops (array of references to Item).
• Item — name, icon, rarity, effects (json).
• Level — name, layout (json), spawn list (array of references to Enemy), background music (audio).
• DialogueLine — speaker (reference to NPC), text (richtext), conditions (json), next (array of references to DialogueLine).

Each one becomes a fully editable form in the GUI, plus a typed C# class via jaina codegen.

Unity integration

jaina codegen my-game --lang csharp --output ./Assets/Scripts/Models/

Generates strongly-typed POCOs you can use directly:

var enemies = await client.Records.ListAsync<Enemy>("my-game", "enemy");
foreach (var e in enemies.Items)
{
    SpawnEnemy(e.Name, e.Hp, e.SpriteUrl);
}

For offline builds, export model.json at build time:

jaina export my-game --format json --output ./Assets/StreamingAssets/

Why teams pick Jaina for games

• Designers edit content without engineering involvement; the GUI is built from the schema.
• The export is canonical — no separate "shipping format" to maintain.
• AI fits naturally — Claude can generate enemies that match your existing rarity curve because it can see the existing records via MCP.
• Hot-reload during development — the SDK has a watch mode that re-fetches packages on change.

What we don't do

We're not a game engine. We don't ship physics, rendering, scripting, or input. We ship the data layer. Everything else stays in Unity, Godot, Unreal, or your custom engine.