How a playable game is made out of a story you already have

A game made this way generates no pictures at all, which sounds like a limitation and is the reason it works. By the time you make one, the hard visual work is done: you have a cast with approved renders and scenes with places and characters in them.

So a game is not another generation problem. What is actually undecided is where the choices go, what each one does, and which scene it leads to — and all of that is writing, not drawing.

That is worth saying because the obvious mental model is wrong. People expect making a game to be the biggest job of the three, because games are the biggest job everywhere else. Here it is the smallest, and it is the smallest because it inherits everything.

Two kinds, and their limits

Both are deliberately finishable in a sitting. The limits below are not placeholders waiting to be raised: a generated game that runs for two hours is a generated game nobody completes, and a sixteen-room adventure somebody finishes is worth more than a hundred-room one they abandon.

• Adventure — walk through the story scene by scene and choose what happens. Up to sixteen rooms, each with its own choices and where each one leads.
• Quiz — questions on the film you just made, with a score at the end. Up to ten questions.

A third kind is planned and is not here, which is worth saying plainly rather than leaving as an implication.

One engine, not generated code

This is the architectural decision that matters, and it runs against the obvious approach.

The obvious approach is to have a model write the game — actual code, per game, which then runs. It demos brilliantly and it fails in a specific way: every game is a fresh program, so every game has its own bugs, its own edge cases and its own ways of not working on a phone. You cannot fix any of them centrally, because there is no centre.

Here the model writes a specification — rooms, choices, where each choice leads, which cast member is in which scene — and a single engine reads it. Nothing is built per game. That means a rendering bug fixed once is fixed in every game that exists and every game anyone makes afterward, including the ones already shared.

It also means the spec is checkable. A room that points at a room that does not exist is a validation failure, not a dead end somebody discovers three choices into your game.

The cast walks in from the film

The characters in the game are the cast members you approved, using the renders that already exist. Nothing is drawn again, and nothing is re-imagined from a description — which is the same mechanism described in why the faces hold, applied to a different output.

This is why the order of operations is worth knowing. A game made after a film or a book inherits a cast that has already been looked at and approved. A game made first has to establish one, which is the same work wherever it happens.

What you end up with

A link. The game is hosted and plays in a browser, so sending it to somebody is sending them a URL rather than a file and an instruction to install something. That is most of the point for the audience this was built for — a game you cannot send to a friend in one message is a game that does not get played.

The same story can also be a printed storybook. Film, book, game: three endings for the same five stages, and none of them re-invents the characters.

What it is not

It is worth being clear about the ceiling. Sixteen rooms is a short adventure. Ten questions is a short quiz. There is no physics, no inventory, no combat and no save system, because none of those exist in the engine.

What it is good for is turning a story you already made into something a person can play through once and enjoy, in about the time it takes to read this post. That is a narrow thing to be good at, and it is genuinely good at it.