The best first build establishes movement, feedback, objective, failure, and restart. It does not need every system imagined for the final game.

Design documents describe; playables answer

A design document can describe a mechanic in perfect detail and still be wrong about the only thing that matters, which is how it feels at sixty frames a second with a controller in your hands. Feel is not derivable from a specification. It has to be played.

This is why the first build should be aggressively small. Not because ambition is bad, but because the first build's job is to answer a question — is this fun to move around in? — and a larger build answers it no better while taking longer to produce and longer to change.

The five things worth having on day one

1. Movement that responds the way you expect.
2. Feedback that confirms your actions landed.
3. An objective that gives the next thirty seconds a point.
4. A failure state, so the objective has stakes.
5. A restart, so failing costs you seconds instead of a page reload.

Once that loop feels understandable, new mechanics have a stable place to land. Every addition can be evaluated against a baseline you have actually played, which turns "is this better?" from an argument into an observation.

Iterating on an answer you trust

Oryn is designed around this cycle of build, play, inspect, and refine. The planning questions and the plan approval exist to get the first playable pointed the right way; version history exists so that the tenth experiment is as low-risk as the first.