The Brief
Most multiplayer FPS game development starts with a download. This one couldn’t.
The client wanted a shooter their players could reach without an installer, an app store review, or a 4GB first-run download – but with the systems people expect from a real shooter, not a browser toy. Rooms. Voice chat. Progression. A weapon economy. Shootable maps that didn’t feel like a tech demo.
Those two goals pull hard against each other, and most of the interesting work on this project happened in the space between them.
The Hard Part
Building a shooter is well-trodden. Building one that holds up inside a browser tab is not, and the constraints stack up quickly.
Everything the player needs has to arrive over the connection they already have – no install step to hide the download behind. Memory belongs to the browser, not to you. Frame budget is shared with whatever else the machine is doing. And the netcode has to survive the same tab being backgrounded, throttled, and reconnected when someone’s laptop wakes up from sleep.
The delivery decision drove the architecture. We built it in Unity and shipped through WebGL, which meant every asset, every map and every system got sized against how long a player would tolerate a loading bar before closing the tab.
What Shipped
Rather than list seventeen features, here’s what they do:
The match loop. A lobby and room system so players can find or make a match. Downloadable maps, so the map pool grows without shipping a new build. A quest system that gives returning players something to chase. And AI bots: the unglamorous system that decides whether a browser game survives its first month, because an empty lobby at 3pm on a Tuesday is how player counts die.
The social layer. Voice and text chat, customizable characters, and a leaderboard. In a browser shooter, where nobody has installed anything and nothing is holding them there, the social layer is the retention layer.
The economy. A weapon shop, crates and bonuses, and special events to give the calendar some shape.
The plumbing nobody sees. Persistent user data, version gating so out-of-date clients can’t join a live match, and mobile push notifications to bring lapsed players back.
The Web3 Layer
Item ownership runs on-chain, which is the part of Web3 that actually makes sense for a shooter: a player’s skins and weapons are theirs, verifiably, outside the game’s own database. By Astar Network by Polkadot.
We’ve built this layer more than once, and the rule we work by is that the blockchain integration has to be invisible to a player who doesn’t care about it. Wallet-gating the front door costs you the majority of your audience on day one. Players who want on-chain ownership get it; everyone else just plays a shooter.
One Build, Three Places
The same game runs in a desktop browser, on Android and on iOS. One codebase, three delivery routes, and a player who starts a match on a laptop at work isn’t locked out of it on the train home.
Cross-platform sounds like a checkbox on a feature list. In practice it’s an input problem, a UI-scaling problem and a performance-budget problem, and it’s decided at the start of a project or not at all.
We’d Done This Before
Astar Strike wasn’t our first browser shooter. We also built Gunsbytes IO, another web-based multiplayer game, which passed 100,000 players.
That’s the reason this project ran the way it did. The hard-won knowledge in browser multiplayer isn’t the shooting – it’s knowing where WebGL will bite you, and having already paid for that lesson on somebody else’s schedule.
What We’d Bring to Your Project
- Decide the delivery platform first. Browser, store, or both changes the asset budget, the netcode and the art direction. It is not a port decision you can defer.
- Plan for the empty lobby. Bots, region logic and match-fill aren’t polish, they’re launch survival.
- Keep Web3 optional. Ownership as a feature, not as a gate.
- Build the live-ops layer before launch. Version gating, events and downloadable maps are much cheaper before there are players in the game than after.
Work With Us
If you’re planning a multiplayer game that needs to run without a download; a shooter, a .io title, a browser-based competitive game, or a mobile build that also has to work on the web – we’ve shipped it twice and know where the traps are.
We also build in the other direction, when the goal isn’t retention but comprehension: the digital citizenship game we built for Türkiye’s Ministry of National Education uses the same WebGL delivery for entirely different reasons.
Tell us the platforms and the player counts you’re aiming at, and we’ll come back with scope, team and a fixed quote within two business days.
Got a Game That Needs to Ship?
Send a design doc, a build, or three sentences and a reference game. We’ll come back with scope, team and a number.
