SandboxSandbox use works best when each play, creation, or ownership task has its own proof, upkeep, and stopping point
Sandbox tasks span play sessions, creative work, publishing, and wallet-based ownership, but those uses do not need the same commitment. A session may finish when the intended Experience loads or records its expected state. A creation task can stop when a saved draft behaves correctly in Game Maker. Ownership requires a confirmed transaction and the expected asset at its destination. Repeat a task when its underlying state changes, not merely because another interval has passed.
Match each task to its required tools and proof
Playing, building, publishing, and owning require different tools. Begin with the output the job must produce. If an account record or saved draft shows completion, an on-chain action adds no useful proof. If the result involves SAND, LAND, or an NFT, the wallet and blockchain record become part of the job.
Playing for a specific outcome
A play task needs the account access and software required by the selected Experience. Some Experiences are free, while a creator may restrict particular access or gameplay through NFT ownership. The task ends when the intended session result appears in the relevant game or event record. A reward should count only when the applicable event rules provide one and the account satisfies their conditions.
Building and testing
A cryptocurrency wallet is not required to use the free creation tools. VoxEdit produces Assets, while Game Maker combines compatible Assets and logic into an Experience. Uploaded creator-owned Assets can enter the Game Maker library without becoming NFTs. Save and test again after changes affecting gameplay, asset behavior, or presentation. A stable draft, rather than a token transaction, supplies the useful result.
Ownership and wallet actions
A connected wallet becomes relevant when the intended outcome changes a blockchain holding, receives an eligible blockchain reward, or exercises a token-based right. The wallet address, selected asset, transaction status, and destination then matter together. An account screen may help identify the action, but it cannot replace the network record controlling ownership. Maintenance follows later transfers or intended uses rather than a preset daily routine.
What should prove a Sandbox job is complete?
Completion comes from the system responsible for the change. Game Maker should contain the saved draft, and a Gallery share should open the intended version. Experience Manager uses its required readiness states before launch. For a wallet action, the selected network must confirm the transaction and show the expected holding at the intended address. A button press alone proves only that a request began.
A bounded creation trial before a review deadline
All inputs in this example are hypothetical: an unpublished Experience, creator-owned Workspace Assets, no connected wallet, no LAND allocation, and a review deadline supplied by the recipient. The creator needs to deliver a playable draft before that deadline, without map placement or on-chain ownership.
Check the draft and Asset eligibility
The request is a Gallery-shareable build. Before sharing, the creator checks that Game Maker holds the intended save and every included Asset is either an owned NFT or the creator’s own published Workspace item. The second condition applies here, so the wallet-free route remains sufficient. The requested behavior also needs a successful test inside Game Maker.
Share the Experience and verify the Gallery version
The creator shares the current Experience to the Game Maker Gallery. Selecting Share does not show that the Gallery received the intended version. Gallery search must return the Experience, and opening it must load the intended draft with its requested behavior. The check must finish before the supplied deadline, which is the only timing requirement in this hypothetical case.
Stop after the recipient confirms the build
Work stops when the recipient can open the shared draft and observe the requested behavior. If Gallery presents an older build, the reader saves the intended version and shares it again. The result is a playable Gallery entry using the creator’s eligible Assets, without LAND allocation or a wallet transaction.
When does wallet-based ownership belong in the task?
Wallet-based ownership belongs when completion requires control of SAND, LAND, another NFT, or an eligible blockchain reward. The connected address must match the address meant to hold or authorize the item. A creator who only builds and tests with eligible Workspace Assets does not gain stronger proof by adding an unrelated wallet transaction.
Transaction approval is consequential because it can change a blockchain-controlled state. Check the asset, destination, selected network, and requested action before approval. After submission, keep the task open while the transaction remains pending or failed. Close it only after network confirmation and the expected receiving state agree. This distinction prevents an interface message from being mistaken for completed ownership.
Maintenance follows the record that can change
Retest the Experience after edits to its logic, Assets, or presentation. Game Maker’s Save command overwrites the previous save. Duplicate an Experience before a separate baseline is needed, because ordinary saving does not create version history. Run the relevant play test again after a meaningful change rather than repeating every test on a calendar.
Share the Experience again to update its Gallery build, name, or description. Launch readiness deserves another check when edits alter required Assets, page fields, access settings, or map placement. If neither the draft nor its publishing settings change, no new check is needed.
Wallet records need renewed attention after a transfer request, a failed transaction, or a changed intended use. Routine viewing does not improve the underlying ownership record. Likewise, an Experience location cannot change while the Experience remains launched and open. Moving it requires closure followed by another launch at the selected location, so relocation carries its own stop and restart boundary.
A stop point prevents use from becoming a standing commitment
Each route should end at the narrowest state satisfying the original job. Play can stop after the expected session state appears. Creation can stop at a stable local draft or a working Gallery share. Map publishing adds LAND, asset, and readiness requirements only when map placement is part of the intended outcome. A wallet task ends after confirmation and destination evidence agree.
An alternative becomes preferable when the current route demands a commitment the job does not need. Gallery sharing fits review and feedback without requiring LAND placement. Map launch fits an Experience meant to appear on LAND, while a wallet route fits ownership changes. For a share-only build, the clean endpoint is a working entry in the Game Maker Gallery.
Things people ask about Sandbox
How often should launch readiness be checked?
Launch readiness should be checked after a saved change affects the Experience, its Assets, mandatory page fields, access settings, or map location. The final check belongs immediately before launch because the Ready states must describe the version being released. A previous pass does not prove a later draft still meets the same requirements. This cadence follows meaningful changes rather than a fixed calendar.
Why can a newly shared Experience be hard to find in the Game Maker Gallery?
A newly shared Experience may not appear near the top because Gallery ordering follows its creation date, not the day it was shared. Use Gallery search to locate the title. If the result opens an older build or details, save the intended draft and share it again so the listing reflects the update. This separates a discovery issue from failed sharing.
Can a published Experience page be edited without a separate release?
Yes. Saving changes in the Experience Page Editor updates the published page immediately, so preview and check the change before selecting Save. This behavior concerns page content; it does not relaunch the playable Experience or move its LAND location. The saved page is the observable result, and there is no separate delayed page-release step.
What happens to the setup when a launched Experience is closed?
Closing a launched Experience makes it unavailable and unpublishes its landing page, but it does not erase the saved setup or configuration. The creator must launch it again before players can access it on the map. Closing is therefore a real availability stop, not a project-deletion action, and the retained setup supports a later return.
Is the former staking schedule still a valid recurring Sandbox task?
No. The staking pools closed, and staked SAND stopped generating yield after June 26, 2025, at 15:30 UTC. Staked SAND left in a pool remained withdrawable, but waiting longer did not create new staking rewards. A current upkeep plan should treat withdrawal and confirmation as the remaining task, not recurring reward collection.
Does removing an Experience from the Gallery delete its Workspace copy?
No. Remove from Gallery and Delete are separate Workspace actions. Removing the listing ends public Gallery availability while leaving the project available for further editing. Deletion addresses the Workspace copy itself, so the creator should confirm the selected menu action before proceeding. The visible proof of removal is the listing’s absence from Gallery search.