Can Jev Act as an AI Game Director for Three.js?

A Jev AI game director sounds more ambitious than the system we can honestly build today. Jev does not watch gameplay footage, create a Three.js scene, generate animation, or decide whether a finished game is fun. Its documented job is narrower: read supplied text or structured state, answer bounded questions, and return choices, scores, or yes/no probabilities that code can inspect.

That narrower job may still be useful. An AI game-building workflow often has to choose among known scenes, characters, animation packs, and gameplay templates before it writes or assembles anything. The practical question is whether Jev can make those repeated choices faster or more predictably than a general-purpose model—and whether it adds enough value to justify another API call.

What Jev would direct

Imagine that a player asks for “a relaxing robot game where I collect stars in a sunny garden.” A normal language model can translate that sentence into a small requirements object:

{
  "theme": "cozy nature",
  "loop": "collect",
  "pressure": "low",
  "platform": "desktop",
  "input": "keyboard"
}

The asset catalog might contain two scenes, two characters, two animation packs, and two fixed gameplay templates. Jev could receive the requirements and the text metadata for those eight candidates. Four Choice questions could select one candidate in each category. Separate Score questions could rate how directly each candidate matches the intended experience. A Boolean question could estimate whether any supplied gameplay template supports the requested loop.

That is the full role: bounded selection from an existing catalog. Jev would return IDs and probability distributions. It would not return game code or an explanation of its reasoning.

The rest of the game still belongs to code

A useful game director cannot rely on semantic fit alone. A fox character and a robot animation pack may both sound playful while using incompatible skeletons. A template may match “collect stars” while adding enemies that conflict with “low pressure.” An attractive asset may lack a usable license or exceed the browser budget.

Those checks should remain deterministic:

• Filter candidates by verified rights, file availability, runtime support, and device budget before model selection.
• Check character rigs, animation clips, units, axes, and gameplay requirements after selection.
• Map returned IDs to an allowlist of local constructors or reviewed files.
• Reject unknown IDs instead of turning model output into a path, import, or executable instruction.
• Keep the previous playable scene when a selection is incomplete or uncertain.

Three.js then runs the actual game loop: input, movement, collisions, animation state, collectibles, hazards, win or loss, and restart. The player should not need a model call for every frame—or every movement decision—unless the game is specifically designed as an AI-control experiment.

You can see the difference by browsing finished browser games: their value comes from complete controls, feedback, goals, failure states, and retry behavior. Asset selection is one upstream production decision, not the playable experience itself.

What our local experiment proves

We built a local, mock-first adapter around a synthetic catalog of eight records. It creates four Choice questions, eight Score questions, and one Boolean question in a single bounded request. The surrounding policy validates complete probability distributions, separates scores from probabilities, rejects uncertain selections, checks rig and clip compatibility, and refuses a gameplay template whose loop or pressure conflicts with the stated requirements.

The fixture suite also exercises malformed answers, missing distributions, unknown options, inconsistent scores, HTTP failures, timeouts, and an apparently confident but incompatible selection. All of that is useful engineering evidence for the adapter and fallback policy.

It is not evidence that Jev chooses game assets well. The fixture probabilities were written by us. We have not yet run a labeled Jev-versus-LLM comparison, measured calibration on game requirements, or browser-tested a complete Three.js assembly driven by a real Jev result.

Why not let a stronger language model choose?

That may be the right answer. A general-purpose model already interpreting the player's idea can also choose among a small number of assets. If it makes one good selection during a game-building session, adding Jev would create more integration work without improving the product.

Jev becomes interesting when the workload contains many repeated, independent, bounded judgments. Its interface returns typed decisions and distributions directly rather than generating prose that the application must constrain and parse. That could make it useful for catalog routing, policy checks, or rapid decisions inside a larger agent workflow.

The comparison has to use the same state, candidates, question boundaries, and labels. A fair evaluation would test at least three approaches:

1. Deterministic tags and compatibility rules.
2. The general-purpose model already used by the game-building agent.
3. Jev with the same bounded candidate set.

The useful measurements are accepted-choice accuracy, abstention rate, invalid bundle count, latency, and actual cost. A model's own 90% probability is not proof that it is correct 90% of the time. Calibration has to be checked against independently labeled outcomes.

A better demo than “AI picked the garden”

A single successful selection would be a weak demo. A stronger version would show four cases side by side:

• A clear cozy request where all three approaches choose the same compatible pack.
• An ambiguous request where the probability distribution exposes two plausible directions.
• An unsupported request, such as multiplayer racing, where the system declines to assemble a collecting template.
• A semantically attractive but technically incompatible character and animation combination that code rejects.

After a valid selection, a fixed Three.js game could assemble a small level: move a character with the keyboard, collect five objects, show progress, win, and restart. A second template could add moving hazards and a loss state. The model would choose among those known templates; it would not invent their implementation at runtime.

If you want to prototype an original browser game now, OpenGame Studio is the relevant starting point. The Jev experiment is about improving one decision boundary inside that broader workflow, not replacing the creative and engineering work around it.

Should OpenGame integrate Jev now?

Not yet. The adapter shape is feasible, but the product case remains unproven. A small catalog is easier to handle with tags and deterministic checks. The next useful step is a blind comparison on representative game briefs, including ambiguous, contradictory, unsupported, and multilingual requests.

If Jev improves accepted selections while keeping invalid bundles at zero, it may deserve a narrow role between requirement extraction and Three.js assembly. If the existing agent or simple rules perform just as well, the honest result is to keep the workflow simpler.

That is the standard we want for an AI game director: not whether it can return an impressive probability, but whether it helps creators reach a better playable result with fewer wrong turns.

Source note

TypeSafe's Jev introduction defines Choice, Score, and Noul as independent typed questions over shared state. Its model reference states that Jev accepts text and structured text values, not image, audio, or video input. Vercel's evaluation API documentation documents the corresponding Choice, Score, and Boolean interface through AI Gateway. Pricing and availability were changing during Jev's launch, so check the current official model page before running a paid comparison.