Carbon · AI Node-Graph Orchestration Engine
Carbon is an AI node-graph orchestration engine for game-content generation - every skin is produced by a directed graph of hundreds of nodes that routes work across ten specialised AI models from seven labs, chains them through vision feedback loops, and finishes the output with a deterministic pixel-math layer that guarantees game-playable geometry. One theme line in; a complete, validated game skin out - released live to players at a single button push.
The engine scales decades of accumulated games-studio engineering expertise - craft that normally lives in individual artists and engineers is encoded in the graph and applied to every skin, automatically.
Each stage names the models it runs and the job they do. Models are addressed per-node and versioned, so any single model can be swapped or upgraded without touching the rest of the graph.
A fast LLM reads live news and current events and proposes themes that name real, concrete stories - the seed for every skin. Also exposed as a public generate API.
From one theme line, an LLM authors a structured, machine-readable scene plan: protagonist, arena, palette, mood, and per-asset art direction. The plan is parsed and schema-conformed, then fans out to every downstream branch - which is why dozens of independently generated assets come out looking like one coherent world.
Reference-anchored image generation: a shared anchor reference gives every sprite, tile, and prop the same visual identity. Targeted AI edits and seam repair run as separate graph nodes with their own prompts and guardrails.
Four video models, each doing what it is best at: cinematic one-shot moments, ambient looping backgrounds, image-to-video from a generated still, and a fast fallback tier. The graph handles moderation false-positives, escalating retries, and async completion automatically. The result is a living, animated world rather than static art: ambient idle loops, distinct win and loss moments with seamless crossfades, and per-risk background variants that swap with the player's chosen stakes.
Vision-capable LLMs read the generated art back: they extract the real palette from the finished background, design dependent assets to match it, and colour-match UI elements to the scene. Every vision call is content-hashed against the exact image bytes, so a changed frame forces a fresh pass and an unchanged one is replayed for free.
A full music track and ambience bed generated per skin from theme-conditioned prompts, plus event sound effects (win, cashout, crash) from natural-language SFX prompts.
A proprietary pixel-math library does what generative models cannot be trusted to do: chroma-keying, hue-window recolouring, perspective and plane warps, trims, and luminance guards. Game-critical geometry is never prompted - it is enforced in code. The board a ball bounces on is mathematically exact, every time.
Assets assemble into a per-game manifest that is validated against the real game client's loading code - not a spec on paper. From there, release is a single button push: the skin publishes to CDN and goes live to customers as a playable game, with deployment fully automated and zero client deploys or downtime.
The models are rentable; the orchestration is not. Here is what the same request produces on each side.
Seven capabilities that live in Carbon's engine, above any individual model.
Carbon scales decades of accumulated games-studio engineering expertise. What the team knows about playfield geometry, asset contracts, readability under motion, and player-facing polish is captured in the graphs, guardrails, and validators - so it compounds with every skin shipped instead of living in the heads of individual artists and engineers.
Every asset type goes to the model that is empirically best at it - chosen and re-chosen through continuous head-to-head evaluation, encoded per node, swappable in one line.
One structured plan drives every branch, so the music, the background video, and the smallest sprite all agree on the story being told.
Node behaviours are addressed id@version and hash-pinned; a skin generated today can be explained, audited, and regenerated. Content-hash caching means unchanged nodes never re-bill.
Escalating retry policies, moderation-failure handling, async callback and polling infrastructure, and watchdog timeouts - the unglamorous layer that makes generation an operation, not an experiment.
Deployment is automated end-to-end: a single button push takes a finished skin from the studio to a live, customer-facing game - CDN publish and live-game rollout included, with zero downtime and no release engineering.
Adding a new game clones a proven builder pattern. The last three games (Dice, Beer Pong, Crash) each went from zero to generatable-in-production in days, not months.
For the technical reader - what a Carbon graph is actually made of.
Every skin is a directed acyclic graph assembled from a registry of more than sixty node types across six families: AI sources, LLM prompt operations, deterministic pixel math, computer-vision measurement, iterators and reducers, and persisted state. Each node is addressed id@version; changing a node's behaviour requires a version bump, and node behaviours are hash-pinned in tests so nothing can drift silently.
Dedicated computer-vision nodes locate a container's opening, measure a housing channel, and scan colour bands in the generated images, feeding exact pixel coordinates to downstream placement - so gameplay elements sit inside the artwork, not pasted on top of it.
Every node's output is memoized on a hash of its inputs and parameters; vision-LLM calls additionally key on the sha256 of the exact image bytes. Tweak one node and only the affected subgraph re-runs - everything else replays instantly and at zero cost.
The deterministic cores run both server-side and in the browser, so an operator previewing a node in Carbon Studio's visual graph editor sees the exact pixels the production run will produce. Any node can be opened, inspected, and re-parameterised on the canvas.
Video and music generation are long-running third-party jobs; the runtime manages them with callback and polling waitpoints, watchdog timeouts, and escalating retry cooldowns tuned per provider - a failed clip recovers on its own, without a human restarting the run.
The node types in the production registry
Model inventory verified against the production codebase. Model IDs shown are the versions pinned in production graphs today; the routing layer exists precisely so these upgrade continuously as the frontier moves.