How Malaguo reviews a browser game before publication

Why publication is a gate, not a button

A creator upload reaches Malaguo as an untrusted software package. It may be an excellent game, but the platform cannot assume that its files are safe, that its start button works, or that a touch player can complete the same actions as a keyboard player. Publication therefore happens only after a named build has passed a repeatable review. Drafts and rejected builds remain private. The public game URL is activated only when an approved version, reviewed media and complete catalogue record point to the same release.

This process protects players and creators at the same time. Players receive a page that works as advertised. Creators receive a precise reason when a build cannot ship, rather than a vague rejection. Malaguo keeps the original archive, its checksum and the reviewer decision so a later update cannot silently replace the approved code.

Gate one: archive integrity and offline safety

The first pass inspects the ZIP without executing it. A valid browser game needs one root entry document, readable local assets and a bounded number of files. The inspector records the uncompressed size, file count and cryptographic hash. It rejects path traversal, symbolic links, executable server files and other archive patterns that could escape the game directory.

The network review is equally important. Every external URL, WebSocket reference, dynamic network capability and root-relative asset is reported. A path such as /images/card.png looks harmless, but inside an isolated runtime it points at the platform root rather than the uploaded game. That causes missing art after publication and can make a working local prototype appear broken online. Approved builds either bundle these assets or declare a separately reviewed integration.

Gate two: real playability on desktop and touch

Structural safety does not prove that a game is playable. A reviewer opens the exact candidate build in the protected preview, follows the first-run experience, starts a session and performs the core loop. The review covers visible controls, score or progress updates, pause and restart, win or failure states, and a clean browser console.

Desktop input and mobile input are checked independently. Keyboard labels must match the keys handled by the code. Touch targets need enough size and separation. Swipe gestures cannot depend on hover. The viewport must not create horizontal overflow, clipped dialogs or controls hidden below the browser chrome. If a game rotates the device or requests fullscreen, the ordinary embedded mode must still offer a safe path to play.

Gate three: truthful catalogue content

The game page is part of the product. Reviewers verify the title, category, short summary, full description, how-to-play instructions, controls and age rating against the actual build. A polished description cannot promise levels, multiplayer, rewards or features that do not exist. The cover should communicate the real mechanic, while at least one screenshot should come from the approved gameplay rather than from unrelated concept art.

Malaguo does not fabricate ratings, views or community reactions during this stage. New releases can honestly say that they are new. Trust is more valuable than decorative numbers, and real engagement will be measured after publication.

Gate four: localization and search quality

The creator's source language remains the source of truth. After approval, the platform generates localized catalogue records for English, Simplified Chinese, Traditional Chinese, German, French, Spanish, Brazilian Portuguese, Indonesian, Japanese and Korean. Each record includes the title, summary, description, instructions and controls. Automated output is stored as a review candidate, not treated as approved merely because an API returned text.

Language checks look for missing fields, mixed scripts, leaked interface keys and untranslated instructions. Search metadata is produced per market from the localized content and the platform's recorded search-intent evidence. Canonical URLs, reciprocal hreflang links, structured data and the sitemap are tested as one cluster. A language selector must point to a real localized page, never manufacture a translated-looking 404.

The decision and the evidence trail

An approval records the reviewer, timestamp, candidate version, scan findings and notes from the play test. It activates that immutable version and makes the public URL available. A rejection records what must change and leaves the earlier approved release untouched. A corrected archive receives a new semantic version and a new checksum; it never overwrites the evidence for the failed candidate.

After publication, Malaguo checks the public page, cover, runtime launch document and localized routes over HTTPS. Search discovery is requested only after those checks pass. Indexing itself remains a search engine decision, so the platform reports submitted, discovered, crawled and indexed states separately rather than claiming instant inclusion.

What creators should prepare

Creators can speed up review by packaging all required files locally, using relative paths, testing in a clean browser profile and checking both mouse or keyboard and touch. Include a clear title, an honest description, concise instructions, control details and original media. Test the exact ZIP you intend to upload. If the game requires a remote service, disclose it before review so privacy, security and reliability can be assessed.

The goal is not to create paperwork. It is to make every public release reproducible: one creator, one reviewed package, one active version, one trustworthy page and a clear route to the next update.