You don't have to build with AI to publish on wilds.ai. Bring a game you already have. a homebrew ROM, an interactive-fiction file, a web build. and it becomes a first-class, playable, earning world like any other.You don't have to build with AI to publish on wilds.ai. Bring a game you already have. a homebrew ROM, an interactive-fiction file, a web build. and it becomes a first-class, playable, earning world like any other.
#What you can upload
Three kinds of games, each at Create → Upload:
- Retro ROMs. NES and the other supported emulator cores. The game runs in the in-browser emulator with save states, leaderboards, and the full retro HUD.
- Interactive fiction. Ink (
.inkor compiled.ink.json) and published Twine HTML (.html/.htm) import into the creator interactive-fiction family. Z-machine story files (.z3,.z5,.z8) and Scott Adams adventures (.dat) run through the classic text-adventure upload path. - Web games. A zipped HTML5 build (Unity WebGL, Godot HTML5, or hand-rolled HTML/JS). The bundle is hosted on wilds and runs in a sandboxed frame.
#Web games: file structure
A web game uploads as a single .zip of your build. Put index.html at the root of the zip and include everything it loads next to it (images, scripts, stylesheets, audio, fonts, WebGL data), exactly the way itch.io expects an HTML5 upload. If your entry file isn't named index.html, leave it as the only .html at the zip root and it resolves as the entry. A one-file game still ships as a .zip with that HTML inside.
Use relative asset paths. Your game is served from a sub-path, so a root-absolute reference like /art/hero.png points at the wrong origin and 404s. Reference assets relative to your HTML instead: ./art/hero.png or art/hero.png. This is the same rule itch.io and most static hosts enforce, and a build that runs there runs here.
A bundle holds up to 2,000 files and 200 MB. The game runs in a sandboxed, cross-origin frame, so it can't read your wilds session or reach the page hosting it.
Hardcoded absolute paths, or assets pulled from a fragile external URL? Collapse the whole build into one self-contained file first, then zip and upload that:
npx portapack ./your-game -o game.htmlPortaPack inlines every local script, stylesheet, and image into a single HTML file, so absolute-path and external-asset breakage disappears. It is the fallback for builds you can't make relative. The zip-everything model above is the normal path.
#The two steps: file, then license
Public submission is deliberately two steps so the rights question is never an afterthought. Private Ink and Twine imports keep the uploaded file owner-scoped by default; public catalog submission still needs the rights basis below.
- Pick your file. The picker filters to the formats valid for the kind you chose.
- Attest the license. You tell us how you have the right to distribute this game, and you sign a short attestation. This is the legally meaningful part. it's what lets us publish your game and, where eligible, pay you for it.
The form shows an earnings-eligibility line before you submit, so you always know whether a given upload will earn before it goes anywhere.
#Rights basis. and what earns
You pick one rights basis. it drives both whether the game can be published and whether it earns.
| Rights basis | What it means | Publishable? | Earns? |
|---|---|---|---|
I created this (original) | Your own work | yes | yes |
| I hold a license + commercial rights | Third-party work you licensed with the right to monetize | yes (after human review) | yes |
| I hold a license, non-commercial | Licensed for distribution but not monetization | yes (after human review) | no |
| Public domain / freely licensed | Public-domain or others' freely-licensed work | yes | no |
The rule is simple: earning follows the rights you actually hold, not the file format. A ROM you wrote earns exactly like an AI-built world. A public-domain classic is fully playable and shareable, it just doesn't pay you. See the creator economy guide for the rates (every tier earns; the rate scales with plan) and how creator rewards work for spending what you earn.
#The review flow
What happens after you submit depends on the rights basis:
- Original and public-domain uploads take the fast lane. Automated checks run immediately. the file is parsed and format-validated, the declared license is checked against the allow-list, and the content is policy-scanned. If everything passes, the game publishes right away and you land on it.
- Licensed uploads go to a human review queue. A reviewer confirms the license proof you provided actually substantiates your right to distribute (and to earn, if you claimed commercial rights). You'll get an in-app notification and an email when a decision lands, and you can reply in the submission thread if the reviewer asks for a change.
Track everything at Account → My uploads: status, the reviewer conversation, and the published link once it's live.
#After it's published
Your upload becomes a creator-owned, public world. It shows up in Explore, can be favorited, carries your @username in the session footer, and. if it's earning-eligible. starts accruing reward credits on every unique audience-day, exactly like the rest of your catalog.
If a published upload is ever found to violate its declared license, it can be revoked. it flips back to private and stops earning. Attest honestly; the attestation is the thing that protects both you and the platform.