In 10 for the Chairman 77 hat Chris Roberts die Katze aus dem Sack gelassen und eine neue Herangehensweise an die Instanzierung in Star Citizen vorgestellt. Der Hauptunterschied zum alten System ist, dass es faktisch keine Instanzen mehr geben wird. Auf der Serverseite sollen Game Server per Server-Meshes zusammengeschaltet und auf der Client-Seite soll nur ein Teil der Schiffe im Sichtbereich angezeigt werden.

In diesem ersten Teil werden wir uns die Aussagen vornehmen, die Chris Roberts gegeben hat. Danach schauen wir uns das grundlegende Konzept, das sich aus den Aussagen extrahieren lässt, an. Abschließend geht es um die Serverseite und dabei insbesondere um die Umsetzbarkeit des Systems und mögliche Problemlösungen. Im zweiten Teil schauen wir uns dann die Problematik des Wegblendens von Schiffen auf der Clientseite an.


Der Vollständigkeit halber, könnt Ihr in den folgenden Posts die bisherigen Aussagen zum alten Instanzierungssystem und meine Erklärungen dazu finden:

• Das Zonensystem in Star Citizen
• Instanzierung in Star Citizen - Teil 1
• Instanzierung in Star Citizen - Teil 2 
• Instanzierung in Star Citizen - Teil 3

Ich habe in den Posts ein Update eingefügt, welche Teile immer noch aktuell sind, und welche durch das unten beschriebene neue System abgelöst werden. Die Aussagen zum Zonensystem bleiben wie gehabt bestehen.

Chris Roberts Wortlaut

Lasst uns zunächst mit den Aussagen von Chris Roberts selbst starten. Es gab zwei Fragen zu diesem Thema, die uns zusammengenommen ein Überblick über dieses neue System geben. Normalerweise würde ich Euch das ganze einfach auf Deutsch zusammenfassen, aber in diesem Fall habe ich mir die Mühe gemacht ein englisches Transkript anzulegen - einfach um nichts zu übersehen.




Dieses erste Video zeigt Chris Roberts Antwort auf Frage Nummer eins, ob und wann es eine Erhöhung der Spielerzahl von 16 auf 24 geben wird. Und wie versprochen der englische Wortlaut der Antwort:

The answer to that is absolutely. I think if you have been watching some of the chatter on the recent PTU releases and you know what's going to be in 2.2, it is gonna be 24 players. So, we have been working hard on sort of optimising areas, so we can scale more. I think, I mentioned before, the biggest issue that we have is just the overhead that the ships have, because they are very complicated.

They have multiple items and all of this functionality that need to talk together over the network, is attached to a ship. A ship is not just one entity. In the case of a Hornet it could be 66 entities. For a bigger ship it could be a lot more than 50 or 60. They are very heavy processing wise, for the server simulation and also on the network (in terms of traffic).

So, in general that's more the limiting factor for which we have been working on. We were restructuring lot of things to it much more smart about when it has to update and all the other things. This ties into the work we have done in the past on the zone system. We are doing sort of a network and update Level of Detail that sort of scopes depending on how well you can see things, how far away they are, whether they are active, whether it is another player and whether it is relevant to you. So, hopefully all that stuff helps to increase the load that we can do.

We are doing things like pushing more and more into multiple cores, multithreading to be able to do more Physics processing in the same time we are doing entity updates in the simulation. So, part of the result of that is moving to more players in Crusader. We will continue and we are expecting to continue this over time to get more and more player in the map.

We are actually working on some backend server Mash tech that will allow us to sort of mash a lot more players in what would be essentially be sort of the same instance. But this is a little further along. I think it is exciting. I think we will deliver probably more players than we were thinking originally in concurrent areas. I think actually there is a question about it later on.

Dieses zweite Video zeigt Chris Roberts Antwort auf eigentliche Frage zum Thema Instanzierung, wo es darum geht, wie das Spiel sicherstellt, dass Freunde in die gleiche Instanz kommen. Und auch hier wie versprochen der englische Wortlaut der Antwort:

Right, I touched a little bit of the it at the top of this 10 for the Chairman. I'm talking about the fact that we are working on getting more and more people into an individual instance - or really what it's more about is getting more people into an individual game server. So, Right now if you play Crusader in 2.2 there will be 24 players in one game server instance. Now, we actually have 8 of those, I believe... Yep, 32 core servers we are running on and we have 8 game server instances on this 32 core server each using 4 cores.

Now, the real goal would be not to have 8 on that, it would be rather to have one game server running on that one 32 core machine. Then, if we have 8 game server now and you have 8 times 24 you are getting a much larger number of people. You would be almost at 200 people at that point; and that would be one server. And that is without us doing more and more optimizations. So that's were we sort of moving towards.

Then on the client side, even hough the server can maybe deal with more entities, because it doesn't have to render, it doesn't have to move all the memory around, it just has to sort of deal with the background simulation and updating stuff. The clients may not be able to [handle all the entities the server can], but then the client would sort of make sure, what's around you, what you can see is what it is drawing and updating and been told by the server.

On top of that we are planning to have sort of seamless server transitions and basically mash the servers together. So, instead of: "I'm in Stanton system and I'm on one server, or I'm on a second server or a third server of the Stanton system." That is not the way how Stanton is gonna work.

It's gonna be very dynamic. We will actually have [something like this]: Say, we start with one server and people fly around. It could be anywhere in Stanton. Like is what you can do right now in Crusader. But then, as you go beyond the cap: say, just for simplicity sake, lets just say, say we can run 50 people on a server.

You know, 30 people, 40 people, they are all running around in Stanton, no problem doing their stuff. AI doing their stuff. But now a bunch of people come in and we move from 30 people to 60 people. Well, that is more than we can fit on one server. So, at that point, we will always have probably one server taking-over-ready - keeping one as a buffer.

Now, we got more [players] than we can fit on one server, so we sort of migrate players to whichever server is appropriate. It might be just arbitrary where you go. Well, there is a group of players over here, so [the first] server will take care of them. And there is a group of players over here and [the second] server will take care of them.

Both servers have full global view of the whole star system and the server also talk to each other as well as the clients. A server is essentially responsible for simulating the entities it is "authoritative" of. But it will also tell the other server if the other server needs to know, what the entity on the server did.

That's where it is educative. It's like: "[First server] I'm updating those people, but there is one guy who is over here, that's coming towards [the second server] and one guy is coming towards [the first server from the second server]". And then: "[First Server] This is were [my] guy is." The [second] server knows and has a sort of copy of it in his memory space and vice versa. So you can sort of basically resolve overlaps between sort of server controlled areas.

That's kind of the idea. As more and more people come in, you spin up more and more servers and they all mesh them together. You can ultimately have hundreds if not thousands of people all simulating essentially in the same instance. Then your real limitation is more about the client and what the client can render and see on its side.

That's kind of the plan which is sort of a more dynamic and [is] actually more advanced and I think [an] ultimately better solution that what we have talked before. Which was much more instances on top of each other and you can only ever see 30 or 50 other people or what ever it would be. I think it's gonna be good.

There will probably be some cases where there are still too many people. I can see in a landing area, where there's a thousand people hanging around in a landing area. We just won't be able to have thousand people. Or, hundreds or 500 people getting together and say lets go to the courtyard.

Well, on a client you just can't render 500 people. Just won't happen. What we will probably do is, besides having aggressive Level of Details, at some point we just cull out people beyond a certain area. They will all be sort of tagged and known there. As you move around as a client people will come in and out of your visibility - basically your sphere of visibility. I think it will be pretty seamless. 

On top of that, you know, getting down to your friends which is one key parts of this question. We will know, who are sort of your acquaintances, who is your person of interest, who you play with, who is on your friend list, stuff like that. If you are making decisions of who you can see: Like as in at some point there are to many people and the client saying: "I can't just render that many people. I have to choose some entities and people to not see."

It would not be the people you as a player has sort of tagged as your friends or the ons you are interested in. They would get preference in terms of the algorithm that determines who you see and who is culled out.

I think it's gonna be pretty cool. You should be able to kind of hang out and work with your friends. I think the only issue we are gonna get - which will happen - because we have some massive organisations. There is no way possible have one of those massive thousands people in a space battle set-ups. But I do think we will probably get like quite a few hundred into it. That would be pretty cool.

I'm sure you guys will break - figure out a way to break it. You know, that's what it is. I think it's gonna be a pretty cool experience. I'm actually quite excited by the tech that we are working on for this. It's not gonna happen overnight. It can take a lot of time, because  we are building something that's really - we are right on the cutting edge of this kind of stuff.

I mean there is a few other projects that are doing similar stuff: sort of using the cloud architecture to sort of dynamically scale and process much more bigger, denser worlds than you could do on a single server or a single client - which is what we are doing. But I think it is the future and it's going to be pretty cool.

Das Grundlegende Konzept

Nun also zu der Erklärung, wie das Konzept für die Instanzierung genau aussehen soll. Zunächst sagt Chris Roberts deutlich, dass es faktisch keine Instanzen im herkömmlichen Sinne mehr gibt. Auf der Server-Seite sollen durch den Zusammenschluss vieler Game Server, die ein Sternensystem zusammen verwalten, die Trennlinien zwischen den physischen Servern wegfallen. Ihr könnt Euch das als einen großen Verbund an physischen Rechnern vorstellen.

Wenn sie das schaffen, dann könnte jede Zahl an Spielern in einem Sternensystem dadurch abgedeckt werden, dass sie einfach neue Server hinzustellen. Dies wäre prinzipiell auch im bisher kommunizierten System möglich gewesen, aber der Witz dabei ist, dass es sozusagen nur eine einzige Instanz des gesamten Sternensystems gibt. So kann jeder Spieler theoretisch mit jedem anderen Spieler in Kontakt treten. Die Aufteilung auf die Instanzen würde wegfallen.

Für die weiteren Beispiel schauen wir uns das folgende kleine Beispielsystem an, welches Ihr schon aus meinen bisherigen Artikeln zum Instanzierungssystem kennt. Es hat zwei Planeten und ein Asteroidenfeld. Dieses Mal habe ich auch noch ein paar Raumschiffe mit eingezeichnet, um die Beispiele noch anschaulicher zu machen.

Kleines System für die Beispiele

Chris Roberts nennt folgendes Beispiel: Ein System beherbergt 30 Spieler. Nun kommen 30 weitere Spieler dazu (durch einen Jump Point oder sie Starten von einem Planeten). Das Limit an Raumschiffen, welche auf einem Server des Systems maximal berechnet werden können, sei 50. Nun wird ein neuer Game Server hochgefahren (einer ist immer als Puffer schon in Reserve) und die 60 Schiffe werden auf die beiden Game Server verteilt.

Weitere Spieler kommen dazu, die nicht mehr auf einen Server passen.

Wie Ihr seht, wird sich ein Game Server um den einen Teil des Systems kümmern und der andere um den anderen Teil. Für dieses Beispiel sind die Bereiche der Karte, welche die Game Server verwalten,  überlappungsfrei. Was passiert nun, wenn sich Schiffe auf die Grenze dieser Bereiche zubewegen?

Chris Roberts beschriebt, dass dann die beiden Game Server mit einander sprechen, um die Situation zu lösen. Er sagt nicht genau wie, aber wahrscheinlich wird ein Server seinen Spieler an den anderen übergeben, je nachdem wo der Treffpunkt sein wird.

Server entscheiden zusammen, was mit den Schiffen passiert.

Interessant ist nun natürlich, was an der Grenze passiert. Meine Vermutung ist, dass diese Grenzen zwischen den Bereichen, welche die Server kontrollieren, in den unendlichen Weiten des Alls liegen werden. Also zum Beispiel in der Mitte zwischen Port Olisar und Yela. Es ist unwahrscheinlich, dass Spieler genau dort im Nichts herumfliegen. Und selbst wenn, kann das Spiel darauf reagieren, in dem die Grenzen entsprechend ein paar 10000 km verschoben werden, wenn ein Spieler genau auf der Grenze entlang fliegen sollte.

So weit so gut. Solange also nirgends mehr als die maximale Zahl an Spieler in einem Bereich des Sternensystems sind, dann gibt es keine Probleme. Aber selbstredend wird genau das nicht der Fall sein. An den Ballungspunkten jedes Systems können locker hunderte von Spielern mit ihren Schiffen zugegen sein. Ich denke da an Terra, die Erde, andere große Planeten, Raumstationen und viele andere interessante Punkte im All, wie zum Beispiel Ziele von Quests/Missionen.

Chris Roberts macht dazu keine genaue Angabe, aber so wie er das Beispiel oben beschrieben hat, ist in dem System vorgesehen, dass es auch Game Server gibt, die überlappend den gleichen Bereich im Weltraum kontrollieren. Nehmen wir hier als Beispiel eine Raumstation wie Port Olisar, in der eine neue Questreihe startet. Nach einem Patch ist da also entsprechend viel los und es sind deutlich mehr Raumschiffe im Sichtbereich der Station, als ein einziger Game Server schaffen kann.

Also werden ähnlich wie im bisherigen Instanzierungskonzept weitere Game Server für den Sichtbereich um die Station herum angelegt. Zum Beispiel sind es 500 Schiffe und 50 ist wieder unser Limit. Dann benötigen wir also 10 Game Server. Damit jetzt wirklich alle 500 Spieler jedenfalls theoretisch miteinander interagieren können, müssen diese 10 Server alle Informationen über ihre 50 verwalteten Raumschiffe mit allen anderen Servern teilen - und zwar augenblicklich, d.h. ohne Verzögerung.

Mehrere Game Server verwalten denselben Bereich.

Der letzte Punkt ist extrem wichtig, da man anderenfalls die anderen Spieler zeitversetzt sehen würde. In so einem Gewusel um die Raumstation ist natürlich auch die Kollisionsabfrage extrem wichtig. Und auch die braucht aktuelle Informationen von allen anderen Servern. Laut Chris Roberts ist all das eine ganz neue Entwicklung, die nur wenige andere Projekte im Moment ebenfalls erforschen.

Kommen wir zum letzten Punkt, den das neue System ausmacht. Chris Roberts sagt, dass er glaubt auf der Server-Seite durch den Verbund von Servern alle Spieler in eine Instanz zu bekommen. Aber auf der Client-Seite gibt es keinerlei Möglichkeiten um Beschränkungen der Grafikkarten und CPUs herum zu kommen. Es ist unmöglich die 500 Schiffe im Sichtbereich aus dem oberen Beispiel auf einem PC anzuzeigen.

Deshalb werden sie erstens, so weit es irgendwie möglich ist, das Level of Detail aggressiv herunterschrauben, wenn das andere Schiffe auch nur ein Stück entfernt sind. Zweitens, wollen sie am Client Spieler ausblenden. Das müsst Ihr Euch so vorstellen, dass wenn in Eurem Sichtbereich zu viele Schiffe angezeigt werden müssten, dann entscheidet der Server anhand Eurer Freundesliste und der Organisation, welche Schiffe ausgeblendet werden sollen. Das folgende Bild zeigt Euch wie das dann aussehen könnte.

Spieler bewegt sich durch einen vollen Bereich, sieht aber nur ein Teil der Schiffe.

In den oberen Bildern habe ich nur drei Schiffe in der Nähe als angezeigt gekennzeichnet. Natürlich werden es im Spiel mehr sein, aber hier geht es vor allem darum zu verdeutlichen, wie das System funktioniert.

Es wird in vollen Bereichen des Weltraums dazu kommen, dass das Spiel Euch andere Schiffe, die eigentlich auch da sind, nicht anzeigt. Im zweiten Teil dieses Artikels werde ich Beispiele aufführen, welche zeigen, dass CIG hier noch genauer nachdenken muss, wie sie Immersionsbrüche weitestgehend verhindern wollen.

Die technische Hürde (bei überlappenden Game Servern)

Ich hatte es oben schon beschrieben, dass bei überlappenden Game Servern die Kommunikation zwischen den Servern so verzögerungsfrei wie möglich sein muss, damit man als Spieler nicht merkt, dass sein Mitspieler eigentlich auf einem anderen Server unterwegs ist.

Es gibt viele Möglichkeiten wie sie dieses Problem angehen könnten. Chris Roberts spricht in seiner Beschreibung davon, dass alle Server alle Schiffe aller anderen Server im Speicher haben. Das deutet darauf hin, dass tatsächlich irgendeine Art der Verteilung der Daten zwischen allen Servern stattfindet. Jeder Server informiert jeden anderen Server über alles, was passiert.

Das würde aber zu einem üblichen Problem in der Informatik führen: Mit jedem neuen Server, der auf Grund zu vieler Spieler in einem Bereich, hinzugefügt werden muss, führt zu einer Zunahme der Netzwerklast von 2*n - 2 zwischen den Servern (n ist die Zahl der Game Server). Die folgende schematische Darstellung verdeutlicht Euch das Problem:

Kommunikationkanäle zwischen den Game Servern

Ab irgendeinem Punkt wird das Netzwerk zwischen den Servern, die Netzwerkkarten in den Servern oder die CPUs der Server allein mit diesem Datenaustausch komplett überlastet sein. Dies ist dann die Grenze, an der auch das Hinzufügen weiterer Server keinen Nutzen mehr bringt. Im Gegenteil, das Hinzufügen neuer Server führt dann zu einer Abnahme der Leistungsfähigkeit aller Server.

Zu diesem Problem hat Chris Roberts leider nichts gesagt. Wie beschrieben ist das ein bekanntes Problem, das viele in der Software-Entwicklung haben. Ich arbeite selbst in einem Bereich, wo wir versuchen durch Parallelisierung auf verschieden Ebenen (Threads in der Software, CPU-Threads, Verbund von Servern) Berechnungen auf extrem großen Datenmengen, so schnell wie möglich zu machen. Man stößt immer wieder auf Grenzen der Skalierung, die oft mit genau einem solchen Austausch an Daten zu tun haben.

Ich bin deshalb recht skeptisch, ob CIG hier ein Durchbruch gelungen ist. Meine Vermutung ist eher, dass sie - wie viele andere auch - einen Weg gefunden haben, dass Problem so weit zu umgehen, dass die Grenze der Skalierung für ihre Zwecke hoch genug liegt. Einige Möglichkeiten bzw. Ideen habe ich in den folgenden Abschnitten aufgeführt, aber bei allen gibt es Licht und Schatten. Aber seht selbst.

Mehr Spieler auf einem Game Server

Zum Beispiel spricht Chris Roberts davon, dass auf den Cloud-Servern 32 Kerne zur Verfügung stehen, sie aber im Moment nur 4 pro Game Server verwenden. Sie wollen irgendwann alle 32 Kerne für einen Game Server ausnutzen. Dazu müssen die Serverprozesse aber auch darauf ausgelegt werden, alle diese Kerne zu nutzen. Daran arbeiten sie. Somit wäre es theoretisch möglich, auf einen Server 192 Spieler (derzeit 24 Schiffe mal 8 Game Server) unterzubringen.

Auch hierbei gilt aber wieder, dass was ich oben schon geschrieben habe. Nur dass es dieses Mal nicht Game Server sind, die miteinander Kommunizieren müssen, sondern CPU-Threads und die darauf laufenden Prozesse. Am Ende sollten wir auch hier mit einer wesentlich niedrigeren Grenze der Skalierung rechnen, als 192 Spieler.

Dennoch: wenn auf einem Game Server eine höhere Zahl an Spieler verwaltet werden kann, dann brauch man weniger parallele Game Server und ergo weniger Kommunikationslast zwischen diesen.

Verringerung der Kommunikationslast durch Serverwechsel

Eine andere Möglichkeit, die sich ihnen bietet, ist schlicht die Spieler von einem Server auf einen anderen zu verschieben. Wenn man sich jetzt folgendes Szenario überlegt: Ich bin gerade mit meinem Schiff gestartet und ein Freund will sich mit mir treffen. Wir sind aber beide auf verschiedenen Game Servern gelandet. Jetzt könnte das Spiel einfach hergehen und einen von uns auf den jeweils anderen Game Server übertragen.

Dies muss natürlich ohne Ruckeln für den Spieler passieren. Es gibt technische Möglichkeiten - und ich glaube das Chris Roberts das gemeint, hat mit der Aussage, die anderen Schiffe sind schon im Speicher - der Synchronisation der Daten zweier Server, so dass es für den Endanwender, in dem Moment wo der Server-Switch passiert, keinerlei Ruckler gibt.

Vor allem für Dogfights ist es wahrscheinlich notwendig, dass die beteiligten Spieler auf dem gleichen Game Server sind. Wenn dem nicht so wäre, dann würden weitere Datenmengen hinzukommen, die zwischen den Servern ausgetauscht werden müssten. In einem Kampf sind das natürlich die Laser, Projektilwaffen und Raketen. Hier muss CIG ganz genau überlegen, wie viel Datenübertragung bei wie vielen Servern möglich ist.

Leider hat aber auch der Serverwechsel seine Schattenseiten. In dem Gewusel einer größeren Schlacht in der viele kleine Schiffe auf einander schießen, kann es extrem schwer werden, zu errechnen, wer mit wem auf einem Server sein sollte, um möglichst wenig Kommunikation zwischen den Servern zu haben.

Clients kommunizieren direkt miteinander

Eine Idee, die Server-zu-Server-Kommunikation zu umgehen, wäre es, die Clients direkt miteinander sprechen zu lassen. In Bugsmashers gab es dazu einige Hinweise, dass sie dies jetzt schon nutzen. Es könnte also möglich sein, dass die beiden Spieler auf verschiedenen Game Servern während des Kampfes verbleiben, und die Clients direkt miteinander kommunizieren.

Natürlich würde dann aber die Kontrollinstanz gegen Cheats verloren gehen, wenn der Dogfight von den Clients selbst verwaltet wird. Es wäre dann möglich möglich, dass ein gehackter Client dem zweiten Server die Information schickt, dass der Gegner getroffen wurde. Der zweite Server kann dies nur überprüfen, wenn er mit dem ersten Server direkt kommuniziert. Was uns aber wieder zum Kernproblem führt.

Für das normale Herumfliegen wäre die Client-zu-Client-Kommunikation aber eine valide Möglichkeit.

Abschließende Bemerkungen

Wir werden noch abwarten müssen, bis CIG uns mehr Details zu diesem Game Server System erklärt. Das kann durchaus noch dauern, da wir uns darüber im Klaren sein müssen, dass all diese Dinge viel, viel Zeit in der Entwicklung benötigen.

Ich bin sehr gespannt auf weitere Details zu diesem System, nicht nur weil mich das auch beruflich interessiert, sondern vor allem, da durch dieses System die Lebendigkeit der Welt maßgeblich bestimmt wird.

Im zweiten Teil dieses Artikels werden wir uns mit der Clientseite genauer beschäftigen. Die von Chris Roberts angedachte Variante des Ausblendens von Schiffen kann sehr schnell zu Immersionsbrüchen führen. Dazu mehr im nächsten Post.