Layout & Structure: What the Shape of Code Means

In Part 1 you learned to read a single line of Verse like a sentence. This lesson is about what happens when you have many lines. Because here is the surprise that trips up almost everyone:

In Verse, the shape of your code is part of what it means.

In a lot of writing, how you arrange things on the page is just decoration. Not here. Where a line sits — how far it is pushed to the right — changes what the code does. Once you can read the shape, you can look at a hundred lines of Verse and instantly see how they fit together, the same way you can glance at the map and instantly read the storm circle.

Indentation = belonging

<!-- section-art:indentation-belonging -->

Indentation Belonging

Indentation is the empty space at the start of a line. When a line is pushed in further than the line above it, that line belongs to the line above it.

Think about your loadout. You have a backpack, and inside the backpack are your items. The items belong to the backpack. You'd draw it like this:

• Backpack
  • Shield potion
  • Wood
  • Pickaxe

The shield potion is indented under the backpack, so it lives inside it. Verse uses that exact idea. Look:

OnTimerEnd() : void =
    set CurrentScore += 1
    EndGame()

Read the shape: OnTimerEnd is the backpack. The two lines pushed in underneath — set CurrentScore += 1 and EndGame() — are the items inside it. They are the steps that run when OnTimerEnd happens. They belong to it because they are indented under it.

If you un-indented EndGame(), you'd be saying it no longer lives inside OnTimerEnd — it would be a separate thing entirely. Same words, different shape, different meaning. The shape is load-bearing. In our projects the house style is two spaces per level of indentation, and we keep it perfectly consistent — because a crooked indent isn't a style problem, it's a meaning problem.

A block is a group of steps

A block is just a stack of lines that belong together — a group of steps that run in order, top to bottom. The body of OnTimerEnd above is a block: two steps, run one after the other.

Most of the time a block is introduced by something ending in : or =, and then the steps are indented underneath. You already met this with functions and if in Part 1. Here it is with an if:

if (CurrentScore >= WinningScore):
    EndGame()
    ShowVictoryScreen()

Read the shape: the if line asks a question — is the score high enough to win? The two indented lines underneath form a block — they are what to do if the answer is yes. They belong to the if. Outdent them and they'd run no matter what, win or not.

There is also an explicit way to say "the following indented lines are a group," using the word block:

StartRound() : void =
    block:
        ResetScore()
        SpawnPlayers()

You'll mostly see plain indentation, but block is handy when you need to be crystal clear that some steps are one unit. (Our project rule even uses it to keep a half-finished function valid: write MyFunction() : void = block: and a real step inside, so the code still makes sense before you've finished it.)

Containers: where nouns live

Single lines and blocks handle actions. But your game also has things — and things need somewhere to live. Verse gives you containers: bigger shapes that hold a named bundle of related stuff. The three you'll meet first are the module, the class, and the struct. The trick is the same every time: the contents are indented inside the container.

A class — a thing the game can place and run

A class is a blueprint for a thing that has its own data and its own actions. The most important one for a beginner is creative_device — that's the blueprint for "a Verse thing you can drop into your map," like a custom rule-box you built yourself.

score_manager := class(creative_device):

    var Score : int = 0

    OnBegin<override>() : void =
        Print("Score manager ready")

Read the shape from the outside in:

• score_manager := class(creative_device): — "score_manager is a class, and it's a kind of creative_device." That's the container.
• Everything indented underneath belongs to score_manager. It owns a noun (var Score) and a verb (OnBegin).
• OnBegin is itself a container — its own steps are indented one level further in. So Print(...) is two levels deep: inside OnBegin, which is inside score_manager.

That nesting — boxes inside boxes — is the whole game. OnBegin is a real, special function: it's the one Verse runs automatically when the device starts up, like the moment the bus doors open. The <override> part says "I'm filling in this slot the device already expected."

A struct — a plain bundle of values

A struct is simpler than a class: it's just a labeled bundle of values stuck together, with no behavior of its own. Think of a player's stats card:

player_stats := struct:
    Eliminations : int
    Placement : int

Read it: "player_stats is a struct that holds two whole numbers — Eliminations and Placement." It's one tidy thing you can pass around, instead of juggling two loose numbers. A struct is for holding data; a class is for holding data and doing things.

A module — a folder for your code

A module is the biggest container: it's like a folder that groups related code so it has a tidy address. You don't write modules much as a beginner, but you use them constantly through the using line at the top of a file:

Read it: "I'm going to use the things from the Fortnite Devices module, and from the Verse Simulation module." That first line is exactly what makes creative_device, button_device, and friends available to you — they live in /Fortnite.com/Devices, and using opens that folder so you can reach in.

Reading nested structure

<!-- section-art:reading-nested-structure -->

Nested Structure

Put it together and you can read a whole file just from its shape. Each step to the right is one box deeper:

using { /Fortnite.com/Devices }
using { /Verse.org/Simulation }

round_manager := class(creative_device):

    @editable
    StartButton : button_device = button_device{}

    var RoundActive : logic = false

    OnBegin<override>() : void =
        StartButton.InteractedWithEvent.Subscribe(OnStartPressed)

    OnStartPressed(Agent : agent) : void =
        if (not RoundActive?):
            set RoundActive = true
            Print("Round started")```

Read it as a set of nested boxes:

1. The file uses the Devices module.
2. `round_manager` is a `creative_device`. Everything below, indented once, belongs to it: a button, a `logic` flag, and two functions.
3. `OnBegin` is one box deeper. Its single step — *subscribe to the button* — is one level deeper still.
4. `OnStartPressed` is also inside `round_manager`. Inside *it* is an `if`. Inside *that* `if` are the two steps that run when the round isn't already going.

You never had to memorize the file. You read the indentation like an outline and the structure told you who owns what. The `@editable` line, by the way, is a small label that means "let me set this button in the UEFN editor by clicking" — a tag attached to the noun on the line below it.

## The rules that keep your shape honest

These come straight from how we write Verse on real projects, and they're as much for *you* as for any AI helper you direct:

1. **Indent consistently — two spaces per level.** The shape *is* the meaning, so a sloppy indent is a real bug, not a cosmetic one. Keep every level lined up.
2. **One container, one job.** A class or module should be about *one* clear thing (a score manager manages score). Keeping each box focused is what makes code easy to read and reuse — our projects call this keeping modules "self-contained."
3. **Open what you use.** If you reference `button_device`, the file needs the matching `using { /Fortnite.com/Devices }` at the top, or Verse won't know where that noun lives.

## Why this helps you direct an AI

When you can talk about *shape*, you can give precise instructions: *"Add a function `OnStartPressed` inside the `round_manager` class, and inside it put an `if` that checks `RoundActive`."* That tells a helper — human or AI — exactly which box the new code belongs in. Someone who only thinks in loose lines can't say where things go. You can, because you read structure.

## Quick recap

- **Indentation = belonging.** A line pushed in under another line lives *inside* it. Two spaces per level, always consistent.
- A **block** is a group of steps that run in order; it's introduced by a line ending in `:` or `=` (or the word `block`).
- **Containers** hold named bundles: a **class** has data *and* actions, a **struct** is a plain bundle of values, a **module** is a folder you open with `using`.
- Read a file from the **outside in** — each step to the right is one box deeper. The shape tells you who owns what.

Next: [Part 3 — Nouns: Values, Types, Variables & Constants](/guides/verse-nouns-values-and-types), where we slow down on the *things* you name and the kinds they come in.

## References

- [Verse Language Reference (Epic)](https://dev.epicgames.com/documentation/en-us/uefn/verse-language-reference)
- [Create Your Own Device Using Verse (Epic)](https://dev.epicgames.com/documentation/en-us/uefn/create-your-own-device-in-verse)
- [Modules and Paths in Verse (Epic)](https://dev.epicgames.com/documentation/en-us/uefn/modules-and-paths-in-verse)
- Grounded in the Verse Cortex knowledge base and our project Verse conventions (.cursor/rules).