Roblox Build: correct code does not mean a fun game

Analysis of the October 8 official report. Expanded October 14, 2026.

The point that matters

A game can follow every instruction and still leave you with no reason to return. Roblox illustrates this with a Build-generated obby that scored 98/100 for engineering and 31/100 for design. Those scores describe that example, not every AI-created game.

How Roblox evaluates it

The report separates specification, static review, playtesting and presentation. Playtests check whether a game responds and can be completed; design examines depth, decisions and reasons to return. Combining everything into one score can conceal the problem worth fixing.

It works: but what do you choose?

Editorial recommendation: watch what players do between start and finish. In one hypothetical course, they may repeat the same jump; in another, they choose a safe route or a harder one with a different reward. Both can work technically, but the second offers a decision. You need not add options every few steps: one clear choice beats several buttons without consequences.

Progression with a purpose

Think of a skill players learn and can use later. Introduce a moving platform in a safe area, combine it with an obstacle afterward, then offer an optional route for players who have mastered the movement. Difficulty then builds on learning. Simply increasing jump distances can produce more failures without making the experience more interesting.

A reason to replay

Editorial recommendation: write down what changes on the next run before adding rewards. It might be improving a personal time, finding an alternative route or solving a different challenge. A coin at the finish helps only if spending it changes a decision or unlocks something useful. If the prize is the only reason to continue, review the course supporting it first.

Ask AI for something you can check

A prompt such as “make a fun obby” leaves too many decisions unexplained. Try a concrete request: “Create two routes visible from the start, one easy and one demanding. Allow switching before the first checkpoint and preserve that checkpoint after a fall.” Turn each sentence into a test. Are both routes visible? Does switching work? Do you respawn correctly? This checks implementation; deciding whether the choice interests people still requires observing players.

Technical testing and experience testing

1. Check functionality: join, move, clear an obstacle, fail, respawn and finish.
2. Observe decisions: where players hesitate, which route they choose and whether they understand consequences without your explanation.
3. Check mobile: whether controls leave the next jump visible and text remains readable during action.
4. Ask about a second run: what they would try again and what they would change. Avoid suggesting the answer.

Improve one thing, then observe again

If nobody understands the fork, improve its signposting before building more routes. If a fall requires excessive repetition, review the checkpoint before adding another reward. If the course is understandable but monotonous, introduce a variation and observe its effect. These are editorial design examples, not retention promises.

What to take into your project

Keep two questions separate: does it work as designed? and does it offer something players want to do? The first finds bugs; the second guides improvements. AI can help build and review, but finishing the code does not by itself resolve the experience.