Some thoughts on the functionality of sieges

[La_fleur_]

I just took part in the siege. The number of problems is huge:

- Players disappearing
- Ship control failure
- terrible long texture downloads
- terrible and unclear shot registration work
- General lags

It's hard for the game to calculate everything around. The server does not have time. My subjective opinion:

We need to move away from the current concept of sieges and move into the mechanics of session sieges. The siege has started, a huge sphere is being created inside which players cannot fly out and there is also no interaction with the outside world. And the outside world also cannot interact with this sphere during the siege. The start of the siege a loading screen appears during which models of ships, capitals, stations, and so on are loaded, so as not to make them constantly reloaded. All calculations are done inside this session, which is separate from the rest of the game. All players outside the sphere do not see what is happening inside until the siege is over, and therefore the game will not call the server what is happening around the sphere. After the end of the siege, the result is uploaded from the sphere to the big world and all the debris is already available to other players. If a player outside the sphere wants to take part in the siege, he flies up to the sphere and makes a request, and then he also downloads, after which the player chooses a side.

You need to think about limiting the number of ships involved in the siege and the number of ships during the test in order to understand the maximum load after which problems begin. The current concept of sieges is costly in terms of client and server capabilities. There are too many calculations.

 

[XenoCow]

Before changing the whole paradigm of how sieges work, it might be good for us to know how many of these are just underoptimizations and how many are unsolvable problems. Hopefully it's just a matter of optimization, or change of implementation rather than limiting the gameplay to match the current capabilities.

For example, I wonder how many of these issues are due to players all having to (as far as I know) directly connect to all other players to properly interact with them. Maybe it could be possible that instead of all these direct connections, players that have fast connections to two players that have slow connections between them could act as a relay. I understand that a dynamic mesh version of P2P would be difficult mathematically and technically, and may already be in-place, but that's the kind of implementation change that might help fix some of these issues.

 

[La_fleur_]

Before changing the whole paradigm of how sieges work, it might be good for us to know how many of these are just underoptimizations and how many are unsolvable problems. Hopefully it's just a matter of optimization, or change of implementation rather than limiting the gameplay to match the current capabilities.

For example, I wonder how many of these issues are due to players all having to (as far as I know) directly connect to all other players to properly interact with them. Maybe it could be possible that instead of all these direct connections, players that have fast connections to two players that have slow connections between them could act as a relay. I understand that a dynamic mesh version of P2P would be difficult mathematically and technically, and may already be in-place, but that's the kind of implementation change that might help fix some of these issues.

Yes. I am also interested in learning all this. How many games do there even exist with massive space battles? (EVE ONLINE will not consider the implementation there much simpler). For example, there are session team shooters. Up to 100 people and sometimes even more can take part in such games and there are no problems. The whole problem in Starbase is the rehost system. I have personal doubts that such mechanics are capable of withstanding a massive influx of players. The server is just going crazy. Yesterday we participated in a siege where there were about 30 people. I'm afraid to imagine what would happen if there were 50 people. And it's even scarier for me to imagine what will happen if 2 sieges take place side by side at the same time. Let's hope that the developers have chosen the right solutions and all the problems are only technical in nature, and not architectural in nature of the program

 

[XenoCow]

Let's hope that the developers have chosen the right solutions and all the problems are only technical in nature, and not architectural in nature of the program

I agree. I hope they take the time to reconsider any infrastructure choices now during this phase of quiet development to see if there are alternative methods, or even overhauls required. I am glad for the recent tests on the test server to make obvious the problems with the system.