Game lifecycle

Launch operations target an explicit instance ID or the persisted current instance. Profile selection and instance selection are separate concerns

Install and launch

Desktop instance action
  -> GameLaunchCoordinator (installed instance)
     or GameInstallationWorkflow (new installation)
  -> version and patch selection
  -> resumable download and Butler extraction
  -> runtime prerequisites
  -> GameLauncher authentication and client preparation
  -> GameProcessTracker and per-instance logs

GameInstallationWorkflow rejects concurrent installation work for the same instance. Every instance targets an explicit branch and numeric version. It records PendingVersion before modifying an installation so an interrupted update can be resumed. An installed instance whose metadata matches the selected version uses a fast path without contacting version sources or mirrors

GameVersionCatalog selects a mirror and resolves its request headers for the selected download URL. GameInstallationWorkflow and PatchManager pass those headers to HttpFileDownloader for file size checks and transfers. Mirror discovery and availability checks use the same launcher version placeholders. See mirror definitions for discovery methods and header fields.

Game payloads are cached under Cache/Game/Downloads. Transfer and patching propagate cancellation through network I/O, writes, extraction, and process waits. A successful installation automatically starts the game

InstancePackageService exports a selected instance as a metadata manifest or an archive of selected files. The Desktop instance wizard chooses the content and destination. InstanceRepository imports ZIP contents and registers the resulting instance; JSON import creates an uninstalled instance from its metadata. See instance packages for the package layout.

Authentication and patching

Profile and mode	Session provider
Official profile	Official Hytale OAuth and game-session endpoints
Local profile with online mode enabled	Configured custom authentication service
Local profile with online mode disabled	Per-launch Local Node

ClientPatcher restores the stable original backup before changing a client target. It redirects supported embedded service domains for custom or autonomous sessions and preserves NativeAOT string metadata. On macOS, backup state is kept outside a recognized application bundle

Autonomous launch starts Local Node before client preparation, obtains session tokens, and applies the node's certificate trust to the game. See Local Node for protocol and certificate details

Runtime and environment

RuntimeProvisioner discovers or downloads the managed Java runtime and handles Windows Visual C++ prerequisites. Official JRE archives are SHA-256 verified when metadata supplies a hash; failed verification removes the archive before extraction

The launcher builds Java arguments, GPU overrides, DualAuth settings, and user environment assignments. Custom assignments are applied last. JVM sanitization excludes options that would replace the managed agent or executable setup

Process ownership

GameProcessTracker persists PID, process start time, instance, profile, and authentication owner. On restart, it restores a live process only when its start time matches within 100 milliseconds. This accounts for small differences in process start times reported by separate launcher processes while rejecting stale records from ordinary PID reuse.

Different instances may run together. The same instance cannot run twice, and official authentication permits only one running client per Hytale account owner

After an autonomous game starts, Local Node transfers lifetime ownership from the launcher to the game PID. On exit, the launcher reconciles play time and cleanup; Local Node stops when its attached game exits

Use typed process events and instance-scoped progress to update a host. Do not infer game lifetime from whether the launcher window is open

Source: Game services