Requirements

The short version

SlopTV Games is open to anyone. If your game runs in a browser, is yours to publish, and isn't broken or harmful, it will be approved. An admin plays every submission before it goes live. That is the only gate.

Technical requirements

• HTML5 only. No Flash, no Java applets, no downloads. Anything that exports to a folder with an index.html works.
• Relative paths. Your build is served from /play/<id>/, so absolute paths starting with / will 404. Most engines do this correctly by default.
• Runs in a sandboxed iframe. Players see your game inside a 16:9 frame on desktop and fullscreen on mobile. Scripts, input, pointer lock and click-started audio work; portal cookies, parent DOM access, popup navigation and origin storage such as localStorage do not. Use relative files in your build.
• Size. Up to 100 MB per upload request. Bigger builds can be uploaded as a folder, which we send in batches. Keep the first load under 30 MB if you want people to actually wait for it.
• Scales to the container. Use a resize handler or a canvas that fills its parent. Fixed 800×600 is fine if it centers.
• Audio after interaction. Browsers block sound until the first click or tap. Start your audio context on the first input.
• No external accounts. Don't require players to log in to another service to play. Optional accounts are fine.
• No SharedArrayBuffer yet. Godot 4 "threads" exports and Unity builds that need cross-origin isolation won't run. Export without threads for now.
• Externally hosted games need an https:// URL that allows framing (no X-Frame-Options: DENY and no restrictive frame-ancestors).

Multiplayer

Full multiplayer reference →

Rooms, matchmaking and message relay are provided for you. You do not need a server, a signalling service, or an account with anybody else — connect, and the players who connect after you are in your room.

Turning it on

• Tick Multiplayer on your game in the developer portal. Until you do, the ticket endpoint refuses and SlopMP.connect() rejects.
• Load the client: <script src="/mp/client.js"></script>

The whole API

const mp = await SlopMP.connect();        // or .connect({ room: 'friends-only', cap: 4 })

mp.me        // { id, name }   who you are
mp.room      // the room you landed in
mp.players   // [{ id, name }] everyone here, you included

mp.on('join',    (player, players) => {});
mp.on('leave',   (player, players) => {});
mp.on('message', (data, from) => {});     // from is { id, name }
mp.on('close',   (code) => {});

mp.send({ x: 10, y: 4 });                 // to everyone else in the room
mp.send({ deal: cards }, somePlayerId);   // to one player

How rooms are chosen

• Call connect() with nothing and you are matched into the oldest room with space, so players gather in one game instead of scattering one-per-room and each waiting alone.
• Pass a room name and you join exactly that room. This is how you build "play with a friend" — let one player share a code and have the other type it in.
• Pass cap to set how many players a room holds. Default 8, maximum 32, minimum 2.

What the server does and does not do

• It relays, it does not referee. Whatever you pass to send arrives at the other players unchanged. The server never inspects your game state, so it cannot stop a modified client from lying. For anything competitive, have one player act as host and validate moves, or check each move on every client.
• Sender identity is stamped by us. The from on a message is the signed-in account that sent it, not something the client supplied, so you can trust who a message came from even though you cannot trust what it says.
• Messages are JSON, up to 64 KB each. Send a small object many times rather than a big one occasionally.
• Idle rooms cost nothing. A room with nobody talking is evicted from memory and the sockets stay open, so turn-based games are extremely cheap to run. There is no need to poll — and polling is the one thing that will make a quiet game expensive.
• A ticket is single use. If the socket drops, the game has to be restarted to get a new one; a reconnect cannot be done silently from inside your game. Handle close by telling the player, rather than appearing to hang.

Controllers

Every game gets the site's controller layer. If your game reads the keyboard, a connected gamepad already works: d-pad and left stick are the arrow keys, A is Space, B / X / Y are X / Z / C, Start is Enter, Back is Escape, the shoulders are Shift and Control, and the right stick is WASD. Nothing to add.

If your game reads the Gamepad API itself, the layer stands down as soon as it sees you polling, so you get raw input and never a doubled key. The frame is granted the gamepad permission.

Saving progress

Your game runs sandboxed on its own origin, where the browser refuses localStorage and sessionStorage. We put a memory-only stand-in in front of both, so a game that reads a high score on load still starts — but nothing survives a reload. Keep progress in memory, or on your own server if the game has one.

Content rules

• You own the game or hold a license for every asset in it. Asset-store and CC-licensed assets are fine when the license allows it.
• No hate speech, harassment, or content that targets real people.
• No sexual content. Mild violence and horror are fine. Mark it in the description.
• No real-money gambling, no crypto miners, no wallet connectors, no forced ads or redirects of your own.
• No malware, tracking pixels that harvest data, or scripts that phone home with player data.
• Clones and "inspired by" games are allowed if they use your own code and assets. Straight rips are not.

Listing quality

• Name: the same title that appears in the game, up to 35 characters.
• Thumbnail: 16:10 or 16:9, at least 640 px wide, shows gameplay. It will be shown small in a black and white grid, so use big shapes and contrast.
• Description: what the game is, how to win, anything the player should know. At least 40 characters, ideally a few paragraphs.
• Controls: one per line as Key - action. They are rendered as key caps.

Export guides by engine

Engine	Export	Upload
Unity (2022, 6)	File → Build Settings → WebGL → Build. Compression: Gzip or Disabled both work; Brotli works too. Enable "Decompression Fallback" if you're unsure.	Zip the build output folder (the one containing index.html, Build/, TemplateData/).
Godot 3 / 4	Project → Export → Web. Godot 4: set Thread Support off. Name the export index.html.	Zip or pick the export folder.
Phaser, PixiJS, Three.js, Babylon.js, plain JS	Run your bundler's production build (Vite, webpack, Parcel) with a relative base path, e.g. Vite base: './'.	Zip or pick the dist/ folder.
Construct 3	Menu → Project → Export → Web (HTML5). Untick "Minify" only if you see errors.	Upload the exported zip directly.
GDevelop	Export → Web (browser game) → Export as a local folder.	Zip or pick the folder.
GameMaker	Target: HTML5 → Create executable. Produces a zip.	Upload the zip directly.
Defold	Project → Bundle → HTML5 application.	Zip or pick the bundle folder.
Cocos Creator	Build → platform "Web Mobile" or "Web Desktop".	Zip or pick the build folder.
PlayCanvas	Publish → Download .zip build.	Upload the zip directly.
Twine, Ren'Py (web), Bitsy, PICO-8 (web export)	Use the engine's HTML export. Rename the main file to index.html if it isn't already, or set the entry file on step 1.	Zip or pick the folder.

Review process

Submit from the developer portal. Your game gets a pending badge. An admin plays it, checks the rules above, and either approves it (it goes live on the home page right away) or rejects it with a note. You can fix and resubmit as many times as you want. Editing a live game sends it back through review.

Questions? Use the Contact link in the footer.