Logic Bricks

A logic brick is a single reusable block of behavior. Instead of writing a script, you drop bricks onto a node and wire them together into a graph. Every brick answers one of three questions — when?, should it pass?, do what? — and that’s the whole model. Master those three roles and you can build almost any gameplay behavior visually.

The three kinds of brick

Every brick is a listener, a gate, or an executor:

  • Listeners notice that something happened — a key pressed, a timer elapsed, a collision, a value crossing a threshold — and emit a pulse.

  • Gates decide whether a pulse counts. They combine conditions (AND, OR, …), block disabled branches, and route state-aware logic.

  • Executors make something happen — move a node, write a variable, update UI, change scenes, play a sound.

They always run in that order, so a graph reads left to right like a sentence:

Keyboard(Space, On Press) -> AND -> Motion2D(jump)
   listener                  gate     executor

That single line is a complete, working behavior. See Listeners, Gates, Executors for a deeper look at each role.

A graph lives on a node

A brick graph is authored on the scene node it controls. Select a CharacterBody2D and its graph is right there — the logic travels with the object, gets duplicated when you duplicate the node, and is inspectable at a glance. There’s no separate script file to keep in sync.

Note

The editor is for authoring and inspection. At runtime the native GDLink engine evaluates the graph every physics tick — you design the logic visually, and it runs deterministically. See the Runtime Model.

Why bricks instead of script

  • Visible — the behavior is the diagram. Anyone can read what a node does without parsing code.

  • Reusable — the same Motion2D or Keyboard brick works across projects; you configure, you don’t rewrite.

  • Composable — small bricks combine into rich behavior, and you can prove each branch in isolation (see Debugging).

  • Designer-friendly — tuning values, states, and variables are exposed in the inspector, so non-programmers can iterate.

The systems bricks build on

Three shared systems give graphs their power, each covered on its own page:

  • Variables — local and global values that bricks read and write, so logic can share state and UI can show it.

  • States — up to 30 layers per node for organizing modes like idle, moving, or menu-open without swapping graphs.

  • Runtime Model — how the listener → gate → executor pipeline is evaluated each tick, and why it’s deterministic.

Where to go next