Metarun: a 1v1v1 competitive mobile runner, built end to end
Unreal Engine client, server-authoritative races, MMR matchmaking, anti-cheat, and hero ownership on BNB Chain, peaking at 39,000 concurrent players during an event. Published under its own brand and listed on Google Play, so the claims below can be checked rather than taken.
Why this one is named
A portfolio claim a reader cannot check is worth about as much as no claim at all.
Three of the client case studies on this site are anonymised, because permission to name those clients has not been given. That is honest and it is also weak evidence. Metarun is named with the client's permission, which means the product, the store listing and the feature set are all open to inspection, and every architectural claim on this page can be tested against a game you can install.
What is checkable, as of 28 August 2026: the game at metarun.game; the Android build on Google Play, where Google's listing shows 50,000+ downloads and a 4.0 rating from about 2,970 reviews, last updated by the studio in February 2023; the three character classes, the ranked leagues and the marketplace described on the product's own pages; and the BNB Chain token the site links out to. The site also links to an App Store entry, and that listing no longer returns a result in any region we checked — so Android is the live surface today, and this page does not claim otherwise.
Open metarun.game → · Google Play listing → · Game development
Metarun project snapshot
A competitive Web3 mobile title, delivered as one product rather than three subcontracted halves.
What the product is
A character-based tactical mobile runner with two modes: Battle Run, a 1v1v1 skill-based PvP race, and Endless Run, a PvE progression loop. Three character classes — Sprinter, Fighter, Craftsman — each with distinct abilities. At its event peak it held 39,000 concurrent players.
What the build covered
Unreal Engine client for Android and iOS, authoritative match services, MMR matchmaking and ranked leagues, anti-cheat, PvE progression, on-chain hero ownership and marketplace, in-app purchases and a fiat item shop, and the live-ops surface behind seasons and events. Six engineers, one team — not a client squad handing off to a backend squad.
What is publicly checkable
The live Google Play listing and its download and rating figures, the product site and its feature set, the published roadmap that records what shipped when, and the on-chain contract the site links to. None of those numbers are ours to claim — they are Google's and the chain's.
Why a competitive runner is not a runner
The genre is single-player by default. Making it competitive changes almost every engineering decision.
Three players, one race, one truth
A single-player runner can trust the device. A 1v1v1 race cannot: the moment a result decides a ranked league position, the client stops being an acceptable source of truth and the run has to be simulated somewhere neither player controls.
Mobile networks, not desktops
Players race on cellular connections that drop, roam and spike. The match service has to hold a fair race across that, which is a different problem from holding a fast one — and reconnection cannot be allowed to become an advantage.
Rewards make cheating profitable
In a Web3 title an exploited race is not a spoiled match, it is an asset the exploiter keeps. That moves anti-cheat from a polish item to a structural requirement, and it is why the product's own roadmap has it landing alongside the third PvP player rather than after launch.
Unreal Engine client, authoritative match services and an on-chain ownership layer
Every item below is visible in the shipped product.
Unreal Engine mobile client
The game client for Android and iOS: the run itself, the three character classes and their abilities, the hero collection, the shop and the league screens.
Server-authoritative match services
The services that own a race while it is running, so the outcome of a Battle Run is decided off-device and the same result is reported to all three players.
MMR matchmaking and ranked leagues
Rating-based matchmaking feeding a league ladder, with unranked play alongside it. Matchmaking constraints compose badly, which is why it shipped after the third PvP slot rather than with it.
Anti-cheat
Validation on the authoritative side rather than trust in the client, because the reward loop makes a successful exploit permanent.
On-chain hero ownership and marketplace
Hero and skin ownership, the access-ticket and genesis mints, and the marketplace where those assets change hands — on BNB Chain, so a player holds the asset rather than a database row.
Purchases, shop and live ops
In-app purchases with a fiat route into the item shop, plus the live-ops surface behind seasons, passes, upgrade systems, new maps and tournament rooms — the machinery that lets a live game change without a client patch.
Where the on-chain boundary actually sat
The one decision that decides whether a Web3 game is playable.
Ownership on-chain, gameplay off it. Heroes, skins, tickets and the marketplace are on BNB Chain, where a player can hold, trade or sell them independently of the client. The race is not: a 1v1v1 result has to be settled inside a tick, and no chain settles anything on that timescale. Put the match on-chain and you have a slideshow; put ownership in a database and you have a normal free-to-play game wearing the word Web3.
Everything downstream follows from that line. The authoritative match service reports a result; the reward that result earns is granted through the game's own economy; and only the artefacts a player is meant to own outlive the session on chain. Which also keeps the failure modes separate — chain congestion delays a trade, not a race.
Web3 in games: what actually belongs on-chain · Smart contracts
The published milestones, and where our four months sit in them
Taken from Metarun's own published roadmap rather than from our notes, so it can be checked against the page it came from. The order is the product's; the calendar is the client's.
Concept and prototype
Concept documentation and community launch, then a product prototype and the token generation event.
PvE alpha, then two-player PvP
A closed PvE alpha and the Play Store release, followed by the first PvP mode and the iOS build.
Third player, and anti-cheat with it
Closed beta on access tickets, the 1v1v1 mode, anti-cheat protection and a new map.
Open beta and MMR matchmaking
Genesis mint, open beta, the character recharge system and rating-based matchmaking.
Ranked play and a real shop
Leagues and unranked modes, the in-game item shop, fiat purchases and the App Store release.
Global release and live ops
Custom rooms, seasonal passes, character upgrades and the tournament machinery a competitive title needs to keep a ladder alive.
Those milestones run from a late-2021 concept to a global release announced for early 2024, and our engineering inside that span was four months. The rest of the calendar is the client's and not ours to take credit or blame for: token sales, beta windows, store submissions and marketing beats sat between the milestones, and none of them are development time. It is worth stating in both directions — four months is a fast build for this scope, and a two-and-a-half-year roadmap is not evidence that it was a slow one.
What the backend had to hold: 39,000 concurrent players at 60 ms, 99.8% uptime in production
The measured peak was 39,000 concurrent players, reached during an in-game event and published with the client's permission. An event peak is the honest way to read that number: it is what the tier autoscaled into on its busiest hour, not a steady-state figure, and event traffic is exactly the shape that breaks a backend designed against an average.
It is also the number that makes the rest of this page concrete. Three players per race at that concurrency is on the order of thirteen thousand simultaneous authoritative races, each one owning its own state, each one matched by rating before it starts. That is the load the single-writer design and the connection-count autoscaling exist for, and it is why load simulation ran against a multiple of the target rather than the target.
Alongside it, 60 ms average round-trip to the match service — measured as the round trip from the client to the authority and back, which is the figure that decides whether a race feels fair rather than whether a server is busy. It is deliberately stated as RTT to the match service and not as "latency", because the two get quoted interchangeably and mean different things; the 62 ms quoted for a different project elsewhere on this site is a different measurement of a different game.
And 99.8% uptime in production, which is roughly an hour and a half of unavailability a month. Across the whole history of the project, beta and early operation included, the figure is 98% — both are stated because quoting only the better one would be the ordinary way to publish this, and the gap between them is the part a reader can learn something from: almost all of the downtime a live game accumulates happens before it is a live game.
What breaks, in order, on the way to that number · What concurrency like that costs to run
What this page does not claim
The absent numbers are absent on purpose.
The concurrency, latency, uptime, team-size and duration figures are published with the client's permission. Retention, revenue and installs-to-payers are not. Those belong to the studio that runs the game, and this page publishes none of them. The download and rating numbers above are Google's, read from the public listing on the date given, and they measure the store rather than our delivery.
Nothing here is a statement about $MRUN as an asset. The token exists and the game's economy uses it; its market behaviour is not an engineering outcome, we do not comment on it, and no figure about it appears on this page.
The other numbers on this site belong to other projects. Metarun's own peak is the 39,000 above. The 52,000 peak concurrent players, 62 ms latency and 99.98% uptime quoted in our multiplayer game backend case study come from a different title, and mixing the two would flatter both.
The picture behind the title is the client's, not ours. It is one of the screenshots on the game's own Google Play listing, cropped to shape and otherwise untouched. Metarun is published there by Encore Games: the game and its art are theirs, the engineering described above is ours.
How much does a game like this cost to build?
Three engagements in one, and only one of them is banded.
A title of this shape is three builds that have to agree with each other: a mobile game client, a real-time authoritative backend, and an on-chain ownership layer with a marketplace. We publish bands for the work we can band and quote the rest, which is why there is no single figure for the whole title — the backend half runs $40,000–$90,000 priced by development time, while marketplace and contract work stays quoted against contract complexity and audit scope.
What we can publish is the shape of the team that did it and how long it took: six engineers, four months of active development, working as one team across the client, the services and the on-chain layer rather than as three groups with interfaces between them. On a title where the interesting bugs live exactly at the seams — prediction on the client against authority on the server, an in-game reward against an on-chain asset — that is a delivery decision as much as a staffing one, and it is the main reason we quote this kind of work as one engagement rather than three.
What is calculable in advance is the monthly infrastructure the backend runs on. On AWS list prices that is roughly $1,200 a month at 500 peak concurrent players and $6,900 at 5,000, with egress the largest line at every scale above the smallest — and for a title racing three players at a high update rate, egress is the number to model before the design is frozen rather than after.
Every band we publish, and the two we do not · The monthly bill, line by line · Build or buy the backend?
Common questions
What studios ask about a build of this shape.
Building a competitive mobile title?
We will review the authority model, the matchmaking constraints and where your on-chain boundary should sit, before any of the three is expensive to move.
Message received
We’ll review your enquiry and respond within one business day.