> 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/overview/capabilities.md).

# What You Can Build

A studio composes its game from a small set of parts the engine already runs, wired together through configuration rather than built from scratch. The shared cross-game economy sits above them and stays platform-owned. The examples below use a pet game, a spin game, and a test app to keep it concrete.

## Engagement and loyalty mechanics

These are the core of [Engagement and Loyalty](/use-cases/engagement-and-loyalty-use-cases.md). The parts are in place; a studio shapes them into its own program and sets the reward balance.

* **Quests.** A quest runs a built-in lifecycle (accept, evaluate, claim, complete), with staged, sequential, or parallel orchestration for multi-step chains. Progress is measured two ways: a delta since the quest was accepted, or an absolute value like a level. A "grow your pet" chain, for example, uses staged orchestration, unlocking each step once the previous one is claimed and checking against an absolute growth stat.
* **Recurring challenges.** Daily quests and rotating stock renew on their own on a schedule, or when an action triggers it, and each repeat is a fresh instance. A set of daily quests refreshes the next time the player opens the game, with no cron job behind it.
* **Progression and achievements.** Progression rules and milestone checks run against player state, so achievement rewards and progression tracks are configuration, not custom code.
* **Rewards and inventory.** A single reward package carries anything through grant, store, open, and fulfill, and can nest other packages inside it. Quest rewards, spin results, and starter kits all ride the same delivery path. A spin result, for instance, grants a package; a nested currency-and-cosmetic package inside it resolves in one call.
* **Refillable quotas.** Anything shaped like "so many uses per day" (energy, care actions, spin tickets) refills instead of running out for good. A pet game might cap care actions at four a day and top them back up at the next daily boundary.
* **Shared loyalty standing.** Loyalty points, a live tier drawn from the balance, and a Bronze/Silver/Gold/Platinum badge ladder are platform-level, so a player's standing follows them across connected games and shows on platform-operated surfaces rather than being read or set inside a game. Higher-level loyalty and campaign tooling is on the [Roadmap](/releases-and-reference/roadmap.md).

For how these combine into daily loops, loyalty tiers, seasons, and onboarding, see [Engagement and Loyalty Use Cases](/use-cases/engagement-and-loyalty-use-cases.md).

## Track player activity and state

Underneath the mechanics, the platform records what players do and keeps their state current on read.

* **Actions.** One model covers anything a player does. A no-receipt path keeps frequent actions cheap, while a synchronous path returns a receipt when the game needs the result at once. A pet game might send `tap` on the no-receipt path and use the synchronous one only for a spin.
* **Resources.** Vitals, currencies, and stats settle at the moment they are read, not on a background timer, and never drop below zero. Some are computed from others: a pet's hunger decays continuously and is caught up on the next read, and its mood is derived from hunger without a row of its own.
* **Several subjects per player.** State is keyed per subject, so a game where a player owns more than one thing (several pets, several characters) does not need a second state model bolted on. Two pets under one player keep separate vitals and never collide.

## Engagement data

As a game runs, its actions, quest changes, rewards, and economy movements are captured in the platform's operational logs. Working with them is hands-on today, and the reporting layer on top is not built yet. [Operational Data](/use-cases/engagement-data-and-operational-insights.md) sets out what you can get now and what is planned.

## Identity and economy across connected games

This is the part a studio would otherwise rebuild and reconcile for every title.

* **One identity, every game.** A durable player record that a device proves possession of and a one-time handoff carries to another install, so a studio does not build and maintain its own account system. [Players and Identity](/core-concepts/players-and-identity.md) has the model, and [Product Availability](/overview/current-scope.md) records the sign-in methods available today.
* **The platform currency and loyalty standing.** GG, loyalty points, a live tier, and a badge ladder follow a player across their connected games. All of it is platform-operated: what a game builds against is the milestone it declares in its own configuration, which the engine emits when the reward behind it is delivered. [Local and Shared Economies](/core-concepts/shared-economy.md) gives the exact read and write boundary object by object.

## Marketplace foundations

The same inventory, item, and economy models a game already uses are what its trading runs on, so a studio configures these rather than building a separate marketplace. [Marketplace Workflows](/use-cases/marketplace.md) covers the scenarios in full.

* **Shops and offers.** A studio-managed catalogue priced in the game's own currency, delivering through the same reward pipeline as any other grant. MetaMarket's own storefronts run on these parts today.
* **Within-game listings.** A player lists an item they own at a price they set, and another player in the same game buys it. The item is escrowed the moment it is listed, so it cannot be listed twice, and it is priced in whatever currency that game already uses. Buyer and seller are always in the same game.
* **Across connected games.** A shared catalogue and cross-game features are planned extensions of these foundations, not available today; see [Product availability](/overview/current-scope.md).

Calling this a marketplace does not imply cross-game player-to-player trading, real-world money, external ownership, or unrestricted transfers. [Marketplace Workflows](/use-cases/marketplace.md) draws the line precisely.

## Change mechanics without redeploying

Everything above is authored as configuration, which is what lets a studio move quickly once it is integrated.

* **One delivery model.** A quest, a reward, a shop item, and a player listing all move through the same delivery path and one universal action, so they are variations on a single idea rather than four subsystems. Each keeps a stable address, so refreshing its contents does not break a client that already pointed at it.
* **Live state in the response.** A response carries an echo of the values an action touched, snapshots of the entities it changed, and any instruction the client should act on, so a health bar updates without a second fetch. After a `feed`, the new hunger and mood come back in the same response.
* **Deferred state updates.** A returning player is brought up to date as part of their next action, with no background job cycling in the meantime. A spin can grant a package set to open itself the next time that player does anything at all.

## What your studio controls

Game logic, content, and UX stay with the studio: the engine runs your configuration, not your rules or your screens, and each game's data stays scoped to itself. Where the studio-and-platform line falls in full, including the real-money boundary, is in [Studio and platform responsibilities](/architecture-and-trust/responsibilities-and-boundaries.md).

Once a capability here matches what you need, [Engagement and Loyalty](/use-cases/engagement-and-loyalty-use-cases.md) and [Game Economy Infrastructure](/use-cases/game-economy.md) show the parts combined into working loops, and [Evaluate MetaMarket](/evaluate-and-integrate/evaluate.md) is how a first flow gets built with the team.