XWARS ▶ Play

// DEVLOG #001 · LIFTOFF

How XWARS is being built

An honest tour of the stack, the design thesis, and what early pilots can expect from a 2D vector space MMO that runs in a browser tab.

MAY 27, 2026 · RAY, FOUNDER

XWARS is a free real-time multiplayer space arena that runs in your browser. You point a ship, you fire a cannon, you mine asteroids, you talk smack on proximity radio to other pilots in the same galaxy. There are three galaxies. Two of them want you dead.

That’s the elevator pitch. Here’s how it’s being built.

The thesis: vectors over voxels

I didn’t want to make another photoreal space sim. There are good ones already, and they cost a lot of polygons and a lot of your patience. What I missed was the feeling of standing in front of a Tempest or Asteroids cabinet at 11pm in a pizza parlor — neon lines, instant feedback, no install, no tutorial, just push the button and play.

So XWARS leans the other way on purpose:

  • Vector ships. Every hull is a few stroked lines on a black background. Hardware-cheap, screen-readable, immediately legible at a glance.
  • Browser-first. No download, no installer, no launcher. Sign in with Google in one tap and you’re flying.
  • Free to play. Sign in, fly, mine, fight, talk. Earn credits in-flight. A separate premium catalog of optional customization is on the roadmap — the core loop stays free.

The aesthetic isn’t decorative — it shapes every gameplay decision. Vector ships read at a glance from across a radar. Newtonian physics feels good when projectiles are bright slashes against a starfield. Proximity chat feels intimate when other pilots are little glowing triangles, not HUD-cluttering nameplates.

The stack

The whole thing is one Railway service. Multi-stage Dockerfile builds the client and the server together and serves them off one port.

Client. Phaser 3 + TypeScript strict, bundled with Vite. Phaser handles the scene graph and input; everything else is plain TS. The ship is composed in code from interchangeable parts (hull / engine / weapon / shield, three variants each, six hull palettes) so customization is just swapping which draw function runs.

Server. Node 20 + Express + Socket.IO + Postgres, all TypeScript strict. Game state is server-authoritative — the server runs the physics tick, the client predicts and interpolates for smoothness, but the server has the final word on where everything is. Helmet/CORS/rate-limit on the front door. Express 5 for the routing. Google OAuth as the primary login, callsign+passphrase as a fallback for the holdouts.

Persistence. Pilot identity, ship loadout, credits, resources — all in Postgres. Combat state (hull integrity, position, velocity) lives only in memory and resets when you respawn. That keeps the database calm and lets respawns be instant.

Shared module. Physics constants, the parts catalog, the integration step, and the validation logic live in a small shared/ TS module that both client and server import. That means the client can render projectiles with exactly the visual the server stamped on them, and the server can validate a loadout the client submitted using the same code that produced the costs on the editor page. One source of truth, no drift.

Three galaxies, three feels

We just shipped a feature called Drift that gave each galaxy its own physics knobs:

  • ORION is the welcoming galaxy. Strong drag — release thrust and you glide to a stop. Pickups are everywhere. Magnetism pulls loot toward your hull. PvE only, no other pilots can shoot you.
  • ANDROMEDA is the in-between. Moderate drag, balanced loot density, moderate magnetism. PvPvE — other pilots can shoot you but no one’s guaranteed to.
  • CYGNUS is pure Newton. No drag at all. Pickups are sparse. Magnetism is gone. Your ship coasts indefinitely unless you counter-thrust or hit something. PvP zone — everyone is hostile.

Same controls, same ship, three completely different flight models. Going from ORION to CYGNUS feels like switching games — and that’s the point. The difficulty label finally matches the difficulty.

Three galaxies is the alpha set. More are queued, each with its own personality and objectives — think contraband economies where running hot cargo matters, bounty zones where other pilots are payday, and story belts where the asteroid spacing spells out a thread for pilots who look. Once the galaxy catalog goes data-driven (see What’s next), shipping a new one becomes a config file rather than a code change. We have a list.

What’s hard

Real-time multiplayer in a browser is the gnarly part. Some honest notes:

  • Latency hiding. Your inputs apply locally first (prediction), then the server confirms them and corrects if needed. Other pilots are interpolated between server snapshots. Done right it feels seamless; done wrong, ships teleport. Most of the iteration time goes here.
  • Mouse vs. keyboard. Two control schemes that need to feel equally good. We’ve already shipped mouse-aim twice (the original launch and a same-day hot-fix the same day pilots flagged the wobble) and once more this week. Tuning the cursor-tracking controller is a surprisingly deep rabbit hole.
  • Browser quirks. Phaser’s input event lifecycle, Google’s OAuth popup flow, CSP headers strict enough for security but loose enough for audio — these are not the parts you brag about, but they’re a third of the work.

How it gets made

Worth being plain about: XWARS isn’t a hand-cranked weekend project, and it isn’t an AI-button-pressed demo. I work with a team of AI agents — they handle code, copy, art, even some of the devlog scaffolding sits closer to a co-write than a solo draft. Every decision, every design call, every “no, this feels wrong, do it again” comes from me. The agents move the bricks. I’m still drawing the building.

I think this is how a lot of indie games will get built going forward — one person with a tight taste budget and a team of agents handling the tonnage. The taste has to stay human. The hours don’t.

What I want XWARS to feel like is a dish my grandma used to make me. Slow, careful, made with love, served warm. Two pilots in a CYGNUS dogfight at 11pm should feel like sitting at her table. That’s the spec.

What’s next

Two big things in flight:

  • Ironlogic — programmable AI drone ships you build by chatting with them. “Mine the iron belt and call me when your cargo hits 80%.” “Camp the jump point. Shoot anything red. Don’t chase.” No menus, no code, just plain English. Preview later this quarter. There’s a teaser on the landing page and it’s why I named this devlog series “Liftoff” instead of “Crosshair Notes” — Ironlogic is the second stage rocket.
  • More galaxies. ORION/ANDROMEDA/CYGNUS are the starter set. Once the galaxy catalog goes fully data-driven, adding a new one will be a config file, not a code change.

How to play

play.xwars.ai. Continue with Google, pick ORION if it’s your first time, point with the mouse or the keyboard, fire the cannon, see what happens.

If something breaks — or you want a feature, or you just want to say a thing — hit [ESC] mid-flight. Time pauses, you breathe, you say your piece. The form ships your current game-state snapshot so we can repro without a back-and-forth. Pilots whose feedback turns into a fix or a feature usually get their callsign in the patch notes — pilot MADMEX set the bar by flagging two regressions within minutes of the mouse-control launch, both fixed and shipped the same day. Open alpha means open feedback loop.

— Ray