Custom Providers & Platforms

Two parts of the SDK are interfaces you can replace: where tickets come from, and how the WebSocket is carried.

Custom ticket providers

HttpTicketProvider is one implementation of ITicketProvider. If your backend uses a different request or response shape, or your game gets tickets some other way, implement the interface:

using System.Threading;
using System.Threading.Tasks;
using Pairiquium.Tickets;
 
public class MyTicketProvider : ITicketProvider
{
    public async Task<TicketInfo> GetTicketAsync(string preferredRegion, CancellationToken cancellationToken)
    {
        // Call your backend however you like, then return both values.
        var result = await MyBackend.RequestPairiquiumTicketAsync(preferredRegion, cancellationToken);
        return new TicketInfo(result.Ticket, result.WsEndpoint);
    }
}

Pass it to Initialize in place of HttpTicketProvider. The SDK calls it for every connection attempt, including reconnects. preferredRegion is null when no region was requested.

Keep the API key out of the game

Whatever provider you write must get tickets from your backend, not from Pairiquium directly. The SDK is designed never to hold the API key.

Platforms

Platform	Support
Windows and Linux desktop	Supported out of the box through `ClientWebSocketTransport`.
WebGL	Not supported. Browsers don't allow the kind of WebSocket access the default transport uses, and the Unity assembly excludes WebGL.
Consoles	Supply your own transport. See below.

Custom transports

The transport is the layer that sends and receives text frames. To use your own, for example on a console, implement IWebSocketTransport: connect to a URI, send one JSON text frame, receive one JSON text frame, and close. The MatchmakingClient class handles everything above it.

Console SDKs are under each platform's NDA, so console transports aren't part of the open source repository. The interface is the extension point that lets you add one.

Pass a factory for your transport to Initialize. It is called once for every connection attempt, so each reconnect gets a fresh transport:

_matchmaking.Initialize(
    tickets,
    options: null,
    transportFactory: () => new MyConsoleTransport());

You keep everything MatchmakingBehaviour does for you: events on Unity's main thread, and cleanup when the component is destroyed. Leave the factory out on Windows and Linux desktop to use the default ClientWebSocketTransport.

Needs SDK 1.1.0 or later

The transportFactory parameter was added in 1.1.0. On 1.0.x, MatchmakingBehaviour always uses the desktop transport, so upgrade, or use MatchmakingClient directly as described below.

Without the Unity component

MatchmakingClient is the engine-agnostic core class that MatchmakingBehaviour wraps. You can use it directly, for example outside a MonoBehaviour:

using Pairiquium;
 
var client = new MatchmakingClient(tickets, () => new MyConsoleTransport());
 
client.MatchFound += metadata => { /* background thread */ };
await client.BeginSearchAsync("1v1");

MatchmakingClient raises its events on background threads, so move them onto the main thread yourself before touching Unity objects. MatchmakingBehaviour does this for you; the client doesn't.

Other engines

The core library is plain C# with no Unity references, and it ships as source. If you are porting to another engine, it is a working reference for the protocol. The wire format itself is described in API Specs.