A 2D game maker where the first thing you do is press play

A new project in Flockbay opens on a single question, shown as two pictures: 2D or 3D. There is no default and nothing is created until you pick one.

That sounds like a small piece of interface, and it is most of the argument. Tools that "also do 2D" usually bolt it on as a mode inside a 3D editor, so the flat game inherits menus written for a solid world and quietly gets the worse half of everything. Here the choice comes first and the builder carries it from then on. Same app, same Director 1, different set of tools in your hands.

What changes is which tools those are. A 3D project gets terrain built from an elevation map, water, weather, a time of day and a sky. A 2D project gets none of them, because none of them mean anything in a flat world. It gets four families of its own instead: the ground, what is beyond the ground, the person, and the things you place.

Press play on a 2D project you made ten seconds ago and something happens. There is a sky colour and a band of scenery along the horizon. There is ground with a ledge in it and a platform floating above. There is a person standing on that ground who walks when you hold a direction, falls when the ground runs out, and jumps when you press the key.

None of that is your game, and it is not a tutorial you have to finish either. It is a floor to stand on. The usual first evening of a 2D project — get a character moving, get gravity roughly right, give them something to land on — has already happened, so the first thing you do is judge something rather than assemble something.

That changes the shape of the work more than it sounds like it should. When the starting point runs, every change has an immediate answer. You paint a bit more ground and play it. You move the platform and play it. You are never staring at an empty scene working out which of the twelve missing pieces is the one stopping you.

Ground is a tile layer, and you do not place tiles. You drag to say which cells are ground, and drag again to take it back. Which picture lands in each cell, where the edges and outside corners fall, and what the player collides with are all derived from that one map of covered cells.

The matcher that does the deriving is ours, and it is a pure function of the coverage. That has a practical consequence you only notice when it is missing: paint the same cells in a different order and you get the same world, and a rebuild never reshuffles your edges into a slightly different arrangement of the same level. The sixteen drawn tiles are cut from the nine pieces a tile pack already ships, so nobody has to author art for the corner cases.

Whether ground stops a walker is declared per material rather than assumed. A platformer's solid block and a top-down dirt path are painted with exactly the same gesture, and only one of them stops anybody.

The limit worth saying out loud: this is tiles. There is no pencil that draws an arbitrary curve of ground, and there is no layers panel. If what you want is a hand-drawn hillside rather than a grid, that is not here, and knowing it now is worth more than finding out in week three.

Most tools ask you to pick a template at the start — platformer, or top-down — and then the two behave like different products, so moving between them means starting again.

Here it falls out of one declaration. Say there is gravity and down becomes a direction: steering is horizontal, the body has weight, and a jump is a thing you can have. Say there is none and the same body steers on both axes, with nothing to jump away from. Same character body, same code, two genres.

The rest of how the person feels is a set of controls rather than a script. Walk and run speed. How long it takes to reach that speed and how long to lose it. Air control, gravity, jump apex, body size, step length. So "it should feel heavier" is a retune of numbers that already exist, which is why asking for it works and also why you can drag it yourself. The walk cycle advances by distance travelled rather than by a timer, so the legs stay with the speed instead of skating.

The camera rides with the person and you frame it by dragging three boxes on the running game: what is in view, the dead zone the character can move around inside before the camera bothers to follow, and the limits the scroll will not cross. The limits follow the ground you have painted until the moment you drag them yourself, after which they are yours. Cameras are one of the least forgiving parts of a 2D game, and one of the hardest to fix by describing it in a sentence.

The Catalogue holds 60,648 objects and 55,073 of them are sprites — 90.8%. You search it by name and see a picture of each one before you take it. For a flat world that is the main route to art, ahead of drawing anything and ahead of asking for anything.

You place a picture, or a scene from your own project, at an exact position, turn and size, by hand with the mouse. It sits on the drawn figure's own bottom-centre rather than the middle of the file, so a barrel stands on the ground instead of hovering by however much transparent margin the artist left around it. Draw order follows that same point, which means a thing lower down the screen is in front of a thing higher up without you sorting anything.

Beyond the ground there is one band of scenery along the horizon and the sky above it. The sky colour and whatever continues below the band are both read from the band picture's own first and last solid rows, so replacing the picture replaces both. It is one band. There is no parallax stack.

The gap, plainly: you cannot make new animation here. The person's walk cycle is built in, but there is no animation editor and nothing that produces a multi-frame sprite. Director 1 can make a single flat still image when you ask for one; an animated character it cannot. If your game needs a six-frame attack, those frames come from you or from the Catalogue.

Most of the hard parts of a 2D game are invisible in a screenshot. Coyote time. Input buffering. State machines for a character with six actions that can interrupt each other in the wrong order. What an enemy does when it loses sight of you. What happens to a save file when the player quits mid-level.

These are exactly the things people give up on. They are also exactly the things a code-writing layer is good at, because they are well-understood problems with fiddly implementations. Asking for a jump that forgives a few frames of late input is one sentence. Writing it, testing it and not breaking the wall slide is an afternoon.

You say what should happen, Director 1 writes the GDScript inside your project, and you play it. You do not have to read the script. You do have to play the game and say whether the jump feels right, because nobody else can tell you that. That loop — you judge, it revises — is the normal way of working, not a sign something went wrong.

Flockbay is downloaded and installed on Mac or Windows. It ships with Godot inside it, so pressing play runs your game locally, on your machine, at your machine's framerate. What you end up holding is an ordinary Godot 2D project in an ordinary folder.

For 2D that sounds like it should not matter, and for one room it does not. It starts to matter when the painted world is large, when there are a few hundred things moving at once, or when you simply want the gap between making a change and seeing it to stay near zero.

Building does need an internet connection. Director 1, generation and world data all come over the network. Playing the game you built does not. If you are on a train with no signal you can play; you cannot build.

The distance between "the character moves nicely in a test room" and "this is a game" is mostly content and mostly boring. You need a way to move between rooms without losing state. You need a checkpoint that puts you back somewhere sensible rather than at the start of the world. You need a menu, an options screen, a volume slider that persists, and a pause that stops the physics rather than merely hiding it.

People underestimate this every time. The movement is the fun part to build, so it gets built first and built well, and then the project meets the unfun part and stops. Having that half written for you is not a shortcut around the craft. It is a way of arriving at the craft with time left.

The order that works is roughly: get the feel right in one room, then build the connective tissue, then make levels. The middle step is short here, which is the point.

And when you do reach the level-making step, you have a character that already feels correct, so every room you paint can be judged honestly rather than through a fog of "well, the jump is temporary".