Once you have a playable build, the failure mode changes. The risk is no longer getting nothing — it is losing something that already worked. Iteration that stays safe is mostly a matter of keeping each step small enough to evaluate and keeping a known-good version behind you.
One meaningful change at a time
Bundling five requests into one message feels efficient and usually is not. When the build comes back, you cannot tell which of the five caused the thing that now feels worse, and the fix is another five-part message. Separate requests give you a clean signal on each one.
Instead of:
Make the enemies smarter and faster, add a dash, rebalance
the health bar, change the arena to a canyon, add music.
Ask for:
Add a dash on Shift with a one-second cooldown.
→ play it, then:
The enemies should keep their distance instead of charging.
→ play it, then:
Move the fight into a narrow canyon arena.The second version takes three messages instead of one, and each one lands on a build you have already validated. That is faster in wall-clock time than debugging a single ambiguous regression.
Play the preview after every change
The web preview exists to make this cheap. A change that looks right in the diff and feels wrong in play is extremely common in games — feel is the whole product. Ten seconds of playing tells you more than reading the summary of what changed.
Version history is the safety net
Oryn keeps saved versions of the project. Restoring one replaces the current game files with that snapshot, and changes made after it are removed from the active project — but the versions themselves stay in version history, so restoring is not a one-way door.
Before an experiment, note where you are
If the current build is one you would be unhappy to lose, know which version it is before you ask for something ambitious.
Let the experiment be ambitious
Large speculative changes are exactly what a recoverable system is for. Ask for the risky version rather than the timid one.
Restore without ceremony if it did not work
Going back is a normal move, not an admission of failure. The failed direction still stays in history.
Describe the symptom, not the fix
"The jump feels floaty at the top of the arc" is a better bug report than "reduce gravity to 20". The first describes the thing you actually want changed and leaves room for the right fix; the second prescribes a solution that may not be the cause. Say what you observed, when it happens, and what you expected instead.