Games
Pricing
←All guides

Planning·2 min read

Answer the planning questions, then approve the plan

The two checkpoints before any file is written, why the second one is the cheapest place to change your mind, and what to look for in a plan.

Between your description and the first line of GDScript there are two deliberate stops: a short set of planning questions, and a plan you have to approve. Both exist for the same reason — correcting a misunderstanding in a sentence costs seconds, correcting it in a built project costs a full rebuild.

The planning questions

Questions arrive one at a time inside the chat rather than as a form, with a progress counter so you can see how many are left. Each one offers suggested answers, and each one also accepts a custom answer if none of the options match what you have in mind.

They are worth reading rather than clicking through. The questions asked are the decisions your brief left open — which means every one of them is a place where the result could diverge from what you pictured. If a question surprises you, that is information: it usually means your brief was ambiguous somewhere you thought it was clear.

  • Pick the suggested answer when it matches — it is a well-formed answer, and typing a synonym gains nothing.
  • Use the custom field when your answer is genuinely different, and keep it short and concrete.
  • If a question reveals that your brief was wrong, say so in chat instead of answering around it.

The plan

Then you get a written plan of what will be built, with an Approve button. Nothing is created until you press it. This is the last free checkpoint, so read it as a specification rather than a summary — you are checking whether this describes the game you want, not whether it sounds reasonable.

  1. 1

    Check the core loop first

    If the plan's description of what the player does moment to moment is wrong, nothing else in it matters. Fix that before reading further.

  2. 2

    Check the scope

    A plan noticeably larger than what you asked for will take longer and produce more surface area to debug. Asking for less is a legitimate response to a plan.

  3. 3

    Check what is missing

    Fail states, restart flows, and UI feedback are the usual omissions. If you do not see them, ask before approving.

Approving is cheap, but it is not free

Approval starts a real build that consumes credits. Rejecting a plan you have doubts about and restating the goal costs one message; approving it and rebuilding costs a full run.

Once you approve, the plan runs and you get a playable build to react to. From there the loop is different, and that is the subject of the iteration guide.

Previous

Write a brief that produces a coherent game

Next

Decide mobile or desktop before you build

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

Planning·2 min read

Answer the planning questions, then approve the plan

The two checkpoints before any file is written, why the second one is the cheapest place to change your mind, and what to look for in a plan.

Between your description and the first line of GDScript there are two deliberate stops: a short set of planning questions, and a plan you have to approve. Both exist for the same reason — correcting a misunderstanding in a sentence costs seconds, correcting it in a built project costs a full rebuild.

The planning questions

Questions arrive one at a time inside the chat rather than as a form, with a progress counter so you can see how many are left. Each one offers suggested answers, and each one also accepts a custom answer if none of the options match what you have in mind.

They are worth reading rather than clicking through. The questions asked are the decisions your brief left open — which means every one of them is a place where the result could diverge from what you pictured. If a question surprises you, that is information: it usually means your brief was ambiguous somewhere you thought it was clear.

  • Pick the suggested answer when it matches — it is a well-formed answer, and typing a synonym gains nothing.
  • Use the custom field when your answer is genuinely different, and keep it short and concrete.
  • If a question reveals that your brief was wrong, say so in chat instead of answering around it.

The plan

Then you get a written plan of what will be built, with an Approve button. Nothing is created until you press it. This is the last free checkpoint, so read it as a specification rather than a summary — you are checking whether this describes the game you want, not whether it sounds reasonable.

  1. 1

    Check the core loop first

    If the plan's description of what the player does moment to moment is wrong, nothing else in it matters. Fix that before reading further.

  2. 2

    Check the scope

    A plan noticeably larger than what you asked for will take longer and produce more surface area to debug. Asking for less is a legitimate response to a plan.

  3. 3

    Check what is missing

    Fail states, restart flows, and UI feedback are the usual omissions. If you do not see them, ask before approving.

Approving is cheap, but it is not free

Approval starts a real build that consumes credits. Rejecting a plan you have doubts about and restating the goal costs one message; approving it and rebuilding costs a full run.

Once you approve, the plan runs and you get a playable build to react to. From there the loop is different, and that is the subject of the iteration guide.

Previous

Write a brief that produces a coherent game

Next

Decide mobile or desktop before you build

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