A Defold alternative when you would rather not write Lua

Defold is free, with no royalties and no seat cost, and it has been used to ship real commercial games. Its build sizes are unusually small, which matters more than people expect when your audience is on a phone or a low-end laptop. Its editor is fast and its component model is clean.

It is also stable in the boring, valuable sense. Projects do not rot between versions the way they can elsewhere. If you have a 2D game running well in Defold, there is no argument here that you should move it.

Its constraints are the flip side of that focus. 3D support exists, but the engine is plainly centred on flat games, and that is a choice rather than a shortfall. The constraint that actually bites is that everything is Lua. You program, and the size of what you can build is the size of the Lua you are prepared to write.

More on this: The best free 2D game engines, and what "free" means for each

The obvious reading used to be dimension. Defold is centred on 2D, so anyone who wanted a valley to walk down went somewhere else, and that was the whole story of a Defold exit. It is not the story now. In Flockbay the brief settles which kind of game you are making, 2D or 3D, before anything is built, and a flat game gets flat tools rather than a 3D world with the depth switched off.

What does not move is the language. Lua is small and pleasant and learning it is still learning a programming language. For someone who wants a game rather than a programming hobby, that is the whole of it.

Flockbay answers that one, at a price. The engine underneath is Godot, open source and bundled inside the app. You do not write the code: from a brief you approve, Flockbay builds the world, writes GDScript inside your project, and plays the game to check its own work. What you give up is Defold's tiny footprint and its reach onto small devices, and neither is a small thing to give up.

More on this: A Construct 3 alternative that does not ask you to give up 2D

Pick 2D and the first build is the one in the brief you approved, and it is playable: tile ground, a band of scenery behind it, sprites, and a player controller that walks, falls and jumps under the keys you press. That arrives after you approve the brief rather than at the end of a tutorial, which means the first thing you do is play something instead of assembling something.

Ground is a tile layer. Flockbay lays it, and Paint in the Godot editor lets you drag to lay or erase cells yourself; either way the tiles, the edges and the collision are all derived from which cells are ground rather than placed one at a time. That matcher is ours, and it is a pure function of the coverage, so painting the same cells in a different order draws the same world and a rebuild never reshuffles your edges. The sixteen drawn tiles are cut from the nine pieces a tileset already ships, so nothing has to be authored to make the edges meet. The camera is framed by three boxes (what is in view, the dead zone, and the scroll limits). Flockbay sets them, they sit under Player controller in the editor's 2D view when you want to drag them, and the limits follow the ground until the first time they are set by hand.

Side-on and top-down are not two modes you choose between. They fall out of gravity. Declare it and down is a direction, so steering is horizontal and a jump is available; declare none and the body steers on both axes and there is nothing to jump away from. Same code either way, and the same character settings underneath (walk and run speed, air control, jump apex, body size, step length), so "make it feel heavier" is a retune rather than a rewrite.

Art is the part people expect to be the problem. Flockbay's library of ready-made objects is 90.8% sprites (55,073 objects out of 60,648), and a sprite goes into the scene at an exact position, rotation and scale, placed by Flockbay or by you with Place. A sprite sits on its own drawn bottom-centre, so it stands on the ground rather than floating by however much transparent margin its file happens to carry. Where that breaks: Flockbay generates still pictures, not sprite sheets or an animated character. The frames come from you, an artist or a library, and Godot's own animation tools in the editor put them in motion.

More on this: Pixel art is a discipline, and the code is still the blocker

Flockbay builds the world from the brief. In a flat game that is tile ground and sprites. On the 3D side it is terrain, a lake with its outline, weather, buildings, the characters that populate the place. A spatial call that is pure taste is faster made by pointing than by describing, so the same tools are buttons around the Godot editor's view, with Godot's undo behind them.

Those 3D tools are 3D tools and there is no flat version of them. A 2D game here has no water and no weather, because neither family has an answer in a world with no depth to put it in. Better to read that now than to find it on a Tuesday.

Behaviour is described in both. You tell Flockbay what should happen (the jump forgives a few frames of late input, the enemy loses your trail, the shop closes at dusk) and it writes the GDScript into your project. You then play it and say whether it feels right.

That judgement is the job. Not writing code does not mean not having an opinion; the opinion is the input the whole loop runs on.

More on this: Flockbay vs GameMaker

Flockbay is a desktop app for Windows, macOS and Linux, and it ships with Godot inside. Press play and the game runs locally on your machine. Nothing streams and nothing renders remotely.

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

On cost: Flockbay is free, AI included: free hosted AI every day, or your Claude or ChatGPT plan, your own agent, or an API key. Defold is free outright, and that is a real difference worth weighing if the money matters more than having the code written for you.

If you have a Defold game underway, moving it here is a rebuild rather than a migration. Lua does not become GDScript and collections do not become scenes. Your art, audio and design notes come with you; everything else is done again.

That is sometimes worth it and usually is not. The case where it clearly pays is when the project has stalled on the scripting rather than on the design — you know exactly what the game should do, and the distance between knowing and having it is a fortnight of Lua you have no appetite for. Having that part written for you is the entire offer. The case where it does not pay is when the game is nearly finished and the appeal is novelty.

If you are between projects, the decision is much cheaper, and starting the next one here costs you an afternoon to find out.