Bad Goons gameplay running against authoritative Linux dedicated servers
Bad Goons · Containerized Linux dedicated servers · Unity 6 + FishNet

GAME BACKEND DEVELOPMENT

Game backend development for online games.

Sourcegarden Studio designs, integrates and deploys the online services around a game: session and lobby flows, dedicated server deployment, client–backend contracts, persistence and the monitoring a team needs to operate live matches. Our real-time netcode work lives on the multiplayer page; this service covers the systems that keep those matches reachable, observable and maintainable.

Discuss your game backend

HOW AN ENGAGEMENT WORKS

Scope, deliverables and ownership—before work begins.

01

Where the backend starts and the game server ends

Most online games involve several layers with different responsibilities: the game client, a real-time game server that simulates the match, application services that handle sessions, players and persistent data, a database, and the observability tooling that tells operators what is happening. Problems appear when these boundaries are implicit and every layer depends on the internal details of the others.

We start by drawing those boundaries for your game: which state is authoritative in the match, which data must survive it, which calls the client makes, and which operations the team must be able to perform without a developer present. The result is an architecture document with explicit contracts rather than a diagram that only the original author understands.

  • Client, game server and service boundaries
  • Authoritative versus persistent state
  • Versioned client–backend contracts
  • Architecture document your team can maintain
02

Sessions, lobbies and connection flows

Players experience the backend first as the path into a match: finding or creating a session, joining a party or lobby, receiving a server address and connecting with the right build version. We integrate these flows with the game client and the dedicated server so failure states such as full servers, version mismatches and dropped connections have defined behavior.

Where a proven platform service already covers part of this flow, we integrate it instead of rebuilding it. Where custom services are justified, we keep them small, documented and testable. Either way, the session lifecycle is modeled explicitly so it can be diagnosed when players report problems.

  • Session and lobby integration
  • Server allocation and connection handoff
  • Version compatibility checks
  • Defined failure and reconnect behavior
03

Dedicated server deployment and operations

A dedicated server that runs on a developer machine is not yet an operable service. It needs a reproducible build, a container or image, configuration per environment, health checks, graceful shutdown, log collection and a safe way to roll out a new version while matches are still running.

Bad Goons runs Unity headless builds on authoritative Linux servers with containerized deployment. We apply the same discipline to client projects: automate the server build, make deployments repeatable and document capacity assumptions, costs and limits honestly instead of quoting concurrency numbers that have not been tested.

  • Headless Linux server builds
  • Containerized, repeatable deployment
  • Health checks and graceful shutdown
  • Version rollout and rollback
04

Monitoring, debugging and handover

Online problems are expensive when nobody can see them. We add structured logs, metrics and health signals around sessions, server processes and service calls, then connect them to dashboards and alerts that match how your team will actually operate the game.

Every engagement ends with a documented handover: architecture, deployment steps, runbooks for common incidents, known limits and the cost drivers of the infrastructure. If you need continued support, its scope and response expectations are agreed explicitly rather than assumed.

  • Structured logs and metrics
  • Dashboards and alerting
  • Incident runbooks
  • Documented handover and optional support
05

Player data, progression and economy services

Accounts, progression, inventory, economy, analytics and LiveOps tooling are frequently requested, and they carry real security, data-protection and balancing responsibilities. We do not treat them as a checkbox. For each game we first assess whether an existing platform service fits, then scope the integration or custom work separately.

We are explicit about evidence: our documented production work is strongest in dedicated servers, deployment, session flows and multiplayer integration. If your project needs a service type we have not shipped before, we say so in the proposal and plan the validation work accordingly.

  • Platform-service assessment first
  • Separately scoped persistence work
  • Data-protection and security review
  • Honest evidence in every proposal

COMMON QUESTIONS

What teams ask before we begin.

What is the difference between your multiplayer and backend services?

Multiplayer development covers the real-time simulation inside a match: authority, prediction, reconciliation and replication. Backend development covers the services around it: sessions and lobbies, server deployment, client–backend contracts, persistence, monitoring and handover. Many projects need both, and we scope them separately.

Can you integrate an existing backend platform instead of building custom services?

Yes, and we usually recommend evaluating that first. We assess whether a platform service fits your session model, data and cost constraints, then integrate it with the client and dedicated servers. Custom services are proposed only where they are justified.

Do you deploy and operate dedicated game servers?

We build, containerize and deploy dedicated servers and set up the health checks, logs and rollout process needed to operate them. Ongoing operation after handover is optional and agreed separately, including response expectations.

Can you guarantee a specific number of concurrent players?

No. Capacity depends on the game simulation, server hardware, hosting model and player behavior. We define load scenarios for your game, measure them and report the results and limits honestly instead of promising untested numbers.

What do you need to estimate a game backend project?

The game type and session model, expected concurrency range, existing engine and server stack, any backend platform already in use, the services you need and your timeline. With that we can propose an assessment or a bounded implementation scope.

What do we receive at handover?

Architecture and contract documentation, automated build and deployment steps, monitoring dashboards, runbooks for common incidents, known limits and an overview of infrastructure cost drivers.

START A CONVERSATION

Need a game development partner?

Bring Sourcegarden Studio an idea, a prototype, or a production already in motion. We’ll help define the right development scope.

Discuss your game