We get a lot of questions about the exact nature of the multiplayer in Astroneer. Questions range from how many players it supports to what the server model is, to whether there is an online persistent world. As the one who spearheaded our multiplayer capabilities, I thought I’d speak in detail about our current multiplayer capabilities and where we’re headed.
I think it’s important to establish, first, that at the beginning of this project, the team had no one with significant network engineering experience, let alone a networking expert. Because of this, the initial release plan called for a single player only experience, with multiplayer to be explored in later updates. When the schedule became extended, we decided to attempt multiplayer, but we would do so with a conservative approach. Multiplayer version 1 would feature no matchmaking, no dedicated servers, no host migration, no game lobbies or otherwise complicated state flow. It would be straightforward co-op where one person could join another person’s single player experience, and only if those people were friends. A limit of four players was later established, and there would be little to no in-game UI for multiplayer sessions. Joins would happen via platform friends lists. This is what the game will release with on December 16.
Why So Limited?
Half the answer is I didn’t know what I was doing, so I was at least going to limit the length of rope with which to hang myself. The other half was we didn’t have the resources to hire people who knew what they were doing. Astroneer features a bunch of things that present challenges for any networking model: Procedural world generation, smooth real time terrain deformation, and large numbers of dynamic objects. I expected that tackling these issues while also implementing required features like join-in-progress correctly would leave little time for other features or for deep optimization by the time we needed to ship Early Access.
The four player limit was a concession to the lack of optimization time. In single player, since the game world is so vast, we try to maintain framerate by only simulating objects that are near you, and only generating collision surfaces for nearby terrain. Astroneer is built with Unreal Engine 4, employing a strict server-client model, where the server is the authority for all game state. The host machine therefore has a tremendous CPU load, increasing linearly with the number of players in the game. This is made especially difficult because if all players are simultaneously in different areas of the world, the host has to generate and maintain collision information for every player, while processing all of the terrain deformations they might be performing. By capping the player count we bound things to what current hardware is reasonably able to handle and buy some time to improve the networking core in future iterations.
Dedicated servers and matchmaking, by contrast, are less a technical challenge for us than a simple scoping issue. Unreal Engine has good support for dedicated servers, but we wanted to have a decent server browsing experience beyond a box where you can punch in an IP address (which certainly wouldn’t fly on Xbox), and we also wanted to provide users with vetted options for purchasing servers, which is extra business overhead, and finally, dedicated servers means a likelihood of playing with strangers, and we wanted to take our time deciding how best to deal with griefing and other design related problems that can arise in a game that we encourage all ages including the very young to play. Matchmaking carries similar caveats in terms of stranger danger, and tends to be work intensive with UI, another area where we lack resources.
Before we tackle major new capabilities, we need to focus on maturing and improving the essential peer-to-peer net code, which I’m sure many will find is riddled with bugs! The replication code for the terrain is novel, and will ship with some known issues, player movement and vehicle net code was written nearly from scratch, and the variety of stateful interactions we have with all the in-world dynamic objects creates a nasty matrix of cases to test and maintain. For the first couple of months, I’ll be focused on glitches, and network performance.
After that, dedicated server support is a big priority. We know how much the experience will improve when you have a persistent environment for any of your friends to drop into at any time and contribute to, especially given the creative sculpting power you have in the game. Expect to see news about work on this not long after release. Following that work will come the fun and fascinating challenge of significantly increasing the player count. I imagine this will require a rewrite of much of the underlying replication code to suit our particular needs and stress points, and we’ll be batting a lot of ideas around about distributed authority models – very much unexplored territory for us.
The best way to think about it is that the MP capabilities of the game are the most limited now that they will ever be in the future, so there is a lot to look forward to!