create

Create and upload a game

Already have a browser build? Upload it here. Starting from an idea? The tutorials below give you a finishable scope, a strong AI prompt, and a test checklist.

CLI publish Upload rules

You need an account first. Sign in or join free.

You need an account to upload. Create one or sign in.

TitleDescription

AI toolCategory

Platform featuresCloud saves
Sync player progress across devices.Multiplayer

Game-making tutorials

Pick a small game you can finish. Each tutorial gives you the scope, build order, quality checks, and a prompt you can hand to a coding agent. Change the theme if you want; keep the mechanical limits until the first version is fun.

Choose a loop

Start with one tutorial. Resist combining three game ideas before the first one works.

Copy and adapt

Paste the prompt into a coding agent. Change the name, theme, and characters without deleting the test rules.

Play, then upload

Test the whole loop yourself. Use the improvement prompt for rough spots and the packaging prompt when it is ready.

tutorial 01 · 60-second score chase

One-button arcade game

The best first project. One action, one obvious danger, and a score worth chasing. Think jump, flap, dash, or switch lanes.

Starter1-2 hours

build it in this order

1
Choose one verb
Pick jump, flap, dash, or lane-switch. The same input should work with Space, click, and tap.
2
Build the fair version
Start slow, show hazards early, and leave enough room to react. Speed should rise gradually instead of spiking at random.
3
Add the reason to replay
Track score and best score. Reward close calls or clean streaks, then restart in one click when the run ends.
4
Polish the hit
Use a tiny freeze, sound, and visible impact when the player scores or crashes. Keep particles short and capped.

check before moving on

A new player understands the control in five seconds
The first obstacle is safe enough to learn from
A full run takes about 45-90 seconds
Restart works without reloading the page

Open the ready-to-copy build prompt

Change the title and theme if you like. Keep the scope, fairness, accessibility, and verification sections for the first build.

Build a polished one-button browser arcade game for Slop Farm.

## Game idea
Create a game called "Barnstorm Bounce." The player controls a tiny spring-loaded pig crossing a farm at sunset. Space, click, or tap makes the pig bounce. The pig automatically moves forward.

## Main loop
- Runs last about 60 seconds, but skilled players can continue longer.
- The player dodges fences, mud puddles, and low hay carts.
- Passing a hazard earns one point. A close pass fills a short combo meter.
- Speed increases gently every 15 points. Never create an unavoidable obstacle pattern.
- One collision ends the run. Show score, best score, and a large instant-restart button.

## Feel
- Use crisp original pixel-style shapes drawn with canvas or CSS. No external art.
- Make the jump readable: squash before takeoff, a clean arc, a small landing puff, and a brief impact pause on failure.
- Add lightweight generated sound with Web Audio, plus a mute control.
- Use a warm farm palette with strong contrast between the pig, ground, and hazards.

## Controls and layout
- Space, click, and tap all trigger the same bounce.
- Prevent accidental double input while airborne.
- Scale to phone and desktop screens. Keep the game centered with no browser-page scrolling.
- Show the control on the start screen, then get out of the way.

## Slop Farm build rules
- Deliver a complete small game, not a scaffold, mockup, or design document.
- It must be a static browser build with index.html at the project root.
- Use relative local paths. Do not require a custom backend, database credential, API key, package install, or arbitrary internet service.
- Do not load scripts, fonts, images, or audio from a CDN. Generate simple art and sound in code when practical.
- Support keyboard and pointer controls. Add touch controls when the game needs more than one action.
- Include a clear start state, short instructions, pause, mute, restart, win/lose feedback, and a way to play again.
- Fit phones and desktop browsers without page scrolling during play. Keep important text readable at 390px wide.
- Respect prefers-reduced-motion. Do not use flashing effects or rely on color alone to explain danger or success.
- Keep game state bounded: cap particles and enemies, clamp frame time, clean up removed objects, and avoid console errors.
- For local-only progress, save harmless settings or high scores in localStorage and keep working if storage is unavailable.
- If the project declares Slop Farm cloud saves or multiplayer, load only https://slopfarm.games/sdk/slopfarm.js and use its documented API. Never embed Supabase credentials or call platform tables directly.

## Finish the job
1. Build every required file.
2. Run the game in a browser and play through the main loop several times.
3. Fix broken controls, impossible states, console errors, layout overflow, and unclear feedback.
4. List the final files and give exact local test instructions.
5. End with a short manual test checklist and name the folder I should compress for upload.

Do not stop after explaining the code. Create the working game.

tutorial 02 · Handmade logic levels

Grid puzzle

A good choice when you care more about rules than reflexes. Keep the board small, make moves reversible, and teach one idea at a time.

Starter2-4 hours

build it in this order

1
Write the rule in one sentence
Example: push every crate onto a marked tile. If the rule needs a paragraph, the first version is too large.
2
Make three teaching levels
Level one teaches movement, level two introduces the obstacle, and level three asks the player to combine both ideas.
3
Protect the player from dead ends
Add undo and restart. If a move creates an obvious unwinnable state, explain it instead of silently trapping the player.
4
Then add depth
Introduce one new tile or rule at a time. Ten sharp levels beat fifty generated rooms that all feel the same.

check before moving on

Every level has been solved from a fresh start
Undo restores the exact previous state
The selected tile is visible without color alone
Movement works with keys, taps, and on-screen buttons

Open the ready-to-copy build prompt

Change the title and theme if you like. Keep the scope, fairness, accessibility, and verification sections for the first build.

Build a complete grid puzzle game for Slop Farm called "Moonlit Turnips."

## Rule
Move a rabbit around a 7x7 garden and push every glowing turnip into a moonbeam. The rabbit can push one turnip at a time but cannot pull it. Rocks block movement.

## Levels
- Include 12 handmade levels stored as readable data, not random generation.
- Levels 1-3 teach movement and pushing.
- Levels 4-7 introduce corners, narrow paths, and planning order.
- Levels 8-12 combine those ideas without requiring blind guesses.
- Verify every level is solvable. Include a small development-only solver or validation function if useful, but keep it out of normal play.

## Player tools
- Arrow keys or WASD move. Tapping an adjacent cell moves on touch screens.
- Add undo, restart level, level select, and a move counter.
- Persist unlocked levels locally, but do not block play if localStorage fails.
- Clearly mark the rabbit, turnips, goals, walls, and selected direction with shapes as well as color.

## Presentation
- Use a quiet night-garden look built with CSS or canvas shapes.
- Keep animation quick. A move should never make the player wait.
- Celebrate a solved board briefly, then offer Next level and Replay.

## Slop Farm build rules
- Deliver a complete small game, not a scaffold, mockup, or design document.
- It must be a static browser build with index.html at the project root.
- Use relative local paths. Do not require a custom backend, database credential, API key, package install, or arbitrary internet service.
- Do not load scripts, fonts, images, or audio from a CDN. Generate simple art and sound in code when practical.
- Support keyboard and pointer controls. Add touch controls when the game needs more than one action.
- Include a clear start state, short instructions, pause, mute, restart, win/lose feedback, and a way to play again.
- Fit phones and desktop browsers without page scrolling during play. Keep important text readable at 390px wide.
- Respect prefers-reduced-motion. Do not use flashing effects or rely on color alone to explain danger or success.
- Keep game state bounded: cap particles and enemies, clamp frame time, clean up removed objects, and avoid console errors.
- For local-only progress, save harmless settings or high scores in localStorage and keep working if storage is unavailable.
- If the project declares Slop Farm cloud saves or multiplayer, load only https://slopfarm.games/sdk/slopfarm.js and use its documented API. Never embed Supabase credentials or call platform tables directly.

## Finish the job
1. Build every required file.
2. Run the game in a browser and play through the main loop several times.
3. Fix broken controls, impossible states, console errors, layout overflow, and unclear feedback.
4. List the final files and give exact local test instructions.
5. End with a short manual test checklist and name the folder I should compress for upload.

Do not stop after explaining the code. Create the working game.

tutorial 03 · Three-minute action run

Arena survival

A compact action game with movement, enemy waves, and meaningful upgrades. Scope is the enemy here, so cap the run at three minutes.

Intermediate4-8 hours

build it in this order

1
Make movement feel good first
Tune acceleration, speed, collision, and the arena edge before adding enemies. Bad movement poisons everything built on top of it.
2
Use two enemy behaviors
One enemy chases. One predicts or blocks. Clear silhouettes matter more than a long roster.
3
Offer real upgrade choices
Every 30 seconds, pause and offer two upgrades that change how the player acts. Avoid tiny percentage bumps nobody can feel.
4
Control the chaos
Cap active enemies and effects. Telegraph damage, grant a short recovery window after a hit, and never spawn on top of the player.

check before moving on

The player can survive the first 30 seconds without guessing
Every damaging object is readable before it hits
Enemy and particle counts have hard caps
Touch controls do not cover the player or upgrade choices

Open the ready-to-copy build prompt

Change the title and theme if you like. Keep the scope, fairness, accessibility, and verification sections for the first build.

Build a finished three-minute arena survival game for Slop Farm called "Static Garden."

## Premise
The player is a small repair robot protecting the last green patch in a field of broken machines. Survive for three minutes while an automatic tool fires at the nearest threat.

## Core systems
- Move with WASD or arrow keys. Add a responsive touch joystick for phones.
- Two enemy types: slow scrap crawlers that chase and quick signal drones that stop briefly before charging.
- Enemies drop bolts. Collecting bolts fills an upgrade meter.
- Every 30 seconds, pause safely and offer two large upgrade cards.
- Include six upgrades with visible effects, such as orbiting shears, a chain zap, a wider pickup magnet, a short dash, a repair pulse, and a slowing seed trail.
- The player has three health points and a one-second invulnerability window after damage.
- Win at 3:00. Show final bolts, enemies cleared, chosen upgrades, and a replay button.

## Fairness and performance
- Telegraph drone charges and every source of damage.
- Spawn outside a safe radius and never directly on the player.
- Cap enemies at 60 and particles at 120. Reuse objects or remove them promptly.
- Clamp large frame deltas so switching tabs cannot break the simulation.

## Art and sound
- Draw an original chunky pixel garden and readable machine silhouettes in canvas.
- Use restrained screen shake and generated Web Audio sounds. Include mute and reduced-motion behavior.

Do not stop after explaining the code. Create the working game.

tutorial 04 · Small board, visible odds

Turn-based tactics

The player should lose because of a decision, not because the rules were hidden. Use a tiny squad and show exactly what enemies will do next.

Intermediate4-8 hours

build it in this order

1
Keep the board legible
Use an 8x8 board and three friendly units at most. Highlight movement, attack range, cover, and the currently selected unit.
2
Telegraph the enemy turn
Show each enemy's intended target and action before the player commits. Prediction creates strategy without a wall of rules.
3
Make units distinct
Give each unit one job and one signature ability. More stats are not a substitute for a clear role.
4
Test the losing path
Make sure the player can recover from a mistake, understand defeat, and restart without sitting through an intro again.

check before moving on

Legal destinations and targets are obvious before clicking
Enemy intent updates after every player action
No turn can hang when a unit dies or has no legal move
The tutorial battle can be won without lucky damage rolls

Open the ready-to-copy build prompt

Change the title and theme if you like. Keep the scope, fairness, accessibility, and verification sections for the first build.

Build a compact turn-based tactics game for Slop Farm called "Fence Line."

## Scenario
Three farm animals defend a gate from waves of junkyard pests on an 8x8 board. Win by surviving six rounds or clearing every enemy. Lose if the gate reaches zero health.

## Friendly units
- Ram: short movement, pushes an adjacent enemy one tile.
- Hen: long movement, throws a seed at range, low health.
- Dog: medium movement, marks one enemy so it takes extra damage this round.

## Tactics rules
- Each unit can move once and use one action per round, in either order.
- Clicking a unit shows legal movement. Clicking an ability shows valid targets and a plain-language preview of the result.
- Enemies display their next target, path, and expected damage before the player ends the round.
- Keep damage deterministic. No hidden accuracy rolls.
- Add simple cover tiles, hazards that change by round, undo before End turn, and a restart button.

## Battles
- Include a short guided first battle and two harder scenarios.
- Store scenarios as readable data so more can be added later.
- The AI should choose legal actions quickly, prefer its stated target, and never hang if a path is blocked.

## Interface
- Work with mouse, touch, and keyboard focus.
- Keep the board visible beside or above the unit panel at 390px wide.
- Use symbols and text for health, actions, targets, and enemy intent.

Do not stop after explaining the code. Create the working game.

tutorial 05 · Ten-minute branching tale

Choice-driven story

No giant script required. Build one strong situation, let earlier choices change later scenes, and give the player endings that feel earned.

Starter2-4 hours

build it in this order

1
Start with a decision under pressure
Open inside the problem. Skip the lore dump and ask the player to do something that reveals who they want to be.
2
Track a few meaningful facts
Use two relationships and one practical resource. Refer back to choices in later scenes instead of branching into dozens of disconnected pages.
3
Make choices say what they mean
Buttons should describe the action, not vague moods. If a choice has a cost the character would know, tell the player.
4
Earn the endings
Write three distinct outcomes based on the tracked facts. Let the ending recap specific decisions without grading the player as good or bad.

check before moving on

The first choice appears within 30 seconds
At least three early choices change later text or options
Back, restart, and text-size controls work
All endings are reachable and no scene points to a missing id

Open the ready-to-copy build prompt

Change the title and theme if you like. Keep the scope, fairness, accessibility, and verification sections for the first build.

Build a complete choice-driven browser story for Slop Farm called "Last Bus to Bramble."

## Setup
The player is driving the final bus out of a flooded valley. There are four stops left, room for only two more passengers, and a storm closing the road. The story should take 8-12 minutes.

## Story design
- Open on the first flooded stop with a decision in the first 30 seconds.
- Track fuel, time, and trust with two recurring passengers.
- Write 10-12 short scenes and three distinct endings.
- At least three early choices must change later dialogue, available options, or who helps at the final roadblock.
- Avoid fake choices. If two choices lead to the same scene, change meaningful state or acknowledge the difference in the writing.
- Choice labels should state the action plainly. Show known costs such as "Use 10 minutes to wait" before selection.

## Interface
- Present one readable scene at a time with 2-4 large choice buttons.
- Support keyboard selection, touch, text-size controls, mute, back one choice, restart, and reduced motion.
- Include a simple route map that updates after each stop.
- Use original CSS illustration and subtle generated ambience. Do not fetch images, fonts, or audio.

## Writing
- Keep paragraphs short and concrete. Give each recurring character a distinct way of speaking.
- No lore prologue, chosen-one plot, morality meter, or ending labeled "good" or "bad."
- Proofread every branch and validate that every scene id and ending is reachable.

Do not stop after explaining the code. Create the working game.

already have a prototype?

Make the game better without making it bigger

This prompt tells an agent to play what exists, fix the largest problems first, and verify the result. It explicitly pushes back on the usual rewrite-and-add-features spiral.

game improvement prompt

Diagnose, tighten, and test an existing game

Add two short notes at the bottom: what already feels right and what bothers you. Leaving the second note blank is fine.

Act as a practical game designer and browser-game engineer. Improve the game in this project without replacing its identity or expanding it into a much larger game.

## First, inspect what is really here
1. Run the game and play the main loop long enough to understand the controls, goal, failure state, and restart flow.
2. Read the source and identify the actual entry file, rendering approach, state flow, and asset dependencies.
3. Write a short diagnosis with the five biggest problems, ordered by how much they hurt the player. Be specific. "Needs polish" is not a diagnosis.

## Then improve it
- Fix broken controls, console errors, impossible states, collision mistakes, page scrolling, and unreliable restart behavior first.
- Make the first 15 seconds understandable without a paragraph of instructions.
- Tighten the main loop. Remove waiting, unclear feedback, and features that do not support the central mechanic.
- Improve game feel with a small number of useful touches: readable anticipation, impact feedback, sound, animation, score response, or a short recovery window after damage.
- Check difficulty from a fresh player's point of view. The opening should teach; later play should ask for mastery.
- Make text, controls, and important game state readable on a 390px-wide phone and a desktop screen.
- Add keyboard and pointer support. Add touch controls when the game needs directional input.
- Add pause, mute, restart, win/lose feedback, and a clear way to play again if any are missing.
- Respect reduced motion and do not rely on color alone for meaning.
- Keep the game static and self-contained. No backend, account, API key, CDN, or remote asset dependency.
- Keep index.html at the project root and use relative local paths.

## Keep scope under control
Do not rewrite a working game from scratch. Do not add a shop, login, multiplayer, procedural story system, giant settings screen, or unrelated meta progression. Prefer ten well-chosen fixes over a pile of new features.

## Verify before stopping
1. Play several complete runs, including a loss, restart, pause/resume, mute/unmute, and a win when the game has one.
2. Test keyboard, pointer, touch-sized controls, and a 390px viewport.
3. Check the browser console and network panel. Fix errors and unexpected external requests.
4. Report what changed, what you tested, and any limitation that remains.

Here is what I want to preserve about the game:
[DESCRIBE THE PARTS THAT ALREADY FEEL RIGHT]

Here is what currently bothers me:
[DESCRIBE PROBLEMS OR LEAVE BLANK FOR THE AGENT TO DIAGNOSE]

stack notes

Get the right folder out of your tools

The game tutorials cover design. These notes cover the less glamorous part: finding the actual browser build and keeping its files together.

Pure canvas / vanilla JS

One HTML file plus a few scripts and assets. Great for arcade, puzzle, and tiny experiments.

Put index.html at the root of the folder you compress
Load scripts and assets with relative paths (./game.js, ./assets/…)
Avoid fetch() to other domains unless you know CORS is fine
Test by opening index.html locally in Chrome before uploading

Built with an AI chat (Claude, ChatGPT, Grok…)

Ask the model for a self-contained web game, then package the files it gives you.

Tell it: static only, no backend, works offline from a folder
Ask for index.html plus separate .js / .css if the game is more than a page
If it gives you one giant HTML file, that's fine. Still name it index.html
Use the packaging prompt below so the model zips it correctly for Slop Farm

Phaser / Pixi / Three.js

Export or copy the dist (or public) build that opens in a browser without a custom server.

Upload the built output folder, not the whole monorepo
index.html must reference bundled assets with relative URLs
Skip node_modules. Only ship what the browser needs to run
If you use a bundler, run the production build first

Godot web export

Export as HTML5 / Web, then compress the export folder that contains index.html and the .wasm / .pck files.

Project → Export → Web; enable the export templates you need
Keep the whole export folder together (don't pick only index.html)
Threads / SharedArrayBuffer builds can be finicky in an iframe. Prefer a simple web export when you can
Stay under the size limit; strip debug symbols if the export is huge

Unity WebGL

Build WebGL, then zip the Build folder's parent so index.html sits at a known entry path.

WebGL build template should produce index.html at the root of the build
Include Build/, TemplateData/ (if present), and index.html together
Compression formats matter. Gzip/brotli must match how Unity wrote the files
WebGL builds are large; trim assets or use a smaller scene if you're near the cap

Anything else that runs offline

If double-clicking (or serving the folder) plays in Chrome without a game server, you're good.

Start page: index.html, game.html, or play.html
No custom multiplayer server required for the public catalog
Prefer relative paths over absolute file:// or localhost URLs
Compress the folder that contains the start page, not a parent of random projects

upload packaging prompt

Build and verify the folder you will upload

Use this after the game works. It tells an agent to find the real build, fix paths, remove junk, test the final folder, and stay under 50 MB / 500 files.

Prepare the browser game in this project for a Slop Farm upload. Inspect and fix the real files; do not only write instructions.

## Upload contract
- Static browser games only: HTML, CSS, JavaScript, canvas, WebGL, Godot Web, Unity WebGL, Phaser, Pixi, or similar
- No backend, custom game server, login, API key, install step, or required internet connection
- index.html should be at the root of the folder I will compress (game.html, play.html, or main.html are accepted only when the project already relies on one)
- All scripts, images, audio, data, fonts, and wasm must load through safe relative paths
- Stay below 50 MB and 500 files
- Do not include node_modules, source maps, secrets, unrelated project files, caches, or absolute localhost paths

## Work in this order
1. Find the actual source project, build command, output folder, and browser entry file. Do not guess when the repository answers the question.
2. Run the existing production build if one exists. Do not introduce a new framework or replace a working build system.
3. Create a clean upload folder such as:

   my-game/
     index.html
     game.js
     style.css
     assets/

4. Fix packaging problems in the output:
   - Rewrite absolute or root-relative asset paths so they work from the uploaded folder
   - Bundle required local dependencies and assets
   - Remove calls to localhost and development-only services
   - Keep filenames and letter casing consistent
   - Preserve wasm and engine data files needed by Godot or Unity
5. Serve the upload folder with a simple local static server and play the game. Check the console and network panel. Fix missing files, MIME problems, blocked requests, overflow, and broken controls.
6. Inspect the final folder for secrets, source maps, node_modules, symlinks, unrelated files, and size bloat. Remove anything the browser does not need.

## Final answer
- Name the exact folder I should compress, and make sure index.html is at that folder's root
- Show the final file tree and total size
- Give the exact command or steps to test it locally
- List what you changed and any external dependency that still remains
- Suggest a plain title, a one- or two-sentence description, one category, the AI tool used, and 3-5 honest tags for the upload form
- If something cannot work as a static browser game, say exactly why and propose the smallest static alternative

My game / project notes:
[PASTE DESCRIPTION, FILE LIST, OR CODE HERE]

Build a polished one-button browser arcade game for Slop Farm. ## Game idea Create a game called "Barnstorm Bounce." The player controls a tiny spring-loaded pig crossing a farm at sunset. Space, click, or tap makes the pig bounce. The pig automatically moves forward. ## Main loop - Runs last about 60 seconds, but skilled players can continue longer. - The player dodges fences, mud puddles, and low hay carts. - Passing a hazard earns one point. A close pass fills a short combo meter. - Speed increases gently every 15 points. Never create an unavoidable obstacle pattern. - One collision ends the run. Show score, best score, and a large instant-restart button. ## Feel - Use crisp original pixel-style shapes drawn with canvas or CSS. No external art. - Make the jump readable: squash before takeoff, a clean arc, a small landing puff, and a brief impact pause on failure. - Add lightweight generated sound with Web Audio, plus a mute control. - Use a warm farm palette with strong contrast between the pig, ground, and hazards. ## Controls and layout - Space, click, and tap all trigger the same bounce. - Prevent accidental double input while airborne. - Scale to phone and desktop screens. Keep the game centered with no browser-page scrolling. - Show the control on the start screen, then get out of the way. ## Slop Farm build rules - Deliver a complete small game, not a scaffold, mockup, or design document. - It must be a static browser build with index.html at the project root. - Use relative local paths. Do not require a custom backend, database credential, API key, package install, or arbitrary internet service. - Do not load scripts, fonts, images, or audio from a CDN. Generate simple art and sound in code when practical. - Support keyboard and pointer controls. Add touch controls when the game needs more than one action. - Include a clear start state, short instructions, pause, mute, restart, win/lose feedback, and a way to play again. - Fit phones and desktop browsers without page scrolling during play. Keep important text readable at 390px wide. - Respect prefers-reduced-motion. Do not use flashing effects or rely on color alone to explain danger or success. - Keep game state bounded: cap particles and enemies, clamp frame time, clean up removed objects, and avoid console errors. - For local-only progress, save harmless settings or high scores in localStorage and keep working if storage is unavailable. - If the project declares Slop Farm cloud saves or multiplayer, load only https://slopfarm.games/sdk/slopfarm.js and use its documented API. Never embed Supabase credentials or call platform tables directly. ## Finish the job 1. Build every required file. 2. Run the game in a browser and play through the main loop several times. 3. Fix broken controls, impossible states, console errors, layout overflow, and unclear feedback. 4. List the final files and give exact local test instructions. 5. End with a short manual test checklist and name the folder I should compress for upload. Do not stop after explaining the code. Create the working game.

Build a complete grid puzzle game for Slop Farm called "Moonlit Turnips." ## Rule Move a rabbit around a 7x7 garden and push every glowing turnip into a moonbeam. The rabbit can push one turnip at a time but cannot pull it. Rocks block movement. ## Levels - Include 12 handmade levels stored as readable data, not random generation. - Levels 1-3 teach movement and pushing. - Levels 4-7 introduce corners, narrow paths, and planning order. - Levels 8-12 combine those ideas without requiring blind guesses. - Verify every level is solvable. Include a small development-only solver or validation function if useful, but keep it out of normal play. ## Player tools - Arrow keys or WASD move. Tapping an adjacent cell moves on touch screens. - Add undo, restart level, level select, and a move counter. - Persist unlocked levels locally, but do not block play if localStorage fails. - Clearly mark the rabbit, turnips, goals, walls, and selected direction with shapes as well as color. ## Presentation - Use a quiet night-garden look built with CSS or canvas shapes. - Keep animation quick. A move should never make the player wait. - Celebrate a solved board briefly, then offer Next level and Replay. ## Slop Farm build rules - Deliver a complete small game, not a scaffold, mockup, or design document. - It must be a static browser build with index.html at the project root. - Use relative local paths. Do not require a custom backend, database credential, API key, package install, or arbitrary internet service. - Do not load scripts, fonts, images, or audio from a CDN. Generate simple art and sound in code when practical. - Support keyboard and pointer controls. Add touch controls when the game needs more than one action. - Include a clear start state, short instructions, pause, mute, restart, win/lose feedback, and a way to play again. - Fit phones and desktop browsers without page scrolling during play. Keep important text readable at 390px wide. - Respect prefers-reduced-motion. Do not use flashing effects or rely on color alone to explain danger or success. - Keep game state bounded: cap particles and enemies, clamp frame time, clean up removed objects, and avoid console errors. - For local-only progress, save harmless settings or high scores in localStorage and keep working if storage is unavailable. - If the project declares Slop Farm cloud saves or multiplayer, load only https://slopfarm.games/sdk/slopfarm.js and use its documented API. Never embed Supabase credentials or call platform tables directly. ## Finish the job 1. Build every required file. 2. Run the game in a browser and play through the main loop several times. 3. Fix broken controls, impossible states, console errors, layout overflow, and unclear feedback. 4. List the final files and give exact local test instructions. 5. End with a short manual test checklist and name the folder I should compress for upload. Do not stop after explaining the code. Create the working game.

Build a finished three-minute arena survival game for Slop Farm called "Static Garden." ## Premise The player is a small repair robot protecting the last green patch in a field of broken machines. Survive for three minutes while an automatic tool fires at the nearest threat. ## Core systems - Move with WASD or arrow keys. Add a responsive touch joystick for phones. - Two enemy types: slow scrap crawlers that chase and quick signal drones that stop briefly before charging. - Enemies drop bolts. Collecting bolts fills an upgrade meter. - Every 30 seconds, pause safely and offer two large upgrade cards. - Include six upgrades with visible effects, such as orbiting shears, a chain zap, a wider pickup magnet, a short dash, a repair pulse, and a slowing seed trail. - The player has three health points and a one-second invulnerability window after damage. - Win at 3:00. Show final bolts, enemies cleared, chosen upgrades, and a replay button. ## Fairness and performance - Telegraph drone charges and every source of damage. - Spawn outside a safe radius and never directly on the player. - Cap enemies at 60 and particles at 120. Reuse objects or remove them promptly. - Clamp large frame deltas so switching tabs cannot break the simulation. ## Art and sound - Draw an original chunky pixel garden and readable machine silhouettes in canvas. - Use restrained screen shake and generated Web Audio sounds. Include mute and reduced-motion behavior. ## Slop Farm build rules - Deliver a complete small game, not a scaffold, mockup, or design document. - It must be a static browser build with index.html at the project root. - Use relative local paths. Do not require a custom backend, database credential, API key, package install, or arbitrary internet service. - Do not load scripts, fonts, images, or audio from a CDN. Generate simple art and sound in code when practical. - Support keyboard and pointer controls. Add touch controls when the game needs more than one action. - Include a clear start state, short instructions, pause, mute, restart, win/lose feedback, and a way to play again. - Fit phones and desktop browsers without page scrolling during play. Keep important text readable at 390px wide. - Respect prefers-reduced-motion. Do not use flashing effects or rely on color alone to explain danger or success. - Keep game state bounded: cap particles and enemies, clamp frame time, clean up removed objects, and avoid console errors. - For local-only progress, save harmless settings or high scores in localStorage and keep working if storage is unavailable. - If the project declares Slop Farm cloud saves or multiplayer, load only https://slopfarm.games/sdk/slopfarm.js and use its documented API. Never embed Supabase credentials or call platform tables directly. ## Finish the job 1. Build every required file. 2. Run the game in a browser and play through the main loop several times. 3. Fix broken controls, impossible states, console errors, layout overflow, and unclear feedback. 4. List the final files and give exact local test instructions. 5. End with a short manual test checklist and name the folder I should compress for upload. Do not stop after explaining the code. Create the working game.

Build a compact turn-based tactics game for Slop Farm called "Fence Line." ## Scenario Three farm animals defend a gate from waves of junkyard pests on an 8x8 board. Win by surviving six rounds or clearing every enemy. Lose if the gate reaches zero health. ## Friendly units - Ram: short movement, pushes an adjacent enemy one tile. - Hen: long movement, throws a seed at range, low health. - Dog: medium movement, marks one enemy so it takes extra damage this round. ## Tactics rules - Each unit can move once and use one action per round, in either order. - Clicking a unit shows legal movement. Clicking an ability shows valid targets and a plain-language preview of the result. - Enemies display their next target, path, and expected damage before the player ends the round. - Keep damage deterministic. No hidden accuracy rolls. - Add simple cover tiles, hazards that change by round, undo before End turn, and a restart button. ## Battles - Include a short guided first battle and two harder scenarios. - Store scenarios as readable data so more can be added later. - The AI should choose legal actions quickly, prefer its stated target, and never hang if a path is blocked. ## Interface - Work with mouse, touch, and keyboard focus. - Keep the board visible beside or above the unit panel at 390px wide. - Use symbols and text for health, actions, targets, and enemy intent. ## Slop Farm build rules - Deliver a complete small game, not a scaffold, mockup, or design document. - It must be a static browser build with index.html at the project root. - Use relative local paths. Do not require a custom backend, database credential, API key, package install, or arbitrary internet service. - Do not load scripts, fonts, images, or audio from a CDN. Generate simple art and sound in code when practical. - Support keyboard and pointer controls. Add touch controls when the game needs more than one action. - Include a clear start state, short instructions, pause, mute, restart, win/lose feedback, and a way to play again. - Fit phones and desktop browsers without page scrolling during play. Keep important text readable at 390px wide. - Respect prefers-reduced-motion. Do not use flashing effects or rely on color alone to explain danger or success. - Keep game state bounded: cap particles and enemies, clamp frame time, clean up removed objects, and avoid console errors. - For local-only progress, save harmless settings or high scores in localStorage and keep working if storage is unavailable. - If the project declares Slop Farm cloud saves or multiplayer, load only https://slopfarm.games/sdk/slopfarm.js and use its documented API. Never embed Supabase credentials or call platform tables directly. ## Finish the job 1. Build every required file. 2. Run the game in a browser and play through the main loop several times. 3. Fix broken controls, impossible states, console errors, layout overflow, and unclear feedback. 4. List the final files and give exact local test instructions. 5. End with a short manual test checklist and name the folder I should compress for upload. Do not stop after explaining the code. Create the working game.

Build a complete choice-driven browser story for Slop Farm called "Last Bus to Bramble." ## Setup The player is driving the final bus out of a flooded valley. There are four stops left, room for only two more passengers, and a storm closing the road. The story should take 8-12 minutes. ## Story design - Open on the first flooded stop with a decision in the first 30 seconds. - Track fuel, time, and trust with two recurring passengers. - Write 10-12 short scenes and three distinct endings. - At least three early choices must change later dialogue, available options, or who helps at the final roadblock. - Avoid fake choices. If two choices lead to the same scene, change meaningful state or acknowledge the difference in the writing. - Choice labels should state the action plainly. Show known costs such as "Use 10 minutes to wait" before selection. ## Interface - Present one readable scene at a time with 2-4 large choice buttons. - Support keyboard selection, touch, text-size controls, mute, back one choice, restart, and reduced motion. - Include a simple route map that updates after each stop. - Use original CSS illustration and subtle generated ambience. Do not fetch images, fonts, or audio. ## Writing - Keep paragraphs short and concrete. Give each recurring character a distinct way of speaking. - No lore prologue, chosen-one plot, morality meter, or ending labeled "good" or "bad." - Proofread every branch and validate that every scene id and ending is reachable. ## Slop Farm build rules - Deliver a complete small game, not a scaffold, mockup, or design document. - It must be a static browser build with index.html at the project root. - Use relative local paths. Do not require a custom backend, database credential, API key, package install, or arbitrary internet service. - Do not load scripts, fonts, images, or audio from a CDN. Generate simple art and sound in code when practical. - Support keyboard and pointer controls. Add touch controls when the game needs more than one action. - Include a clear start state, short instructions, pause, mute, restart, win/lose feedback, and a way to play again. - Fit phones and desktop browsers without page scrolling during play. Keep important text readable at 390px wide. - Respect prefers-reduced-motion. Do not use flashing effects or rely on color alone to explain danger or success. - Keep game state bounded: cap particles and enemies, clamp frame time, clean up removed objects, and avoid console errors. - For local-only progress, save harmless settings or high scores in localStorage and keep working if storage is unavailable. - If the project declares Slop Farm cloud saves or multiplayer, load only https://slopfarm.games/sdk/slopfarm.js and use its documented API. Never embed Supabase credentials or call platform tables directly. ## Finish the job 1. Build every required file. 2. Run the game in a browser and play through the main loop several times. 3. Fix broken controls, impossible states, console errors, layout overflow, and unclear feedback. 4. List the final files and give exact local test instructions. 5. End with a short manual test checklist and name the folder I should compress for upload. Do not stop after explaining the code. Create the working game.

Act as a practical game designer and browser-game engineer. Improve the game in this project without replacing its identity or expanding it into a much larger game. ## First, inspect what is really here 1. Run the game and play the main loop long enough to understand the controls, goal, failure state, and restart flow. 2. Read the source and identify the actual entry file, rendering approach, state flow, and asset dependencies. 3. Write a short diagnosis with the five biggest problems, ordered by how much they hurt the player. Be specific. "Needs polish" is not a diagnosis. ## Then improve it - Fix broken controls, console errors, impossible states, collision mistakes, page scrolling, and unreliable restart behavior first. - Make the first 15 seconds understandable without a paragraph of instructions. - Tighten the main loop. Remove waiting, unclear feedback, and features that do not support the central mechanic. - Improve game feel with a small number of useful touches: readable anticipation, impact feedback, sound, animation, score response, or a short recovery window after damage. - Check difficulty from a fresh player's point of view. The opening should teach; later play should ask for mastery. - Make text, controls, and important game state readable on a 390px-wide phone and a desktop screen. - Add keyboard and pointer support. Add touch controls when the game needs directional input. - Add pause, mute, restart, win/lose feedback, and a clear way to play again if any are missing. - Respect reduced motion and do not rely on color alone for meaning. - Keep the game static and self-contained. No backend, account, API key, CDN, or remote asset dependency. - Keep index.html at the project root and use relative local paths. ## Keep scope under control Do not rewrite a working game from scratch. Do not add a shop, login, multiplayer, procedural story system, giant settings screen, or unrelated meta progression. Prefer ten well-chosen fixes over a pile of new features. ## Verify before stopping 1. Play several complete runs, including a loss, restart, pause/resume, mute/unmute, and a win when the game has one. 2. Test keyboard, pointer, touch-sized controls, and a 390px viewport. 3. Check the browser console and network panel. Fix errors and unexpected external requests. 4. Report what changed, what you tested, and any limitation that remains. Here is what I want to preserve about the game: [DESCRIBE THE PARTS THAT ALREADY FEEL RIGHT] Here is what currently bothers me: [DESCRIBE PROBLEMS OR LEAVE BLANK FOR THE AGENT TO DIAGNOSE]

Prepare the browser game in this project for a Slop Farm upload. Inspect and fix the real files; do not only write instructions. ## Upload contract - Static browser games only: HTML, CSS, JavaScript, canvas, WebGL, Godot Web, Unity WebGL, Phaser, Pixi, or similar - No backend, custom game server, login, API key, install step, or required internet connection - index.html should be at the root of the folder I will compress (game.html, play.html, or main.html are accepted only when the project already relies on one) - All scripts, images, audio, data, fonts, and wasm must load through safe relative paths - Stay below 50 MB and 500 files - Do not include node_modules, source maps, secrets, unrelated project files, caches, or absolute localhost paths ## Work in this order 1. Find the actual source project, build command, output folder, and browser entry file. Do not guess when the repository answers the question. 2. Run the existing production build if one exists. Do not introduce a new framework or replace a working build system. 3. Create a clean upload folder such as: my-game/ index.html game.js style.css assets/ 4. Fix packaging problems in the output: - Rewrite absolute or root-relative asset paths so they work from the uploaded folder - Bundle required local dependencies and assets - Remove calls to localhost and development-only services - Keep filenames and letter casing consistent - Preserve wasm and engine data files needed by Godot or Unity 5. Serve the upload folder with a simple local static server and play the game. Check the console and network panel. Fix missing files, MIME problems, blocked requests, overflow, and broken controls. 6. Inspect the final folder for secrets, source maps, node_modules, symlinks, unrelated files, and size bloat. Remove anything the browser does not need. ## Final answer - Name the exact folder I should compress, and make sure index.html is at that folder's root - Show the final file tree and total size - Give the exact command or steps to test it locally - List what you changed and any external dependency that still remains - Suggest a plain title, a one- or two-sentence description, one category, the AI tool used, and 3-5 honest tags for the upload form - If something cannot work as a static browser game, say exactly why and propose the smallest static alternative My game / project notes: [PASTE DESCRIPTION, FILE LIST, OR CODE HERE]

Create and upload a game

Game-making tutorials

Choose a loop

Copy and adapt

Play, then upload

One-button arcade game

Choose one verb

Build the fair version

Add the reason to replay

Polish the hit

Grid puzzle

Write the rule in one sentence

Make three teaching levels

Protect the player from dead ends

Then add depth

Arena survival

Make movement feel good first

Use two enemy behaviors

Offer real upgrade choices

Control the chaos

Turn-based tactics

Keep the board legible

Telegraph the enemy turn

Make units distinct

Test the losing path

Choice-driven story

Start with a decision under pressure

Track a few meaningful facts

Make choices say what they mean

Earn the endings

Make the game better without making it bigger

Diagnose, tighten, and test an existing game

Get the right folder out of your tools

Pure canvas / vanilla JS

Built with an AI chat (Claude, ChatGPT, Grok…)

Phaser / Pixi / Three.js

Godot web export

Unity WebGL

Anything else that runs offline

Build and verify the folder you will upload

Create and upload a game

Game-making tutorials

Choose a loop

Copy and adapt

Play, then upload

One-button arcade game

Choose one verb

Build the fair version

Add the reason to replay

Polish the hit

Grid puzzle

Write the rule in one sentence

Make three teaching levels

Protect the player from dead ends

Then add depth

Arena survival

Make movement feel good first

Use two enemy behaviors

Offer real upgrade choices

Control the chaos

Turn-based tactics

Keep the board legible

Telegraph the enemy turn

Make units distinct

Test the losing path

Choice-driven story

Start with a decision under pressure

Track a few meaningful facts

Make choices say what they mean

Earn the endings

Make the game better without making it bigger

Diagnose, tighten, and test an existing game

Get the right folder out of your tools

Pure canvas / vanilla JS

Built with an AI chat (Claude, ChatGPT, Grok…)

Phaser / Pixi / Three.js

Godot web export

Unity WebGL

Anything else that runs offline

Build and verify the folder you will upload