Adaptive Example Project

The Ultimate Multiplayer Lobby example is one provider-neutral walkthrough for UCIK. It reads the registered online, matchmaking, and hosting providers at runtime and shows only their advertised capabilities. Adding a future provider does not require another example project or a backend switch in the widget.

Open the example

1. Enable Ultimate Crossplay Integration Kit in a C++ host project and restart Unreal Editor.
2. Open /UltimateCrossplayIntegrationKit/ExampleContent/Maps/LobbyMap from the Content Browser. Enable Show Plugin Content if the mount is hidden.
3. Configure the providers and network driver described below.
4. Start PIE. The dashboard shows the registered providers, their primary/mirror or selected role, availability, and capability groups.

The menu map is UI-first and has no ThirdPerson template dependency. GM_Lobby selects HUD_Lobby, and the HUD creates WBP_CrossplayLobby once. The four smaller widgets are reusable provider, friend, discovery, and progression rows. Successful lobby-game and session-game hosts travel to MultiplayerMap, a dependency-free replicated playground built from engine basic shapes.

Configure providers

Gameplay-provider priority is startup configuration. Login method choice is runtime data returned by the identity registry.

Choose matchmaking and hosting in the UCIK role policies. The dashboard reports which available provider was selected. It never renders credentials or rewrites provider policy.

Choose the active transport in the UCIK Overview and use Apply Transport Configuration before testing travel. See Crossplay Network Setup.

Runtime journey

The dashboard exposes semantic choices that remain valid across providers:

• The login dropdown comes from Get Login Methods. Selecting a method renders its declared fields and submits one data-driven request; adding an identity authority does not require a new button or widget asset. Automatic follows the configured route order.
• Host / Listen starts the configured net driver before creating a lobby or session, then travels only after the asynchronous create succeeds. Client / Find discovers games; the row's Join action joins through UUCIKLobbySubsystem or UUCIKSessionSubsystem and travels through UUCIKTravelSubsystem.
• The social card displays one folded row per person, publishes rich presence, routes invites by the configured priority, and accepts normalized join requests.
• The matchmaking card starts or cancels the configured UMIK_Subsystem queue and travels only after shared connect information passes UCIK validation.
• Achievements, leaderboards, and integer stats use configured identifiers and remain unsupported, idle, loading, empty, ready, or failed independently.

An unavailable capability stays explicit. A successful query with no rows says that it is empty; a provider or configuration error remains visible in its card. A degraded mirror does not hide a usable primary result.

Blueprint entry point

There is no UML facade. The shipped widget calls the same unified nodes a customer graph uses: Login, Create/Find/Join Crossplay Lobby, Create/Find/Join Crossplay Session, the party, social, storage, progression, voice, hosting, matchmaking, travel, and reconnect nodes. Widget state is presentation state only.

C++ entry point

Add UCIKCore to the module dependencies, then use the role subsystem you need:

#include "Lobbies/UCIKLobbySubsystem.h"
#include "UCIKIdentitySubsystem.h"

UUCIKIdentitySubsystem* Identity = GetGameInstance()->GetSubsystem<UUCIKIdentitySubsystem>();
UUCIKLobbySubsystem* Lobbies = GetGameInstance()->GetSubsystem<UUCIKLobbySubsystem>();

FUCIK_LoginRequest LoginRequest;
LoginRequest.MethodId = TEXT("Auto");
Identity->Login(LoginRequest);

FUCIK_LobbySettings LobbySettings;
LobbySettings.MaxMembers = 4;
Lobbies->CreateLobby(TEXT("Party"), LobbySettings, Callback);

Matchmaking remains exposed by UMIK_Subsystem; its provider and hosting choices come from the UCIK role policies, and its match result uses the same FUCIK_ConnectInfo travel path.

EOS-only PIE

1. Configure EOS credentials and the EOS net-driver block.
2. Start the EOS Developer Auth Tool and sign in the required Context_N accounts.
3. Disable Steam for the host run, or run without an available Steam client.
4. Start PIE and confirm the provider strip reports EOS as the available primary.
5. Exercise login, friends, lobby, session, invite, and travel. Steam-only operations must not appear as successful fallbacks.

EOS plus Steam PIE

1. Keep the EOS setup above and set SteamRemoteServiceIdentity=epiconlineservices.
2. Start Steam with the configured app ID available to the host process.
3. Use two single-process PIE players. Player zero may expose EOS plus Steam; player one uses the second EOS Developer Auth Tool context.
4. Confirm the provider strip reports the configured primary and mirror roles rather than a user-selected backend combination.
5. Send the lobby invite after discovery and before join, then verify lobby and session travel.

The repository's exact two-client prerequisites and expected log markers are in docs/agents/crossplay-test.md. Account identifiers and credentials must be redacted from shared logs.

Two-window multiplayer playground

Use this customer-style check to prove ownership and replication without the repository's private test controller.

Prepare PIE

1. Apply the EOS GameNetDriver configuration from Crossplay Network Setup, then restart the editor.
2. Start the EOS Developer Auth Tool on the URL configured in EOS Integration Kit settings. Sign in two different accounts as Context_1 and Context_2.
3. For an EOS-plus-Steam host, keep Steam signed in and configure SteamRemoteServiceIdentity=epiconlineservices. The second single-process PIE player intentionally remains EOS-only because Steam identity is process-wide.
4. Open /UltimateCrossplayIntegrationKit/ExampleContent/Maps/LobbyMap.
5. In Editor Preferences > Level Editor > Play, set Number of Players to 2, enable Run Under One Process, and choose Play Standalone as the net mode. From the Play dropdown choose New Editor Window (PIE) so both players remain visible.

Lobby path

1. Start PIE. In the first window choose EOS Connect · Steam; expect EOS and Steam identities when both are configured. In the second window choose the configured EOS Developer Auth Tool route; expect EOS only.
2. In the first window select Host / Listen under Lobbies. A started request is not success: the window stays on the dashboard until backend creation completes, then travels to MultiplayerMap as Host.
3. In the second window select Client / Find. When the host row appears, select Join. The client joins through UCIK's resolved and net-driver-validated connect string, then travels to the same map as Client.
4. Confirm both HUDs report Connected players: 2. Each player has a different color and overhead name.
5. Focus the first window and use WASD, mouse look, and Space. The character must move and jump in the second window. Repeat from the second window and observe its character move in the first.

Session path

Stop PIE and repeat from LobbyMap, using Host / Listen under Sessions, then Client / Find and the discovered session row's Join action. The same connected-player, ownership, movement, camera, and jump checks must pass.

The test fails if either player remains on the dashboard after a successful join, reports the wrong role, never reaches two connected players, cannot control its own character, cannot see the other character move, or logs a travel or net-driver validation failure. Test-only automatic movement is never enabled by this walkthrough; it requires the explicit -UMLReplicationTest development flag.

External prerequisites

UCIK does not invent service data. Live tests require valid provider credentials, Developer Auth Tool state, Steam state when applicable, matching net-driver configuration, provider-side achievement/leaderboard/stat definitions, and a real queue/deployment for non-local hosting. Missing definitions produce actionable validation or unsupported states; Automation covers the provider-independent state and error paths.

Intentionally unavailable features

Commerce, inventory, entitlements, and platform avatars are not presented as portable. UCIK does not currently expose a unified capability contract for them, so the example contains no shop, inventory, or Steam-avatar fallback. Add platform-specific UI in your game only when that product decision is intentional.