How HexNest Built and Runs Birds of War as a Three Person Team with AccelByte

Birds of War started as viral AI clips of a game that didn't exist. People wanted to play it, so HexNest Games built it. It's a 3v3v3 aerial PvP game. Nine birds, three nests, and a scoreboard that counts how many eggs you stole and managed to keep. Proximity chat is always on, so the enemy hears you before they see you, and every hit ragdolls. It shipped on Steam on 22 July 2026 at $9.99, built in Unreal Engine 5 by a three-person team alongside the Discord community that asked for it, and currently sits at 87% positive reviews.

What a Live PvP Game Needs Before Anyone Can Play It

Write out the backend requirements for Birds of War and very little of the list is about birds. Players authenticate through Steam and carry one identity across sessions. Matchmaking has to form matches quickly, respect latency, and backfill players into games already in progress, because Birds of War drops you straight into a lobby that visually fills up rather than holding you on a queue screen.

Dedicated servers have to exist in every region where players are, scale with demand, and recycle when matches end. A store reconciles Steam purchases against an in-game wallet, an entitlement system grants rewards without double-granting them, and progression, battle pass state, leaderboards and save data all have to survive a client crash.

None of that is the game, and all of it has to work before the game is playable. For a team of three, building it in-house isn't a sprint. It's a different company.

What HexNest Kept and Handed Off

HexNest didn't hand off the whole backend. The split was between integrating existing services for the common infrastructure and writing the game-specific logic themselves. AccelByte Gaming Services covers identity, the economy and the multiplayer layer. AccelByte Multiplayer Servers runs the dedicated servers, which at launch peak reached 287 across 11 fleets in 9 regions. AccelByte Extend hosts the services they wrote themselves.

HexNest's progression and reward logic took several iterations before it was reliable. At match end the dedicated server reads authoritative XP and mastery levels, checks fulfillment history so rewards missed in an earlier match get recovered without duplicating anything, and grants every item on the ladder with a stable order number so retries are safe. The loot box roll with its pity guarantee is a Go service running on Extend, built on AccelByte's loot box template with HexNest's own guarantee logic on top, so the platform routes the entitlement decrement through their app and their app decides what the player gets.

AccelByte didn't remove backend work from the project. It meant more of HexNest's backend work could stay focused on Birds of War itself.

Five Weeks from Demo to Launch

HexNest ran a demo during Steam Next Fest in June 2026. Around 24,000 people downloaded it over the week, it peaked near 300 concurrent players, and the wishlist count passed 100,000. Full release was set for 21 July, which left about five weeks.

Their requirements were short: backend services they didn't have to write, somewhere to run game-specific logic without maintaining a fork of the platform, regional coverage they could expand on request instead of provisioning themselves, and a cost model that didn't punish a game which might peak at 300 players or at 5,000. That last point was not hypothetical. Asked for a launch-day CCU estimate, the honest answer from the studio was somewhere between 3,000 and 10,000, with no real confidence in either end of it. AGS is priced on peak concurrent users, so they didn't have to guess right in advance. Public Cloud also has no platform subscription fee and includes the first 30 CCU, so the team could integrate and test before launch without paying a platform fee just to validate the setup.

HexNest initially asked us for the built-in Challenge service to be switched on, which would have handled what they needed at the time, namely granting an item at 100 kills. The service is on low support and doesn't receive feature work, and HexNest already suspected they would want daily challenges. Rather than switch it on, AccelByte pointed them at the open-source Extend challenge suite. That gave HexNest an existing pattern they could extend for daily and weekly challenges instead of shipping a one-off implementation they would have to replace and migrate later.HexNest weighed that against the added Extend cost, took the recommendation, and shipped daily and weekly challenges in launch build.

They made a similar decision with the loot box system. Pity systems are game-specific by definition, so nothing ships one out of the box. Instead of building the surrounding entitlement flow from scratch, HexNest started from AccelByte's Go loot box template on Extend and added the pity guarantee logic their game needed. Keeping it as a service override left the entitlement flow authoritative on the backend rather than depending on a call sequence completing correctly elsewhere.

What Launch Readiness Actually Looked Like

In the final week, our QA team ran three passes against a private build. The blockers ranged from a fleet-version mismatch that stopped matchmaking allocating a dedicated server at all, to TURN connectivity failures on custom games, to a missing Create Entitlement permission that meant dedicated servers were getting a 403 on every progression grant they attempted. One pass also found a path that flipped the battle pass to Premium without charging any Feathers, then reverted it and granted nothing.

Most of those were integration issues rather than platform defects. HexNest cleared nearly all of them within 48 hours, with AccelByte QA staying in the build loop and rerunning matchmaking, backfill, login queue, commerce and progression flows against each new build.

HexNest had been developing against their production namespace, which meant the demo's stats, currency and leaderboard positions would carry straight into the live game. Matt wrote a reset script to clear them, and AccelByte engineers reviewed the code before it ran. They found two problems: a deprecated wallet API being called with a currency code where a UUID was expected, and a cloud save read that was missing a nesting level. Once those were corrected, the snapshot phase alone ran for hours, with the reset pass estimated at another four to six on top, against a launch that was already running late.

Running the reset after release introduced a bigger risk. Some player data can be deducted after the fact and some cannot, so a partial reset against a live population can leave accounts in inconsistent states. The alternative was to create fresh stat and cloud save records and point the launch build at those, leaving the demo-era records untouched. HexNest took that route. A small number of demo players carried a level or a cosmetic into launch, which was a considerably safer outcome than inconsistent production state on day one.

Birds of War went live on 23rd July, a day later than planned.

A few smaller issues surfaced during the first week. A US-East queueing report turned out to be the client requesting a region that wasn't deployed, while another connectivity problem was traced to ISP-level UDP filtering in one region. Steam purchases were reaching the backend correctly but weren't refreshing in the client until restart. HexNest fixed the game-side issues, and affected players were routed around the external UDP problem.

Two Production Incidents Worth Learning From

Requests that Never Left the Dedicated Server

After launch, HexNest replaced a deprecated fulfillment call with the supported server SDK method. In testing, roughly a third of each match-end reward burst produced no fulfilment record, while calls immediately before and after them succeeded, and the same rewards went through normally when re-sent in a later match.

Our engineers checked the platform logs first. They showed no failed calls, because there were none to show: the requests never arrived. The Unreal SDK applies its own client-side rate limit, six requests per second by default, and a full back-pay ladder for one player can run to 10 or 20 calls dispatched over a second or two. The excess was being dropped inside the SDK on the dedicated server, surfacing as a network error rather than a 429, which is why it looked transient and unrelated to the payload.

The first instinct was to raise the limit in the engine config, but that would only have moved the bottleneck. The requests would then have left the server and been throttled at the platform instead, returning 429s and consuming more of HexNest's namespace-wide request budget. We recommended pacing the dispatcher instead, to five requests per second per user, which also keeps it under the hard user-level cap. HexNest spaced their grants 200ms apart and added a fulfilment-history recheck as a backstop, so anything still missing gets re-sent without risk of double-granting. That resolved it without increasing backend traffic.

A Signing Key Fetched Once and Never Retried

Five weeks after launch, the crate opening broke in production. The first two visual cracks played normally and then the screen sat on "OPENING..." indefinitely, with no timeout and no error, until the player force-quit. It had been broken for more than a day before anyone reported it. The entitlement decrement endpoint was returning HTTP 500, and nothing was reaching the Extend app's handler at all.

The root cause was in our own Go loot box template. The app validates incoming tokens against IAM's public signing keys, which it fetches once at startup. If that first fetch fails, for example during a brief network problem while the pod is starting, the app carries on running without the keys and never retries, after which it rejects every incoming call and only a restart could clear it. A pod replacement that morning had landed in exactly that window.

Restarting the app restored service that day. We then changed the template so the initial key fetch retries with backoff and logs the failure, the gRPC health check reports NOT_SERVING until token validation is actually ready, and calls arriving before then return UNAVAILABLE rather than PERMISSION_DENIED. In the SDK, the key refresh now keeps running after a failed initial fetch so the app recovers on its own once IAM is reachable again, and startup errors name the step that failed. That fix shipped in our latest go sdk, so the recovery behaviour became the default rather than a one-off patch in HexNest's environment.

The Launch Window

Over the first five days, Birds of War drew 5,471 unique players who completed 13,422 matches.

Matchmaking took in 37,125 tickets over the first 72 hours and matched 99.97% of the ones players didn't cancel. P99 time to match was around 15 seconds through the main launch window, rising to three or four minutes during thinner off-peak periods on day five. Match success stayed the same during those periods.

Where They Are Heading Next

HexNest wants free-to-play weekends: switch on a Steam demo app ID for a weekend and let demo players share matchmaking, dedicated servers and progression with everyone who owns the full game. That requires one namespace to accept Steam authentication from two app IDs and resolve both to the same player identity, which isn't supported today because of how the commerce and platform integrations are bound to a single app ID. We have scoped the change at one to two weeks of further assessment followed by roughly four to five weeks of implementation and testing which is queued.

Birds of War is still run by the same three people who built it. The backend work didn't disappear when the game went live. It moved: less integration, more progression, content and the game-specific systems they wanted to own in the first place.