Blueprint basics

Using SteamForge in Blueprint

The three patterns every SteamForge feature uses. Read this before any feature page.

Everything in SteamForge is reached one of three ways. Learn these once and every feature page will make sense.

1. Subsystems

Most features live on a Game Instance Subsystem. To reach one, drop a Get Game Instance Subsystem node and pick the class from the dropdown.

The subsystems are:

Subsystem	What it holds
SteamForge	Connection state, the local player, hardware, DLC
SteamForge Lobbies	Everything lobby related
SteamForge Sessions	The higher level host and join layer
SteamForge Friends	Friends list, avatars, Rich Presence
SteamForge Overlay	Opening the overlay, reacting to it, the on screen keyboard
SteamForge Cloud	Cloud save files
SteamForge Networking	Sending your own data between players
SteamForge Input	Action sets, button prompts, controller effects
SteamForge Server Browser	Dedicated server lists
SteamForge Host Migration	Keeping a match alive when the host leaves

A subsystem lives as long as the game instance, so you can call it from anywhere: a widget, an actor, the game mode. You do not need to store it.

INFO: You can call these from any Blueprint that has a world context, which is nearly all of them. If a node refuses to appear, uncheck Context Sensitive in the node search box.

2. Latent nodes for anything that waits

Steam answers many calls later rather than immediately. Those are latent nodes: they have two output execution pins, On Success and On Failure, and execution continues down whichever one applies when Steam answers.

You can tell them apart by the (Async) suffix in the node name, for example Create Lobby (Async).

The important part: do not treat these like normal function calls. Nothing useful has happened when execution leaves the node. Put your follow up work on the success pin.

WARNING: A latent node keeps itself alive until it finishes, but it is bound to the object that started it. If you start one from an actor and that actor is destroyed, the result is dropped instead of running. That is deliberate, and it is what stops the game crashing when you stop Play In Editor mid call.

3. Events for anything Steam tells you

Some things happen without you asking: another player joins your lobby, a friend invites you, the overlay opens. Those arrive as events.

Get the subsystem.
Drag off it and find the event, for example On Lobby Member Changed.
Choose Assign to create a bound custom event.

Bind before you need them. Binding after a lobby is already created means you miss the events that fired while you were not listening.

Where you bind decides how long the binding lasts, so pick by how long you need it:

Bind in	Lasts	Use for
A widget, on Event Construct	While that widget is on screen	Updating a list the player is currently looking at
Your Player Controller, on Event BeginPlay	Until the level changes	Anything tied to being in a match
A Game Instance Blueprint, on Init	The whole run of the game	Invites

WARNING: An invite can arrive while the player is on the main menu, mid match, or before any level has loaded at all when the invite is what launched the game. On Lobby Join Requested is the one event worth making a Game Instance Blueprint for. Bound anywhere shorter lived, it is missed whenever that object happens not to exist.

Types you will see everywhere

Type	What it is
Steam ID	Identifies a player. Not a string, so it cannot be wired into the wrong pin by accident. Convert with To String (Steam ID).
Steam Lobby Id	Identifies a lobby. Deliberately a different type from Steam ID, so the two cannot be swapped.
Steam Result	The outcome of a call: whether it succeeded, the raw code, and a plain language explanation of what to do about it.

When something fails, break the Steam Result and read Explanation. It is written to be shown to a developer, and often to a player.

Where nodes actually go

The pages that follow say things like "call Create Lobby" without saying where. The answer is almost always a Widget Blueprint's graph, because these calls come from a player pressing a button, and buttons live in widgets.

If the call is triggered by	Put it in
A button press	The widget's graph, on an On Clicked event
A level starting	Your Player Controller, on Event BeginPlay
Something Steam tells you	Wherever you react to it, bound as above

SteamForge does not require any particular class. Its subsystems live on the Game Instance, are reachable from all of these, and survive changing level, so nothing about the session needs carrying across a match start yourself.

Where to go next

New to Unreal multiplayer? The tutorial, which builds a working menu step by step.
Comfortable already? Creating a lobby.
Not building multiplayer? Achievements and stats.