Building a football manager on a server-authoritative C# game backend

In FOOTDRAFT, server-authoritative has a specific meaning. The same C# PlayerAction code runs on the client and on the server. The client applies each action straight away so the game feels instant, the server runs the same action and validates it, and the server's result is the one that counts. FOOTDRAFT is a live service football manager we built on the Metaplay SDK, and every part of it, from the draft to the transfer market, runs this way.

You can play it in the browser and read the code at metaplay-shared/footdraft. This post covers how the backend keeps the server in charge, how it holds league state, and how it is tested without a running server.

What a football manager needs from a server-authoritative game backend

A football manager is a good test of a backend because its players compete over shared, persistent state:

• Twenty managers play in one league, so the season has to live on the server rather than on anyone's device.
• One matchday is simulated per day, and every manager has to see the same result.
• Managers buy and sell players with coins and gems, so every transaction has to be one a modified client cannot fake.

Card battlers, city builders and any other game with a shared economy lean on the same three things. How FOOTDRAFT handles each of them is below.

How a shared C# model makes the game backend server-authoritative

FOOTDRAFT's PlayerModel and PlayerAction classes are shared C# code compiled into both the Blazor WebAssembly client and the Metaplay server. When a manager makes a pick or a purchase, the client executes the action locally and shows the result, and the server executes the identical action against its own copy of the player's state. Because both sides run the same deterministic code, they agree, and the server's copy is the one that is kept.

The economy uses what the repo calls a charge-in-action pattern. Transfer fees and gem spends are charged inside the action itself, so the server validates the charge as part of validating the action. When an operation spans more than one entity, such as a transfer that has to succeed in both the player's state and the league's, and the second entity rejects it, the server issues a refund action. The README points to PlayerLeagueTransferSwap as the worked example.

A client that reports a balance it does not have gets nowhere, because the server never takes the client's word for a balance. For more on the trade-off between the two models, see our server-authoritative vs client-authoritative comparison.

Persistent league state in a server-authoritative C# backend

Each 20-team season league runs inside a LeagueActor, in Backend/Server/League/LeagueActor.cs. It is a persisted singleton: the standings, fixtures, results and squads are actor state on the server, and they survive server restarts and redeploys. That is what makes one matchday per day work. A manager can close the browser mid-season and come back a week later to standings that include every matchday played while they were away.

The World Cup mode added in the June 24 commit uses the same approach for its global leaderboard, a WorldCupLeaderboardActor in Backend/Server/WorldCup/.

Schema versioning in a live C# game backend

A live game has to change its data model without breaking the saves players already have. PlayerModel declares its schema version with [SupportedSchemaVersions(1, 1)] and marks each of its 31 persisted fields with a numbered [MetaMember]. FOOTDRAFT is still on schema version 1, so it has not needed a migration yet.

When it does, the Metaplay SDK handles the rest: a method tagged [MigrationFromVersion(1)] upgrades each stored player from version 1 to 2 the next time that player is loaded, and a schema-migrator maintenance job can wake up every stored entity to move them all across without waiting for each player to log in.

Testing a server-authoritative game backend without a server

Because the game logic is plain C#, it is plain code a test runner can execute. Backend/SharedCode.Tests/ holds 29 test files covering the draft, the league, match simulation, the economy, cosmetics and the World Cup flows, and they run with dotnet test Backend/SharedCode.Tests without a server process or a database behind them. The Playwright browser tests are the ones that need the server and client running.

Run the FOOTDRAFT C# game backend yourself

The project runs on Metaplay SDK Release 38, which is publicly available. Give this prompt to an AI coding agent such as Claude Code and it clones the repo, installs the Metaplay Agent and opens a local copy of the game in your browser:

Clone this repo and install Metaplay Agent using the Metaplay CLI, and open a playable version of the game locally in my browser so I can start building on top of it