Make a mobile game with AI: build it on a desktop, honestly

Flockbay is a desktop app for Windows and Linux. You install it, you build there, and the game runs locally on the copy of open-source Godot that ships inside it. There is no phone version of the app and no browser version.

That is not a strange arrangement. Almost nobody makes a mobile game on a phone, because the work involves a lot of playtesting, a lot of reading what went wrong and a lot of looking at things side by side, and a small touchscreen is a poor tool for all three.

What is worth being clear about is that Flockbay does not have a button that puts your game on a phone. Its Export makes a native Windows build, an .exe. Your project is a genuine Godot project on your disk, which stock Godot opens, and Godot's own export can take it to Android. Getting from there to a store listing is separate work with Godot's export tooling and the platform's developer requirements. That part is yours.

More on this: Multiplatform game maker: Godot underneath, so export is not proprietary

The design constraints of a phone game are mostly about input and attention. A thumb covers a third of the screen. Sessions are short and interrupted. Precision is unreliable, so anything that needs a pixel-accurate tap is a bad idea.

So say it is a phone game when Flockbay asks its first questions. Those answers go into the brief, and the brief is what every later change is held against. A level laid out for a mouse and keyboard rarely converts cleanly, so it is better to build knowing the constraint than to build freely and adapt later.

Touch input itself is code. Describe how the controls should work — drag to move, tap to interact, hold to charge — and Flockbay writes the GDScript in your project, then plays it by sending input events to check it responds. You will still want to feel it on an actual device before deciding it is right, and that is a step worth planning for early.

More on this: Free mobile game maker: read this before you download anything

It starts with a brief. Flockbay asks questions one round at a time, each 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.

Then it builds the world and writes the code. Most phone games are flat, and a flat world is tile ground (the tiles, the edges and the collision follow from which cells are ground), a band of scenery behind it, and sprites at an exact position, rotation and scale. A 3D one is terrain, water, sky, weather, plants, the player controller and props. Either way it is real nodes in the scene tree, and the movement, interaction, progression and saving are GDScript in your project. Then it play-tests its own work: it runs the game, sends input events and reads the debugger.

You judge the result by playing it and say what is wrong. When a call is pure taste, like exactly where a platform sits, the same world tools are buttons around the Godot editor's 2D and 3D view, so you can make that one change by hand and Godot's undo takes it back. That loop is the same whether the game ends up on a desktop or a phone.

More on this: Flockbay is not a VR game maker

If your goal is specifically a mobile free-to-play game with in-app purchases and ad mediation, this is not the shortest path and there are toolchains built for exactly that.

If your goal is a game you care about that you would like to also exist on a phone, building it properly on a desktop first is the right order, and the fact that it is a normal Godot project keeps that option open.

Building needs an internet connection because the chat and asset generation are network services. Playing what you built does not. Flockbay is free, AI included: free hosted AI every day, or your Claude or ChatGPT plan, your own agent, or an API key.

More on this: No-code mobile game maker: check the ceiling before you commit

Whatever your pipeline to a phone ends up being, get something on a real device early. Everything about a phone game is different in the hand: the screen is smaller than you remember, your thumb is in the way, and outdoor light washes out anything subtle.

Text size is the usual casualty. Interface that is comfortable on a monitor is routinely unreadable on a phone, and the fix is a layout decision rather than a scaling one.

Battery and heat are the other thing a desktop will never tell you. A scene that runs fine on a computer can be an expensive scene on a phone, and the sooner you know, the fewer things you have to undo.