Integration in practice
For launch, you do two things:- Link the SDK
- Build an
ArcaneClient
init: Arcane Powered hands your game process the game id of your title in ARCANE_GAME_ID and the signed-in account in ARCANE_USER_ID when it launches the game. Building the client is the ownership check — unless the cached drm_enabled flag is false, in which case it succeeds without a ticket. When a ticket is missing or expired, init asks the Arcane desktop app to refresh (and may open Arcane). You do not wire a separate ownership step.
The client then holds what your game needs for the rest of the session — the signed-in user_id, that game_id, the ownership status, the device fingerprint — so nothing downstream has to pass the id around.
Quickstart
Link the SDK and build a client at launch.
Client
Lifecycle, what is cached, and when to refresh.
Local development
Run your game outside the launcher, with the ids set by hand.
Ownership
What init does by default, and when DRM is skipped.
Rust API
Public functions and types for native Rust games.
C ABI
FFI for Unity, Unreal, and other native engines.
Errors
Function → error code → what to fix when debugging.
Contribute
PRs, SemVer, merge queue, and how releases work.
Game id
Each title has a game id in the Arcane portal. You never pass it toArcaneClient::init: Arcane Powered sets it in ARCANE_GAME_ID on the game process, and game_id() reports that value. You only reach for the portal value during local development, when you start the game yourself and set the variable by hand.
The id identifies your game to Arcane Powered — it is not a hand-picked slug or package name, and it is not a secret: it names your title, and ownership is proven by the signed ticket the SDK checks, never by knowing the id.