Behind the scenes
How MLMN Games decides which games to publish
The actual pipeline a game goes through here before it appears in the catalogue — what we test, what we scan for, and what gets rejected.
Most game portals are silent about how a game ends up on them, which makes “hand-picked” meaningless. So here is the concrete process a package goes through on MLMN Games, including the automated checks that run every time the site is built.
Nothing on this site is user-uploaded, and there is no submission form that dumps straight onto a page. A game is added only after it works on a phone, plays reasonably on a desktop, and passes the tracker scan described below.
1. It has to load on a phone, from cold, quickly
The first filter is size and startup behaviour. Our builds range from about 5 MB to 60 MB on disk, and the ones at the top of that range take noticeably longer on a mobile connection. A game that shows a blank screen for many seconds, or that assumes a mouse hover state exists, is rejected — on a phone the hover state never happens, and games designed around it are unplayable.
2. Orientation is a design decision we do not override
Each game declares whether it is portrait or landscape, and we keep that. Portrait games are thumb-designed vertical puzzles and shooters; landscape games are the wide battlefields — Tank Era, Ace Strike, Arrow Maze Solve and Shift Dash Reac. We do not letterbox a landscape game into a portrait frame to make the site look uniform, because it makes the game worse.
3. A tracker and ad-tag scan runs at build time
The site generator scans every delivered code file and reports analytics and advertising identifiers it finds, separating browser-loaded services from identifiers that require a native app wrapper.
Some games retain dormant mobile-app ad configuration. The website advertising integrations have been removed, and the current scan reports no ad or analytics endpoint loading directly from a hosted game package. Website analytics are handled by the portal pages. New game exports are scanned again before publishing.
4. Structured data describes what is really on the page
Every detail page publishes VideoGame, HowTo, BreadcrumbList and FAQPage markup. What it does not publish is ratings or review counts, because we do not collect real user ratings and an invented number in structured data is worse for a player than no number at all. The same reasoning is why the catalogue carries no play counts: a static site with no backend has no way to know how many people played something, and there is no honest figure to print.
5. What gets rejected
Games we cannot get to run cleanly on a phone. Games that ask for a login before the first level. Games whose only content is an ad wall. And games we have no right to distribute — publishing someone else’s work without permission hurts the developer and gets the site removed.
The honest limitation of this process is scale: with 18 games, we are a small curated shelf, not a portal. Every entry has a written guide on the site and every guide was written after reading what that build actually contains. A larger catalogue of the same quality would be better; a bigger number of the same games we already have would not.
If you want to suggest a game, or think one of ours is misfiled, the contact page is a real mailbox that a person reads. That is a smaller promise than “millions of games”, and it is the one we can keep.
A rule or detail changed? Send a correction. Read our editorial approach.