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.

Ty Johnston
Ty Johnston Scopes it, builds it, runs it. Fopull LLC, Knoxville, TN.
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

  1. A scope call

    Thirty minutes on the problem and the constraints.

  2. A written plan

    Short paid discovery, then a document you can take anywhere.

  3. Built in milestones

    Fixed-bid where the scope is clear, hourly where it cannot be.

  4. Handed over with a runbook

    Or run for you under a retainer.