Unreal Engine
Multiplayer Backend

Straight talk: there is no Unreal plugin — and you don't need one

This API is a hosted backend service, not a netcode layer. It doesn't replace actor replication, and there's no marketplace plugin to install — because the integration is genuinely simpler than that. Unreal projects already contain everything needed to reach it: the engine's HTTP stack, or standard C++ compiled into your module.

Two supported paths cover every workflow:

Setup — C++ SDK in an Unreal project

1. Register and copy your API token from the cabinet (the private token stays server-side only — never in a shipped client).
2. Download SDK.zip and extract include/ into your project (e.g. Source/ThirdParty/Multiplayer/).
3. Add the include path in your module's Build.cs: PublicIncludePaths.Add("ThirdParty/Multiplayer/include").
4. Add nlohmann_json the usual way (vendored or via your existing UE JSON setup) — that's the SDK's only dependency.
5. Include michitai/multiplayer/Client.h and call the API.

Real calls, real SDK

This is the same API the C++ example project uses — namespaces trimmed for readability:

#include "michitai/multiplayer/Client.h"
#include "michitai/multiplayer/Players/Players.h"
#include "michitai/multiplayer/Rooms/Rooms.h"

using namespace michitai::multiplayer;

Client client("YOUR_API_TOKEN");

// Register — privateKey is the player credential, persist it
auto reg = players::Players::registerPlayer(
    client, "PlayerOne",
    nlohmann::json{{"level", 1}, {"rank", "bronze"}});
FString PlayerToken(reg.privateKey.c_str());

// Create a realtime-enabled room
auto room = Rooms::createRoom(
    client, reg.privateKey, "Lobby 1",
    /*maxPlayers*/4, /*password*/"", /*realtime*/true);

// Keep the session alive on a timer
players::Players::sendPlayerHeartbeat(client, reg.privateKey);

Response objects expose success/error — check them like the other SDKs. The full call list mirrors the REST reference one-to-one.

REST & Blueprint path

For Blueprint-heavy projects or prototypes, skip C++ entirely. Every endpoint is POST https://api.michitai.com/api/… with JSON bodies and headers X-Api-Token / X-Game-Player-Token. A VaRest-style plugin (or UE's own HTTP module) covers the whole surface — register, create/join rooms, matchmaking, leaderboard queries, player data.

curl -X POST "https://api.michitai.com/api/game_players.php/register" \
  -H "X-Api-Token: YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"player_name": "PlayerOne", "player_data": {"level": 1}}'

Where it fits in a UE architecture

• Menu/lobby layer — accounts, friends, invites, matchmaking lobbies and room creation all happen before a map loads: pure API calls, no session involvement.
• In-room signaling — the realtime channel (WebSocket + UDP) relays lobby events, ready checks and lightweight sync. For full actor replication, UE's own networking stays the answer — the services complement, not compete.
• Persistence — player stats, loadouts and unlocks live in player/game data JSON; leaderboard queries rank it server-side.
• Dedicated servers — a headless UE server can hold the private token and perform admin calls (bans, game-data writes) that clients never see.

Honest limits

• Not a replication layer. Actor replication, server-travel, and UE's dedicated-server model stay Unreal's job — this is the backend around them.
• No Blueprint-node SDK. Blueprints reach the API via REST plugins or a C++ wrapper you write once; there's no generated node set today.
• Console cert caveat. Console builds can call HTTPS REST, but platform-holder network requirements are yours to satisfy — test early on target hardware.
• Realtime is a relay, not a game state sync engine. Position-level replication belongs to UE networking or your authoritative layer.