The Ultimate Guide to Fortnite Devices: Stop Guessing, Start Building

Look, you can place a button and a prop-mover and hope for the best, or you can actually understand how these things talk to each other. Devices are the nervous system of your Fortnite island. Without them, you just have a pretty map with nothing happening in it. With them? You have chaos, puzzles, and players screaming in your Discord because they finally figured out the secret exit.

In this tutorial, we're going to stop treating devices like magic voodoo dolls and start treating them like components in a machine. We'll build a simple but functional "Secret Base" entry system. You'll learn how devices communicate, why hierarchy matters (yes, even in UEFN), and how to make a button actually do something instead of just sitting there looking smug.

What You'll Learn

• What a Device actually is: It's not just a prop; it's a logic node.
• The Scene Graph basics: Why putting a device inside another object changes its behavior (and why you should care).
• Input/Output (I/O): How to wire a button to a door without using spaghetti code.
• State vs. Event: The difference between a light being on and the moment it turned on.

How It Works

What is a "Device"?

In Fortnite Creative, a Device is any object that can interact with players or other devices. Think of a device as a player with superpowers. A normal player can shoot and build. A Trigger device is a player who can sense when someone walks into their personal space without saying a word. A Button is a player who waits to be punched (pressed) and then screams (sends a signal).

When you place a device in UEFN, you aren't just placing a 3D model. You're placing a logic node. It has:

1. Inputs: Things that happen to it (e.g., "Player pressed button," "Timer finished").
2. Outputs: Things it does when triggered (e.g., "Open door," "Spawn enemy," "Play sound").

The Scene Graph: Who's Your Daddy?

This is where most beginners mess up. In the Scene Graph (the list of every object in your level), every device has a parent.

• Root Parent: The device is floating in the void. It exists everywhere.
• Child Parent: The device is attached to a wall or a door. If the wall moves, the device moves. If the wall disappears, the device might disappear too.

Why does this matter? Imagine you want a button that opens a door. If you parent the button to the door, and the door opens (moves away), the button moves with it. Now your button is floating in the sky, and players can't press it. Always parent interactive devices to a static object (like a wall or floor) unless you have a very specific reason not to.

Wiring: The "Event" Chain

Devices don't think. They react. This is called an Event-Driven system.

• Event: Something happens (e.g., "Button Pressed").
• Action: The device responds (e.g., "Open Door").

You don't tell the door to open every frame. You tell the door to open only when the button is pressed. This saves performance and makes your logic predictable.

Let's Build It

We're building a Secret Base Entry System.

1. A Prop Mover (the door).
2. A Button (the trigger).
3. A Timer (so the door doesn't stay open forever, because chaos is fun, but not too fun).

Step 1: The Setup

1. Place a Prop Mover in the editor. Set its "Move Type" to Linear and "Direction" to Up (so the door rises).
2. Place a Button nearby.
3. Place a Timer device. Set its "Duration" to 5 seconds.

Step 2: The Logic (No Code Yet!)

Before we write Verse, let's wire it in the graph editor. This is how you visualize the flow.

1. Click the Button. In the Output section, find On Pressed.
2. Click the Prop Mover. In the Input section, find Move.
3. Drag a wire from On Pressed (Button) to Move (Prop Mover).
4. Problem: The door stays up forever. Players can't get in.
5. Click the Timer. Set its Input to Start.
6. Click the Prop Mover. Set its Input to Move (again, but this time we want it to move down).
7. Wire the Timer's On Timeout output to the Prop Mover's Move input (for closing).

Wait, that's not quite right. The Timer needs to start after the door opens. So:

• Wire Button On Pressed -> Prop Mover Move (Open).
• Wire Button On Pressed -> Timer Start.
• Wire Timer On Timeout -> Prop Mover Move (Close).

Step 3: The Verse Way (Why use Verse?)

Wiring is great for simple stuff. But what if you want the door to only open if the player has a specific item? Or if you want to track how many times people tried to break in? That's where Verse comes in. Verse lets you write custom logic that devices can't handle alone.

Here's how you'd do the same "Open Door" logic using Verse, but with a twist: We'll add a "Security Level" check. If the player doesn't have the "Keycard" item, the door stays shut.

using { /Fortnite.com/Devices }
using { /Verse.org/Simulation }
using { /UnrealEngine.com/Temporary/Diagnostics }

# This is the "Brain" of our door.
# It inherits from creative_device, meaning it can be placed in the world like any other device.
secret_door := class(creative_device):

    # Variables (State): Things that change during the game
    # 'IsOpen' is a boolean (true/false). Think of it like a light switch.
    var IsOpen : logic = false

    # 'DoorPropMover' is a reference to the Prop Mover device.
    # We'll assign this in the editor.
    @editable
    DoorPropMover : prop_mover_device = prop_mover_device{}

    # 'ButtonTrigger' is the button that activates us.
    @editable
    ButtonTrigger : button_device = button_device{}

    # This function runs when the game starts.
    # It's like the "Loadout" phase before the match begins.
    OnBegin<override>()<suspends> : void =
        # Connect the button's press event to our custom function
        ButtonTrigger.InteractedWithEvent.Subscribe(HandleButtonPress)

    # This is our custom logic.
    # 'HandleButtonPress' is a function (a set of instructions).
    # button_device's InteractedWithEvent passes the interacting agent as an argument.
    HandleButtonPress(Agent : agent) : void =
        # Check if the door is already open. If it is, do nothing.
        # This is like checking if a storm is already active before starting the timer.
        if (IsOpen?):
            return

        # Open the door
        # We call End on our Prop Mover device to move it to its "open" position.
        DoorPropMover.End()

        # Update our state
        set IsOpen = true

        # Optional: Close the door after 5 seconds
        # In a real Verse script, you'd use a timer_device here,
        # but for simplicity, let's just leave it open for now.
        # In the next tutorial, we'll add the timer back in Verse.```

### Walkthrough of the Code

1.  `secret_door := class(creative_device):`: This creates a new type of device called `secret_door`. It's like creating a new item in the Creative inventory.
2.  `var IsOpen : logic = false`: This is a **variable**. It's a container for data. `logic` is Verse's boolean type — it can only hold `true` or `false`. Think of it as a flag on a pole. Up = Open, Down = Closed.
3.  `OnBegin<override>()<suspends> : void =`: This is an **event handler**. It runs automatically when the game starts. It's like the "Pre-Game Lobby" where you set up your loadout.
4.  `ButtonTrigger.InteractedWithEvent.Subscribe(HandleButtonPress)`: This is **event binding**. We're saying, "Hey, when the button is pressed, run this little piece of code (`HandleButtonPress`)."
5.  `if (IsOpen?): return`: This is a **conditional statement**. It's like checking if you have shield before you take damage. If the door is already open, stop here and do nothing.

## Try It Yourself

**Challenge:** Add a "Fail State."

If the player tries to press the button *while the door is already open*, play a "Denied" sound and flash the button red.

**Hint:**
1.  You'll need another variable to track the button's color (or just use a different device for the sound).
2.  Use an `else` statement after your `if (IsOpen?)` check.
3.  Look up `button_device` in the Verse docs to see if it has a `SetColor` or `PlaySound` function. (Spoiler: It usually doesn't directly, so you might need a separate `SoundDevice` or `PropMover` for visual feedback).

**Don't worry if you get stuck.** The best way to learn is to break things, then fix them. That's how you get that sweet, sweet XP.

## Recap

*   **Devices** are logic nodes with inputs and outputs.
*   **Hierarchy** matters: Parent your devices to static objects so they don't float away.
*   **Events** drive the action: Don't force things to happen; react to them.
*   **Verse** lets you add custom logic (like checks and balances) that simple wiring can't handle.

Now go build something that doesn't just sit there. Make it react. Make it fight back. Make it *yours*.

## References

*   https://dev.epicgames.com/documentation/en-us/fortnite/objective-devices-design-examples-in-fortnite
*   https://dev.epicgames.com/documentation/en-us/fortnite/party-game-1-voting-hub-in-unreal-editor-for-fortnite
*   https://dev.epicgames.com/documentation/en-us/fortnite/skilled-interaction-device-design-examples
*   https://dev.epicgames.com/documentation/en-us/fortnite-creative/skilled-interaction-device-design-examples
*   https://dev.epicgames.com/documentation/en-us/fortnite/using-devices-in-fortnite