TorvenTool schrieb: »

RogeFederball schrieb: »

Oh man und ich dachte eben erst, na endlich die arbeiten an dem Problem. Dann bemerkte ich der Thread wurde im März 2015 eröffnet...

Ne, das sagen sie nur bei jeder Gelegenheit. Getan wird spürbar nichts.

Nur weil es noch nicht weg ist, heist das nicht, dass sie nichts dran gemacht haben...

Ich möchte mich jetzt hier auch mal zu Wort melden.

Dass der Performance-Engpass beim Server liegt ist ja wohl eindeutig.
Allerdings ist nicht bekannt, was das Problem ist.
Dabei sehe ich verschiedene Probleme/Möglichkeiten:

1) Berechnungen sind zu komplex sodass der Server nicht mit der Berechnung nachkommt.
Beispiel dafür: Char X möchte einen Zauber Y durchführen. Mögliche Ziele werden ermittelt. Server lädt alle verfügbaren Spieler im Umkreis - *** 2000stk und ermittelt die 20 nächsten. Die 20 Ziele werden an den Spieler zurückgeliefert als "mögliche Ziele". Der Spieler feuert seinen Zauber ab - Berechnung geht erneut los. Zauber hat einen Flächenschaden (Feuer). Damit muss der Server pro Tick erneut die Spieler durchrechnen um zu sehen wer Schaden bekommt.
Das Ganze dann eben x mal. 2000 vs 2000 Spielen => bestimmt 8000 Effekte die berechnet werden müssen.
Viele Berechnungen lassen sich parallelisieren, wobei durchaus 16000 CPUs zum Einsatz kommen können.
Allerdings setzt das wirklich fette Server voraus und ein gutes Spieldesign damit die Berechnungen ohne große Leistungseinbußen parallelisiert laufen können.
Die Skills wurde dann aber auch nicht optimal gewählt, da diese durch ihre "boost pro Gegner im Umkreis", "Ketteneffekte" und Co einfach viel Leistung brauchen für die Berechnung.

2) Übertragene Datenmenge ist zu hoch.
Wenn der Server nichtmehr mit dem versenden und entgegennehmen der Daten hinterherkommt, was durchaus sein könnte wenn ich mir den Ping bzw die Downloadrate ansehe, dann wäre das die angenehmere Variante.
In diesem Fall kann man auch Serverseitig etwas machen indem man zb Server-Cluster einsetzt. Dadurch würde sich die Spielerlast auf mehrere Endpunkte verteilen. Wichtig wäre hier, sicherzustellen dass die Server untereinander eine wirklich gute Anbindung haben damit der Datenaustausch zwischen den Servern so performant wie Möglichkeit geschehen kann.
Eine kurzfristigere Lösung wäre es die Datenmenge zu überprüfen und eventuell sein Kommunikationsmodell neu zu entwickeln.
Was werden dann an Daten übertragen?
Muss ein Spieler wirklich die exakte Farbkennung / Rüstungssets kennen? Wenn jemand zb eine Robe trägt interessieren mich seine Armlinge/Beinlinge zb schon mal 0.
Wie oft werden Funktionen aufgerufen (Siehe 1. bei der Berechnung)? Dann wird eben keine "Zielvorauswahl" mehr angeboten (Highlighting der Ziele bei GTAE Effekten) sondern nur noch die Effektberechnung selbst durchgeführt.
Oder man muss einen neuen Standort für den Server finden, der einem eine deutlich bessere Verbindung anbietet.

Bei DAOC zb wurde es in großen Zergmengen auch kritisch. Bis die Spieler festgestellt haben, dass die Datenmenge deutlich geringer wird wenn sie die Umhänge weglassen.
Da wurde wohl die Umhangposition mit an die anderen Clients übertragen.
Sobald es also Lags gab musste jeder seinen Umhang ausziehen und alles war gut.

3) Anzahl der Verbindungen / Datenpakete ist zu hoch
Hier unterscheidet sich TESO zb von DAOC enorm. Bei TESO habe ich den Eindruck, dass auf Spielerseite alle Aktionen an den Server geschickt werden und dieser die Aktion genehmigen muss.
Beispiel: Spieler wirft eine Speerscherbe
Client -> Server: Spieler möchte Speerschwere werfen
Server prüft: Skill ready? Mana vorhanden? Skill geskillt? Charakter Status ok (liegt nicht am Boden oder ähnliches)?
Server -> Client: Okay
Client -> Server: Spieler wählt GT Position 500/700
Server prüft: Liegt 500/700 in Reichweite des Spielers? Hat der Spieler noch genug Mana? Charakter Status okay?
Server -> Client: Okay, Mögliche Ziele: x , y, z (Damit der Client anzeigen kann, was man treffen würde)
Client -> Server: Spieler wirft Speerscherbe auf Position 500/700
Server prüft: Liegt 500/700 in Reichweite des Spielers? Hat der Spieler noch genug Mana? Charakter Status okay? Welche Ziele betroffen? Schadensberechnung? Neuer Status aller Ziele?
Server -> Client: Neuer Status des Charakters, Neuer Status aller Ziele

Die Kommunikation ist sehr cheat-sicher, da der Server über die volle Kontrolle jeder Aktion die Hoheit hat, benötigt aber enorm viel Kommunikation.
Ein anderes Modell könnte in etwa so aussehen:
Client: Spieler möchte Speerschwere werfen
Client prüft: Hat der Spieler genug Mana, ist der Skill geskillt, Charakter Status okay -> okay
Client: GT 500/700 ausgewählt
Client prüft: Liegt das Gt in Reichweite, Hat der Spieler noch genug Mana? Charakter Status okay? Mögliche Ziele: x , y, z (Damit der Client anzeigen kann, was man treffen würde)
Client -> Server: Spieler wirft Speerschärpe auf Position 500/700
Server prüft: Skill ready? Mana vorhanden? Skill geskillt? Charakter Status ok (liegt nicht am Boden oder ähnliches)? Liegt 500/700 in Reichweite des Spielers? Welche Ziele betroffen? Schadensberechnung? Neuer Status aller Ziele?
Server -> Client: Neuer Status des Charakters, Neuer Status aller Ziele

Kurzum: Man überlässt dem Client die Vorberechnungen und der Server prüft am Ende nur einmal ob die Aktion okay ist und welche Auswirkungen der Effekt hat. Dadurch lässt sich die Kommunikation und die Berechnungen enorm reduzieren und man verliert kaum etwas an "Cheatsicherheit", da der Server vor dem Ausführen letzten Endes prüft, ob der Client da auch keinen *** macht.

Man kann das sehr schön sehen, wenn man einen Lag in TESO mit einem Lag in DAOC vergleicht. Bei DAOC konnten bei einem Lag alle Aktionen durchgeführt werden (Schlagen, Springen, Reiten, Zaubern, ...). Allerdings hatten sie keinen Effekt mehr. Die Gegner haben sich nichtmehr bewegt, es wurden keine Effekten mehr anerkannt und Ausdauer/Manakosten wurden auch nicht berechnet. War der Lag vorbei konnte es sein, man wurde mal eben 500m in der Position verschoben weil der Server eine andere Position des Charakters hat als der Client und in dem Fall der Server natürlich gewinnt.
TESO: Man kann gar keine Aktion mehr durchführen. Türen lassen einen nichtmehr durch, man kann keinen Skill mehr aktivieren, ...

4) Datenbank ist überlastet
Ich nehme mal an, dass die eingesetzte Datenbank in Cluster urteilt ist.
Dabei wird jeder Cluster ein Gebiet repräsentieren. Sobald viele Spieler in einem Gebiet sind laufen dann natürlich enorm viele Anfragen auf diesen einen Cluster.
Das ist ein sehr ekelhaftes Problem was sich nicht ganz so einfach lösen lässt. Man kann nur Maßnahmen ergreifen und hoffen dass es hilft.
Ich gehe jetzt mal davon aus, dass die Primärschlüssel und Co bereits gut gesetzt sind und führe das jetzt nicht noch extra an.
Maßnahmen wären hier:
Cluster weiter unterteilen (Verspricht wenig nutzen)
Mehr Caching einsetzen damit die Daten nicht nachgeladen werden müssen
Views überprüfen (Was für Joins werden eingesetzt? Lassen sich Joins reduzieren?)
Datenbankorganisation prüfen (Wie breit sind die Tabellen, wie viele Tabellen gibt es)
Eventuell muss eine Logic-Schicht eingezogen werden sollte die View einfach nicht performant / flexibel genug sein
Das zieht allerdings gewaltige Änderungen am Sourcecode nach sich und ist alles andere als angenehm

Andere Vorschläge von wegen "Spielerzahl reduzieren" sehe ich als extrem blöd an.
Cyrodill ist so riesig, dass ich ja gerade eine hohe Spielerzahl haben möchte / haben muss damit auch was los ist. Man reitet ja jetzt schon teilweise eine halbe Ewigkeit.
Das heißt es wäre nur Sinnvoll, wenn die Kartengröße ebenfalls angepasst werden würde.
=> Spieler halbieren, Karte halbieren

Die Einführung von Schlachtfeldern ist an sich eine gute Idee.
Leider würden alle nur noch Schlachtfelder spielen weil Cyrodill ja nicht geht.
Damit würde dann eine natürliche reduzierung der Spieler führen, was wiederum das Problem von "Spielerzahl reduzieren" mir sich zieht.
Ich persönlich würde mich auf Schlachtfelder freuen, da ich mir davon kürzere Wege und mehr Kämpfe verspreche.
Allerdings wäre es mir lieber, Cyrodill wäre kleiner und würde sich spielen lassen.

Dazu kommt, dass das System ja so gewünscht / beworben wurde und sich die Spieler natürlich auf ihre "epischen Schlachten" freuen.

Das wären keine Lösungen sondern nur eine Verschiebung des Problems. Das eigentliche Problem "Probleme bei großen Spielermassen auf einem Haufen" ist nicht gelöst.

Die Skills abzuspecken und eine pvp und eine pve variante zu machen ist genauso doof.
Allerdings wäre ein Redesign der Skills vermutlich genau das richtige um die Berechnungen deutlich einfacher zu gestalten.
Dabei ergeben sich aber massive Probleme. Es wird garantiert einen ****storm bei den Spielern geben.
-Das Spielgleichgewicht wird total über den Haufen geworfen.
-Templates werden unbrauchbar.
-Spieler müssen umskillen bzw überhaupt erstmal wieder in ihre Skills reinfinden.
-Es muss wegen des neuen Ungleichgewichtes wieder viel nachgebessert/verändert werden.

Edited: Nur Rechtschreibung verbessert. Keine Inhaltlichen Änderungen

Thraben schrieb: »

Ich habe insbesondere 2) in Verdacht - es besteht ziemlich unzweifelhaft eine Korrelation zwischen der Zunahme optischer Gestaltungsmöglichkeiten und dem Lag. Leider ist Korrelation nun nicht gleich Kausalität. 1) spielt da hinein, kann aber nicht die tatsächliche Ursache abgesehen von einer handvoll Skills sein, da in der Beta, in der noch alles trotz RIESIGER Schlachten locker lief (vom Ladebildschirm abgesehen), nun auch reichlich Skills verwendet wurden.

Daher sollte man die Lösung des einzigen Massenspiels wählen, welches ich kenne, das nicht unter massiven Lags leidet: Planetside 2. Also 3 Uniformmodelle pro Fraktion, und gut is.

Wer das nicht will, für den soll´s halt noch Poser- und Lagserver geben.

Und wenn das nicht reicht, dann noch zusätzlich ein "Kollisionskontrolle-und-sündhaft-teure-Skillkosten"- Server, wo dann der Lag ziemlich garantiert weg ist.

So extrem muss man es ja garnicht haben. Ich persönlich finde es schon sehr schön, wenn individualität geboten wird. Alles zu vereinheitlichen ist nicht das richtige Modell. Aber man kann ja vielleicht durchaus absprecken. Dabei denke ich zb daran, dass man die Farbpalette eben reduziert und keine x Rottöne, x Grüntöne, x Blautöne, usw mehr hat sondern von jeder Farbe nurnoch 1-3 Schattierungen. Die Vielzahl an verschiedenen Setgegenständen könnte man auch reduzieren. Das hat den Vorteil, dass statt der langen ID ein sehr kurzer statischer Wert übertragen werden kann (1 byte zb).

Ich vermute mal dass die Rüstungsteile mit dem Namen (oder deren ID) übertragen werden und es dem Cielt dann überlassen ist, wie das gerendert werden muss. Demnach besteht eine Rüstung also aus seiner ID, 3 x Farb-ID. Wenn für die ID jetzt eine Zeichenkette von 32 Zeichen Länge genommen wird kommt es auch extrem auf die Kodierung an. Da es sich hierbei um ein multilinguales Spiel handelt wäre es naheliegend wenn UCS Kodierungen wie zb UTF-16 verwendet wird. Das würde bedeuten, dass 32x16bit = 512bit für die ID des Brustteils übertragen wird. Dazu kommt dann im schlimmsten Fall noch 3x32x16bit für die Farben (1536 bit) und dazu noch eine Verzauberung (Stäbe können ja Leuchten usw). Macht dann also 5x32x16bit = 2560bits / Teil. Im schlimmsten Fall macht das also bei 7 Rüstungsteilen und 4 Waffen 28160bits => 27,5kBit ohne dass Werte wie Level, Name, Allianz und Co übertragen wurden. Das ganze dann natürlich pro Spieler.

Ich habe noch nicht nachgesehen, aber eigentlich müsste man es sehen/merken wenn gewaltige Datenmengen über die Netzwekkarte gehen. Muss ich bei Gelegenheit vielleicht mal machen.

Das würde sich ja aber testen lassen indem man einen Satz von Spielern nimmt und die "nackt" im PvP Zergen lässt. Würde es eventuell schon was bringen wenn die Spieler ihre Helme weglassen oder sind Haare schlimmer als Helme (Weil die Bewegung der Haare gleich mit übertragen wird) und es wäre besser die Helme zu aktivieren?

Es ist sehr schade dass Zenimax sich dazu nicht äußert woran genau es denn nun eigentlich hakt. Eventuell würde sich ja eine einfache Lösung finden lassen mit der alle Leben können.

Eventuell muss man sich auch überlegen ob man nicht gleich die Server clustert. Wenn googel versuchen würde alle Anfragen über einen Server / Kontinent zu leiten dann wäre das auch nicht machbar. Natürlich ist eine Suchmaschiene etwas anderes als ein Spiel. Aber ich denke mit der richtigen Technik lassen sich auch Server clustern und synchronisieren.

Damit hast du natürlich Recht.
Meine Regierung hat anfang der Woche auch angefangen zu Spielen.
Habe mir da die Zeit genommen mit ihr den Vorspann anzuschauen direkt nach der Charakter Erstellung.

Was sieht man? Charaktäre, die in super genialen Rüstungen (Noch nie gesehen den Stil) gegen Monsterhorden von zig hundert Monstern kämpfen.
Also ich habe in dem Spiel noch keine solche Monsterhorden gesehen. Geschweige denn so schicke Rüstungen.
Da hatte ich mir auch mehr von dem Spiel versprochen. Das Maximale was man so hat sind vielleicht mal 10 oder 20 Gegner aber keine hunderte.

Ein 200 vs 300 vs 250 sollte auf einem Haufen schon stattfinden können.
Wenn es keine 20.000 vs 21.000 vs 23.000 sein können, dann hat man da vielleicht ein Verständnis dafür.
Aber bei so läppischen Spielerzahlen sollte das eigentlich machbar sein.