Unreal Initialization
Last updated
Toolkit for Steamworks
Last updated
When properly configured, Unreal will initialise Steamworks SDK for you on startup however, the toolkit does require the use a Steam Game Instance.
Steam Game Instance is a C++ base class that you can use on your custom Game Instance. It houses all the global values and delgates that are needed to leverage the full feature set of Steamworks SDK and can be used to initalize the SDK while running in PIE.
Initialization is smart, if the API has been initialized by another system it will go with it and will still invoke the success events.
You will notice that initialization does require the use of a few nodes. The main node here is the Initialize Steam API function node. This will read the configuration you have provided from the Steam Game Instance and initialize the Steam API for you. It will always initialize Steam Client API endpoints when executing on a client or listen server, and will always initialise Steam Game Server API endpoints when executing on a dedicated server, aka a "headless" server.
If you are building a dedicated server, you will likely want to read the server configuration from some external source before calling this node.
The output of the node will indicate success or failure. If you are initializing for a client/listen server it may also indicate "Should Restart". This is a feature of Steam API, if the game was not launched from the Steam client then it will attempt to relaunch from the Steam client ... so if this is true you should close the game as Steam will be relaunching it from the Steam client its self.
Finally, we call a few event handlers so we can better organize our nodes.
This occurs in the event that the game was not launched from the Steam client. It indicates that Steam API is attempting to relaunch the game from the Steam client and thus this instance of the game should be closed.
This generally only happens if your user isn't logged into Steam, doesn't have Steam installed at all or doesn't own the game and thus the API can't initialize. In this case, you should generally notify the user of this issue and its common causes and then close the game gracefully.
The Bootstrap Your Game Here is the ideal place to warm up your game systems and runs right after the Steam API has successfully initialized. This is where you would enable Steam Input, find your leaderboards, load system settings, read the player's inventory and initialise any additional game systems relevant to your game.
The Steam Game Instance has all of Steam's global events, and you can register to them easily by adding a Steam Game Instance (or your derived class) as a variable to whatever blueprint you want to leverage the events from. In the constructor for that blueprint set the variable to Steam Game Instance, casting to whatever specific type you might need.
Once we have our Game Instance variable created and the logic to set it in the Construction Script, we can then leverage the events from the instance as you would any other Blueprint event
Steam Lobbies are generally a key part of your game and they are relevant between scene transitions. It is generally in your interest to store data about the lobbies your player is in on the Game Instance, where it will happily persist and can easily be accessed from anywhere.
Create a custom game instance derived from Steam Game Instance
DO NOT: Derive from the BP_SteamGameInstance That is simply a working example of how to do this you can check for ideas on how to set up your events.
Create a new variable of type Integer 64 ... this is where we will store our lobby ID when a lobby is created, joined, etc.
Handy Game Functions
Create functions that use the lobby and are specific to your game
These will be specific to your particular game. In this example, our game has a concept of teams, so we make a function to get or set the team for a player on the lobby metadata.
This function... again specific to our game ... this is just idea food for you to get thinking ...
Our function here takes in the Steam ID of the user to who we are setting the team as well as a Gameplay Tag that represents which team they will be assigned to.
We get the Hex ID from the Steam ID ... this just makes that long number a shorter Hex string
We append _Team to that and use the result as the "key" in our lobby data ... this will look something like ABCD1234_Team
We get the string name of our Team ... this might look like State.Team.1 which we set as the "value" of the key.
The result is that we have now stored ABCD1234_Team = State.Team.1 on our lobby as metadata ... this can then be read back by any member of the lobby at any time by simply getting the Game Instance and calling Get Team to return the Gameplay Tag that is the player's team.
Every blueprint you make will have a construction function ready for you to set up. This is where you should set the Game Instance variable, as this happens before anything else, so you will know that this will always be set when this object is in scope.
