Building Switchback with AI: the asset factories.

I make Switchback, a cozy hiking and park management game for iPhone and iPad. The parks are full of small things: signs, benches, campsites, trees, rocks, cabins. Each needs to belong to the same world, and some need to do something when a visitor reaches them.

AI-assisted development is part of how I build that world. One of the most useful pieces of the workflow is what I call the asset factories: reusable code that constructs the actual 3D objects, paired with rules and tools for checking the result.

What an asset factory makes

In Switchback, a factory is a JavaScript function that returns a group of Three.js meshes. A lookout tower is built from posts, braces, stairs, roof panels and glass. A park sign has a frame, a stone base and a face that can carry the park's name.

The function can take options such as scale, a random seed or wear. Seeded randomness lets stones and moss feel irregular while keeping the same object stable when it rebuilds. Where an asset supports it, a season or a wear setting can change its appearance.

That gives the AI a concrete thing to work on. It can help write a builder, revise proportions, reuse the game's material helpers and connect the result to existing systems. The output is editable geometry with parameters I can inspect and change.

The same builder serves the game, the asset viewer and the build-menu thumbnails. A change to the object can be checked in the viewer and baked into its menu image from that same source.

The contract around the object

A model needs a place in the game. Each asset has metadata describing its identity, category, cost, ground footprint and lighting, along with the capabilities that apply to it.

A bench needs a seating profile. A viewing scope needs a point a visitor can approach and an activity to perform there. A shop has different requirements again. Shared registries connect those behaviors to the object, so adding a new asset follows an established path.

This is useful context for an AI coding assistant: the materials to use, the fields to fill in, the catalog to register with, and the checks to run are written down. An asset audit catches omissions such as a missing menu entry or a seating claim with no matching interaction.

Some metadata also describes capabilities intended for future systems. Declaring that an object can get wet or weather does not, by itself, implement that simulation. The runtime still has to support the behavior.

Give the workflow eyes

The asset viewer puts the real mesh on a turntable. The capture tool produces repeatable views from several angles, with adult and child Hikees beside it. I can change the light, inspect supported variants and compare the next revision with the last one.

The review has several passes: form and readability, materials and light, charm, and a cleanup pass for clipping, seams and strange proportions. A thin detail that reads well from the front can disappear from the side. A roof can look fine in isolation and enormous beside a visitor.

One nurse-log revision had bracket fungi that disappeared edge-on. Making them thicker then made them look like pale rocks stuck to the trunk. Small, flattened forms finally gave them a better read around the whole log. That is the kind of specific visual feedback a factory can respond to.

The last check is in a real park. The lookout tower's lantern and stove looked acceptable in the viewer, then bloomed into an oversized bright halo in the game. Their intensities needed another adjustment. The surrounding scene changes the answer.

The factory also owes the phone a budget

It is easy to add charm one little mesh at a time: another board, another bolt, another flower. A park repeats those objects, and the rendering cost adds up.

I check both triangles and draw submissions. Compatible static pieces can be batched together inside the factory. Parts that need to move or change independently keep their own handles: a swinging seat, a door, a live campfire.

As one concrete example, batching the picnic table reduced its mesh submissions from 18 to 3 without changing its triangle count. That is an asset-level measurement, not a promise about frame rate; a whole park still needs its own performance review.

What makes AI useful here

The repeatable loop is the part I would carry into another project: define the object and its capabilities, build it against a shared contract, capture it, give specific feedback, check the wiring and measure it in the game.

Every useful correction can become a rule or a tool for the next asset. Keep the random seed stable. Check the back. Put a visitor beside it. Protect the moving parts when batching. Verify that a seat actually gets used.

AI helps with the code and the iteration. The shape of the workflow determines what it can see, what it can verify and how precise the next correction can be. I still have to decide whether the thing feels like it belongs in Switchback.

For the conversation around this workflow, here is my Reddit comment.