# Your first AI game: make it work on the second try

StudiCraft Journal editorial
Published: 2026-10-02
Canonical: https://blog.studicraft.com/articles/gamedev-restart-loop/

The bell rings. Your character made the last jump. For a moment, the game you imagined is a game you can actually play.

Then you press Restart. The timer keeps counting, the key is still missing, and the character slides off the starting platform before you touch anything.

If that sounds familiar, you've reached a useful milestone. You have enough of a game to discover what a fresh attempt really needs. Start here: build one short route with a clear finish, write down what resets, and make it survive a second run. This guide walks through that process using lessons from StudiCraft's scene loading and resource work.

## Give your first game one good minute

A big idea is a lovely place to begin and a difficult place to debug. “An open-world adventure with crafting, combat and vehicles” gives you dozens of systems to blame when the player gets stuck.

Shrink it to a moment you care about. Perhaps someone crosses three floating platforms and rings a bell. Perhaps they steer a car around one bend. Keep the part that makes you want to play, then build the smallest route that lets someone experience it.

For an AI assistant, a useful request could look like this:

> Build a short jumping course with a start platform, three reachable landings and a bell at the finish. The player can move and jump. Falling ends the attempt. Show a clear result and a Restart button. Restart returns to the start, clears movement, restores the course and resets the timer. Keep settings unchanged. Work in small steps and explain how I can check each one.

“One minute” is a scope choice, not a rule about attention. The point is to have something you can finish and inspect before asking for more. Save a working revision after movement, after the finish, and after restart. Those small saves give you somewhere useful to return when an ambitious change goes sideways.

![Native StudiCraft development view of Skybound Sprint, with floating platforms and a windmill.](/media/gamedev-restart-loop/v3-studicraft-20260917/project-capture.webp)

*Skybound Sprint, in a native development capture from the September review. The cover is an AI editorial illustration; this image records the actual scene.*

[Explore Skybound Sprint in the interactive view](#explore-scene). Look for a starting place, the next landing and a destination. The viewer lets you study the original world from different angles; completing a playable course is a separate test. You can also [compare the recorded scene views on 3DForge](https://3dforge.build/showcase/view/?entry=studicraft-game-atlas&scene=skybound-sprint).

## Let a new player understand the invitation

You know that the bell is the goal because you put it there. Someone arriving for the first time might think it is scenery.

Give them a simple invitation: “Reach the bell.” Put the first useful action within reach, show its control, and make the result of that action recognizable. If the player lands on a checkpoint, acknowledge it. If they finish, let the game say so before sending them anywhere else.

A short objective that can be checked again is helpful after an interruption, too. Microsoft's [objective-clarity guidance](https://learn.microsoft.com/en-us/xbox/accessibility/xbox-accessibility-guidelines/109) recommends making current goals and progress available for review. Players should not have to remember the one instruction they saw before a phone call.

Try handing over the first build with one sentence: “See whether you can reach the finish.” Watch what happens before explaining the route. A pause at the start might mean the controls are unclear. Wandering past the bell might mean the finish needs a stronger cue. Neither observation tells you to add another level.

## Decide what Restart promises

Imagine collecting a key, reaching a checkpoint and falling. You tap Restart. Do you expect the key to stay collected? Do you expect to return to the checkpoint or the beginning?

There isn't one right answer for every game. There does need to be a consistent answer for yours. Use different labels when you offer different actions: **Retry checkpoint** and **Restart course** make a clearer promise than two buttons that both say **Try again**.

Write a small reset sheet. Here is a starting point for the bell course:

| Part of the attempt | On Restart course | Check it by |
| --- | --- | --- |
| Player position and movement | Return to the start, with no carried momentum | Restarting during a fall |
| Timer and result | Clear both; start timing when play begins | Restarting after a win |
| Keys, switches and obstacles | Restore the course's starting state | Restarting after collecting the key |
| Checkpoint | Clear it for a full course restart | Restarting after reaching it |
| Settings and saved progress | Keep the choices intended to persist | Changing volume, then restarting |

The distinction is between **attempt state**, such as this run's timer, and **lasting choices**, such as a player's control settings. If your game deliberately carries progress between attempts, put that in the sheet. The assistant and the player should be working from the same rules.

Also decide what happens when Restart is pressed twice quickly. A reasonable prototype rule is to accept one restart, show that it is happening, and ignore extra presses until the next attempt is ready. Whatever you choose, a double tap should not create two players or two timers.

## Stop yesterday's loading from entering today's game

Some restart bugs are really timing bugs. The old attempt can still have work in progress after the player has moved on.

Picture this sequence:

1. Attempt A begins loading its character.
2. The player leaves and starts attempt B.
3. B becomes ready.
4. A's character finally arrives.

That last arrival must not insert a second character, clear B's loading screen or announce that an abandoned attempt is ready. Give each attempt an identity, then check that identity before attaching a completed result to the game.

StudiCraft's October 1 importer review makes this problem concrete. Its queued model work can cancel or reject abandoned work, but a model parse already in progress may still finish. Asking work to stop and preventing its late result from changing the game are both necessary concerns.

You can ask your assistant for a plain explanation before accepting the fix:

> Show me how the game knows which attempt owns a loading result. What happens if I leave during loading? What happens if the old result arrives after the next attempt starts? Add a check that reproduces that order.

Keep loading failure understandable as well. If a required character or route fails to load, show a useful message and a way to retry or leave. Starting a timed attempt with essential pieces missing makes the failure look like the player's mistake.

For testing, distinguish a **cold load**, where the required asset is not already cached, from a replay that can reuse it. An instant second load can hide the awkward first one.

## Make room for ordinary interruptions

A person playing your game may answer a message, switch apps or put the phone down with a thumb still on the screen. Try those things while the course is small enough to understand.

The browser's [Page Visibility API](https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API) reports when a page is hidden. Background tabs commonly have animation callbacks paused and timers throttled. Choose an explicit pause and resume policy instead of assuming that hidden time behaves like active play.

For a local practice course, you might pause when the page becomes hidden, clear held movement and show a Resume button on return. That gives the player a moment to find their place. Online or timed competitive games need rules suited to their own shared clock; copying this policy blindly would change the game.

Check touch cancellation as well as lifting a finger. A canceled gesture should not leave movement held. The [phone guide](/articles/gamedev-phone-camera/) shows how to check that alongside camera framing.

The useful question is simple: when the player comes back, can they understand where they are and deliberately continue?

## Turn “something feels wrong” into a fix

You don't need a large audience to find an obvious broken restart. You do need observations precise enough to act on. These are illustrative notes, not results from a StudiCraft player study:

| What someone says | What to look for | A focused next check |
| --- | --- | --- |
| “It threw me off straight away.” | Movement remains after restarting | Restart while holding a direction, then release |
| “I don't know where to go.” | The goal or next landing is unclear | Keep the route; change one cue |
| “The second try is different.” | A key, timer or enemy kept old state | Compare against the reset sheet |
| “It freezes sometimes.” | A pause near loading or a crowded view | Record the exact moment, device and build |

After a first attempt, ask “What did you think would happen?” and “What got in your way?” Leave room for an answer you didn't anticipate. If you coach every jump, you learn how well someone follows your directions, and much less about the game's own instructions.

Record one next change. Repeat the same steps after the fix, but remember that the same person now knows the route. A fresh player helps check whether an improved first impression is actually clearer.

When a project grows to a broader Steam test, Valve's [Steam Playtest documentation](https://partner.steamgames.com/doc/features/playtest) describes controlled access through a separate test app and recommends a clear way for players to submit feedback. The small habit is useful from day one: tell people what you want to learn and where their observations should go.

## If you're building the runtime, check asset ownership

Here is a less visible problem: two scenes share the same stone texture. You leave the first scene and its cleanup releases the texture while the second scene is still using it.

StudiCraft's October 2 resource work addresses that relationship with a shared ownership registry. It tracks owners of the same resource and releases it after the final owner lets go. The scoped tests support that behavior; they do not establish a whole-game memory budget or faster frame rates. The detailed receipt is in the review notes below.

The later source-admission review adds another useful rule: if a newly decoded model still exceeds the shared source limits after unused assets are reclaimed, reject that new source while preserving assets already in use. This is a limit on known source estimates, not every allocation on the device. For your game, include that failure in the loading design: a player should get a clear retry or exit choice when a required asset cannot be admitted.

In Three.js, removing an object from the scene does not automatically dispose its geometry, materials and textures. Its [cleanup guide](https://threejs.org/manual/pages/cleanup.html) explains explicit disposal. Before asking an assistant to “clean up everything on restart,” ask which assets are shared and which part of the application owns them.

Then repeat a scene transition. Look for disappearing surfaces, duplicate objects or resource counts that keep growing after settling. Those symptoms give you an investigation to pursue. A stable counter is evidence about that counter, rather than a complete account of browser memory.

## Leave yourself a game worth opening tomorrow

Before expanding the world, run one saved build through six situations: finish, fail, restart after each, leave during loading, and return after an interruption. Record the first repeatable problem with its steps and expected result.

The next improvement might be delightfully small: the bell is easier to spot, the player stops sliding, or Retry finally means the same thing every time. That's a solid place to add another stretch of world.

For the next prop or landing, our companion [3DForge asset workspace](https://3dforge.build/generator/#asset) can help you develop the piece. Keep its dimensions and recipe with the asset, then check its collision and behavior inside your game.

[Open the second-attempt playtest brief](/tools/?brief=gamedev-restart-loop) to record your next test, or [download the printable worksheet](/media/gamedev-restart-loop/v9-journal-brand-20261003/article-worksheet.svg?download). Start with the moment that broke. Get that moment working twice.

*Reviewed October 2, 2026. [Project evidence and research notes](/media/gamedev-restart-loop/v8-public-20261002/project-review.json?download) identify the dated observations, current sources and suggested exercises. The exercises are proposed methods, not completed player studies.*

## Sources

- [MDN: Page Visibility API](https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API): Visibility changes and background scheduling. The article proposes explicit pause and input-reset rules.
- [Three.js: Cleanup](https://threejs.org/manual/pages/cleanup.html): Removing a scene object does not automatically release its GPU resources; resource owners need explicit cleanup.
- [3DForge: Skybound Sprint scene comparison](https://3dforge.build/showcase/view/?entry=studicraft-game-atlas&scene=skybound-sprint): Original artwork beside two recorded reconstruction views. This public showcase is a separate snapshot from the dated development capture in the article.
- [3DForge: procedural asset generator](https://3dforge.build/generator/#asset): Companion asset-creation workspace. Exported geometry still needs collision and game logic in the target engine.
- [Microsoft: Objective clarity](https://learn.microsoft.com/en-us/xbox/accessibility/xbox-accessibility-guidelines/109): Guidance on making current goals and progress available for review. The bell course and player-observation examples are authored exercises.
- [Valve: Steam Playtest](https://partner.steamgames.com/doc/features/playtest): Controlled test access and explicit feedback collection. Mentioned as a later distribution option, not a requirement for the small prototype.