Photo by Jake Weirick on Unsplash. Illustrative, not footage of Cinevva.
One ship. One asteroid. One score increment.
That is a useful first milestone for a prompt-built 3D game: a complete interaction you can explain, repeat and change. Before requesting a whole galaxy, I would give the generator this small design brief:
Build a single-player asteroid-shooter prototype.
Use placeholder shapes and one stationary asteroid.
Movement: holding Left or Right moves the ship;
releasing the key stops that movement.
Scoring: the first projectile hit destroys the asteroid
and adds one point. Further callbacks for that asteroid
must not award more points.
Restart: clear projectiles and input state, set score
to zero, and restore the original ship and asteroid.
Do not add upgrades, multiplayer or a leaderboard yet.
This is a proposed specification, not a tested Cinevva prompt or a claim about its generated code. The point is to make success visible before increasing scope.
What the prototype account actually shows
In a June 27, 2025 account, Cinevva describes iterating on an asteroid shooter and flight-simulation prototype through prompts. The author reports working across several evenings and describes a Three.js-based workflow with scene and behavior instructions.
That is an interesting creator account, not an independent productivity benchmark. It does not establish how long your project will take, and early multiplayer experiments are not evidence of a production-ready networked game. I would borrow the small-step iteration pattern rather than promise the same timeline.
The useful opportunity is a shorter path to something you can play. The next question is what, exactly, you will test once it appears.
A rendered scene and a game have different jobs
The Three.js manual's game tutorial draws an important boundary: Three.js is a 3D library, not a complete game engine. It supplies a scene graph and rendering features; a game still needs systems for input, collisions, physics and other behavior, whether you write them or integrate other libraries.
A generated scene can therefore look convincing before its rules are settled. A spaceship model answers “what does the player see?” It does not, by itself, answer “what happens when the player releases the key?”
Separating those responsibilities helps you ask better follow-up questions. Instead of “make it feel better,” describe the behavior you want to change and the behavior you want to preserve.
Turn each contract into a short playtest
Movement: Hold a direction, release it, then press the opposite direction. Does the ship follow the stated rule? Stopping immediately is only one possible design; if you want inertia, specify acceleration and braking instead. Neither choice is universally more fun.
Scoring: Hit the asteroid with closely spaced projectiles. The score should increase once for that asteroid, even if multiple collision callbacks arrive. A useful implementation separates “target is active” from “target has already been destroyed,” rather than treating every callback as a fresh reward.
Restart: Fire, restart, then wait. Old projectiles should not reappear or change the fresh score. Check that the ship, target and input state also return to their starting conditions. A restart button is a good test of whether the prototype has a coherent session lifecycle.
These are acceptance checks, not a substitute for evaluating game feel. Once they pass, someone still needs to decide whether aiming is readable, movement is satisfying and the interaction invites another try.
Grow the game one deliberate change at a time
Save the working version before asking for a moving asteroid. Then repeat the same three checks. If the new version changes movement or restart behavior unexpectedly, you have a smaller difference to inspect or roll back.
Only after that would I add a second target, richer art or another weapon. Keep a brief note of the prompt, the observed result and the version you retained. That makes iteration a series of design decisions rather than a pile of increasingly elaborate requests.
The exciting part of prompt-assisted creation is not handing over authorship. It is getting an idea into a form where you can make better decisions about it.
Which rule would you make explicit first in your own prototype: movement, scoring or restart?
Full KRI ZEK article: The Prompting Revolution in 3D Game Development
Download Altered Brilliance: https://play.google.com/store/apps/details?id=tech.krizek.alteredbrilliance
Global website: https://global.krizek.tech
Pre-register for Arzenal Human Health: https://play.google.com/store/apps/details?id=tech.krizek.arzenal
Join The Power Of Gaming: https://discord.gg/sbYSPcCqJn
Top comments (0)