Services
Game backends and real-time systems
The backend a game needs to be real: sign-in from a client that cannot keep a secret, saves the server owns, an economy that reconciles, matchmaking over websockets, and multiplayer that works from two home connections. All of it runs in production at Fopull, for three different games.
- Stack
- Unity, C#, Laravel, Reverb, UDP relay, OAuth 2.0 + PKCE, .NET rules engine, Rust
- Terms
- Scope call, paid discovery, written plan, fixed-bid milestones
How Fopull approaches it
A game backend is a business system with a hostile client. Every player has the binary, so every rule that matters has to live on the server, and every request has to be treated as possibly forged. That shapes everything: saves are server-authoritative, currency moves through one code path with a ledger, and a client is told what happened rather than asked.
Sign-in from a game client is OAuth 2.0 with PKCE. Authorization codes are single-use and short-lived, the redirect URI is matched exactly, tokens are hashed at rest and rotated with a link to what replaced them. A game gets a token that can reach its own endpoints and nothing else on the account.
Real-time play runs over websockets for turn-based games and over a UDP relay for anything with a tick. Fopull operates both: Laravel Reverb carries the card game and Connect Four, and Floptle Cloud runs a managed relay so two players on home connections can join each other by a six-character code, with dedicated servers on the paid plans.
Worked example: three games, three shapes
Deviant is a Unity MMO that signs in to fopull.com with OAuth and PKCE and stores its saves through a server-authoritative API. The authorization code is consumed under a row lock so it cannot be redeemed twice, expires in five minutes, and is bound to the exact redirect it was issued for.
Foduel is a browser trading card game with its rules in a separate .NET engine that the web application calls over localhost. The engine is stateless; the game state lives in PostgreSQL and moves over Reverb websockets. Keeping the rules out of the web app is what lets a card's behaviour be verified against the running engine by a probe before a release goes live, which is how three player-reported bugs were root-caused to the exact rule in one afternoon.
Floptle Cloud is a control plane for a managed UDP relay and a small fleet of dedicated-server boxes. The control plane owns lobby codes so one survives a server restart, issues game keys, meters concurrent players against a hard cap, and tells a fleet agent what should be running. The first real match across the Atlantic measured 234 kbps per player and found a lobby teardown bug in ten minutes; both are written up in the engineering log.
More of this, dated and with the numbers, in the engineering log.
Questions people ask
- Do you build the client too?
- Fopull has built Unity clients and its own engine, Floptle. Most engagements are the backend for a client the studio already has; some are both.
- Can players host their own games?
- Yes. Floptle Cloud's relay lets a player host from a home connection and friends join by code, with no port forwarding. Dedicated servers are for a game that should stay up whether or not any player is there.
- How do you stop cheating?
- By never trusting the client with a decision that matters. Saves, currency, matchmaking and rules are all decided on the server; the client is told the result.
How an engagement goes
A scope call
Thirty minutes on the problem and the constraints.
A written plan
Short paid discovery, then a document you can take anywhere.
Built in milestones
Fixed-bid where the scope is clear, hourly where it cannot be.
Handed over with a runbook
Or run for you under a retainer.
Other kinds of work