How to make a 2D game without learning to code

Every 2D game splits the same way. There is the layout — where the ground is, where the gap is, how far the jump has to carry, where the enemy stands so that the player sees it a beat before it matters. And there is the code — gravity, collision response, the state machine that decides whether you are running or falling or hurt.

The layout half rewards doing rather than describing. If you want a ledge slightly further away, dragging it is faster than writing a sentence about how much further. The code half rewards the opposite: describing what should happen is quick, and typing it out is the slow part, especially if you have never written GDScript.

Flockbay is built on that split. Creating a project asks which kind of game you are making, 2D or 3D, as two pictures with no default — it will not create the project until you pick one. Pick 2D and it is the same app, the same builder and the same chat: 2D is a setting the project carries, not a second product. You build the level yourself. Flockbay writes the code inside your project. Neither half pretends to be the other.

A new 2D project opens playable. There is a sky colour and a band of scenery along the horizon, ground with a ledge and a floating platform, and a person who walks, falls and jumps under the keys you press. Seconds, not a tutorial.

That matters more than it sounds, because the first hour of most 2D projects goes on getting a rectangle to move without catching on the corner of a wall. Starting from something that already moves means the first question in front of you is a design question — is that gap the right width — rather than a plumbing one.

What it does not do is guess your game. The person, the ledge and the platform are a starting position, not a genre. Everything after that is the same work every project has: deciding what your rooms are for.

More on this: AI level generator: generate the ground, place the meaning

Ground is painted. You drag to lay it and drag to erase it, and the tiles, the edges and the collision all follow from which cells are covered. You are not picking corner pieces out of a palette; you are saying where the ground is and the matcher works out the rest. Because it is a pure function of that coverage, painting the same cells in a different order draws the same world, and a rebuild never reshuffles edges you already liked.

The same painting covers a platformer's blocks and a top-down game's paths. Whether ground stops a walker is declared per material, so the two are drawn identically and only one of them stops anybody.

On top of that you place things: pictures or scenes from your project, put at an exact position, turn and size, by hand with the mouse. A picture sits on its own drawn bottom-centre rather than on the corner of its file, so a crate stands on the ground instead of hovering by however much transparent margin came with it, and draw order follows the same point — a thing lower down the screen is in front. The Catalogue is mostly sprites, 55,073 of its 60,648 objects, searchable by name with a picture of each, and your own art works too because it is a normal Godot project underneath.

The camera is framed by dragging three boxes on the game itself: what is in view, the dead zone the player can move inside before it follows, and how far it may scroll. The scroll limits follow the ground you paint until you drag them yourself.

None of this involves a script editor. It involves a viewport and your hands, which is the same way level design has worked since before there were engines.

More on this: AI 2D game generator: the code is generated, the game is not

You say what should happen. The player should double jump. The spikes should send you back to the last checkpoint. The key should open the red door and only the red door. Flockbay writes the GDScript that does it, inside your Godot project, in files you can open if you ever want to.

You are not asked to read the code, and you are not asked to approve a diff you cannot evaluate. You are asked to play the game and say whether the jump feels right. It usually will not on the first try, because jump feel is a taste judgement and taste is the part you supply. So you say it feels floaty, and it gets revised, and you play it again.

For the person's own movement, that revision is usually not new code at all. Walk and run speed, how long it takes to reach a speed and how long to lose it, air control, gravity, jump apex, body size and step length are controls on the character body, so making it feel heavier is a retune rather than a rewrite. The walk cycle advances by distance travelled, which is why the legs stay with whatever speed you settle on instead of skating.

That loop is the work. It is not a fallback for when the AI fails.

Flockbay is downloaded and installed on Windows. There is no browser version. For a small 2D game that might sound like unnecessary friction, and for the first ten minutes it is.

What it buys you is that the game runs on your machine, on the copy of Godot that ships inside the app, at your machine's framerate. A 2D game with a few hundred particles and a screen full of sprites is not a strain locally and is a strain in a tab. It also means the project on your disk is a normal Godot project rather than a save file on someone else's server.

Building does need an internet connection. the chat and asset generation come over the network. Playing what you built does not.

More on this: Making a match-3 game without writing the board logic

Install the app, pick 2D, and play the thing that opens. It will feel wrong, because a default gravity picked for nobody in particular always does. Say so, retune it, play it again. That is the whole first twenty minutes, and none of it is setup.

Then build one room properly. Not a game, one room. Paint the ground, get the jump distances so the room reads clearly, place one hazard, give one reason to go left instead of right. By the end of that you will know whether you enjoy this, which is more useful than a finished tutorial project you did not design.

The second afternoon is where a game starts, because by then you are not fighting the tool, you are making decisions about your game.

Easier: everything to do with space. No lighting rig, no navigation mesh, no terrain to shape, and you can see the whole level at once while you edit it. Even the camera is three boxes you drag rather than a problem to solve. That removes a large fraction of what makes a first 3D project slow.

Not easier: art volume. A 3D character can be viewed from any angle from one model. A 2D character needs a drawing for every direction it faces and every thing it does, and the frames add up fast. Nothing here generates those frames for you — an animated character is not something Flockbay can produce, and that is a real gap rather than a detail. Frames come from the Catalogue or from your own hand.

The practical response is to keep the character simple and the animation count low until the game is proven. A rectangle that moves beautifully is a better foundation than a beautifully drawn character that moves badly, and you can replace the rectangle at any point.

More on this: Why nothing generates a fighting game, and what can be generated