IN DEVELOPMENT

Ora Gaming is not open to sign-ups yet.

We would rather you read that first than reach the end of this page and find it at the door. Ora Gaming is a real 3D game studio: eleven workspace modes, a node logic graph, deterministic playtests that keep their evidence, and Windows and web builds out of a hash-pinned engine. Today it opens only for platform staff. Everything below is what has actually been built, published so you can decide whether it is worth waiting for.

Beta · Not publicly open

A game studio, not a picture of one.

A project opens into eleven workspace modes: a 3D scene viewport, assets, characters, logic, state, narrative, cinematics, code, playtest, builds and settings. Around them sit a dashboard, a project list, an asset library and a playtest catalogue, which are the four places the platform rail already points at. Every one of those modes is a working editor rather than a tab with a message in it, and the whole thing is served by its own control service beside the platform, not bolted onto a page.

It runs on one machine, for one person, on Windows.

The studio states its own limits and they are the reason the door is shut. It is a Windows-first, single-user local build that needs a browser with working 3D graphics, and it is started as a development service rather than installed. Cloud generation, account-backed collaboration and remote asset connectors are outside it entirely. None of that is a small gap to paper over with a sign-up form, so the platform gates the route on the server and shows everyone else the closed door instead.

Behaviour is wired, not scripted from scratch.

The logic editor is a node graph with seventeen executable node types whose input and output ports are frozen contracts, so an edge that would not run cannot be drawn. Beside it, state machines carry entry and exit actions, guarded transitions and typed context; branching narrative carries choices with conditions and multi-language strings with fallbacks; and a cinematic is between one and sixty-four shots with a camera entity, a lens length, framing and a bounded movement vocabulary. All four are projected into one engine-neutral document, which is what both the browser preview and the engine read.

Press play and a build is what you get.

The project is synchronised into a real engine workspace on disk, run headless, and exported as a web build that is then what you play, with the build bound to the exact revision it came from so a stale one cannot be served quietly. Export produces a Windows executable, a web build, or both. The engine and the modelling tool are pinned in a lock file by version and by a checksum for every installed file, so the thing that produced your build is the thing we said it was.

A playtest keeps its evidence either way.

A plan is a starting state, a list of timed actions of six kinds, and the observations you expect. Running it drives the scene headlessly, then reloads from the save it wrote and requires the reloaded state to hash identically to the first pass, which is how a save-and-reopen claim gets proved rather than asserted. Each run leaves an event log, a state file, the request and result it was given, both projections, a video recording checked for a real header, and a screenshot for every capture step checked for a real signature. A missing capture fails the run.

Nothing here is produced by a model.

The prompt box that turns a described room into a scene reads it with rules rather than a model. The passes named for atmosphere, lighting, population and variants are deterministic transforms, each committed as an immutable revision with a receipt. The operator inside the studio works from an allowlist of twenty-three operations, proposes before it acts, waits for a confirmation, and writes a receipt that can be reversed; asked for anything outside the list it refuses rather than guesses. The consequence is worth saying plainly: authoring, playtests and exports here repeat exactly and cost nothing, because every one of them is local compute rather than a metered call.

What you can do

Eleven workspace modes: Scene, assets, characters, logic, state, narrative, cinematics, code, playtest, builds and settings.
A real 3D viewport: Place, transform and inspect entities, props, lights and materials in the scene itself.
Seventeen logic node types: Typed ports and frozen contracts, so an edge that could not run cannot be drawn.
State and narrative: Guarded state machines, plus branching dialogue with conditions and translated strings.
Cinematics, one to sixty-four shots: Camera entity, lens length, framing and a bounded movement and transition vocabulary.
Play is a real build: Play exports a web build bound by hash to the exact revision it came from.
Windows and web exports: Two targets, both executable. Nothing is offered that has no path behind it.
Playtests with evidence: Event log, state, video and a screenshot per capture. A missing capture fails the run.
A rigged stand-in character: A bounded humanoid recipe: eight bones, skinned meshes and one idle animation.
Bounded shape edits: Six operations, from widening a doorway to a damage variant, proposed then accepted.
A verified starter library: Fourteen first-party CC0 artefacts across twelve collections, hash-checked at start-up.
No metered operation at all: Every authoring, playtest and export step is local compute and quotes zero credits.

Ora Gaming is in development and is not open to sign-ups. The platform asks the server on every visit and opens the studio only for an active platform staff role; every other account, member or not, sees the closed door. A membership does not open it and there is no waiting list. It is a Windows-first, single-user local build today, and cloud generation, shared projects and remote asset connectors are outside it entirely. When those change, this page changes with them.

Check access and pricing