Publisher docs

Quality standards

What we look at in every game before it goes live, and what separates a game players come back to from one they close after ten seconds.

Overview

There are two layers. The submission rules are requirements: file limits, rights, safety. A build that breaks one is declined. This page covers the second layer, quality: the guidelines that decide whether a game that technically works is also a good experience. We review both for every game, and we use the same standard for every game.

Quality is judged by what the player sees and does, not by who made the game or with which tools.
We do not decline a game because we already list a similar one. If yours is better than a similar game in the catalog, that is a reason to list it.
We do not apply a different bar by genre, studio size, or engine.
A decline comes with a concrete reason about the game. You can fix it and send it again.

AI-assisted games

We accept games made with AI tools. We do not accept unrefined AI output. The difference is not the tool, it is whether anyone designed, tested, and refined the game before sending it. We want games with a clear interface, a considered user experience, and a coherent look and feel, with real attention to the player's experience.

What we mean by unrefined AI output

A menu or HUD assembled from mismatched pieces: buttons, icons, and fonts in different styles.
Garbled, misspelled, or placeholder text in menus, instructions, or artwork.
No real game design: a template with a new skin, nothing to learn or master, no goal.
Controls and layout that were never tested on the devices the listing declares.
A thumbnail or cover that promises more than the build delivers.

Rights still apply to AI-generated assets

Every visual, sound, and other asset must be properly licensed or created by you. AI output with unclear provenance or an unclear license is not accepted, however polished it looks.

What a good AI-assisted game looks like

Someone made decisions about it: the first minute was designed, the interface was tested on a phone, the art follows one style, and the difficulty was tuned by playing it. The reviewer cannot tell, and does not need to know, which parts were generated. The reviewer can tell whether the result was cared for.

Onboarding

Players decide in the first minute. A game that gets them into play quickly and shows them what to do keeps them.

Drop new players straight into play. Teach during play instead of through a long tutorial screen.
Cover the core actions first. Skip explaining every feature up front.
Make any tutorial skippable.
Prefer visuals over paragraphs. Show the controls with a key overlay or a gesture hint.
Label buttons so it is clear what happens next. Do not size buttons to provoke accidental ad taps, and do not add delays that confuse players.

Gameplay

Clarity

There is a clear goal the player can reach, and success and failure are visible.
The game is easy to learn and easy to understand. Text is correct and clear, well translated where translated, or replaced with universal icons.
The controls stay consistent from the first screen to the last.

Feel

The game answers the player's input quickly.
Challenge, strategy, and story are paced so the game does not stall or spike.
There is no filler: repeated chores that add time but nothing to play.
The screen layout is comfortable and suits the device. A phone layout is not a shrunken desktop layout.
If the game has solo and multiplayer modes, playing alone is as easy to find as playing with others. If solo play is not available, the game says so.

Controls and input

Make controls intuitive and easy to learn, and show them in the game.
Where you can, adapt key bindings to the player's keyboard layout. On an AZERTY keyboard the movement keys are not where WASD expects them.
Avoid keys the browser already uses. Esc exits fullscreen, and Ctrl or Cmd + W closes the tab.
On touch devices, make targets large enough to hit and keep them out of the screen edges where the system gestures live.

Visuals and audio

A game does not need a large budget to look consistent. It needs one visual language used throughout.

Use one art style. Do not switch between realistic and cartoon, or between high and low resolution.
Keep resolution consistent and free of compression artifacts and blurry scaling.
Keep audio levels consistent, neither too quiet nor too loud, and let music support the visuals. Provide a way to mute.
Make clear what the game is. The name and images must show the genre and type of game the player will actually get.

Identity and listing

Choose a name that is not easily confused with another game, and do not use the name or imagery of a game or brand you do not own.
Keep the genre and main features after submission. A game that turns into something else after approval is a different game.
Change the name and thumbnail only for a real overhaul or major update.
Describe the game as it is. No borrowed footage and no keyword stuffing.
Plan to maintain it: fix bugs, and add levels or content where the design allows it.

Requirements we check

Each row is checked on every submission. The full technical limits and content rules are in the submission rules.

Check	What passes	What fails
It loads and starts	Opens in a modern browser within a few seconds and reaches its first playable screen.	Blank page, stuck loader, or errors on the first level.
The first input works	The first tap, click, or key press does something visible.	The game waits for an input it never explains.
It works on declared devices	Unless marked desktop-only, it works on a mid-range phone with touch controls in the chosen orientation.	Declared for mobile but needs a keyboard, or breaks on rotation.
Controls match the listing	The controls and instructions you submit describe what the game does.	Listing says arrow keys, game uses the mouse.
The listing is honest	Title, description, thumbnail, cover, and preview show the build the player opens.	Thumbnail from a different game; features the build lacks.
It behaves safely	No forced redirects, fake controls, deceptive close buttons, popups outside the game, or imitation system messages. Ads suit a general audience and do not interrupt basic play unfairly.	An ad covers play, opens tabs on its own, or imitates a system dialog.
You have the rights	You own, publish, or license the game, or have written permission to embed it, including art, music, sound effects, and fonts.	Assets or code with no license or permission.
It fits a general audience	Content, ads, monetization, and external links suit a broad audience.	Real-money gambling, adult, hateful, or shock content.
No silent data collection	Trackers and network requests do not send player data to an undeclared service.	The build contacts an undeclared third party with player data.

How we decide

Automated checks validate the ZIP structure and scan the bundle. A reviewer then opens the game, plays the first session on the declared devices, and compares it with the listing. A person makes the final decision.

If a game is declined, the email states a concrete reason, and you can correct it and send it again. For the common technical causes see why HTML5 submissions fail review, and for what a generic rejection can mean on other portals see why game websites reject your game.

What we do not decline for

That AI tools were used, as long as the game shows care and quality.
That the catalog already has a game of the same type.
That the studio is new or has only one game.