How the game works

What runs where

aBetterGun is a browser game. You open abettergun.com on a phone or a computer, and there is nothing to download from a store.

The game servers and the account API are programs written in Go. Both run on Google Cloud Run. The game runs in two regions, one in the US and one in Europe, and the game can pick the one with the lowest ping for you. Accounts, loadouts, Terran Credits and run records are stored in a Postgres database on Cloud SQL. An account uses a username and a password, and a session uses a signed token.

This wiki is a static site. It is generated from the game's own data tables each time a release goes out, so its numbers match the game.

The technology

The client is written in TypeScript with React. The 3D scene is drawn by Three.js through React Three Fiber, and Vite builds it. Enemies, bullets and pickups are drawn as instanced meshes, so a screen full of aliens costs a few draw calls instead of one per alien.

The servers use an entity-component system (the ark library) for the simulation, and a grid-based spatial hash to find what is near what. Health, damage, speeds and prices sit in data tables that the server loads. The wiki reads the same tables.

How the 3D models are made

Each model starts as concept art. Meshy, an AI 3D tool, turns the art into a draft mesh, and it also rigs the characters and creates their animations. These are drafts. The team reduces each one to a triangle budget, cleans it up and edits what is wrong before it ships.

For phones, each model has one material, its textures are WebP, and its mesh data is compressed with meshopt. A weapon is around a hundred kilobytes and even the largest boss is under two megabytes. Concept art and icons also come from AI image tools. The Credits page in the game says which parts use AI tools.

How it runs in the browser

The game is built for phones held in landscape. It is an installable web app: add it to your home screen and it opens full screen without a browser bar. The game's code and fonts are cached on the device after the first visit.

On a phone you play with two thumbs, one stick to move and one to aim. On a computer you use the keyboard and the mouse. The graphics settings let a slower phone turn effects down.

How the game talks to the server

Each player has one WebSocket connection to the game server. Every message is binary and starts with a type byte and a version byte. A snapshot describes each nearby entity in 16 bytes, so a crowded fight fits in a small packet.

The server is authoritative. Your phone sends what you did: the move stick, the aim direction and the buttons. The server decides every hit, every death and every pickup, and tells the clients what happened. The client never decides damage or pickups.

Ticks, prediction and smoothing

The simulation runs 60 times a second on the server. Your phone sends input 60 times a second. The server sends snapshots of the world 30 times a second, which halves the bandwidth and the decoding work and is smooth enough to look the same.

Your own Sentinel moves on your screen at once. The client runs a TypeScript copy of the server's movement code and predicts where you will be. Each snapshot says which of your inputs the server has applied. The client compares, and when the two differ it corrects and replays the inputs the server has not seen yet, blending small corrections in over a tenth of a second. The two copies are tested against each other with shared test vectors.

Other players and enemies are drawn slightly in the past: two snapshot intervals plus an allowance that grows and shrinks with the quality of your connection. That delay is what lets their movement look smooth even when a packet is late.

The server sends each player only what is near them, plus the other players and the boss. This is the area of interest. It keeps the size of every snapshot bounded however many aliens are on the map.