Puzzle game maker: the rule is the game, and the rule gets written

Good puzzle games usually rest on a single mechanic that turns out to be deeper than it looks. Boxes that can only be pushed. A light that reveals one thing and hides another. Time that runs backwards in one room. The design work is finding out what the rule can do.

That means the rule has to be cheap to change. If altering how the mechanic behaves takes an afternoon of code, you will test three variants. If it takes minutes, you will test thirty, and the thirtieth is usually the good one.

Flockbay writes the rule as GDScript in your project. You describe the mechanic, you play it, you say what should be different, and it rewrites. That cycle is the entire reason this is useful for puzzles.

Nobody generates good puzzle levels from a description. A level is a specific arrangement that makes exactly one insight necessary, and every element in it is placed deliberately. Generated levels are solvable and boring.

So you build them. Place the geometry, the objects, the doors, the pressure plates, by hand in the builder, on a Windows desktop with a mouse. Then you play your own level, which tells you almost immediately whether the insight lands or whether there is a stupid shortcut you did not see.

The other half of level design is order. Which puzzle teaches the thing the next one requires. That ordering is judgement and it is yours.

More on this: Generating puzzles is easy. Generating good ones is not

You will get worse at judging your own puzzles the more you build them, because you already know the answer. That is a known hazard of the genre and no tool fixes it.

What helps is that the game runs locally as a real build, so handing it to a friend is a normal thing to do. Watching somebody get stuck in a place you thought was obvious is worth more than any amount of solo tuning.

When they get stuck in the wrong place, you come back and change the rule or the room. Usually the room.

More on this: Make a platformer with AI: getting the jump right is the whole job

The first question a puzzle designer answers is what shape the space is, and the app makes you answer it before it will create the project: 2D or 3D, shown as two pictures, with no default. That is not a cosmetic setting. It decides which tools are in your hands for the rest of the project.

Pick 3D and you get real space. Sightlines, elevation, what you can see from where, what a room looks like from the other side, and terrain, water and weather underneath all of it. A game about a building you have to understand is very much what that half is for.

Pick 2D and you get a grid, which is what a great many puzzle games wanted in the first place. You drag over cells to say where ground is, and which picture lands in each cell, where the edges fall and what the player collides with are all derived from that one map of covered cells. So a room is walkable the moment you have painted it. Whether a material stops a walker is declared rather than assumed, which means a wall and a floor are the same gesture with a different property — most of what a grid puzzle needs, geometrically. Declare no gravity and the character steers on both axes; declare gravity and the same body gives you a puzzle platformer instead.

Where this stops short is worth hearing now rather than in week three. Ground is tiles and only tiles: there is no pencil that draws an arbitrary curve of it, and there is no layers panel. And nothing here makes animation. Flockbay can produce a single flat still image on request, but not a multi-frame sprite, so if a matched pair has to squash and pop when it clears, those frames come from you or from the Catalogue.

More on this: How to make a 2D game without learning to code

A desktop app for Windows, free to download, with Godot bundled inside. Games run locally on your machine. Building needs an internet connection because the chat and asset generation come over the network; playing does not.

The builder is free. Flockbay is free on your own AI: your Claude or ChatGPT plan, your own agent, or an API key.

More on this: Make a game without coding, and without a ceiling

You will build puzzles that work, are fair, and are boring. Those are the hardest to remove because nothing is wrong with them, and removing them is usually what turns a set of puzzles into a game.

A useful test is whether the puzzle taught anything or asked for anything new. If it did neither, it is padding, however clever the arrangement is.

The other common cut is the tutorial. Most puzzle games explain too much, because the designer is nervous. Watching one person play without a word from you will tell you exactly how much of your explanation was necessary, and it is usually less than half.