Mochi Media: The API That Automated Flash Game Ads and Cross-Promotion
A single line of ActionScript could hand a developer ad revenue, a cross-promotion network, and a virtual currency system all at once. For a few years that line was everywhere, and when the service behind it went dark, it took a piece of gaming history with it.
Before any standardized ad service existed for browser games, a developer who wanted revenue from a finished Flash game had to solve several problems separately. Ad sales meant contacting portals or ad networks directly and hoping for a deal that scaled below the biggest sites' minimum traffic requirements. Cross-promotion meant manually swapping banner links with other developers, one relationship at a time. Getting a game noticed on more than one or two portals meant repeating that outreach for every site the developer wanted to reach. None of it was automated, and for a solo developer with a finished game and no negotiating leverage, the entire process could take longer than making the game itself.
What integration actually looked like
The service that changed this arrived as an ActionScript library a developer could drop into a project with a small amount of setup code. Once the code was in place, the game could display a "more games" screen pulled live from a shared catalog, show a banner ad sold and rotated automatically, and report play statistics back to a central dashboard the developer could check without asking any single portal for numbers. Portals benefited too: embedding a game that already carried this code meant instant access to the same ad inventory and cross-promotion catalog, without the portal having to negotiate its own separate deals for every game on its front page.
The cross-promotion wall
The most visible part of the system, to players, was the end-of-game screen offering a grid of other titles to click into next. That screen was not tied to any single portal; it pulled from a shared pool that every participating game and site drew on, which meant a small, independently made game could appear as a recommended next play inside a much larger, more polished title, and vice versa. For developers this was free distribution that no individual cross-linking deal could have matched, and it is a large part of why so many mid-2000s Flash games ended up looking similar in their closing screens regardless of which portal a player found them on — see our piece on how one Flash game ended up on a hundred portals for the broader distribution picture this fit into.
Virtual currency before it was standard
The platform also introduced its own in-game currency system years before virtual currency became a default expectation in casual and mobile games. Players could earn or purchase coins usable across any participating game, and developers who built in-game shops using that currency got a payment and fraud-handling layer they would otherwise have had to build themselves. It was, in effect, an early and largely forgotten preview of the free-to-play economy that would later define mobile gaming, running quietly inside Flash games that most players never thought of as having a business model at all. That business model sat alongside more direct sponsorship arrangements developers negotiated separately, a system covered in more detail in our look at the sponsored Flash game economy.
The shutdown, and what it broke
The service's ad-serving and cross-promotion infrastructure was discontinued in the mid-2010s, and because so many games had that ActionScript code baked directly into their compiled swf files, the shutdown did not just end future revenue — it broke the games themselves. A game built to call out to a live API for its more-games screen or its ad slot would, once that API stopped responding, either display a broken loading state, throw a visible error, or in some configurations hang entirely on a blank frame. Preservationists cataloguing Flash games years later found this to be one of the more common and frustrating failure modes among otherwise perfectly playable titles: the game logic worked fine, but a network call baked in near the start of the file never returned, and depending on how defensively the developer had coded around that call, the whole experience could be blocked from ever starting.
Why this matters for playing old games today
Anyone running an old Flash file through a modern emulator today may still run into this exact failure, and it is worth knowing the cause rather than assuming the emulator itself is broken. Archival copies of the original ad and API servers, where they exist through projects like the Internet Archive's Wayback Machine, occasionally let preservationists reconstruct enough of the expected server response to unstick a game, but plenty of titles from this era remain permanently stuck at their loading screen for exactly this reason. It is a useful reminder that a Flash game was rarely just a single self-contained file; for a large share of the games made during this period, playability depended on a server that no longer exists.