Games
Pricing
←All guides

Iterate·2 min read

Iterate without breaking what already works

One change at a time, test in the preview, and use version history as a safety net rather than a last resort.

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.

  1. 1

    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.

  2. 2

    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.

  3. 3

    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.

When the AI gets stuck, shrink the request

Repeated failed attempts at the same change usually mean the request is too broad or is fighting something structural. Ask for a smaller piece of it, or ask what the current implementation does before asking to change it.

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.

Previous

Decide mobile or desktop before you build

Next

Bring your own assets, or generate them

Try it on a real project

The fastest way to understand any of this is one small brief and one playable build.

Start buildingRead the FAQ
GamesGuidesBlogReviewsAffiliatesFAQPricingTermsPrivacyGuidelinesWithdrawalCancel contracts hereImprint
.dev
Made within Mannheim, Germany
Games
Pricing
←All guides

Iterate·2 min read

Iterate without breaking what already works

One change at a time, test in the preview, and use version history as a safety net rather than a last resort.

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.

  1. 1

    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.

  2. 2

    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.

  3. 3

    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.

When the AI gets stuck, shrink the request

Repeated failed attempts at the same change usually mean the request is too broad or is fighting something structural. Ask for a smaller piece of it, or ask what the current implementation does before asking to change it.

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.

Previous

Decide mobile or desktop before you build

Next

Bring your own assets, or generate them

Try it on a real project

The fastest way to understand any of this is one small brief and one playable build.

Start buildingRead the FAQ
GamesGuidesBlogReviewsAffiliatesFAQPricingTermsPrivacyGuidelinesWithdrawalCancel contracts hereImprint
.dev
Made within Mannheim, Germany

Cookies and analytics

We would like to measure how Oryn is used — which features people reach and where generation fails — using PostHog on servers in the EU. This sets cookies. Oryn works exactly the same if you decline. Privacy notice