Mar 30, 2026 6 min read

So I'm making a 1000 player multiplayer space game

An action game where you pilot a ship in a 1000 player space battle!

Hi, I'm Glenn Fiedler, a professional game programmer with more than 25 years experience. I'm a world expert in netcode and I'm the author of gafferongames.com and mas-bandwidth.com.

In the past, I've worked on some games you may know:

Freedom Force
SWAT 4
L.A. Noire
Mercenaries 2
God of War
Journey
Titanfall 1
Titanfall 2
... plus a tiny bit of my netcode is still active in Apex Legends.

And now, after decades of sharing network programming knowledge on my blogs, and helping many teams network their own games as a consultant, I'm announcing a new project I've been hard at work on for the last one and a half years.

A 1000 player space game.

If you enjoy space games, you're probably familiar with promises of 1000s of players. In fact, Star Citizen has been promising this for a decade (is it done yet?). Other games like Elite: Dangerous and No Man's Sky have high player counts technically, and maybe there can be more than 1000 players connected inside a vast infinite procedurally generated universe at the same time... but good luck seeing them all together in the same place!

So when I say 1000 players, know that I mean something quite different to anything that has been done before. I don't mean 1000 players spread out across a whole galaxy or solar system where occasionally you might have a battle with tens or 100s of ships. I mean 1000 players that you can see, right in front of you, all fighting in one huge space battle.

Here are some references for what I am aiming for:

As you can see I'm going for that classic space battle: fighters, bombers, lasers, missiles, turrets, capital ships – all networked with the fidelity of a FPS, not an MMO. So it's a fast-paced action game, not a flight simulator or role playing game.

Yes, this means that over the past 1.5 years I've literally scaled up traditional FPS netcode to support 1000 players with a completely custom game and netcode engine. No network lodding. No distance culling. No chugging when more than a hundred ships get together in the same space. All spaceships visible and fighting together.

Further to this, this announcement is vaporware free. This is not an announcement of something to come in the future, or something that I am working towards over the next 10 years. This is something I have working right now.

Take a look at our latest prototype from GDC 2026:

A bit more about what you see in the video. First, you probably notice that the graphics are very basic. In the game industry we call this "blockout" or "grey boxing". At this early stage of development, this is normal. First, we prototype with temporary objects until we are sure we have something that technically works and is really, really fun, only once we have this, do we spend money on art to make final quality graphics.

What we have here is my test level, designed to show off one of each type of object that the engine supports, and to test that we can handle the numbers of objects we need to make a really fun space battle.

In the level you can see:

It's set in a space that is a 24km cube in total. It's a relatively small level, so this is not a game about exploring an infinite large universe, but one about an intense space battle in one location. Around a megastructure, around a shield structure protecting a planet, inside an asteroid field – In this game I want space to have terrain. A real level with real obstacles and hazards to fly around.
The first thing you see ahead is a large Dyson sphere made out of 8,000 cubes. Each cube is a "static prop". These props cannot move, they stay still and thus do not need synchronization between the client and the server, although it is possible that I can reconfigure the structure of the Dyson sphere as a a function of some server scripting variable, and maybe it can switch between different physical configurations in the near future.
Outside the Dyson sphere you see 1,000 "asteroids" made up of dark grey cubes. This object type is called "dynamic props". They are simulated in the physics engine on the server and synchronized to the client. Dynamic props are gameplay affecting and can damage other ships. Yes, you can even shoot them with your lasers and push into other ships or structures.
Not shown yet in the demo is another planned type of object "animated props". These props may follow a path that is a function of time. For example, if we needed a gameplay affecting asteroid belt that had more than 1,000 asteroids in it, these asteroids would need to become animated props. They cost nothing to network since the client knows the current time, and from that time it can look up the position and rotation for each animated prop.
Inside the Dyson sphere you see orbiting yellow cubes. These are "cosmetic props". You can shoot them and they'll recursively fragment by breaking up into 8 sub-cubes for several levels. I currently support as many as 16,000 cosmetic props in the level. These are simulated client side and are cosmetic, and not gameplay affecting. They do not damage ships that hit them, they do not push back or affect gameplay objects, and they do not block lasers or missiles. Because these props are cosmetic, they do not require any bandwidth to synchronize, so we are limited only by how many rigid bodies the client can simulate at 60FPS.
The ship you are flying is a fighter. These are very fast and have a boost or afterburner. Currently the boost speed is 1000 meters per-second, because I want this not to be a game about shooting at dots in the distance, so fighter ships need a way to quickly close distance with opponents and start a dogfight. Currently there is no energy cost or cooldown on boost (this will probably change), but you cannot shoot while boosting, and it is less maneuverable than regular speed. When not boosting the fighter regular speed is 200 meters/second, and is highly maneuverable with true 6DOF controls.
You can see at the start your team's carrier ship flanked on either side by destroyers. The same exists on the other side of the Dyson sphere megastructure for the other team. We support multiple ship types with different armor types as well as weapons with different amount of penetration, so for example, a fighter may not be able to directly damage a destroyer or carrier, but may be able to help take out turrets.
Above the carrier in you can see a line of bombers. These are comedically stupid at this point but they represent a type of NPC ship. We can have up to 1,000 NPC ships in the level, in addition to 1,000 player ships. When there is not 1,000 players in the level, we also can scale up the number of NPC ships to give players something to do.
Not shown yet. I plan to have both player and NPC controlled turrets on capital ships, as well as corsair or corvette class ships where one player can fly and their friends can man turrets. There is also a homing missile system where you can lock on and fire missiles at other ships.

We have a game server running in Los Angeles with 1,000 simulated clients connected taking the full bandwidth and CPU load for all 1,000 players, so we know this all works and after an intense amount of optimization and stabilization over the last 1.5 years, we know that we can pull it off with a reasonable per-player cost.

So here we have the announcement of the game. Yes, it is still incredibly early but I promise you that everything you see is real.

So what's next?

I have a few months of work ahead of me to get the first alpha build ready for play testing, and then I'm ready to start getting early feedback from real players. So if you'd like support the development of 1000 player space game, you can support me here on Patreon: Space Game Glenn.

Supporters get access to exclusive posts about the development of the game, access to the space game discord, and access to early playtests.

See you online in Space Game!

ps. A huge thanks is due to two friends of mine: Brian Bucklew and Nathan Drabsch. Brian for massive assistance for the past year and doing a tonne of work in the last year getting the Unity renderer online and hitting 120FPS, and Nathan for his early participation and help in early discussions and ideation around this project from the very start 1.5 years ago.