How Does One Runtime Pay for a Whole Catalog of Games?
The pitch for a universal runtime sounds too tidy: write once, run everywhere, and let one piece of infrastructure carry a whole catalog of games. Skepticism is fair — but the economics aren't hand-waving. They come from deleting a cost category, not from a discount. Let's open the hood.
Q: What does a shared runtime actually save?
The expensive part of shipping a game isn't the idea, it's the factory: a build per platform, an app-store submission per title, a payment integration per market, a QA cycle per release. A runtime collapses all of that into one. You write your game once against the runtime's APIs, and the runtime handles the build, the store relationship, the payments, and the distribution. The saving isn't a discount; it's the removal of an entire cost category.
Q: How does marginal cost behave as I add games?
It falls, and that's the whole point. The first game on a runtime carries most of the fixed cost — the integration, the learning, the setup. The tenth game is closer to a config file: new content, new skin, same plumbing. Your per-game cost curve slopes down hard, the opposite of running N separate native apps where every title re-pays the full factory.
Q: What's the value of a shared user pool across games?
This is the part spreadsheets miss. When several games sit on one runtime and one catalog, a player who bounces off game A can be nudged to game B without a fresh install or a fresh acquisition cost. Cross-promotion inside the runtime turns your existing players into your cheapest UA channel — effectively free, and far warmer than any ad network. A catalog compounds; a pile of disconnected apps doesn't.
Q: Where's the coupling risk?
You're betting on the runtime's stability and roadmap. If the runtime changes an API or goes down, every game feels it at once. That's the real trade: you swapped N independent failure modes for one shared one. Mitigate it by keeping your game logic portable and your dependence on runtime-specific features minimal, so a switch or a fork stays possible.
Q: Is it worth it for a single independent game?
If you have one game and no catalog ambitions, a runtime mainly buys you distribution and payments without the store tax — worth it, but the compounding advantage hasn't kicked in yet. The economics really sing once you're running three or more titles, because that's when the marginal-cost slope and the shared pool start paying you back. One game saves a little; a catalog saves structurally.
| Cost line | Do it yourself | On a runtime |
|---|---|---|
| Per-platform build | N builds | one |
| Store submission | N reviews | handled |
| Payment integration | per market | shared rail |
| User acquisition | cold every time | warm shared pool |
| Cross-promotion | you build it | built in |
