Start here

Game requirements

These are the rules every build must meet. The checks marked automatic run when you upload. A build that fails the size and file checks is not saved; a build that fails the credential scan is saved as a draft but cannot be submitted. Everything else is checked by a reviewer. See the Review and rejection policy for what happens when a rule is not met.

Games we accept

Smaz Games accepts games that run entirely in a web browser from static files: HTML, CSS, JavaScript, WebAssembly, images, audio, video, fonts and data files.

The engine is not restricted. Any tool works if its export meets the rules on this page. Tell us the engine and version on the upload form; it helps the reviewer.

Games we do not accept

• Native programs: .exe, .app, .apk, .ipa, .dmg or anything that must be installed.
• Flash (.swf), Shockwave, Java applets, Silverlight, the old Unity Web Player or anything else that needs a browser plugin.
• Games that need server code we would run, such as PHP, Python, Node.js servers or a database. Your own servers are allowed for online features; see Invites and multiplayer.
• Builds that only load or redirect to a game hosted somewhere else, or show another website in a frame.
• Games streamed from a server as video.
• Games that cannot be played without signing in to another service.
• Source projects (Unity projects, Godot projects, node_modules) instead of an exported build.

ZIP structure

Zip the contents of your build folder, so that index.html is at the top level of the ZIP, not inside a folder.

my-game.zip
├── index.html
├── arcade-sdk.js
├── game.js
├── game.wasm
└── assets/
    ├── atlas.png
    └── music.ogg

Use relative paths everywhere (assets/atlas.png or ./assets/atlas.png, never /assets/atlas.png or C:\…). File names are case-sensitive once published, so a path that works on Windows or macOS can fail here if the case does not match.

Size and file limits (automatic)

The ZIP is rejected if it contains:

• Absolute paths, .., backslashes, or hidden files and folders (names starting with ., such as .DS_Store or .git).
• Symbolic links, encrypted (password-protected) entries or duplicate paths, including names that differ only in case.
• These file types: .exe, .dll, .php, .py, .sh, .bat, .cmd, .pem, .key, .zip, .rar, .7z, .tar.

Note: On macOS, zipping from Finder adds a hidden __MACOSX folder with ._ files. Those are hidden files and the upload fails. Zip from the command line with cd build && zip -r ../my-game.zip . -x ".*" -x "__MACOSX", or use a tool that leaves them out.

Credential scan (automatic)

Text files (HTML, CSS, JavaScript and JSON up to 2MB each) are scanned. A build fails if it contains something that looks like a private key or an access token, such as a -----BEGIN PRIVATE KEY----- block, a cloud access key, a live payment key or a code-hosting access token. The version is kept as a draft with a failed quality report and cannot be submitted: remove the secret, revoke it and upload a new version. Anything in a web build can be read by players.

The scan also lists every web address found in your files, and flags use of the camera, microphone or location. These are warnings for the reviewer, not failures. Text files over 2MB are not scanned and are reviewed by hand.

The browser sandbox

Every uploaded game runs in a sandboxed frame with its own origin, separate from the site and from every other game. This protects players' accounts and other games. It also means some browser features are not available.

Browser storage

Your game can use localStorage, sessionStorage, IndexedDB and Cache Storage. The storage belongs to your game only: other games and the site cannot read it, and your game cannot read theirs.

Browser storage is kept per browser and device. It does not follow a player to another device or browser. It is lost when the player clears site data, and a private window forgets it when closed. Every version of your game, and its private previews, share the same storage in a browser, so an update keeps what the previous version stored. It is also shared by everyone who plays in that browser, whichever account is signed in, so do not use it for account progress (see Browser storage in Saves).

SDK saves are recommended for progress. They save to the player's account when signed in, so progress follows them to any device, and to the player's browser as a guest. The data module works like localStorage, so a game that already uses localStorage can switch with few changes.

Outside addresses

By default a game can only load files from its own build. If your game connects to your own server (WebSocket, REST API, WebRTC signalling) or links to your website, list each address in Outside addresses on the upload form:

• One per line, as an origin: wss://play.example.com or https://api.example.com.
• Only wss:// and https://, with a domain name, no path, and up to 8 addresses.
• The game page shows these addresses to players under Connects to.

Requests to any address not on the list are blocked by the browser. The reviewer checks what each address does. Changing the list needs a new version.

Engine notes

Unity

• Build target WebGL. Unity 2021.3 or later is recommended.
• Set Compression Format to Disabled, or keep Gzip or Brotli and turn on Decompression Fallback. Pre-compressed files are served as ordinary files, so without the fallback the loader fails.
• Data Caching stores the downloaded build in IndexedDB, so later visits in the same browser load faster. It can stay on.
• PlayerPrefs in WebGL is saved in IndexedDB and persists in the player's browser. For saves that follow a signed-in player to other devices, call the SDK from a .jslib plugin. See Install the SDK.
• Do not use a template that loads files from other sites.

Godot

• Use the Web export. In Godot 4, untick Thread Support (Godot 4.3 or later supports single-threaded web exports). Threaded exports need SharedArrayBuffer, which is not available.
• Files written to user:// go to IndexedDB and persist in the player's browser. For saves that follow a signed-in player to other devices, save through the SDK with JavaScriptBridge (Godot 4) or JavaScript (Godot 3).
• Untick Progressive Web App.

Construct 3

• Export as Web (HTML5). Untick Offline support: service workers cannot run in the sandbox.
• The Local Storage plugin uses IndexedDB and persists in the player's browser. For account saves, call the SDK through a script or the Browser object's JavaScript call.

Other engines

• GDevelop storage actions and RPG Maker MV/MZ save files use browser storage and persist in the player's browser. Add the SDK if you want saves to follow a signed-in player to other devices.
• Bundle web fonts as files in the ZIP. Fonts from font services are blocked.
• Remove analytics, ad or social plugins from the export template.
• Remove splash screens that link to other sites.

Devices and orientation

Declare only the devices you have tested.

• Desktop: the game must work with a mouse and keyboard. Do not rely on keys the browser keeps for itself, such as Ctrl+W, Ctrl+T, F5, F11 or Escape (Escape leaves fullscreen).
• Mobile and tablet: every action must work by touch, with controls large enough for a thumb (at least 44×44 CSS pixels). Stop the page from scrolling or zooming during play with touch-action: none on the game canvas and user-select: none on the body.
• Orientation: if you declare landscape or portrait, the site asks phone players to rotate and pauses the game until they do. Choose Any only if the game lays out correctly both ways.
• The frame can be any size, from a small window to fullscreen. Resize to fit the frame (window resize events) instead of assuming a fixed size, and keep important UI away from the edges.
• On iOS, sound starts only after a tap. Start or resume your AudioContext inside the first touch or click handler.

Performance

These are the targets reviewers test against. Builds that are much slower may be sent back.

• Show something on screen within a few seconds and let the player start within 20 seconds on a typical home connection. Load later levels in the background.
• Keep the download before first play under 50MB, and under 20MB for games that support phones.
• Aim for a steady 60 frames per second on a mid-range laptop and 30 or more on a mid-range phone.
• Stop the game loop and sound when the SDK reports paused or the tab is hidden.
• Do not run work that is unrelated to the game, such as cryptocurrency mining.

No ads, trackers or third-party SDKs in games

Smaz Games shows ads around the game page and measures plays itself. Builds must not contain:

• Ad networks, ad SDKs or ad tags, including other games sites' SDKs.
• Google Analytics (gtag.js), Google Tag Manager, Facebook Pixel or any other tracking or analytics script.
• Device fingerprinting, or anything that tracks players across games or sites.
• Payment, purchase or donation flows. See the Monetization policy.

Use the SDK for rewarded ads and analytics events.

Game details

Descriptions must be accurate. Do not claim awards, ratings, player numbers or features the game does not have.