> ## Documentation Index
> Fetch the complete documentation index at: https://docs.alakazam.gg/llms.txt
> Use this file to discover all available pages before exploring further.

# Interactive experiences

> Put a live, playable world-model stream inside your own app — mint a session on your server, mount the player in your client, and let your users drive it.

An Alakazam world isn't a video you render — it's a **live world-model stream
your user drives in real time**. The model generates the next frames as the
player acts, so the experience is interactive all the way down: no pre-baked
levels, no canned clips. This page is the map for building that into your
product — the shape every integration shares, and which guide covers each part.

## The shape of every integration

Whatever you're building — a web embed, a native app, a character your users
talk to — the flow is the same three moves:

<Steps>
  <Step title="Have a world">
    Generate one from a premise (`POST /v1/worlds`), build one visually in the
    Studio, or import one. A world carries its own state graph — states,
    choices, endings — that your code can read and react to.
  </Step>

  <Step title="Mint a session on your server">
    Your secret key stays server-side. Exchange it for a short-lived session
    token bound to a world, a player identity, and your origin:

    ```javascript theme={null}
    // your backend
    const r = await fetch("https://api.alakazam.gg/v1/sessions/token", {
      method: "POST",
      headers: {
        Authorization: `Bearer ${process.env.ALAKAZAM_SECRET_KEY}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ worldId, playerIdentity: user.id, origin: "https://yourapp.com" }),
    });
    const { token } = await r.json(); // hand THIS to the browser
    ```
  </Step>

  <Step title="Mount the player and hand your user the controls">
    In the browser, the SDK boots the world with that token and the stream goes
    live — your user plays it directly:

    ```javascript theme={null}
    import { createEmbed } from "@alakazamworld/embed";

    createEmbed({
      container: "#game",
      slug: "mystical-forest",
      token,
      onReady: () => console.log("playing"),
    });
    ```

    Native instead of web? The same session flow drives the
    [Unity](/unity), [Unreal](/unreal), [iOS](/ios), and [Android](/android)
    SDKs.
  </Step>
</Steps>

That's the whole architecture. Everything else — continuity, characters,
authoring, data — is a layer on top of this loop.

## Pick your path

| You want to build                                      | Read                                                                                                             |
| ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------- |
| A playable world inside a web app                      | [Embedding](/embedding)                                                                                          |
| Long sessions that stay visually sharp                 | [Session handoff & continuity](/sessions)                                                                        |
| A native game or app (Unity, Unreal, iOS, Android)     | [Engine SDKs](/unity)                                                                                            |
| A character your users talk to, with per-player memory | [Characters](/characters)                                                                                        |
| The world itself — generate, edit, version it          | [World generation](/world-generation-examples), [Studio worlds](/studio-worlds), [Graph editing](/graph-editing) |
| Synthetic gameplay data, no end user in the loop       | [Simulation & data generation](/simulation)                                                                      |

Characters and simulation are the same primitives wearing different clothes: a
character is a world that talks (`/say`, `/tts`, cross-session memory), and
simulation is a session your code drives instead of a person. If you can mount
a world, you already know how to do both.

## Sessions are the metering unit

A live stream reserves `session_seconds` against your daily budget, fail-closed
— when the budget is gone, new sessions get a `402` instead of a surprise bill.
Concurrency is capped per app and settled when a session ends. Numbers and
knobs: [Pricing & billing](/pricing), [Rate limits](/rate-limits).

<Note>
  The live embed path currently fires `onReady` and `onError` on the page side;
  richer gameplay callbacks (`onChoice`, `onEnding`) are delivered on the test
  path today and are rolling out to the live player bridge — see
  [Embedding](/embedding) for the current support matrix before you build page
  logic on them. Inside the player, your user's controls are live either way.
</Note>

## Next steps

<CardGroup cols={2}>
  <Card title="Quickstart" icon="rocket" href="/quickstart">
    API key → generated world → playable embed, in one sitting.
  </Card>

  <Card title="Embedding" icon="square-code" href="/embedding">
    Mount options, events, theming, token refresh, cross-origin security.
  </Card>

  <Card title="Session handoff & continuity" icon="repeat" href="/sessions">
    The drift-refresh double-buffer that keeps long streams clean.
  </Card>

  <Card title="Talk to a character in 5 minutes" icon="message-circle" href="/character-demo">
    The smallest end-to-end interactive integration you can run today.
  </Card>
</CardGroup>