Skip to content

Getting Started

Lattice's headline promise is write once, target both: one game-sim source file compiles, with no code change, into a trusted native binary you run on your own fleet and a sandboxed WASM module the platform runs for you. You pick the hosting model at build/deploy time — your simulation code is identical either way.

flowchart TD
  START([Start]) --> COMMON["Common setup<br/>① register a game in the portal → gameId + API key<br/>② integrate the SDK / engine binding<br/>③ author your game-sim against the C ABI"]
  COMMON --> Q{Where will the<br/>authoritative server run?}
  Q -->|"On infrastructure I trust<br/>(my fleet / a player's P2P host)"| A["Path A — Self-hosted / P2P (native)"]
  Q -->|"On Lattice infrastructure,<br/>managed for me"| B["Path B — Managed WASM hosting"]
  A --> A1["build native + link liblattice<br/>run your dedicated server or P2P host"]
  B --> B1["compile the SAME source to wasm32<br/>upload → import-scan → schedule"]
  click A "self-hosted/" "Path A"
  click B "managed-wasm/" "Path B"

Choose your path

  • Path A — Self-hosted / P2P (native) { .path-a }

    Build your module native and link liblattice. Run your own dedicated server, or let a client be a P2P host. You already trust the code — no sandbox needed. Tied to design 07 — Custom Module Guide.

    Path A walkthrough

  • Path B — Managed WASM hosting { .path-b }

    Compile the same source to wasm32, upload it to the console; it is import-scanned and scheduled to run in a capability sandbox next to other tenants — safely. Tied to design 09 — WASM Managed Hosting.

    Path B walkthrough

Both paths share the same first three steps

Whichever hosting model you pick, you start with the common setup: register the game, get a gameId + API key, integrate the SDK, and author your sim against the C ABI. The decision only changes how you build and deploy — see write-once, dual-target for why.