To vibe code a 30-second score attack game prototype, prompt for one scoring action, one escalating risk, one visible timer, and an instant restart. The short clock turns a loose AI game draft into a sharper test: can the loop create greed, panic, and one more try before the timer hits zero?
A lot of vibe-coded games feel playable for exactly one minute because novelty is doing unpaid labor. The character moves. Coins exist. Enemies drift around. Then the player realizes nothing is asking them to make a harder choice.
Put a clock on it. Thirty seconds is rude in the best way. It exposes whether scoring changes behavior or just increments a number in the corner.
This is a first-playable workflow piece for small browser games and AI-assisted drafts. MDN is cited for game-loop context, GDevelop for timer behavior, and itch.io for HTML5 browser-sharing context.

GDevelop
A no-code and low-code game builder with timer tools that are handy for score-attack prototypes.
PICO-8
A fantasy console whose tiny screen and strict limits make short arcade scoring loops easier to judge.
Phaser
A JavaScript framework for browser games when you want direct control over the loop, timer, collisions, and score state.
itch.io
A common place to upload and share HTML5 prototypes once the 30-second loop is ready for outside players.
Score Is a Behavior Test
Do not add a score because arcade games have scores. Add score because it tells you what the player values. If the highest score comes from the safest route, your prototype is training cowardice. If the only way to score is reckless but unreadable, it is training guessing.
A good score-attack prompt names the behavior you want to tempt. Stay near danger for bonus points. Grab coins that pull you off the safe line. Chain pickups before the multiplier decays. The number should pressure the hands, not decorate the HUD.
The score is useful only when it makes the player betray their safest plan.
Weak Prompt vs Score-Attack Prompt
| Prompt shape | Likely result | Sharper version |
|---|---|---|
| Make a dodge game with points | The player survives and score rises passively | Make a dodge game where points spawn beside hazards and expire after two seconds |
| Make a platformer with coins | A normal collection level with no urgency | Make a 30-second platformer where each coin raises the next coin value but also speeds up spikes |
| Make an arena shooter | Enemies appear, bullets fly, score feels automatic | Make an arena shooter where close-range hits score double and missed shots drain the multiplier |
| Make it harder over time | A difficulty ramp with no clear player choice | Increase risk only after the player scores, so greed creates the ramp |
Prompt the Timer as a Rule
The timer is not a UI request. It is the spine of the prototype. Ask for a visible 30-second countdown, a clear end screen, one-button restart, and a final score that appears instantly. If the game keeps going forever, the player can drift. If it ends quickly, every second has to earn its place.
You also need the timer to shape scoring. A coin in the first five seconds should not feel identical to a coin with three seconds left. Add a late bonus, a shrinking arena, a faster spawn rate, or a multiplier that gets mean near the end. The clock should change the decision, not just announce it.
Greed trail
Pickups spawn just off the safe path, forcing the player to choose between route discipline and extra points.
If pickups spawn randomly without readable pressure, the score feels like weather.
Risk ring
Standing close to danger charges a multiplier, then moving away lets the player cash out.
If the danger radius is invisible, players will call the scoring unfair.
Combo decay
Each score event refreshes a short combo window, so the player must decide when to chase and when to reset.
If the decay is too slow, it becomes passive. If it is too fast, it becomes noise.
Keep the Build Ugly Until the Score Hurts
You do not need final art for this. You need contrast. The player, danger, score item, timer, and exit state should all read from across the room. Browser-playable prototypes are perfect for this because the test is quick: send a link, say nothing, and watch whether the player chases a worse idea for a better score.
GDevelop is good when you want to wire this with visible events and timers. Phaser is good when you want exact control over update timing. PICO-8 is good when you want the screen to stay honest. The tool matters less than the discipline: no shop, no lore, no second level until the timer makes someone greedy.
- The timer is visible from the first frame of control.
- Scoring requires a choice, not passive survival.
- The safest route leaves points on the table.
- Risk escalates because the player scores, not only because time passes.
- The final screen shows score and offers instant restart.
- A tester changes their route on the second attempt.
Add one scoring modifier
Players understand the base score and start chasing better routes.
Testing depth without burying the loop.Add one enemy type
Players can predict the existing danger and need a new route problem.
Creating variety that changes movement.Add public sharing later
Players replay for a better number without being asked.
Turning a proven short loop into a challenge page.FAQ
How do I vibe code a 30-second score attack game prototype?
Prompt for one scoring action, one risk that escalates from scoring, a visible 30-second timer, an end screen, and instant restart. Then test whether players change routes to chase a better score.
Why use 30 seconds instead of a full level?
Thirty seconds cuts away filler. It shows whether the core scoring behavior creates urgency before the prototype hides behind content.
Should score-attack prototypes have upgrades?
Not at first. Add upgrades after the base score loop already makes players replay and take smarter risks.