---
order: 1
title: Logic Bricks
---

# 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](listeners-gates-executors.md) 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](runtime-model.md).
```

## 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](../guides/debugging.md)).
- **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](variables.md)** — local and global values that bricks read and write, so logic can share state and UI can show it.
- **[States](states.md)** — up to 30 layers per node for organizing modes like *idle*, *moving*, or *menu-open* without swapping graphs.
- **[Runtime Model](runtime-model.md)** — how the listener → gate → executor pipeline is evaluated each tick, and why it's deterministic.

## Where to go next

- [Listeners, Gates, Executors](listeners-gates-executors.md) — the three roles in detail
- The [Logic Reference](../reference/index.md) — every brick, grouped by category
- The [2D and UI](../guides/2d-ui.md), [3D](../guides/3d.md), and [XR](../guides/xr.md) guides to see bricks in action