Fair Matches in Web3

Benjamin Jordan
Spyre.io
Published in
7 min readOct 16, 2024

The devil is in the details.

“Fun Slide” | sweetjessie

Our goal is to make skill-based casual-competitive games successful. This means that we are building games for people that don’t call themselves gamers (this is the casual part) and our games have a skill curve. That is: you can actually get better at our games.

One of the primary pillars of success in this space is the notion of fairness. If you’ve ever, like me, paid for your son’s soccer tournament and then discovered that one of the refs is apparently BLIND and has NO IDEA HOW OFFSIDES WORKS and can GO SUCK AN EGG — well, then you know what I’m talking about without me needing to explain. It is paramount that we provide fair matches to players. Because of this, we have to focus heavily on security. Without a good security model, we have no hope of providing fair matches.

Our core assumption

Many casual games don’t really require much in the way of security.

If you cheat at Candy Crush, for instance… well, who cares? You really only ruin the game for yourself. No one else loses anything. Many casual games operate in this manner, but obviously that doesn’t really fly in skill-based casual-competitive games. Especially when there is real cash on the line (did I mention you could be winning cash in Hangman Clash right now??).

Here at Spyre, we start with a critical assumption that any self-respecting, security-minded gaming studio starts with: we assume that all players are hackers. Yes, including you. In reality, most of our players are not trying to cheat. However, when building a game where cash is on the line, you have to assume that some players will, and when you don’t know who it is beforehand — well that’s why we assume it could be anyone.

“Fair Sky” | Brittany Randolph

A lesson from Monopoly

Imagine you wanted to cheat at a Monopoly.

There are loads of ways to do this. Why do you think everyone fights to be the banker? Handling the money and the property deeds makes cheating much easier. Trust me, er, I mean — I’ve heard that from people that have cheated at Monopoly. And even if you are a gentle soul (like me) and would never cheat at Monopoly (again, like me), you would of course never trust your arch-nemesis to be the banker! We all have arch-nemeses right, not just me?

So how would we make a game of Monopoly fair? Think with me. Imagine you’re playing against this arch-nemesis, except this time, you, your nemesis, and the game board are all in separate rooms.

You have a tin can on a string that you can shout orders into, and your high school math teacher (they seem trustworthy) is in the room with the game board, moving all the pieces around, dispensing cash, applying fines and penalties (even the one where you have to pay for repairs on ALL your hotels). When your nemesis takes a turn, your math teacher tells you what happened over the tin can: “Ferdinand just bought Park Place!

In this scenario, your arch-nemesis is named Ferdinand (just go with it).

This would be an incredibly annoying way to play Monopoly, but it would make it much more difficult to cheat. Even if I had my own Monopoly board in my room, and I moved all the pieces around and I took all the deeds and the cash for myself — it wouldn’t have any impact on the game board run by my high school math teacher in the other room.

This is effectively how Spyre games operate.

If you haven’t played Hangman Clash yet (the world’s greatest PVP hangman, PLAY NOW!!!), you run the game of hangman on your puny little computer; but we run the real one on our computer. You can muck about all you want in Chrome’s dev tools, changing values and whatnot — but it has no effect on the game running on our computer.

When you guess a letter, we tell you if it’s correct or not, and what spots it fits into. And see that timing bar in the middle? Since our game has a significant timing element, we don’t even trust you to tell us what time you took your guess! That’s right, suckers. We run our own clock with so many hands it would make your head spin. We actually run a full simulation, complete with boosts and timers and all whatnot — written in nice(ish) Golang — running at a tick-rate three times higher than Call of Duty because we actually care about fair matches.

Like what you’re reading? Consider a highlight or some claps.

Play a game of Hangman Clash or follow our adventure on X!

The technical details of Hangman Clash

There are actually some pretty cool, nitty-gritty things going on.

For one, the word you’re trying to guess in hangman is never seen by the client. Some game developers foolishly try to obfuscate or encrypt information in memory. We don’t trust those methods, only because they don’t work for very long. They are toy security models. Remember: all clients are hacked. If we give the client the word, even encrypted in memory or hard to access through obfuscation, a hacker worth his or her salt (that’s an encryption pun) will have no problem accessing that data.

The only information a client has is how many letters there are in the word.

When a client makes a guess, our simulation receives the guess, awards points based on the time our clock says, and then tells the client what the result was.

By somarj.

Fighting physics in Hangman

The astute among you may think, hey what about latency! Yes, latency keeps many an esports developer up at night. Latency is essentially the delay introduced from information traveling over physical space, like wires. If Player A is in Antarctica and Player B is literally sitting in the Spyre data center, the players will have vastly different latency.

There are a huge number of variables that may help calculate latency added per mile of physical distance, but it’s probably somewhere around 5 ms every 100 miles. This is mainly due to physics, not to anything we’ve done. It means that for every 100 miles of distance between a player and our server, their data will arrive an additional 5 ms behind. This could easily bust the timing element of Hangman, giving folks the edge simply based on their geographic location.

To combat this, we use time-tested techniques from the gaming toolbox.

Before and during matches, we measure latency by sending a “ping” from client to server and back. Measuring the time this takes gives us “round-trip time”, i.e. the time it takes for data to get to the server and back. If we divide this number in half, we get a good measurement of how long it takes data to go over the wire one-way.

Next, we take that measurement and fast-forward the game running on the client. This is a common approach in multiplayer gaming, though seldom applied to casual games. This means that when your timer bar hits the golden area, and you click on your best guess, the timer bar on the server simulation is actually slightly behind the one on your computer.

This is intentional, as your guess now needs that time to travel across the network and hit our server. When it hits the server, because we calculated this timing in advance, the server simulation timer bar is at the same spot it was at when you intended.

This entire exercise gives our simulation authority over timing.

This is for a game of hangman. That is how serious we are about security.

But wait there’s more

While authoritative simulations and clever networking tricks are cool, they aren’t the only trick up our multitudinous sleeves. I haven’t even said anything about determinism guarantees, cryptography, or what are they called — blockchains. Just wait till I get to that stuff.

However, these are the only tricks that I can fit into a single blog post.

In the future, we’ll chat about some additional security measures that may or may not make your brain bleed. Until then, join the Clash.

Like what you’re reading? Consider a highlight or some claps.

Play a game of Hangman Clash or follow our adventure on X!

--

--

Spyre.io
Spyre.io

Published in Spyre.io

We are a casual-competitive game studio, building skill-based browser games.

Benjamin Jordan
Benjamin Jordan

Written by Benjamin Jordan

Tech, thought, teaching. Total loser. Founder @SpyreIO, Adjunct @SLU. Formerly VPE @N3TWORK, CTO @Big Run Studios, CTO @Enklu, Studio Tech Director @NCSOFT.

No responses yet