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 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.

Bind them once, early, typically in your game instance or a HUD widget's Event Construct:

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.

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 to go next

Creating a lobby if you are building multiplayer.

Achievements and stats if you are not.