Live ยท adventure engine

Anima

A graphic-adventure creation system: write scenes and dialogue, place hotspots, run the AI art pipeline, and walk the result as a playable point-and-click game. I proved it by building a real game on it — a Lovecraft adventure, Shadow Over Innsmouth.

Creative AI toolchain Phaser + React Playable demo on request

Problem

A point-and-click adventure splits across writing, scene logic, character art, dialogue, inventory, runtime code, and testing — usually seven tools and a lot of glue. Anima collapses that into one system: author the story and interactions, generate the art, and get a scene you can actually play, with a review layer that catches placement and perspective bugs before they ship.

What I Built

Anima is built on StoryScript, a language I designed for point-and-click adventures, wrapped in a Phaser runtime, React tooling, a Hono API, Turso persistence, and an AI asset pipeline that produces characters, backgrounds, and spritesheets. The authoring side defines scenes, hotspots, dialogue, and inventory in StoryScript; the runtime turns them into a walkable point-and-click scene. Shadow Over Innsmouth is the game I built on top to prove the whole loop end to end.

Language StoryScript — my own DSL for scenes, hotspots, branching dialogue, and inventory.
Runtime Phaser scenes, walkable characters, hotspot interaction, scene transitions.
Art pipeline AI-generated characters and backgrounds, chroma-keyed and QC'd into spritesheets.

Built on StoryScript

The authoring layer runs on StoryScript, a plain-text language I designed for point-and-click adventures — scenes, hotspots, dialogue, and inventory written like a screenplay, with a headless engine that runs and validates the story before any art exists. Every scene in Shadow Over Innsmouth is authored in it (about 6,500 lines across four acts), and Anima is one UI drawing what that engine emits. It is its own project: see the StoryScript case study.

System Shape

An animated cutscene from Shadow Over Innsmouth — Kat and Hermes in the hotel lobby. This shows the production bar the system renders at: full scenes, lighting, and character animation, not placeholder art.
Anima editor showing the Arkham Bus Depot interior scene: two characters, a departures board, and the Scene Review panel that lets you switch and inspect scenes.
The authoring layer: the Arkham Bus Depot interior running in Anima with the Scene Review panel (top right). It shows how you switch scenes, toggle playable hotspots, and inspect what the runtime is doing over the live game.

The Art Pipeline

Characters start as AI-generated motion, then get processed into game-ready spritesheets. Nothing is hand-placeholdered — the pipeline is the production line.

Step one: a raw generated walk cycle (Skyler). This is the source material the pipeline captures before any processing — original character design, generated as video.
Step two: the same kind of source (Ashley) run through the pipeline — three processing variants compared side by side, chroma-keyed so the walk cycle can be sliced into a clean spritesheet. This shows the QC that keeps sprites consistent.
Public-safe Anima pipeline: authoring, dialogue logic, editor tools, asset pipeline, API and data, runtime, playable output, and review boundary.
This diagram shows how the pieces connect: authoring and dialogue feed the editor, the art pipeline feeds spritesheets, and the runtime composes both into playable output behind a review gate.

How the cutout actually works

Getting a clean transparent sprite out of AI video is the hard part, and the interesting decision is how. A generated walk cycle sits on a flat backdrop; the naive approach is background removal, but that fights skin tones against grey and leaves halos. So the pipeline uses a difference matte instead: it re-renders each frame twice with an image model — once on pure white, once on pure black — then reads the two side by side. A pixel that looks identical on both is the character (keep it opaque); a pixel that swings all the way from white to black is background (make it transparent). Because the model separates character from background semantically before the math runs, the alpha is pixel-perfect where a chroma-key would smear.

From there it is local tooling: decode the transparent video with the VP9 alpha decoder (the default one silently flattens it), scan for the frame where the walk loops seamlessly, trim every frame to one global bounding box so the character does not jitter, and pack the result into a Phaser spritesheet with JSON metadata the runtime loads directly. The magenta and blue backgrounds in the clips above are just that transparency previewed against a colour that makes stray pixels obvious.

Technical Decisions

  • Design a purpose-built language (StoryScript) instead of a JSON schema or an off-the-shelf engine — plain text that an LLM can write, a human can read, and the runtime executes directly with no compile step.
  • Separate authoring primitives from runtime behavior, so a scene can be edited and played from the same source of truth.
  • React for tooling, Phaser for execution — each framework does the job it is good at instead of one doing both badly.
  • Treat AI as a production pipeline, not a chat box bolted onto the game — and extract alpha with a white/black difference matte instead of background removal, so skin tones on a grey backdrop come out clean.
  • Build a real game (Shadow Over Innsmouth) to validate the system, rather than shipping an abstract engine with no proof it holds up.
  • Verify scenes in a local browser harness — movement, perspective scale, hotspot coverage, and door transitions get checked against the running game.

What This Proves

Anima is the part of the portfolio that is hardest to fake: taste and system design in one place. It joins creative direction, authoring UX, full-stack implementation, runtime engineering, and an AI art pipeline into something you can sit down and play.