How Hydra’s Hybrid Infrastructure Supports Warhammer 40,000: Space Marine 2

Overview

Operating the online systems of Warhammer 40,000: Space Marine 2 required a common infrastructure for matchmaking, dedicated servers, player progression, analytics, diagnostics, LiveOps, and platform integration.

These systems were built on Hydra Game Services, Saber Interactive’s backend platform for game development and live operations. Hydra brings these services together in a single platform used across Saber projects, connecting game clients, platform accounts, dedicated servers, and the operational tools used by development, QA, analytics, support, and LiveOps teams.

Space Marine 2 became one of the projects where Hydra was further tested and refined at production scale, with improvements developed around the game’s requirements becoming part of the platform itself.

During game launch, Hydra supported more than 400,000 players across Steam, PlayStation, Xbox, and Epic Games Store. Reaching that scale required more than deploying additional machines. The game and backend teams had to understand how each part of the infrastructure behaved under real multiplayer load and optimize it accordingly.

Cross-Platform Infrastructure

Each platform supported by Space Marine 2 has its own authentication process, account identifiers, and technical requirements. These platform-specific integrations remained necessary, but the game’s shared online systems still needed a consistent way to represent players after authentication. Hydra provided that common backend layer. Once a player had successfully signed in via Steam, PlayStation, Xbox, or Epic Games Store, the platform identity could be represented by a Hydra account used for matchmaking, progression, analytics, diagnostics, and support tooling.

The integration still required close cooperation between the Space Marine 2 project team and the Hydra team within Saber Interactive. Project-specific requirements identified during development led to further stabilization of the Hydra SDK and refinements to several features. The resulting work also strengthened automated testing, telemetry, and recovery handling across Hydra for other projects.

Matchmaking Based on the Needs of the Game

Matchmaking in Space Marine 2 was configured through Hydra playlists and search graphs.

A playlist represented the type of session a player wanted to join, including the selected PvE or PvP mode and its requirements. Search graphs controlled how that request developed over time: which regions were checked, how the acceptable connection conditions changed, when the backend should prioritize an existing session, and when it should create a new one.

Keeping this logic on the backend allowed the team to adapt matchmaking without placing every rule directly in the game client. As more information became available about player distribution, party behavior, regional demand, and server capacity, the search process could be adjusted without waiting for a new client release.

Regional session creation also needed additional tuning. Early logic could place too much weight on the party leader’s location, even when another region would provide a better connection for the group as a whole. The search graphs and regional selection rules for pings were revised to account for the expected connection quality of the entire party.

As the matchmaking flow matured, the team added backend automated tests covering core session creation, selected state transitions, and common failure scenarios. These tests could not reproduce every combination of real players, regions, and server capacity, but they helped identify regressions before the affected logic reached live builds.

Hydra’s Compatibility Versions mechanism was integrated into the same matchmaking and release process. It defined which client and server versions were allowed to communicate, helping the team separate trial builds, staged platform updates, temporary branches, and emergency fixes.

The mechanism reduced the risk of incompatible clients and servers entering the same session, but it still depended on careful coordination. Client builds, dedicated server deployments, and backend compatibility rules all had to describe the same version model. Hydra provided the control point, while the project team retained responsibility for keeping the complete release configuration consistent.

Dedicated Server Infrastructure

The dedicated-server layer was one of the most important parts of the launch preparation.

Online matches in Space Marine 2 ran on headless game builds that maintained the authoritative simulation, processed the game state, and coordinated connected players. Hydra handled the orchestration and allocation of these servers, while the server builds themselves had to be optimized for the game-specific CPU and memory requirements.

The project migrated its dedicated-server builds from Windows to Linux to establish a more efficient hosting base during development & integration. However, changing the operating system alone did not determine how many matches the infrastructure could support. The teams still needed to understand the real resource profile of an active Space Marine 2 session.

For approximately six months, the project team and the Hydra team conducted repeated multiplayer playtests focused on dedicated-server performance. During these tests, the team measured CPU and memory consumption while several matches ran on the same host and observed how the resource profile changed during longer or more demanding sessions.

The objective was not simply to find the maximum number of processes that could be started on one machine. The teams needed to determine how many complete sessions could run simultaneously while maintaining stable simulation performance throughout a match.

During the playtests, the teams also used Hydra’s dedicated-server tags to add gameplay context to infrastructure monitoring. Each server reported standard values such as the current player count, map, game mode, and FPS, with the FPS value updated once per second. This allowed CPU and memory measurements to be interpreted alongside what was happening in the session: for example, whether a resource spike occurred during a particular map, game mode, player load, or drop in server performance. The additional context helped the teams distinguish general infrastructure pressure from issues tied to specific gameplay conditions.

CPU affinity was used to reduce the impact of dedicated-server startup on matches already in progress. Launching and initializing a new server process creates a short period of high CPU usage, which could otherwise compete for processing time with active sessions running on the same host. By assigning processes to specific CPU cores, the team could isolate much of the startup load and maintain more stable performance for servers already hosting players. The configuration was refined during playtests as the team gathered more data on startup peaks and active-session behavior.

Memory usage had to be evaluated alongside CPU consumption. Increasing the number of processes per host was only useful if every process retained enough memory to operate safely under sustained load. A configuration that looked efficient immediately after startup could behave differently during a longer match or during a gameplay sequence with heavier AI, physics, and replication activity.

The final capacity model was therefore based on measured game behavior rather than a fixed theoretical limit. By reducing the CPU and memory cost of each active server process, the teams increased the number of concurrent matches that could run on the available infrastructure.

The optimizations became particularly important at launch, when Hydra’s infrastructure supported more than 400,000 players. The capacity available during that period was not solely a function of the number of machines deployed. It also reflected the six months spent improving how efficiently each machine could host active game sessions.

Hydra centrally handled matchmaking, session orchestration, identities, configurations, and server allocation, while the Linux dedicated-server layer could be tuned independently around the game’s actual performance characteristics.

Heated Servers

Increasing overall hosting capacity was only one part of the dedicated-server work. The project also needed to reduce the time players spent waiting after matchmaking had found or created a session.

Starting a dedicated server on demand adds several steps to the flow. The process must launch, load the required content, connect to Hydra, receive the correct configuration, and report readiness to accept players.

Hydra’s Heated DS system reduced this delay by maintaining a pool of dedicated-server processes that had already completed most of their initialization. When matchmaking needed a server, Hydra could assign one from this prepared pool rather than restarting the complete process.

"Using Heated DS technology, we reduced loading times by 15–20 seconds."

The improvements developed and validated on Saber projects like Space Marine 2 are incorporated into Hydra, allowing other internal teams and external developers to benefit from the same production experience.

The appropriate pool size, therefore, depended on player activity, regional demand, server density, and the expected traffic profile. Heated DS improved the player-facing startup experience, but its effectiveness relied on the same resource measurements used during the six-month optimization period.

The hybrid infrastructure also supported local dedicated-server testing. Developers could launch a server process on their own machine while connecting it to the Hydra environment. The local process could still participate in backend-dependent flows such as session creation and configuration retrieval.

This approach allowed engineers to investigate the boundary between dedicated-server behavior and backend configuration without deploying every experimental build to shared hosting. They retained direct control over the server process while testing it against the same service layer used by the project.

Game Configurations as a Live Operations Layer

Not every change to an online game should require a new client build.

Client patches may need preparation, platform certification, distribution, and coordination across several storefronts. That process remains necessary for changes to game code and content. Still, it can be unnecessarily slow for operational values and rules that the game has already been designed to receive remotely.

Hydra Game Configurations allowed the client and dedicated server to request selected settings from the backend. In Space Marine 2, this system was used for matchmaking playlists, search graphs, access rules, logging levels, reward parameters, time-limited events, feature switches, and other live settings.

Time-based configurations could activate or deactivate events according to a schedule. Conditional logic could also adjust what individual players see. For example, promotional content could be hidden from users who already own the related content.

The team could change an experience multiplier, adjust reward values, activate an event, update access lists, or disable selected functionality while investigating an issue. Because the game had already been built to read these parameters from Hydra, the changes did not require rebuilding and redistributing the game client.

The system was particularly useful for a game operating across multiple platforms. LiveOps decisions could be separated from platform patch schedules where the change did not require new executable code or content.

"Configuration changes and in-game events can go live in seconds instead of waiting for the next game update."

The same configuration layer connected several parts of the hybrid infrastructure. Matchmaking behavior, server rules, game parameters, events, player-facing conditions, and logging could be coordinated through the same backend even though the game itself ran across clients, platform services, and distributed dedicated servers.

The flexibility came with a practical limitation. The Game Configurations interface was organized through profiles, components, schema versions, and data variations. A user making an update needed to understand not only what a value controlled, but also which environment, profile, version, and variation were currently active. A small edit applied to the wrong configuration path could produce an unintended result in production. The Development Portal could not be treated as an informal settings screen.

The project introduced review and validation procedures for configuration changes. In practice, this created a second release process alongside normal game builds. Backend changes could be deployed more quickly, but they still had to be tested, reviewed, recorded, and applied with care.

In the end, the configuration workflows developed for Space Marine 2 reduced the need to rely on client patches for selected LiveOps changes and became part of Hydra’s broader operational model.

Managing Logs at High Concurrency

Logging was also controlled through the backend configuration layer.

Detailed logs were essential when investigating matchmaking, progression, or dedicated-server problems. At high concurrency, however, recording the same verbose information for every active session resulted in a large amount of redundant data.

The issue was not the cost of one individual log message. It was the effect of multiplying that message across many players, sessions, and dedicated servers.

Hydra allowed engineers to adjust logging behavior without redeploying the game. They could temporarily increase the level of detail for a particular investigation, record only a portion of live sessions, or disable categories of repetitive messages.

This allowed the team to preserve diagnostic visibility without making logging itself an unnecessary infrastructure burden.

The appropriate balance depended on the incident. Excessive filtering could remove the information needed to diagnose a rare problem, while permanently verbose logging could consume processing and storage resources during peak traffic.

Normal operation therefore used controlled logging, with more detailed collection enabled temporarily when a specific investigation required it.

Storage at Production Scale

Hydra’s Abstract Data service allowed the project to store selected types of game data in separate containers. It was not designed to serve as a general-purpose cloud storage layer, but the initial integration treated it similarly and used it for frequent persistence updates.

As a result, relatively small local changes could trigger immediate backend writes, creating much heavier service usage than intended. The team later revised the integration so that Abstract Data was used more selectively and requests were sent at controlled intervals rather than after every minor change.

The team introduced pacing so that changes could be accumulated and written at controlled intervals rather than submitted after every update. Some settings that did not require cloud synchronization were moved to local platform storage, allowing the backend to focus on progression data that needed to remain consistent.

The optimization reflected the same production-scale principle found in the dedicated-server and logging work. The cost of an operation could not be evaluated only from the perspective of a single client or single session. The team also had to consider how frequently it would occur across hundreds of thousands of players.

Connecting Analytics, Sessions, and Failures

Operating a live multiplayer game requires more than collecting separate logs from each service. A player report or server failure may involve matchmaking activity, dedicated-server records, configuration values, backend events, and crash data. Investigating each source independently makes it harder to determine whether several reports share the same cause.

Hydra’s Fact Contexts provided a shared reference across these systems. A player interaction or game session could be associated with related backend events, allowing developers and support teams to follow the same context through several services.

Backend Crash Reports provided a centralized source of information on server-side failures. A crash report could confirm that a process had stopped, but it rarely explained the complete sequence leading to the failure.

Combined with Fact Contexts, session telemetry, and configurable logging, the team could reconstruct more of what the server and backend services had been doing beforehand. This was particularly useful during the first days after major updates, when several reports needed to be compared and recurring problems had to be identified quickly.

Hydra also collected anonymized operational and business intelligence metrics. These included concurrent player counts, session activity, regional distribution, matchmaking performance, and backend request volume.

The metrics were part of the operational feedback loop rather than only a source for retrospective reporting. A regional increase in matchmaking time could point to insufficient capacity or unsuitable routing. A rise in backend API calls could reveal inefficient client behavior. Changes in player activity could be linked to corresponding changes in dedicated-server fleet metrics and Heated DS pool availability.

Together, analytics, Fact Contexts, logs, and crash reports provided a common view across the different layers of the hybrid infrastructure.

Player Support

Hydra’s reporting and moderation tools allowed players to report inappropriate behavior directly in-game. Authorized team members could review these reports through the Development Portal, examine the available session context, and apply sanctions when necessary. Support agents used anonymous identifiers supplied by players to locate relevant sessions, Fact Contexts, and available technical records. This provided more context for investigations without requiring direct access to platform account information.

The same backend context used for technical diagnostics became part of how the live game was supported after release.

The Result

During launch, Hydra supported more than 400,000 players while continuing to coordinate matchmaking, allocate dedicated servers, process progression updates, and collect operational data.

Both Saber teams refined the production setup together through game-specific engineering, extensive playtesting, telemetry, and configuration work. The resulting improvements were incorporated into Hydra for use across other teams and projects.