Server Performance on Densely Populated Ships

[Lord_Void]

So we have seen the planned system of having the game sub-divide a region of space based on the number of players, and this makes a lot of sense for planets and space stations, but how would this work for moving ships with large numbers of people on them? What happens if a ship gets sub-divided into multiple regions? We know the regions update slower with each other, so I imagine this could pose problems with a ship that is trying to maneuver. 

 

I'm not sure what the cut-off point is for the server to sub-divide a region of space, but I'm just going to pick and arbitrary number here for the sake of argument that the system will try to keep around 100 players per server region. It's more than reasonable that there could be ships that have more than 100 people on them, especially a year or two post-launch. Imagine a large Capital ship: the ship is going to need a crew of people to fly it, people to make emergency repairs during combat and probably a team of people to repel boarders and run the guns. And if the ship is carrying fighters then those ships will have pilots and maintenance crews, plus people to move cargo around. Add in an infantry group or non-combat personnel and the ship could easily get over 100 people. So how would the ship function if it was running on two separate machines in the server cluster?

[SirJohn85]

So how would the ship function if it was running on two separate machines in the server cluster?

 

I imagine that these clusters are redundant. Perhaps also a cloud solution.

 

 

A little explanation for the others:

 

Clustered: This means, at a basic level, that two or more servers are combined together to act as one in some way. This may involve a computing cluster, such as in "grid" computing, where all the cluster nodes are computing a portion of the workload in order to scale the power of the system. Alternatively (and more commonly), it may involve a failover cluster of nodes that are designed to take over for each other in the event that one (or more) fails. In that case, a particular service only runs on a single node at a time, but may be moved to another when needed.

 

Redundant: Redundant nodes are those in a failover cluster, where they are designed to take over operations for one another in the event of the failure of one of the nodes.

 

Failover: The term for when services on one node "fail over" to another node in the event of an emergency, or when manually moved.

[yamamushi]

This interview was published in 2014, but it's still probably mostly valid information:

 

http://blog.actor-framework.org/2014-12/spotlight-dual-universe/

 

 

If that article is still valid, even from just an architectural point of view, then they're relying on the actor model to handle the concurrent processing across their cluster. Bearing in mind that the cluster is likely composed of cloud instances, and not a datacenter full of dedicated servers. 

 

If they're using a provider like AWS, then I would imagine they're putting the instances behind autoscaling groups to dynamically expand or shrink the overall size of the cluster depending on its overall load and health. 

 

This would all fall under the "grid" computing that SirJohn85 described. 

 

 

For a much better understanding of what I mean by "Actor Model", this video is a great place to start (I may be exaggerating the "place to start" part, depending on how much someone knows about programming):

 

 

 

If you can get through that video, you'll have a much clearer understanding of how their server cluster probably works. 

 

This is the kind of stuff I work on for a living, albeit for a different kind of problem. 

 

 

Edit: And here's another article from the perspective of Halo 4, and how they leveraged Azure along with the actor model (the orleans framework) : 

https://www.infoq.com/news/2015/03/halo4-actor-model

[Haunty]

JC briefly mentioned the actor model in the Space Game Junkie interview. Around the 13 minute mark.

Edited February 1, 2017 by Haunty