A no-code game engine that is still a real engine

The phrase "no-code game engine" almost always describes a closed system. You get a visual editor, a fixed set of behaviours, and a game that only exists inside the tool that made it. That is a reasonable trade for a weekend prototype, and a bad one the moment your game needs something the menu does not contain. The ceiling is not a difficulty curve you can climb. It is a wall.

The other version of the trade is the browser tool. Your project lives on someone else's server, the editor runs at whatever framerate the tab allows, and the game you export is a web build with the performance that implies. Again: fine for a prototype, and a real constraint on anything you intend people to play for hours.

Flockbay takes neither trade. The engine underneath is Godot, which is open source and which serious games ship on. Your project is a Godot project. What sits on top is a layer that lets an AI build the world and write the code from a brief you approved, with the same world tools in your hands whenever you want them, and none of that removes the engine you are standing on.

More on this: An AI alternative to Unity, compared honestly

It starts with a brief, not a build. Flockbay asks what you want one round at a time, each question with a recommendation, and writes down what gets built first, what comes after and what is not in this version. Nothing is built until you approve it. That is the answer to the usual problem with describing a game to a machine, which is that you get its guess instead of your game.

Then it builds the world, with world tools that write real Godot data: nodes and resources in the scene tree, not a picture of a world. In a 3D game that means terrain, sculpted and painted, plus water, a sky, weather, plants, a player controller, characters and props. In a 2D game none of those appear, because none of them mean anything in a flat world. Both are first-class rather than a main case and a mode.

A flat world is tile ground, a band of scenery behind it, and sprites at an exact position, rotation and scale. The tiles, the edges and the collision are all derived from one map of covered cells, so the ground is walkable the moment it is painted. Whether a material stops a walker is declared rather than assumed, which is why a platformer's block and a top-down path are the same stroke. And most of the Catalogue is already sprites, the library Flockbay builds from: 55,073 of 60,648 objects.

It also writes the code. You say what should happen and it writes the GDScript that makes it happen, inside your project, where you can open it in the Script editor and change it. Then it play-tests its own work: it runs the game, sends input events, reads stdout and the debugger, GDScript parse errors included, and captures the viewport. The first time you press Play is not the first time the game has run.

Then it is your turn. You play it and say what is wrong, and it changes it, held against the brief you approved. When the call is pure taste, like exactly where a ledge sits, the same world tools are buttons around the Godot editor's own 3D and 2D view, so you can make that one change by hand, and Godot's undo takes it back. A sentence gets you a valley; your hand can get you the exact valley. You never have to touch those buttons.

That loop — you judge, it revises — is the normal way to work here, not a failure mode. Not writing the code does not mean not having an opinion about the game. It means the opinion is the part you supply.

More on this: A 3D game generator, and what actually gets generated

Flockbay is a desktop application for Windows, macOS and Linux, and it ships with Godot inside it. When you press play, the game runs locally, at your machine's framerate, with your machine's memory. There is no streaming, no render queue, and no tab.

This matters more than it sounds. A world with real terrain, weather and a few hundred simulated characters is not a thing a browser tool will run smoothly, which is why browser tools quietly steer you toward the smallest version of whatever you asked for. Running locally is what makes an open world a reasonable thing to attempt — and it is also what keeps the gap between changing a painted tile and seeing it near zero.

Building does need an internet connection. The chat, asset generation and world data all come over the network, so this is not an offline tool. The distinction worth holding is that building needs the connection and playing does not.

More on this: Make an endless runner where the tuning is the game

People who want to make a specific game, developers or not, on the free hosted AI or their own Claude or ChatGPT. Not people who want to click through a template and have something that resembles a game by the end of the afternoon — there are faster tools for that, and they are honest about what they are.

The work is real. You will spend time on the brief and on your world, you will play it and dislike parts of it, and you will send it back. What you will not do is learn GDScript first, or spend a week wiring a state machine before anything moves.

More on this: Make a farming game where the seasons actually turn