Does my first project need a shop or saved progress?

Neither is needed to inspect this collection-and-delivery loop. They introduce extra rules about balances, ownership or persistence. Decide on them later, after you know which part of the existing interaction needs to change.

When should I stop refining the first version?

Pause when the objective, progress feedback, completion and retry behave as intended in your recorded checks. Write the next design question before adding features. That stopping point is a prototype milestone, not publication or audience approval.

BC-0023 · CORE GUIDE

Editorial review 2026-09-26

Your First Roblox Build Game

Make your first project a small collection route with a visible objective and a deliberate retry. Finish and inspect that loop before adding a shop, persistent inventory or another level.

Objective

Complete and inspect a delivery loop whose state is understandable before expanding its scope.

Before you start

The creation entry point is accessible on the account and device being used.
Save the intended first-version brief and a cut list of systems that are not part of the prototype.
Decide how the player will recognize the parcel, progress state and delivery exit.

Steps

Define the parcel states: waiting at its start, carried after pickup, delivered at completion.
Describe the gate, parcel and exit in the initial brief with feedback for pickup and delivery.
Inspect the empty-handed exit case before assuming the completion condition is correct.
Collect and deliver the parcel, then check that repeated contact does not create another completion.
Retry and verify that the parcel, player position and outcome all return to the intended start state.
Record the observed result and fix the smallest mismatch before considering a route or hazard extension.

Verification

The player can identify the parcel and intended destination from the opening view.
An empty-handed arrival at the exit does not count as a delivery.
Pickup changes the parcel's visible state and does not award repeated pickups from the same contact.
A valid delivery produces the intended completed state rather than merely changing a label.
Retry after completion restores the waiting parcel and clears the previous outcome.
If a failure hazard is included, retry after failure follows the same documented reset rules.

Limitations

This is a deliberately small editorial prototype plan, not a tested template or a promised generated result.
Attempt state is not the same as persistent account inventory; persistence remains outside this first version.
Local gameplay inspection is separate from account-specific Playtest-sharing status and publication requirements.

Working notes

Use a delivery-garden prototype as the project: move through a short garden, pick up a marked parcel and carry it to an exit. The parcel gives the player a reason to leave the start, and the exit gives the attempt an unmistakable finish. This is an editorial scope choice, not a claim that this theme is officially preferred.

Describe the attempt as states rather than a list of objects. At the start the parcel is waiting; after pickup it is carried; after delivery the attempt is complete. The visual feedback should agree with those states. A parcel that remains collectible after pickup or a completed attempt that still accepts another delivery is a useful defect to investigate.

Choose an explicit failure condition only if it helps test the loop. For example, contact with a clearly marked moving hazard can end the attempt. Keep the hazard separate from the objective so you can tell whether movement, pickup, delivery or recovery caused the failure.

A first project is ready for another design decision when you can describe what happens at the start, during progress, at an outcome and after retry. It need not contain every feature of a public game. The checks on this page are a proposed creator test plan, not results from a Roblox gameplay session.

Examples

First-version brief: Make a compact delivery garden. Start the player at a marked gate with a visible parcel and delivery exit. Picking up the parcel changes its state to carried and shows that progress clearly. Reaching the exit while carrying it completes the attempt. Reaching the exit without it should explain what is missing without completing the delivery. Retry restores the waiting parcel, clears completion and returns the player to the gate. Leave shops and persistent inventory out of this version.
Failure observation to record: the exit completed the attempt before the parcel was collected. The next revision should change the delivery condition, not redesign the garden. Ask for completion only while the parcel is carried, then test the empty-handed and carrying cases again.
Expansion decision after the loop works: introduce a route choice that still uses the same parcel and exit. Retest pickup and delivery before adding another collectible type, because that would add a different state-management problem.

Common questions

Does my first project need a shop or saved progress?: Neither is needed to inspect this collection-and-delivery loop. They introduce extra rules about balances, ownership or persistence. Decide on them later, after you know which part of the existing interaction needs to change.
When should I stop refining the first version?: Pause when the objective, progress feedback, completion and retry behave as intended in your recorded checks. Write the next design question before adding features. That stopping point is a prototype milestone, not publication or audience approval.