---
title: Cookbook
area: globals
globals: []
sources: [src/inject.ts]
---

# Cookbook

Recipes: how to BUILD a whole thing out of the SDK — not what one API does (that is the
[reference](/docs/api/index.md)), but which pieces to combine, in what shape, and how to know it works.
Each recipe is written for the assistant that builds a project as much as for a person: read the
one whose title matches the task before designing from scratch.

| Recipe | Builds | Reference project |
|---|---|---|
| [Project architecture for a game](https://le.codes/docs/api/cookbook/project-architecture.md) | the layout of a game that keeps growing: one-line entries over a shared `boot`, devices → a plain input struct → simulation aspects → EVENTS → systems that only listen (audio, FX, HUD, rumble), level objects as placed aspects found by `Aspect.all`, the game mode as the one wiring point, every number in `config.ts` — and four checks that tell whether the shape holds | `fps-demo` |
| [Game AI with state machines](https://le.codes/docs/api/cookbook/game-ai-state-machines.md) | enemies + allied bots: perception, a squad blackboard, a brain as one state table, weapons and the game mode as machines, a player on the same input seam | `arena-cubes` |
| [Many characters on screen (culling + LOD)](https://le.codes/docs/api/cookbook/many-characters-lod.md) | a crowd of skinned models at a steady frame rate: culling that is safe for animated bodies, mesh + skeleton levels from `lecodes assets doctor --lod`, distance-scaled animation, the `Model.lod` / `Animator.lod` knobs | `fps-demo` |
| [AI-generated 3D assets (Meshy → GLB → game)](https://le.codes/docs/api/cookbook/ai-generated-assets.md) | a model from a text prompt or an image, in the game: the generator as the assistant's skill, raw output kept out of `assets/`, `lecodes assets doctor` for scale / textures / KTX2, clips through `retarget` (humanoids and quadrupeds), what to check on a desktop render, credits and licence | none yet (asset half: `tools/assets` README) |
| [Native plugins (host capabilities)](https://le.codes/docs/api/cookbook/native-plugins.md) | a capability the SDK doesn't have — hardware, an OS API, a vendor library — behind the Service channel: the typed facade, a desktop `.dll`/`.so` in C or Rust that needs no host rebuild, shipping it with the app, and the iOS / Android halves of a plugin of the project (a contract + `lecodes plugin gen`) | `hosts/desktop/plugin-sdk/example` |

## How a recipe is written

Every recipe has the same skeleton, so the part you need is where you expect it:

1. **When** — the task in two lines, with the words a reader would search for.
2. **The shape** — which files, what is an aspect / a system / plain data, who ticks in which
   phase, what stays in the SDK and what is the project's own.
3. **Steps** — the minimal compilable skeleton per part. Real SDK calls, no invented helpers; the
   full version lives in the reference project.
4. **Verify** — the console lines to print, the `tests/*.flow.json` to keep, what runs headless and
   what needs `--desktop`, how to keep the run deterministic.
5. **Traps** — what went wrong while building it and the fix.

A recipe is anchored to a reference project and the date it was last verified there. The reference
projects are not published yet, so a recipe must stand on its own: every step carries the code it
needs, and the project is named only as the place the shape was proven. A published examples
channel will turn those names into links.

Frontmatter: `summary:` — ONE line that starts with when to read the recipe ("Read before…" /
"Read when…"); it is what `llms.txt` on le.codes shows an assistant next to the link, so it has to
let the assistant decide without opening the page. `globals: []` — a recipe never becomes the canonical home of a global (the reference
page does); `sources:` lists the SDK files the recipe relies on, so `docs:check` catches a rename.