Day Two: Devices, Events, and the Language of UEFN Logic

The thing nobody tells you on day one

Most new UEFN creators bounce off the device library because it looks endless. There are hundreds of devices. The official docs treat each one as a self-contained chapter. After an hour of scrolling, the inevitable feeling is "I will never learn all of these." That feeling is correct, and it does not matter. You do not need to learn them all.

Instead, you need to internalize one mental model. Once you have it, every device looks like a small variation on the same theme, and learning a new device takes minutes instead of an afternoon.

The model is this: a device is a small machine. It has options that configure how it behaves, events it can emit when interesting things happen, and functions it can run when something tells it to. That is it. Once you can see every device as the triple of (options, events, functions), the library becomes a parts catalog instead of a textbook.

This post is the day-two follow-up to Day One: From Empty Editor to a Playable Island. If you have not done day one yet, do that first. The rest of this post assumes you have placed a Player Spawner, walked through a trigger, and pushed a build.

The (options, events, functions) triple

Pick any device and you will find these three sections in its Details panel.

Options are the device's configuration. Things like "how long is the cooldown," "which team can use this," "what text does the billboard display." These are knobs you set in the editor. They do not change at runtime unless something explicitly changes them.

Events are the things this device can announce. A trigger device emits a "triggered" event when a player crosses it. A timer device emits "completed" when its time runs out. A button device emits "interacted" when a player presses E on it. Events are how a device says "something happened to me." Other devices (or Verse code) listen for events and react.

Functions are the things you can ask this device to do. The billboard has a Show function and a Hide function. A timer has Start, Pause, and Reset. An item granter has Grant. Functions are how you tell a device "do this thing now."

When you wire two devices together in the editor, you are saying "when this device's event fires, call that device's function." That is the entire idea of UEFN logic. Every island, no matter how complex, is a graph of devices passing events to each other and calling each other's functions.

A worked example: a tiny scoring loop

Let's build the smallest possible loop that demonstrates the pattern. The loop is: a player presses a button, gets a point, and the score updates on a sign.

You will need three devices in your level:

1. A Button Device the player can interact with.
2. A Score Manager Device that tracks a numeric score.
3. A Billboard Device that displays text.

Wire them like this. Select the Button. In its Details panel, find the event that fires when a player interacts with it (commonly called something like "Player Interacted"). Set its target device to the Score Manager and its function to "Increment Score" (or the equivalent). Now whenever a player presses the button, the score goes up by one.

To display the score, use the Score Manager's events. It exposes events that fire when the score changes. Wire that event to the Billboard's "Set Text" function. The billboard now updates whenever the score changes.

Push a build, walk to the button, hit E. Your score goes up and the sign refreshes. You just shipped a feedback loop.

Notice that nothing in this loop required code. It is three devices, each contributing one of (options, events, functions), wired into a small machine. Nearly every gameplay system you can imagine is some variation on this pattern.

Why events beat polling

A reasonable instinct, if you come from a programming background, is to wonder why we do not just have a "tick every frame and check the button" loop somewhere. The answer is performance and clarity.

Events are push. The device tells you when something happened. Polling is pull. You repeatedly ask "did something happen?" Push scales much better, especially with thousands of devices and players. It is also clearer to read. A wiring graph that says "button triggers score increment" is easier to reason about than "every frame, check every button to see if it was pressed."

Verse can break out of this model when you genuinely need to (more on that in Day Three: Your first Verse script). For now, lean hard on events. Most things you want to do already have an event for them.

How to learn a device in five minutes

Every time you encounter a new device, run this exact playbook. It will save you hours over your first month.

Drag it into a level. Even if you have no idea what it does, get it into a level so you can poke at it.

Open its Details panel and scroll the Options section. Every option is labeled and most are documented inline. Even without reading the docs, you can tell from option names what the device is for. A device whose options include "Win Condition" and "Round Length" is clearly a round manager.

Scroll to its Events section. What does this device announce? An item granter that emits "Item Granted" is telling you it can be a source for other reactions. A class designer that emits "On Class Changed" is telling you you can build perks that react to class changes.

Scroll to its Functions section. What can other things ask this device to do? A teleporter has "Teleport Here" and "Teleport Player." Now you know it is a destination and a trigger.

Wire the smallest possible test. Hook one of its events into a billboard's "Show" function, with the billboard text set to something obvious like "fired!" Push a build. Trigger the event. If the billboard fires, you understand the device.

This loop generalizes. After ten devices, you will start seeing patterns. Anything called a "manager" is usually a coordinator with a lot of state. Anything called a "device" with options for "team" and "class" is usually a per-team rule applier. Anything that emits "On Player X" events is a source you can build a meta loop around.

Common day-two mistakes (and the easy fixes)

A few patterns trip up almost every new creator. Recognize them now and you will skip a month of frustration.

Wiring the wrong direction. Events go from a device, functions are called on a device. If your trigger does not seem to be firing, check that you have the trigger emitting an event, not the other way around. Editor tooling makes this easy to flip by accident.

Forgetting that devices need to be enabled. Many devices have an "Enabled" option that defaults to true but can be toggled off. If a device is off, none of its events fire and none of its functions do anything. When something is mysteriously dead, check Enabled.

Confusing a device's visibility with its aliveness. Setting a billboard's "Show" or "Hide" affects whether players see it. It does not turn the device off. Conversely, disabling a device does not necessarily hide it. These are two separate axes.

Putting too many devices in one level too early. Day-two creators want to test ideas, and the right move is to keep your test island sparse. Two devices and a single wired event is a better learning environment than fifty devices in a half-built castle.

What to read next

You now understand the (options, events, functions) triple, which is the deepest model in UEFN. Next steps:

• Day Three: Your first Verse script takes the same patient approach to your first Verse code. Verse becomes much easier to learn once you understand devices.
• Browse the glossary, especially the entries for creative_device, OnBegin, and Verse. Those three terms will land cleanly on day three.
• When you are ready to think about what kinds of games this pattern lets you build, skim our retention engineering guide. Even as a newcomer, knowing what makes a Discover-friendly loop will sharpen your taste.

You have the model. Now place a few more devices, wire them up, and let your fingers learn what your head already understands.