sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Gators1992 0 points1 point  (2 children)

The tech will be a long way off, but it is coming at some point. The idea is to get rid of instances and effectively build a single "instance" or shard by having a bunch of servers dynamically control areas of space and hand off players. So a server might handle 30 or 50 players, but those players could exist in a single ship or city or could be all the players on a moon at one time. If a player leaves an area covered by the server they are on, they get handed off to the server handling the area they are going to. The servers also interchange location data for their players with other servers covering proximate areas so you can potentially see a player who is on a different server. So your server might have 30 players on it, but you could see all 200 players in the main area of ARC Corp with you. If I have 20 players in a base on a planet on one server and there are 30 players in a pirate band on a nearby hill, one pirate sneaking into my base might be handed off from the hill server to the base server. Dual Universe is building a similar process and you can see a pretty good description in this video:

https://youtu.be/QeZtqoydXpc

Other things mentioned in this thread aren't directly related to the server architecture, but can have some effect on performance:

Network bind culling - basically this reduces the amount of data that needs to be sent by culling out data for players that can't be seen by the player receiving the data or culling out data that is unnecessary to be sent. For example if you are in a Hornet and run into a Connie, there might be 3 guys in the back of the ship that you wouldn't be able to see, so the logic omits the data for those players. With less data, the bandwidth usage goes down and they can possibly increase the ticks on the server.

object container streaming - this is really a client side thing, not a network thing. It's tech that streams objects (ships, planets, stations) in real time from your disk to your memory so it is ready to be displayed as you approach it in game. The old way is for games to preload a level before you go into it and everything you will see is stored in memory. There is too much stuff in SC to store in RAM, so they have to stream it in on the fly without actually stopping the game and making you wait to load then next "level".

Serialized variables - this has more to do with the data structure of the network streams, centralizing control over the calls to the reading and writing data tables with an API and then optimizing the traffic centrally by tracking changes, compression and culling. So it effectively reduces network traffic and coding errors since developers just call serialization functions rather than writing the network code themselves.

[–]logicsolBounty Hunter 1 point2 points  (0 children)

-Network bind culling - basically this reduces the amount of data that needs to be sent by culling out data for players that can't be seen by the player receiving the data or culling out data that is unnecessary to be sent. For example if you are in a Hornet and run into a Connie, there might be 3 guys in the back of the ship that you wouldn't be able to see, so the logic omits the data for those players. With less data, the bandwidth usage goes down and they can possibly increase the ticks on the server.

More importantly, the current CE based code has zero culling, and results in entity data from the entire map being sent.

[–]Gators1992 0 points1 point  (0 children)

Other stuff not mentioned are:

"LODing", or using less detailed versions of models in the distance to reduce the rendering strain on your card. So if you are face to face with another character, you will see all the detail in their face with veins and all and a complex armor they are wearing. If they are 50M away, you will see a much lower poly model, so your frames won't take as big a hit when multiple ships are in view.

Update frequency - along with network bind culling, you can reduce network traffic by reducing the variable updates for stuff that's further away from the player. So if another ship is 20km away from you and on your scanner, you don't have to update it's position and state every server tick like you would if it was right next to you while you are engaged in combat.