Story to game: what survives the translation and what does not

By Eduardo Orellana · Updated

Flockbay is free on your own Claude or ChatGPT plan. Claude Pro or Max, or ChatGPT Plus or higher, builds a real Godot project in the Godot editor. Claude Free and ChatGPT Free do not run here. More models are optional, a credit reload at API prices. Windows today. The engine is the official Godot release. A story and a game are made of different material. Some of what you have written will transfer almost intact, and some of it will resist for reasons worth understanding before you start.

What transfers cleanly

Place transfers. A described location becomes a built location with very little loss, and it is the part of your writing a builder handles best — a 3D coast you walk down, or a flat one you drag into place a cell at a time. If you have written a coastal town at dusk, that is a thing you can stand in.

Rules transfer. Anything in your story that works like a law — the dead do not speak after sunrise, iron burns the visitors, the bridge only holds one person — is already a game mechanic wearing a coat. Those are the most valuable lines in your notes.

Characters transfer as behaviour rather than as people. A guard who is bored, a merchant who overcharges strangers, a dog that follows you: each is describable as what it does, and what it does is code.

What resists

Interiority. Prose can say what someone is thinking. A game usually cannot, and the workarounds — journals, voiceover, a diary screen — are how the medium admits the loss rather than how it solves it.

Pacing. In a story you control exactly when the reader learns something. In a game the player might walk the other way for an hour. Any beat that depends on precise ordering needs either a gate or a rewrite, and gates are how a game starts to feel like a corridor.

The ending. Endings in prose land because everything before them was under your control. In a game they land when the player feels responsible for arriving there, which is a different craft and usually the hardest part to get right.

How the work goes in Flockbay

You build the place by hand. Which controls that means depends on the first question the app asks: 2D or 3D, shown as two pictures, with no default and nothing created until you answer. In 3D it is terrain, water, weather, time of day, buildings and characters, placed in the builder directly. In 2D it is ground dragged on a cell at a time, with the tiles, the edges and the collision all falling out of which cells you covered, and sprites set down at an exact position, turn and size. Either way your descriptions are the reference, and building from them is faster and more accurate than trying to re-describe them to a machine.

Then you convert the rules. Each becomes a request to Flockbay, which writes GDScript inside your project: the door that only opens at low tide, the character who will not follow you past the treeline, the item you cannot drop. You play the result and say what is wrong.

That loop is the method. Describe, play, judge, revise. You are not asked to read the code and you are very much asked to have an opinion about whether the scene works.

A practical order of operations

Start with one location and one rule. A single place you can walk through, and a single thing that behaves strangely in it, tells you within an evening whether the story survives being stood in. It very often does not, and that is a cheap thing to learn early.

Then add the second location and the way you move between them. Travel is where most story games either become alive or become a menu.

Only then worry about dialogue, quests and sequence. Those are the parts most writers want to do first and they are the parts that are worthless if the place is dull.

Dialogue, and the temptation to write more

Writers reach for dialogue first because it is the part they are already good at. It is also the part most likely to go unread, because a player who came to explore a coast will skip a screen of text to get back to the coast.

The usual fix is to cut dialogue by half and put the same information somewhere the player will meet it anyway: a room that is obviously abandoned, a boat with the name scratched off, a light that is on when it should not be. Environmental storytelling is not a technique, it is what the medium is good at.

Keep the lines you cannot express any other way. Those will land, and they will land harder for being rare.

The practical facts

Flockbay is a desktop app for Windows. It ships with Godot inside it, so your game runs locally at your machine's framerate. Your project is an ordinary Godot project on your disk, and Godot is open source.

Building needs an internet connection, because the chat, asset generation and world data come over the network. Playing what you built does not.

The platform is free. Flockbay is free on your own AI: your Claude or ChatGPT plan, your own agent, or an API key. Flockbay builds from a library of ready-made objects, or with Godot's own shapes.

More on this: A visual novel maker only if your novel has a place in it

Questions

Can I paste my whole story in and get a game?
No, and any tool claiming otherwise is selling something. The place is built by hand and the rules are converted one at a time, which is slower and produces a game rather than an outline.
Is this good for visual novels?
The reason to say no is shape rather than dimension. A pure branching-text visual novel is a script and a choice tree, and a tool designed for that will serve it better. What you build here is a place you move through, 2D or 3D, and if your story wants one of those it is the right way round.
How is dialogue handled?
Dialogue is code and content. Flockbay writes the system; the lines are yours, because that is the part you actually came here with.
Do I need to write code?
No. Flockbay writes GDScript into your project. You judge the result by playing it.
Does it run in a browser?
No. It is a desktop app for Windows and the game runs locally on the bundled Godot.