Charades where you type the clue instead of acting it out. A player types a free-text motion description, and DeepMotion's SayMotion API generates it live on a 3D character in about 20 seconds — everyone else races to guess what it just performed.
Design bet: watching an AI generate a chaotic physical interpretation of a friend's prompt, then racing to guess it, is fun enough on its own to want another round. Technical bet: a .glb file returned by a partner API can be downloaded and played back on a runtime-imported skeleton in Godot 4.6. Full concept in design/gdd/game-concept.md.
No player is ever judged on their own acting — the AI takes the credit or the blame, removing the embarrassment barrier Charades normally carries.
A weird or wrong AI-generated animation isn't a bug, it's the punchline. Features that make output more "correct" at the cost of funny lose.
The generated clip is the entire marketing engine — every UX and technical call defaults toward "this could be posted online in 10 seconds."
Real generation latency (15-25s) is a fact of the tech, designed around rather than hidden — every wait needs something to react to.
scripts/saymotion_client.gd is a from-scratch GDScript client for DeepMotion's SayMotion REST API — no SDK for Godot exists, so this reads raw HTTP responses, parses a session cookie by hand, and drives an async job through to a playable animation.
Found by reading the official SDK source and logging raw responses when the quickstart wasn't enough — the kind of debugging a forward-deployed engineer does against any partner's real API.
"Model not found" on every job, despite valid auth and a well-formed prompt — the quickstart doesn't mention a required parameter.
SayMotion requires a model param naming one of the account's own character model IDs. Added _ensure_model_id(), lazily resolved via listModels and cached for the session.
Code assumed the job id (rid) was numeric and cast it with int() — it crashed the moment a real job came back.
Logged the raw response: rid is an opaque string like "u5op75geKRgmDXVRfQAB21-text2motion". Never cast it — pass it through as-is.
Godot's HTTPRequest has no cookie jar — the API's session auth relies on the browser/client remembering a cookie between calls.
Parses the raw Set-Cookie response header by hand for the dmsess value, then threads it manually into every subsequent request.
This is a single-scene, single-screen local test — the point is to de-risk the SayMotion integration and the core fun loop before any production build starts. Failure is designed for: every network/API error surfaces its exact message in-UI, and a manual .glb-upload button stays available so a live playtest never hard-stops on an API hiccup.
.env, which is fine for a prototype but must never ship this way in productionThe full design (pillars, MDA player-psychology breakdown, MVP cut lines) was written down before any prototype code, so the prototype tested one clear hypothesis instead of drifting.
No Godot SDK exists for SayMotion — integrated the raw REST API directly: manual cookie handling, async job polling, and two undocumented requirements found by reading the source.
Every API failure surfaces its exact error in-UI, with a manual upload path as a fallback — production-grade resilience thinking applied even to a throwaway prototype.