From a Screenshot to a Flyable Megastructure

A concept image doesn't know what collision detection is. It doesn't know how a ship should turn, how far it should drift after a burst of thrust, or whether the bridge crossing the shaft ahead is something you fly under or something you die against. It knows none of that, and it was still the single most useful artifact I had going into this project.

This is Project Megastructure, an early prototype of a third-person sci-fi game about flying a small ship through the inside of an ancient, incomprehensibly large machine. There's no campaign, no combat, no enemies yet. What exists is a flyable ship and one dressed chamber, "Conduit Delta-17", built three separate times by three different rendering stacks. The interesting part was never that an AI drew a picture or wrote some Three.js. It's the loop connecting the two: a paragraph of description became an image, and that image became something you can steer a ship through.

Conduit Delta-17. Everything below started here.

An image says what a brief can't

The brief I started from was atmospheric, not technical: a camera chasing a small fighter down a monumental shaft, cold composite walls, sparse amber lights, one distant white beam, heavy haze. An image model turned that into the picture above, and the picture made decisions no paragraph had made. It fixed the camera height. It showed how small the ship needed to feel against the architecture, something like 5 to 8 percent of frame height, which is a very different instruction than "make it feel big." It showed that the shaft needed a strong central axis, two crossing bridges, a vertical strut tying them together, and exactly one dominant light source at the far end pulling your eye down the corridor.

None of that is a mechanic. All of it is a composition, meaning the fixed arrangement of shapes, depth, and light that a viewer's eye is meant to follow, and a composition turns out to be something you can hand to a coding agent as a spec.

Turning a picture into a scene you can fly through

The next step was asking a coding agent to build the room the picture implied. It didn't happen in one shot, because a screenshot doesn't contain a flight model, a collision volume, or an update loop; it doesn't tell you whether that bridge is solid or scenery. What it does is remove the blank-page problem. Instead of staring at an empty scene asking "what should the first room look like," there was already a target: a long chamber toward a vanishing point, wall pylons broken into repeating panels, two bridges at different depths, fog thick enough to swallow the far end, and a two-tone palette, cold blue-gray architecture against warm amber lights, held strictly enough that a third hue anywhere in frame counts as a bug.

The ship itself needed a flight model rather than a floating camera: thrust, drag, a speed clamp, WASD for translation, arrow keys for yaw and pitch. That's what gives it the sense of mass that makes the room feel big instead of just looking big. There is, notably, no collision detection yet, so right now the ship can fly straight through every wall in Conduit Delta-17. It is, for the moment, the most expensive ghost I've ever built.

Three implementations, on purpose

A single screenshot can suggest a game, but it can't settle an engine argument, and I had one running the whole time: how much of this "look" is actually the room, and how much of it is just whichever rendering stack happened to draw it? So there are three sibling builds of the same first chamber, and they disagree with each other on purpose.

• Three.js is the main build, the one everything above describes: hand-rolled geometry generators for towers, pillars, bridges and greebled panel detail, a manually assembled post-processing chain (ACES tone mapping, bloom, film grain), and a chase camera tuned by hand.
• React Three Fiber started as a search for a faster level-design loop, level data as a JSON file, edited by dragging pieces around in the browser and writing the result straight back to disk. It works, and it's parked anyway. It was turning into a general-purpose scene editor, undo stack and all, and that's a tool Blender already is.
• Babylon.js is a genuinely independent build, not a port. It was re-derived straight from the concept art rather than copied from the Three.js version, and it shows: the shaft's cross-section is a plus, not a rectangle, because that's what the art actually depicts once you look past the vanishing point. It swaps the hand-assembled post chain for a single built-in rendering pipeline and picks up its own pile of framework-specific gotchas along the way, Babylon is left-handed, so forward is +Z instead of -Z, and a material's emissive texture replaces its emissive color instead of multiplying it, which is a fun way to turn every glow in your scene white if you don't know it going in.

Comparing them answered the question. The palette, the fog, the sense of scale, that all survives the framework switch, which means it belongs to the room and not to Three.js. The level-editing workflow didn't survive contact with "how much editor do I actually want to build," which means that idea belongs to tooling, not to the game.

What the picture couldn't tell me

Someone still has to decide what the player is doing in this room, what counts as danger, which structures you can land on and which ones just look like you can. The image gave me a destination and a mood; it did not give me a game. That's fine. The picture was never supposed to finish the job, only to shorten the distance between having an idea and having something you can fly through and immediately tell is wrong.

Fly it yourself

Pick an implementation below. Click the canvas first so it has keyboard focus, then use W A S D to move and the arrow keys to steer. Remember there's no collision yet, so flying into a wall is a sightseeing option, not a mistake. Desktop only, there's no touch input.