What Three Years of Maintaining a Multiplayer Sample Game Taught Us

We built Byte Wars three years ago for a simple reason: API documentation can show you how a service works, but it cannot show you what that service feels like once authentication, sessions, player data, leaderboards, cloud save, and the rest of an online stack are running together inside a game.

Byte Wars gave us a small, known multiplayer project where developers could try an AccelByte Gaming Services (AGS) feature, change its configuration, see the result in a running game, and then follow the same integration path in their own project.

The original flow was straightforward:

Register for AGS → Try Byte Wars → Follow the tutorial → Integrate the feature into your own game

That is still what Byte Wars is for. But after three years of maintaining it, the project has become useful for more than tutorials. We now use it to validate SDK changes, reproduce integration problems, test backend features end to end, and experiment with tooling that can turn real support scenarios into repeatable test cases.

The interesting part is not that the game became bigger. It is that keeping it deliberately small made all of those uses possible. This article is a look at why we built the game this way, why we are still maintaining it and what it has taught us.

Why We Built Byte Wars

A backend feature rarely lives in isolation once it reaches a real game. A leaderboard needs a value to rank. That value may come from player statistics. Those statistics belong to an authenticated player. A session has its own lifecycle and configuration. Cloud save has to fit into the same player identity and game flow.

You can document each API separately, but a developer still has to understand how the pieces connect in a running project.

Before Byte Wars, we maintained different projects for different jobs. We had smaller sample games for integrations and examples, and we had a more visually complete demo based on Epic Games' Lyra. Both were useful, but there was a practical maintenance cost. The same online features could exist in more than one project, so SDK or service changes could require us to update and validate multiple integrations.

Lyra also taught us something about the kind of project we wanted for this job. It is a much larger project with many systems and plugins. When we were debugging an integration, that extra project complexity made it harder to isolate whether a problem came from our code, the online integration, or another part of the project.

We were not trying to build the most impressive demo game. We wanted a game that was useful when somebody had to integrate or debug an online feature.

The Game Is Intentionally Simple

Byte Wars took some inspiration from Gravity Wars, with Phil Tossell (VP of Engineering) helping shape the gameplay direction around a space setting.

Players control ships in a map with planets, stars, and other ships. You fire missiles at the opposing team, but the projectile path is affected by the gravitational pull of the planets on the map.

So the basic mechanic is easy to explain, but still gives players something to aim, time, and predict. Matches support up to 4 vs. 4 players.

The small gameplay scope is deliberate. When we are using the project to explain a session flow or reproduce an SDK problem, we do not want developers to spend the first hour understanding the game itself.

Current Byte Wars gameplay

The Design Behind Byte Wars

The small game helped, but the more important decision was separating the gameplay from the online feature integrations. At a high level, there are two parts:

The core game owns the gameplay loop. The tutorial and backend work lives in the online integration layer.

Those integration modules use Unreal Engine's Asset Manager together with custom assets that represent individual tutorial modules and their dependencies.

Authentication sits near the base because most player-specific services need an authenticated player. A leaderboard depends on player statistics because there has to be a value, such as a high score, to record and rank. Other dependencies follow the same idea and is also reflected in the tutorials. For example, a developer setting up a weekly leaderboard would go through the work in roughly this order:

We are not trying to hide those dependencies behind a sample that magically works. We want the dependencies to be visible in a project small enough that a developer can trace them from the game code into the SDK and backend configuration. That has turned out to be useful well beyond onboarding.

The point is not to hide those dependencies. It is to make them visible in a project small enough that a developer can trace them from the game code into the SDK and backend configuration. Check out how we do it using Byte Wars learning path.

This Also Helped Us Internally

We originally made Byte Wars small and modular to make onboarding easier for developers. It turned out that the same design also helps people inside AccelByte who do not work on the game integration every day.

If someone needs to verify a bug fix, test a new backend capability, check an SDK change, or reproduce an end-to-end flow, starting from Byte Wars is often faster than creating another test project from scratch.

The reason is simple: we already know what the game is supposed to do. When something changes, we have a stable point of comparison across the game, SDK, and backend configuration. Over time, that reuse became part of how we maintain the project rather than a side effect of it.

Over Three Years of Byte Wars

Byte War's role expanded gradually as we kept finding new uses for the same small, known integration. Roughly, the timeline looks like:

The external use is still close to the original idea.

A developer can use the tutorials as an integration reference, but they can also start with a predefined Byte Wars namespace and sample configuration.

After downloading the game locally, the build can be pointed at that configuration through command-line parameters. From there, the developer can change settings in the Admin Portal and see how those changes affect the running game. That gives them a known integration to try before they reproduce the same setup in their own codebase.

Byte Wars namespace and onboarding page in Admin Portal

Byte Wars downloaded locally using launcher powered by ADT

Reproducing Real Scenarios

Some end-to-end game problems normally need somebody who understands three things at once: the game, the SDK integration, and the backend configuration.

That is a relatively specialised combination.

We have been experimenting with ways to make Byte Wars useful for reproducing those scenarios without requiring somebody to change and rebuild the game for every test case. One internal experiment is our codenamed Playground.

We added a utility module with a cheat-like interface that can load a scenario from JSON. The scenario describes the workflow we want the game to execute, and Byte Wars can run those commands without us rebuilding the project for each scenario.

The next step we are experimenting with is generating that JSON from a natural-language description using an AI agent.

For example, if a support engineer needs to reproduce a sequence that happened in a live environment, the goal is to describe the scenario, generate the configuration, and run it against Byte Wars in a development environment.

The useful part here is not AI generating game code. Byte Wars already provides the known game integration. The AI is helping translate a scenario into a format the test tooling can execute.

This is still an internal experiment, and there is enough engineering behind it to cover separately.

Playground example with Byte Wars login with device id & connect to lobby connection

A Tutorial Game Still Needs Maintenance

There is an easy failure mode with sample projects like Byte Wars: they work when at first , then slowly drift away from the product they are supposed to demonstrate.

Game engines change. SDKs change. Services change. Plugins and build requirements change. Integration patterns also change as teams learn from production use.

If Byte Wars stayed on the same engine and SDK versions it used three years ago, it would become less useful as a reference even if the original tutorials were still technically available.

So we update Byte Wars alongside our SDK work. When we support a new UE version in our SDK plugins, we update the project as part of that work. New AGS features and integration changes also go through our internal test coverage, with Byte Wars used as an end-to-end game integration.

That gives us a practical check beyond whether an API compiles or an isolated service test passes.

Does the integration still work from the game?

For a tutorial project that developers are expected to copy from, that is the standard that matters.

Why We Put Byte Wars on Steam

We later published Byte Wars on Steam so developers could install and play the game without first setting up the project.

Play Byte Wars on Steam

That made the sample easier to try, but it also gave us another environment to validate. A public Steam build sits outside the development setup we control internally, so it exercises more of the packaging, distribution, and runtime configuration that a real game has to deal with. It also lets a developers experience the finished flow before opening the tutorials or integration code.

So far, players have finished 3,600+ single player matches, destroyed 3,300+ enemy ships, and scored over 15 million points. The Team Death-match record stands at 117,800.

Byte Wars Steam page

What Three Years Taught Us

The main lesson for us is fairly practical: a sample game stays useful when the team treats it as a real integration instead of disposable demo code.

Byte Wars is still a tutorial project, but it is also part of how we validate integrations, reproduce scenarios, try new features, and test some of our internal tooling. The same constraints that helped with customer onboarding — small codebase, simple gameplay, modular online features — are also what make it useful for those internal cases.

We still have more to cover around automated testing, newer UE versions, platform work, AccelByte Multiplayer Servers (AMS), and the tooling we are building around the project. But the underlying idea has not changed much since 2023: when you need to understand a backend integration, a small working game can be more useful than another isolated example.