Quality criteria

Why there are criteria

Making a game in an afternoon is easier than ever, and so is making twenty. A store full of unfinished, broken or duplicated games hurts every publisher in it: players stop trying new games. The criteria below are part of the terms of use (section 5), which say what we may do when a game falls short. We may update them; we announce important changes in advance.

The minimum criteria

1. Complete and playable. There is something to do and a goal: a score, levels, an end, or play that keeps going. What players see is finished: no placeholder texts or images ("lorem ipsum", "TODO", missing sprites), no test buttons or debug output, no "coming soon" in place of the game. One mechanic done well is a game. A game that is still growing is fine too, when what is there works and the description says it is an early version.
   Falls short: a start screen with nothing behind it, a single animation, a page of text or links, a demo that ends after a minute, the quick-start example of this guide under a new name.
2. Works reliably. It starts in the sandbox, shows something within a few seconds (a loading screen if it needs longer), and does not crash, freeze or lose progress in normal play; it saves on pause. This also holds later: when a browser update or a change in VibeGames breaks your game, fix it or withdraw it.
   Falls short: many failed starts in your statistics, a level that cannot be finished, progress lost on every restart.
3. Fits the devices it is designed for. Every device you choose under Devices & screenshots can play it: with touch on phones and tablets, with keyboard or mouse on desktops. The game fits the screen in its orientation, keeps controls inside the safe area and out of the area of the shell's menu handle, and its text is readable.
   Falls short: designed for phones, but played only with the keyboard; buttons cut off on a small phone or under the menu handle.
4. Lets players leave. A visible control calls vibe.exit(), reachable from the game's main screen or its pause menu. The validator only checks that your code calls it somewhere.
5. Described honestly. Name, icon, descriptions, tags, screenshots, devices and minimum age match the game. Screenshots show the game as players see it, the description says what the player does, and the features it names are there. No lists of keywords, no other games' names.
   Falls short: concept art or another game in the screenshots; "multiplayer" for a game against the computer; a description that only says "Best game ever!".
6. One game, one listing. Each game is in the store once. Put variants into the same game, as levels, modes or skins, instead of publishing them separately.
   Falls short: ten games that differ only in colours, words or levels.
7. Fair to players. The game does not imitate VibeGames or the device: no fake menus, dialogs, notifications or error messages. Links and messages serve the game, not sending players elsewhere. If the game has fast flashing lights, it warns players when it starts.
   Falls short: a "Leave game" button that does something else; a fake "update available" message.

What we do not judge

Taste. Genre, art style, size, difficulty, how simple the graphics are and whether a game is fun are for players to decide, with their ratings. How you made the game does not matter either: by hand, with an engine or with AI tools. Games made with AI are welcome under the same criteria, and you answer for them like for any other.

How we check

• Validation runs on every upload. It checks the package and the rules of the sandbox, not these criteria: a version that passes validation can still fall short.
• Review. When an admin reviews a version before it goes live (always for apps with sexual content, for every app when the operator turned on manual review), they check these criteria too.
• Live games we look at when something points to a problem: players report the game or complain about it, its starts often fail or it reports many errors (the figures you see in your statistics), or its ratings and uninstalls stand out. We also look at games at random.

When a game falls short

1. We tell you which criterion the game misses, with an example: in the review note of the version, or by e-mail for a live game.
2. You get time to fix it, usually two weeks, unless players need protecting at once. Upload a fixed version, or explain why you think the game meets the criteria.
3. If it stays as it is, we reject the version in review or take the game out of the store. The app's page in your publisher console says so, with the reason. Nobody new finds or installs the game; players who installed it keep playing it and get your updates. Publish a fixed version and tell us: once it meets the criteria, we put the game back (your own Listed switch cannot).

Quality alone is never a reason to block a game, which stops it for the players who installed it; blocking is for games that break the law or the terms in other ways, such as malware or pornographic content. If a publisher keeps publishing games that fall short, for example many near copies, we may withdraw their right to publish.