Round Survival Game Maker: build a readable round loop

Start by saying what players do while waiting, when the countdown begins, and who enters the arena. A short match needs an obvious transition from lobby to active round and a visible remaining-time cue. Decide whether a late arrival watches, joins, or waits for the next round. If those rules are missing, a dramatic disaster can still leave the player unsure whether the game has begun or whether their actions matter.

The Round Survival Game Maker template includes a bounded lobby-to-arena structure, a timer, disasters, elimination, survivor results, and a HUD. It is a starting point rather than a claim that every multiplayer situation already works. Use the prompt to describe the intended round length, the target number of players, and what a player should see after elimination. Review these decisions before building, because a timer value alone cannot define a fair or understandable round.

Describe how a disaster announces itself, where players can move, and whether there is any safe area. The first version can use the reference disaster set; a theme such as a toy city or storm island should support readable danger rather than obscure it. Ask for a cue before damage or elimination, then check that the cue is visible from the places players are likely to stand. The goal is a testable loop, not a promise that the difficulty is already balanced.

Write the win and loss conditions separately. A survivor reward belongs to players who are alive when the round actually resolves; eliminated players should not receive it by repeating a client-side action. The current template keeps outcome decisions server-owned, but real multiplayer consistency still needs testing. In plan review, look for the reward trigger, the eliminated-player state, the result display, and the transition into the next lobby wait.

After submitting a prompt here, the same Agent workspace handles sign-in, scope review, blueprint, and Build plan. A proposed change is not complete merely because it appears in chat. Confirm the round states, timing, disaster behavior, and player feedback that the plan actually supports. Ask a focused question during review if you are unsure whether a player can rejoin, how a tie is handled, or whether the round starts with one player.

When you approve a Build, download the versioned Draft and keep its ID. A later request can target a single issue: lengthen the lobby countdown, make a warning earlier, change the arena layout, or clarify the result HUD. A new Build should not silently overwrite the previous one. This workflow helps you compare the intended rule change and its evidence; it does not mean an arbitrary imported Roblox project can be edited through the same path.

Run the exact Draft in Roblox Studio. First verify a complete loop alone: lobby, countdown, arena, disaster, elimination or survival, result, then reset. Next test at least two players. Observe whether both see the same timer and disaster, whether an eliminated player stays out, and whether only eligible survivors receive the reward. Try joining during a round and disconnecting near the result to expose edge cases that a static report cannot prove.

Record failures against the Build ID and request a precise revision. Retest the new Build, because a prior multiplayer report does not automatically validate later code or layout changes. Actual performance, device controls, asset permissions, and publication still need separate checks. The page gets you to a reviewable survival prototype and a Studio file; it does not offer browser-hosted rounds or automatic Roblox publishing.