Building a little world with Astra

I wanted to write about building with Astra. Then I thought: what if there was something you could actually play inside the article?

The constraint was simple. A small 3D game, on this page, with every model constructed in code. No hunting for a spaceship pack. No downloading textures. Give the world a consistent visual language and see how far a few shapes can go.

This is the first playable prototype. The game above is the result so far. Launch the tug, bring some salvage home, and try the wireframe button to see what the models are made of.

The speed was the surprising part: the first prototype came together in minutes, including the procedural models and the game rules. Testing the controls, checking the mobile layout, and refining the experience are separate work. But getting from an idea to something I could actually play happened fast.

A shipyard with nothing to build from

You arrive at an unfinished orbital station. Emergency power will last three minutes. Twelve pieces of salvage are enough to finish its power array, habitat, and communications system.

Your tug can carry three pieces at a time. Get close to an amber part and it attaches automatically. Return to the green docking ring to deliver it. Each delivery replaces another piece of the station’s wireframe blueprint with solid geometry.

Grey debris drifts through the construction area. Hit it and you lose a piece of cargo, which you can circle back to collect. There are no weapons in this version. The job is to bring things together.

Astra generated the assets by writing the models

“Generate the assets” can mean several different things. Here it means writing the Three.js code that constructs each object. The game loads no model files or image textures.

The tug begins as a box. A smaller dark box becomes its cockpit. Two cylinders become engines. Thin amber beams become the collection arms. Small bright cones behind the engines stretch as the ship speeds up.

Those parts are deliberately simple. Their proportions, placement, and colors do the work of making them read as a spacecraft.

The station follows the same approach:

Part	Geometry	What makes it readable
Central hub	Eight-sided cylinders and a ring	A solid center with an illuminated docking area
Power array	Thin boxes with repeated divider strips	Blue panels extending from the hub
Habitat	Horizontal cylinders	Pale modules with small illuminated windows
Communications	Narrow masts and open cones	A distinct silhouette above the station
Salvage	Small boxes and beams	Amber color, slow rotation, and a bright collection ring

Switch to Wireframe in the game and the surfaces give way to their edges. That view is also a useful reminder of how little geometry an object needs when the camera and art direction are consistent.

Rules before more features

The first loop is collect, return, build. Everything else needs to make that loop feel better.

Movement happens on a flat orbital plane, viewed through a tilted 3D camera. That lets the models have depth while keeping navigation manageable. You can steer with WASD or the arrow keys, or hold a destination with a mouse or finger. Space applies extra braking.

The tug accelerates rather than teleporting to its target speed. Drag slows it when you release the controls. It should feel like a small working vehicle without making each docking approach a physics exam.

A cargo limit creates a reason to return. The timer gives each trip some urgency. Construction provides the payoff: your progress is something you can see in the world, not just a number changing in a corner.

The first version is a starting point

For this prototype, we chose the setting and the constraints in conversation. Astra implemented the geometry, flight controls, collection rules, construction progress, and the page integration.

The next part is playing it and deciding what deserves another pass. Is the tug easy to steer? Do you notice the salvage immediately? Does completing the station feel satisfying? Would drones make the trips more interesting, or just get in the way?

Those are open questions for this build. I want to keep the answers grounded in what happens when someone actually plays it.

A game that lives alongside the writing

The Three.js engine loads when this game approaches the viewport. Ordinary articles do not initialize a 3D scene. Leaving the game pauses the mission, and navigating away releases its rendering resources.

That makes this page both the build log and the thing being built. As the game changes, there is a concrete result to compare against the decisions described here.

For now, there’s a little station waiting for its first crew. Give it some power.