> For the complete documentation index, see [llms.txt](https://sdk.metamarket.tech/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sdk.metamarket.tech/core-concepts/one-player-many-games.md).

# One Player, Many Games

A studio runs more than one title. Sooner or later the same person plays two of them.

That person is one player. The titles are separate products, with separate teams, separate release schedules, separate economies, and separate balance decisions. Both of those facts have to hold at once, and they pull against each other. This page is about that tension, because it is the problem MetaMarket exists to solve and everything else on this site is downstream of it.

## Two things that are not the same

**Cross-platform** means one game, one player, several devices. A player installs your game on a phone and a desktop and expects the same save.

**Cross-game** means several titles, one player, and state that mostly must not be shared. A player who has been with the studio for two years should not arrive at the newest title as a stranger, but the newest title must not be able to reach into the older one.

MetaMarket handles both, and it uses the same device-linking step for each, because a second game installed on the same phone looks exactly like a second device to the platform. The two ideas are still different problems, and the rest of this page is about the second one.

## Why you cannot simply share everything

The naive version is one database for the whole studio. It fails on the first real question.

Suppose Game A and Game B both have a soft currency called coins. If coins are shared, then a balance change in A is a balance change in B, and every economy decision in A is now an economy decision in B. Tuning a drop rate in a live title silently retunes another team's game. Worse, a bug or an exploit in the newest, least-hardened title drains value out of the studio's most valuable one.

So local state has to stay local. But if everything is local, there is no shared player relationship, and the second title starts from zero exactly as it would have without a platform.

The useful system is neither. It splits player state into two scopes and puts a controlled path between them.

Simplified to two games. The solid and dotted edges are real permissions, not decoration.

```mermaid
flowchart TB
    subgraph Local["Local: one game's own tenant"]
        A["Game A<br/>coins, quests, inventory, progression"]
        B["Game B<br/>its own coins, quests, inventory"]
    end
    subgraph Shared["Shared: platform-owned"]
        ID["Player identity"]
        VAL["Platform currency<br/>and loyalty standing"]
    end
    A -. "cannot read or write" .-> B
    A -- "declared milestone,<br/>emitted server-side" --> VAL
    B -- "declared milestone,<br/>emitted server-side" --> VAL
    ID --- A
    ID --- B
    VAL -. "not readable by a game" .-> A
```

## What belongs to one game

Everything the game's own design decides. Its currencies, its resources and quotas, its quests, its inventory, its progression, its shop and its listings. All of it is stored under that game's own tenant and is not readable or writable by any other game, including other titles from the same studio.

This is the default. A piece of state is local unless there is a specific reason for it not to be.

## What spans the games

A deliberately small set: who the player is, and what standing they have built with the studio's games collectively.

Identity is one durable player record that a person carries between titles. Standing is the platform currency and the loyalty ladder, which reflect activity across every connected game rather than any one of them.

The set is small on purpose. Every item in it is something a player would reasonably expect to keep when they open the next title, and nothing in it is something an individual game needs to tune.

## What a title may report

A title reports its own gameplay. Actions the player took, against the vocabulary that title declared in its configuration.

It does not report shared outcomes. A game cannot say "give this player 500 of the platform currency", because a game that could do that could mint shared value, and the value would be worth whatever the least careful title in the portfolio decided.

Instead, the connection is declared rather than called. A game's configuration marks certain of its own achievements as milestones. When one of those actually completes inside the game, the platform is told that the milestone happened, and the platform decides what it is worth. The signal is emitted by the platform's own engine when the reward behind the milestone is delivered, not sent by the game's client, so a client cannot fabricate one.

The platform currency is called GG on this site. A grant is not instant: the platform-owned quest that turns a milestone into GG or loyalty points is evaluated the next time the player touches a platform surface, so the credit appears then rather than at the moment the milestone fired. Design for that delay rather than against it.

Each game has a second, much shorter list, agreed with MetaMarket, of the milestone keys the platform will honour from it at all. That list is deliberately narrower than the game's full action vocabulary, and a key outside it is ignored.

## What a title may read

Its own state, in full. The shared identity's id and display name, so it knows which player it is serving.

Not the platform currency balance, the loyalty points, the tier, or the badges. Not any other title's state. A game can cause shared standing to change through the milestone path and can never observe the result, which is what stops the shared layer from becoming an input to a single game's balance decisions.

Where a player sees their standing is on surfaces MetaMarket operates.

## Who may change shared state

Shared standing, meaning the platform currency and the loyalty ladder, is written only by MetaMarket. A connected game is an input to the platform-owned quests that grant it, and never a writer of their outcome.

Identity is the exception, and it is worth being precise about. A game's client does create and link identity: signing a device in for the first time creates a player, and the handoff step binds another install to that same player. What a game cannot do is read or alter another game's state through that identity, or change what the player's standing is worth.

So the rule is not that games never touch the shared layer. It is that a game can create the player it is serving, can cause standing to change through the milestone path, and can never set the amount or read the result.

This is the part worth checking rather than believing. [Security and Tenant Isolation](/architecture-and-trust/security-and-tenant-isolation.md) documents the enforcement.

## Terms used on this site

The same object goes by four names in different contexts, so they are fixed here.

| Term             | Meaning                                                                                                                                               |
| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| Game, title, app | The same thing: one registered product with one `app_id`. Its data is scoped to that id.                                                              |
| Tenant           | Anything registered with an `app_id`, which includes the games and also MetaMarket's own modules. Every game is a tenant; not every tenant is a game. |
| Local state      | State belonging to one game, invisible to every other game.                                                                                           |
| Shared state     | Identity, the platform currency, and loyalty standing. Platform-owned.                                                                                |
| Cross-game       | Spanning several separate titles.                                                                                                                     |
| Cross-platform   | One title, one player, several devices.                                                                                                               |
| Portfolio        | The set of a studio's titles connected to MetaMarket.                                                                                                 |
| Milestone        | A game achievement its configuration declares as eligible to reach the shared layer.                                                                  |

## Where this goes next

[Architecture Overview](/architecture-and-trust/product-overview.md) shows the services that implement this split and where each kind of data lives. [Local and Shared Economies](/core-concepts/shared-economy.md) gives the exact read and write permissions object by object. [Players and Identity](/core-concepts/players-and-identity.md) covers how one person stays one player across devices and installs.