Fair Online Multiplayer Games — How Server Verification Prevents Cheating

Why cheating is rampant in online games

Most online games operate on a client-server model. Ideally, the server is the authority — it decides what happens. In practice, many games cut corners by trusting the client (your device) to report your position, actions and results. This creates opportunities for cheating.

Client-authoritative games (vulnerable)

• Your device says "I moved here" → the server believes it
• Your device says "I hit that enemy" → the server believes it
• Your device says "I scored" → the server believes it

A modified client can lie about all three. This is how speed hacks, wallhacks and auto-aim work in most browser .io games.

Server-authoritative games (secure)

• Your device sends your intended action → the server validates it
• The server calculates the result → sends it back to all players
• Your device only renders what the server confirms

A modified client cannot lie because the server does not trust it in the first place.

How Arcadigo implements server authority

Every Arcadigo game runs its core logic on the server. Here is what that means for each game:

Bumper Bash

• Collisions: The server calculates whether two players collided, the angle, the force and the damage. Your device only shows the animation after the server confirms.
• Skill effects: Fireball trajectory, Shield duration, Stun timing — all server-calculated. You cannot make your Fireball travel faster or your Shield last longer.
• Eliminations: The server decides when a player's health reaches zero or when they cross the boundary. A laggy opponent cannot "survive" a ring-out because their client disagrees.

Prism Push

• Beam force: The server calculates how much charge you applied and the resulting prism movement. You cannot apply a full-charge force with a quick-release timing.
• Goal detection: The server tracks the prism's position and confirms when it fully crosses the goal line. Your device cannot claim a goal that did not happen.

Neon Cut

• Trail validation: The server tracks your exact movement path and confirms whether your trail forms a valid enclosure. You cannot "draw" a trail by teleporting.
• Cut detection: The server determines whether an enemy crossed your unfinished trail. You cannot cut a trail that was already closed.

Crown Shift

• Zone control: The server tracks which players are inside the active Crown zone and whether the zone is contested. You cannot score ticks from outside the zone.
• Repulse validation: The server calculates the Repulse direction, range and stun. You cannot Repulse an enemy outside the valid range.

Pulse Pass

• Timer: The server owns the six-second pulse timer. Your device cannot pause, extend or reset it.
• Pass validation: The server confirms whether the target is eligible and the pass direction is valid. You cannot pass to a blocked recipient.

What server authority prevents

| Cheat type | How it works on client-authoritative games | Why it fails on Arcadigo | |---|---|---| | Speed hack | Client reports faster movement than allowed | Server caps movement speed; excess is ignored | | Teleport hack | Client reports a new position instantly | Server validates continuous movement; jumps are rejected | | Auto-aim | Client snaps aim to nearest enemy | Server validates aim is within possible turn rate | | Damage hack | Client reports higher damage per hit | Server calculates all damage; client report is ignored | | Cooldown bypass | Client ignores skill cooldowns | Server tracks cooldowns; early casts are rejected | | Wallhack | Client renders enemies through walls | Arcadigo games have no walls to hide behind (open arenas) |

The trade-off: server authority and latency

Server-authoritative games feel slightly different from client-authoritative ones. When you press a button, your input travels to the server, the server processes it and sends the result back. This round trip adds a small delay.

Arcadigo minimises this with:

• Efficient WebSocket protocol. Not HTTP polling, not long-polling — a persistent, low-overhead connection.
• Client-side prediction. Your device shows the likely result immediately (movement, animations) and corrects only if the server disagrees. The correction is usually imperceptible.
• Global server distribution. Servers located to minimise latency for the majority of players.

For most players with a connection under 100ms latency, the experience feels responsive. Above 150ms, the delay becomes noticeable — but the game remains fair. A high-latency player is at a disadvantage, but they cannot cheat.

How to verify a game uses server authority

If you are evaluating a browser multiplayer game, ask these questions:

1. Can I play offline? If yes, the game logic runs entirely on your device — no server authority. 2. Does the game work with JavaScript disabled? If yes, it is not a real-time multiplayer game. 3. Are match results instant or is there a short confirmation delay? A slight delay after a goal or elimination suggests server validation. 4. Does the game publish its matchmaking and anti-cheat policies? Transparency is a good sign. Hidden rules often hide shortcuts.

Arcadigo publishes its matchmaking policy, privacy policy and game rules for every title.

The bottom line

Server-authoritative games are not immune to all forms of cheating — account sharing, win-trading and toxic behaviour still require moderation. But they prevent the most common and destructive cheats: speed hacks, damage hacks, teleportation and fake results.

When you lose a match on Arcadigo, you lost to a better player (or a clearly labelled AI), not to a modified client.

Play fair games →