Behavior common to both the user and game server APIs.

You can’t create this directly; instead use a SteamAPI or SteamGameServerAPI.

In Steamworks, a callback is a broadcast notification. In C++ you discover what notifications are available from the docs and use the STEAM_CALLBACK() macro to connect your method. In this Swift version you register using a run-time call to one of the registration methods such as onSteamServersConnected(_:). If you register after creating your API instance and before making your first call to runCallbacks() then your code is equivalent to the C++ version.

An instance of the Steamworks user API

Create and retain one of these to access and use the Steamworks APIs.

Steamworks ref: steam_api.h

An instance of the Steamworks game server API

Create and retain one of these to access and use the Steamworks game server APIs.

Steamworks ref: steam_gameserver.h

Wrap up the SteamEncryptedAppTicket functions.

See Encrypted Application Tickets

An executor for associating actors with Steamworks

EXPERIMENTAL

This creates a single new thread to run Actor/TaskTask code and periodically call Steamworks – either to dispatch callbacks or do Steamworks maintenance work.

A single executor thread can support multiple APIClients so you can service a gameserver and client API from the same thread.

This solves the problem of using Swift concurrency with Steamworks outside of the main thread.

Problems:

1. The poll resolution promised by the API is dubious – probably because of the thread priorities available via NSThread getting anything below 100ms is a bit sketchy.

To Do (perhaps):

• Change the API clients at runtime - eg. creation of a server or something
• Figure out what on earth is wrong with Linux vs. swift-atomics (or more likely move to built-in atomics)