To fill that gap quickly, use a universal prompt that any AI coding assistant can run. It works in two parts: first the assistant audits the project to find how your game and netcode currently connect to a server, then it adds the matchmaking connection. Both prompts are netcode-agnostic.

Prompt 1 — audit the project (read-only):

Read-only, no code changes. My Unity project uses a netcode framework and I'm adding Edgegap matchmaking, which will give my client a server address (an FQDN) and an external port at runtime. Find and tell me: 1) the method that starts a client connection to a server, the file and line, and what triggers it; 2) where the server address and the port are set before connecting — the exact property or field names, the transport in use, and the file and line. Give file paths and line numbers. Do not change anything.

For the Mirror Tank sample, the audit confirms the client connects by calling StartClient() on Mirror's NetworkManager, with the address set via NetworkManager.singleton.networkAddress and the port set on the active PortTransport — in this case the KCP transport on port 7777.

Prompt 2 — add the connection:

In the Edgegap sample MatchmakingClientHandler.cs, find the block that runs when the ticket status is "HOST_ASSIGNED". It currently only logs the assignment. Replace that placeholder with code that connects to the assigned server using my netcode: read the assigned server's FQDN and set it as the network address, read the external port (it is a string — convert it to the type my transport expects) and set it on the active transport, then start the client connection. Use the connection method, address field, and transport port you identified in the previous step. Return the full updated block.

The assistant reads the project, identifies the netcode, and adapts the connection to it. The same approach works for other netcodes — the audit and edit adapt to whatever connection method the project uses. The one exception is a project that routes connections through its own custom networking layer rather than calling the netcode directly; the audit will flag that, and you can prompt the assistant to adapt the edit accordingly.

Part 3 - Connect the Handler to Your Scene

In your game scene, create an empty object: from the menu, select GameObject, then Create Empty. Rename it "Matchmaking." With the object selected, in the Inspector, select Add Component and add the Matchmaking Client Handler.

Two fields need to be filled: Base URL and Auth Token. Both come from the matchmaker, created next. Leave every other setting at its default.

Part 4 - Create Your Matchmaker

On the Edgegap platform, select Matchmaker, then Create Matchmaker, and give it a name for your own reference, such as "quickstart-dev."

For the configuration, nothing needs to be written or pasted. Open the dropdown and select the Simple Example — a ready-made setup ideal for a two-player match, which suits the Tank game. Selecting it automatically fills in your most recently uploaded application and version. Confirm these are the application and version you intend to use; if you have several versions, select the right one now.

Two parts of this configuration are worth understanding, as they are the starting point for tailoring matchmaking later:

• The match size rule sets how many players are needed — here, one team of two players.

• The latencies rule has each player ping a set of shared beacons and groups players whose results are close enough to share a low-ping match. The server's location is chosen separately, based on where the grouped players actually are.

On submit, a warning may appear that the server image isn't cached. This is a reminder that a production release benefits from a cached image so servers deploy instantly; for testing it is fine, so select Continue. The matchmaker spins up on the free shared cluster — allow a few minutes to initialize, then up to five more for it to become reachable on the network.

Once it is online, open its details. Copy the API URL and, back in Unity, paste it into the Matchmaking object's Base URL field. Do the same for the Auth Token.

This token only grants access to your matchmaker and nothing else on your account, so it is safe to keep in the client during development — no backend needed. In production, you would typically keep this token on your own backend instead. Not to hide the token, since it is matchmaking-scoped and safe, but so players authenticate to your backend first, letting you enforce identity, bans, and skill-based matching before a ticket is ever created.