# You Can One-Shot a Game. But Can You One-Shot Your Vision?

> One-prompt game demos can impress without matching a specific vision. Building Exodus-Protocol has taught us to define and challenge the connections between mechanics before asking AI to implement them.

Published: 2026-10-04
Author: jeroen
Tags: AI, GAMEPLAY, WORKFLOW
Canonical URL: https://exodus-protocol.com/journal/you-can-one-shot-a-game-but-can-you-one-shot-your-vision

My LinkedIn timeline is full of one-shot game demos: Mario Kart-style racers, platformers, flight simulators. People share a single prompt, and the results can be genuinely impressive.

But I keep coming back to one question: am I impressed because AI built what I imagined, or because I hadn’t defined exactly what I wanted?

Ask AI to “make something cool” and there is plenty of room to surprise you. Ask it to realise a specific vision, and you are setting a different challenge.

## A familiar game is already part of the brief

In the simplified kart racers I see, the ingredients are familiar: a track, obstacles, speed boosts, banana-peel-style traps, shields. Naming an established game supplies a substantial part of the brief before you describe any mechanics yourself.

There is nothing wrong with that. An open-ended prototype can help you discover a direction. But familiar ingredients do not automatically produce the particular experience you have in mind.

A game does not need entirely new mechanics to stand apart. The distinction can come from deliberate choices about how familiar mechanics interact, what they reward, and what players risk. Those choices are where our work becomes more demanding.

## One Extractor, several connected systems

In Exodus-Protocol, our persistent multiplayer space strategy game, an Extractor is a ship that collects resources from an uninhabited planet while operating in orbit.

That sounds straightforward. But what happens when another player successfully colonises that planet while your Extractor is still working?

Should extraction stop? Who keeps the resources already collected? Does the fleet leave immediately? What happens if its route home is no longer available?

Our specification makes those choices explicit. Once colonisation completes, all extraction at that planet stops and the affected missions are automatically aborted. Resources already collected stay in the fleet’s cargo. They also remain deducted from the planet; colonisation does not replenish its deposits. A Mining Station built there later works with what remains.

Even the order of events matters. The simulation advances in processing intervals called game ticks. When colonisation completes during a tick, ownership changes before extraction output is awarded. The Extractor therefore receives no final batch of resources for that tick.

Returning is not simply a command to teleport home. The system checks the fleet’s fuel, available routes and access to refuelling locations. It first tries the mission origin, then another reachable player-owned planet if necessary. Without a valid route, the fleet becomes stranded until one becomes available. Aborting the mission does not, by itself, make the ships immune to combat.

One apparently simple feature now touches ownership, resource depletion, cargo, timing, navigation and risk. AI could suggest several plausible ways to connect these systems. The important question is whether those are the connections we intended.

## Challenge the proposal, not just the code

We have tried direct requests to implement features. What we have noticed is that AI can fill gaps with familiar concepts or apparently sensible decisions without examining every consequence.

**A solution can be internally logical and still create the wrong player experience.**

We therefore use spec-driven development: a living specification describing intended behaviour and the relationships between features. It is not a document we finish before development starts; it evolves as we learn.

AI is our rubber duck, a partner to think aloud with. We pitch ideas, explore where they fit, and ask for a proposal. Then we challenge it, sometimes almost line by line.

What else changes? What happens when two actions overlap? Could a player exploit this rule? Does it create an interesting decision, or just unnecessary frustration?

That process does more than help AI reconsider its answer. It exposes choices and consequences we had not considered ourselves. We are not simply explaining a finished vision; we are developing it together.

Most of our human development effort now goes into creating and refining that specification. Once a feature is defined, AI can use it alongside the existing framework and earlier implementations to build the next part.

## Preserve the reasons, not just the rules

Addy Osmani, author of O’Reilly’s [*Beyond Vibe Coding*](https://www.oreilly.com/library/view/beyond-vibe-coding/9798341634749/) and a [former leader of Chrome’s Developer Experience organisation](https://smashingconf.com/sf-2023/speakers/addy-osmani/), describes a related problem in his essay [*The Intent Debt*](https://addyosmani.com/blog/intent-debt/): working code does not necessarily preserve the goals and reasoning behind its design.

He also cautions that specifications cannot capture every implementation decision. That is an important limit, not a reason to leave consequential choices undocumented.

For us, the goal is not to describe every line of code. It is to make the decisions that shape the player experience clear enough to discuss, implement and review. A longer document is not automatically a better specification.

## One prompt does not mean the work disappeared

In one of [Anthropic’s application-building experiments](https://www.anthropic.com/engineering/harness-design-long-running-apps), a one-sentence brief for a retro game-making app was expanded into a 16-feature specification, followed by successive implementation and evaluation rounds.

That is a useful counterpoint: complex work can begin with one prompt. But the planning and iteration still happen somewhere. When an agent fills in the brief, it is making design choices, not discovering an unstated vision with certainty.

Our first-pass implementations tend to come closer to what we intended when the specification is clearer. That does not guarantee correct code or enjoyable gameplay. Review and playtesting still matter, and what we learn needs to feed back into the specification.

One-shotting can be useful once the relevant decisions have been made and communicated. It is not a replacement for making them.

**The goal is not merely to be surprised by whatever AI builds. It is to recognise the game we set out to make.**