Documentation

Docs

Everything to go from an empty folder to a running multiplayer game.

Quickstart

From an empty folder to a running server and a connected client in five steps.

Crossplay generates a complete, ready-to-run project: a .NET server that composes only the pieces you pick, and a Unity client wired to match. You never edit the framework — you snap pieces on and plug your own game into the sockets they expose.

1
Create a project.Open New project, give it a name, choose a database (SQLite is zero-config and the default), and pick a transport. Everything else has a sensible default.
2
Choose your pieces.Tick the features your game needs — Characters, World, Movement, Chat, Inventory, and so on. Dependencies are pulled in for you; a card game and an MMO start from the very same kernel.
3
Generate & run the server.Create the project, then run the generated server. It boots on your chosen port and persists to your chosen database out of the box.
dotnet run --project Server
4
Open the Unity client.Open the generated Unity project. The Crossplay client packages are already referenced and the bootstrap flow is generated to match your pieces: connect → sign in → pick a character → enter the world.
5
Drop in a panel & play.Every piece ships a drag-and-drop UI panel (e.g. the chat window or the inventory grid). Drag its prefab into a scene, press Play, and you're talking to your server.

💡

Prefer real auth from the start? Pick a sign-in method (Username/Password, Steam, Google, …) when you create the project. The generated flow then waits for the Login panel and the Character panel instead of auto-signing-in — a real game flow, not a demo shortcut.

What you get

A .NET 10 dedicated server composed of exactly the pieces you chose — nothing more.
A Unity 6.3 client project with the matching packages and a generated bootstrap flow.
Durable persistence on your chosen database, with account and character data saved out of the box.
A drag-and-drop UI panel for every feature piece, ready to place in a scene.

Where the API docs live

The server pieces install as compiled DLLs, and each one ships its XML doc file beside it. Your IDE picks that up automatically — hover any Crossplay type in Rider, Visual Studio or VS Code and you get the same prose you see in the API reference. Nothing to configure.

How it works

The one mental model that makes everything else fall into place.

✨

Crossplay moves data and syncs state. It does not know what game you are making.

The kernel — Core — is genre-agnostic. It gives you transport, identity, sessions, rooms, and a messaging SDK, and nothing else. It works unchanged for a card game, hide-and-seek, an MMO, or a rhythm game.

Pieces stack downward

Every feature is a piece that depends only on lower pieces, never higher ones. World builds on Characters; Movement builds on World; feature pieces like Chat depend on Core alone. You compose the ones you want and leave the rest out — removing a piece never breaks the others.

Movement → World → Characters → Coredependencies flow downward only

Every piece is the same trio

A piece is Contracts (the wire protocol both sides share), a Server half (.NET), and a Client half (a Unity UPM package). You add the server half with one line and reference the client package — the Hub does both when it generates your project.

services.AddCrossplayChat();server: one line composes the piece

Presentation is always yours

Pieces sync abstract state — ids, numbers, and opaque blobs — never models, animations, or sounds. An emote is an id and a payload: one game renders it as a chat line, another as a UI sticker, another as a full 3D dance. The piece cannot tell the difference, and it just works under any of them. You bind meaning through the SPIs each piece exposes.

The wire carries ids, numbers, and opaque blobs.
The client gives you events and SPI sockets.
The look — models, animators, UI, controls — is 100% your game's.

Composition recipes

Different games, the same kernel. Start here and add only what the genre needs.

Because pieces compose, you assemble a game by taking the kernel plus the handful of pieces the genre calls for. Here are three starting points — notice they share the same Core.

🃏 Card / turn-based game

No avatars, no world, no movement. Just the kernel, matchmaking to pair players, and your own card messages on top. Add the meta pieces (Economy, Achievements, Leaderboards) freely — they no longer require Characters.

Core  +  Matchmaking  +  (your card messages)

🏃 Hide & seek / party game

Now you want bodies in a space. Add Characters, World, and Movement, then layer your own role and tag messages. Emotes and Voice snap on for presence.

Core  +  Characters  +  World  +  Movement  +  (roles, tag)

🗺️ MMO / persistent world

The full spatial stack plus the persistent-world pieces: zones and instancing, the Director for instance placement across nodes, Inventory and the Container family, Guild, Mail, and the combat family. Everything persists to your database and scales out over Redis.

Core + Characters + World + Movement + Director + Inventory + Guild + Combat …

🧭

Unsure which pieces a genre needs? Open any piece's API reference — each one lists what it depends on, the seams it expects you to implement, and the services it hands you.

Implementing an SPI

The pieces ship as compiled DLLs. The SPIs are where your game plugs in.

Crossplay runs the universal machinery — validation, ordering, persistence, broadcast — and calls out to your game whenever a decision is genuinely yours. Those call-outs are SPIs: interfaces Crossplay calls and you implement. Every piece ships an inert or permissive default, so a piece works the moment you install it and gets its meaning the moment you replace the default.

🔑

A service is something you CALL. An SPI is something you IMPLEMENT. The API reference labels every interface, so you never have to guess.

The two kinds of seam

Game SPI — implementing it changes a game rule. IAbilityRules decides whether a cast is legal; IQuestCatalog decides what quests exist; IProgressionCurve decides what level 40 costs.
Provider — implementing it changes infrastructure, never a rule. IDocumentStore decides which database the bytes land in; ICharacterStore decides where characters persist; IServerTransport decides how they move.

Register before you compose

Every piece registers its default with TryAdd, which means the first registration wins. Register your implementation BEFORE the piece's AddCrossplay* call and yours is the one that gets used. Register it after, and the default has already claimed the slot.

// your rules win because they are registered first
services.AddSingleton<IAbilityRules, MyAbilityRules>();
services.AddCrossplayAbilities();the TryAdd seam: register first, and the shipped default steps aside

A worked example

Abilities handles the parts every game shares: the entity is in the world, the payload is a sane size, the cooldown has elapsed, and the observers get told. What an ability MEANS — damage, hit detection, combos, ammo — is the one thing only your game knows. So that is the seam.

public sealed class MyAbilityRules : IAbilityRules
{
    public AbilityDecision Decide(ISession actor, WorldEntity self, ushort abilityId, byte[] targetData)
    {
        if (!_mana.TrySpend(actor.AccountId, Cost(abilityId)))
            return AbilityDecision.Reject();

        return AbilityDecision.Accept();
    }
}the framework already ran the universal gates before calling you

Finding the seams you need

Open a piece in the API reference. Its SPIs are listed first, split into the two kinds above, each with the prose from the source. Because the reference is generated from the same build that produces the DLL you installed, it can never describe a version you do not have.

💡

You do not need the website to read these. Each shipped DLL carries its XML doc file beside it, so hovering an SPI in Rider, Visual Studio or VS Code shows the same text inline.

Docs

Quickstart

What you get

Where the API docs live

How it works

Pieces stack downward

Every piece is the same trio

Presentation is always yours

Composition recipes

🃏 Card / turn-based game

🏃 Hide & seek / party game

🗺️ MMO / persistent world

Implementing an SPI

The two kinds of seam

Register before you compose

A worked example

Finding the seams you need

Piece reference

Core

Spatial

Combat

Economy

Social

Progression

Meta

Infra