> 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/actions-and-state.md).

# Actions and State

Everything a player does reaches MetaMarket as an action, and everything a player has is state. Those are the two halves of the runtime: a game reports actions, the engine turns them into state, and the game reads state back. Almost every other concept in these docs is built from this loop.

## Actions

An action is a single reported event: a verb, a magnitude, and the entity it applies to. `tap` with a value of one on a particular character. `feed` on a particular pet. The game decides when an action happened and sends it; the engine decides what it means, based on that game's configuration rather than on hardcoded logic. An action type the configuration does not declare is not applied: the engine does not process it and reports it in the response's `skipped` count, rather than accepting it silently. A game's vocabulary of actions is explicit.

Actions travel one of two lanes:

* **No-receipt.** The game reports what happened and carries on. This keeps frequent events cheap.
* **Receipt.** The call returns a result in the same response, for actions like a spin that has to reveal what it produced.

An action's configuration fixes its lane, so you do not choose per call and every client behaves the same way.

Either lane returns a response the client must check. An action the engine declines is reported in that response rather than as an error.

## State

State is the current value of everything the engine tracks for a player, stored as keyed values against the player and the entity that owns them. A currency balance, a level, a pet's hunger, a stat: each is a value under a key, and the authoritative copy lives on the platform. State is the present, not a history. Reading it tells you where the player is now; it is not an append-only record of every change that got them there.

A player can own more than one of a thing. A game where someone raises several pets, or controls several characters, keeps each one's state separate by addressing it to a distinct entity, so two pets under one player never share or overwrite each other's values.

## The response carries the change

When an action changes state, the response says so directly. Alongside the domain result, a call returns the values it touched and full snapshots of the entities it changed, so a health bar or a currency counter updates from the action's own reply without a second request. Some values are computed rather than stored, a pet's mood derived from its hunger, for example, and those are recalculated and returned the same way. A game that keeps a live view of state folds these updates in as they arrive; a game that only needs the occasional snapshot can read current state on demand instead.

The wire shape of an action and its response is documented in [Sending Actions](/evaluate-and-integrate/events-and-directives.md) and [Reading State](/evaluate-and-integrate/reading-state.md).