Sticky Paws: Building a PvP card game on Metaplay

Despite what the name suggests, Metaplay was never meant to be just a metagame backend. At its core, it's a generic framework for building and deploying game backend systems, ranging from player accounts to complex live multiplayer interactions. Because it doesn't fall into any existing category, describing what Metaplay does and what kinds of games it is suitable for has been hard.

For years I've thought that a collectible card game like Hearthstone would be a great fit for Metaplay. The collection and the deckbuilding are the obvious part, the kind of metagame Metaplay is known for. The interesting part is the match, a live, turn-based contest between two players, and the matchmaking that pairs them. The match has to be safe from cheating, since players compete for things they care about. It doesn't need the split-second response of a shooter, or the complexity of keeping a 3D simulation in sync.

Building a whole game just to show what the platform can do might have seemed outrageous until recently. AI coding agents changed that.

So, in about a week, I built Sticky Paws, with an AI agent writing the code while I directed and reviewed it. The closest inspiration was Skyweaver, an NFT-era card game I played far too much of.

You can play it in your browser, against another visitor or a bot. The rest of this post is about how it's built: one server for the match and the metagame, and one codebase for the server and the client.

The game

Sticky Paws is a two-player card game that runs in the browser. You build a 25-card deck from your collection and take it into a match against another player or a bot, summoning critters, casting tricks and attacking the opponent's Den until one side's Den falls.

Each card in your collection has a rank from 1 to 5, and a higher rank means better stats. The twist comes after a ranked match: the winner picks one of the cards the loser played and takes a rank from it, so the same card goes up a rank in one collection and down a rank in the other.

Around the match is a small metagame. The pool is 65 cards across five animal clans and a neutral set, and a deck can draw from at most two clans. A new account starts with 45 of the cards and six ready-made decks, and earns one of the missing cards for each three matches played, so the collection screen and the deckbuilder have something to do from the first session.

The systems around the core loop are complete and built the way they would be in a shipping game: accounts, matchmaking, bots that take over when a player leaves, hidden hands, the rank transfer, a leaderboard and a LiveOps dashboard, with tests at each layer.

The game design, on the other hand, is a placeholder on purpose. The cards, keywords and rules are the smallest set that puts those systems through their paces, with no attempt at depth or balance. The lore, the card design and the art are all AI-generated, down to the illustration on each card.

It's a working card game, not a fun one, and that's the point: the engineering is what's on show.

One server to rule them

The server side of Sticky Paws is one program: a Metaplay game server that hosts the player accounts, runs the matchmaking queue and plays out the matches. The easiest way to see how those fit together is to follow a ranked match from start to finish.

Two players tap Ranked. A matchmaker pairs them, by rating and by the strength of the decks they queued with, and creates a match.

The match reads both decks as they were at the moment of queuing, with the ranks each player holds. Then they play: the match takes moves from whichever player's turn it is, carries out their consequences, and broadcasts the changes to both players.

When a Den falls, the match works out the result, the winner picks a card, and both players' collections change: a rank up on one side, a rank down on the other, and a rating adjustment for each. Then the match is gone.

All of that is C# in one codebase, running in one server cluster. The building block of a Metaplay server is the entity: a small, independent piece of the server with its own state, which talks to other entities by sending messages. A player's account is an entity, and so are a match and the matchmaker.

Metaplay doesn't ship a match or a matchmaker for a game like this; the sample builds both on the same entity primitives that the platform's own features, such as guilds and leagues, are built on.

Entities live in memory while they are in use. A player's account is loaded when the player logs in and written back to the database when they go idle, and a match exists only in memory and never touches the database at all. So a turn in a match, or a rank moving from one collection to another, is a change to an object in memory and a message between two of them, with no database round trip in the way.

The platform spreads entities across the nodes of the cluster automatically, so the game scales by adding nodes, and nothing in the game code needs to know which node a player or a match is on. The game server architecture page has the details.

For development, this means a whole game that runs on a laptop: one server process and the web client, started with two commands. The connections between the systems are ordinary game code, so a change that touches both the match and the collection is one change, tested in one place.

For operations, it means one server to build and deploy, one dashboard, and one set of logs and metrics that covers players and matches alike. There are no separately versioned services to keep in step when you ship a change.

Almost none of this is something the game developer has to think about. Loading and saving accounts, placing the pieces on nodes, delivering the messages between them: the platform does all of it. Writing the match and the account is writing game logic, and the plumbing comes with the framework.

One codebase to bind them

The game logic of Sticky Paws is one C# codebase that runs both on the server and in the player's browser, and that is what keeps the two in sync. Metaplay does this with the command pattern: instead of sending state back and forth, the server and the browser send each other the commands that change it, and each side runs the same commands against its own copy. In Metaplay's terms, the state of a game is a model, and the only way to change a model is to run an action against it.

In the match, what travels over the network is not the state of the board but the move: play this card, attack with that critter, end the turn.

A player's browser sends what the player wants to do. The server checks that the move is legal, runs it against its copy of the game and broadcasts it, and only then does each player's browser run it against its own copy. The browser never changes the match on its own. The game logic execution model page goes through the mechanics.

That gives you several things at once. The rules are written once, in C#, and there is no separate client version of them to drift out of step. The traffic is small, because a move is a few bytes and a board is not. And the game is cheat-proof: the server decides what happens, a tampered client can only ask, and it never receives the opponent's hand or the order of the deck, because the server keeps those to itself and sends each player only their own cards.

If a browser's copy does come to disagree with the server's, which takes a bug or a tampered client, the platform notices, because both sides keep a running checksum of their state, and the browser drops its copy and reloads the server's.

The rules also run anywhere the code runs, including in a test with no server. Sticky Paws plays thousands of bot-versus-bot matches in about a minute as part of its test suite, checking that the rules are deterministic, that a client's copy matches the server's after each move, and that nothing a player receives reveals the other player's hand.

In Metaplay, a player's metagame state is a model too: the collection, the decks, the progression and whatever else the game keeps track of. Changes to it are implemented as actions, just as moves are in the match. The difference is that these actions run in the player's browser first, so editing a deck happens instantly, with no round trip. The server runs the same action against its own copy afterwards and refuses anything that doesn't check out, so the server's copy is still the one that counts.

This is how the single-player side of a Metaplay game works, and it's also why the metagame screens of Sticky Paws run in an offline mode with no server at all: the same code is simply running on one side only. The multiplayer entities page describes the two directions as one mechanism with the roles of client and server swapped.

Try it

Sticky Paws is a working card game and a deliberately shallow one, and that's where I'm leaving it: the groundwork is done, and what it needs now is a game designer to build the real content on top.

Play a few matches in your browser, then open the source.

The repository is a complete Metaplay project: the match, the accounts, the matchmaker, the bots, the web client, the dashboard and the tests, with a design document for each system and a README that lists which corners a shipping game would finish differently.

Clone it, change a rule, and watch the change land on the server and in the browser at once.