• Howdy, Freund! Du scheinst neu hier zu sein. Warum erstellst du dir nicht einen Forenaccount, um mitdiskutieren zu können? Du kannst dich hier registrieren.
    Du hast schon einen Forenaccount? Dann kannst du dich hier einloggen. Viel Spaß!

    Was denkst du zum Beispiel über diese Themen?

Feedback Eventwelt Storymodus TWTimes

jugolas

Vampir
Community-Manager
Die Systemadministratoren arbeiten daran den Server wieder zum laufen zu bringen, da allerdings heute in Hamburg Feiertag ist, ist gerade nur der Bereitschaftsdienst da.
 

jugolas

Vampir
Community-Manager
Ich habe leider schlechte Nachrichten: Leider hat es die Datenbank zerschossen, weswegen wir einen Entwickler benötigen würden um das Problem zu beheben. Diese sind leider gerade nicht erreichbar.
Im Normalfall könnte der Server mit den Boni umgehen, allerdings wurden durch die Tatsache, dass der Server schon seit einem Monat läuft und ihr schon einen gewissen Entwicklungsstand hattet, die Grenzen für erreichbares Geld und Erfahrung gesprengt.
Wir kriegen die Welt daher dieses Wochenende leider nicht mehr zum laufen. Das tut uns wirklich sehr Leid. :(
 

FantaSixty

Pubquiz-Champion 2023
Ehemaliges Teammitglied
Montag wäre diese Welt ohnehin geschlossen geworden. Also, dann war es ein unschöner und plötzlicher Servertod, aber die Welt bleibt uns ja trotzdem in guter Erinnerung. Nicht nötig, hier noch Alarm zu machen wegen einige wenige Minuten Spielzeit.
Auch hier deswegen noch ein Danke an alle Organisatoren, Mitstreiter und Mitspieler. ;)
 

Tiltlord

Holzmagier
Für die Rangliste hats doch eh keinen Einfluss mehr, insofern so what :) Eine schöne Eventwelt und vielen Dank für die Mühen der GMs!
 

xyzabcd

Goldgräber
Der Server hatte sich ausgerechnet, dass wir bis zum frühen Abend mehr Dollars auf den Konten haben würden als es Atome im Universum gibt, und hat sich geweigert, das zu unterstützen. Kann ich irgendwie verstehen :-)
 

BilllytheKid

Entdecker
Kann ich ja nicht glauben das ein paar Zahlen einen Server lahm legen, vor allem weil die frequentierung wohl deutlich niederiger heute war als in den letzten Tagen. Wie machen den das die anderen Spiele anbieter mit ihren viel aufwendigeren Spielen?
 

xyzabcd

Goldgräber
Kann ich ja nicht glauben das ein paar Zahlen einen Server lahm legen, vor allem weil die frequentierung wohl deutlich niederiger heute war als in den letzten Tagen. Wie machen den das die anderen Spiele anbieter mit ihren viel aufwendigeren Spielen?
Ich spekuliere jetzt einfach mal:

1. in der Datenbank ist ein Limit für die Größe von bestimmten Feldern wie Erfahrungspunkten, Kontostand und Bargeld drin. Das ist so gut wie sicher, weil nahezu jeder Programmierer da irgendwo ein Limit setzt. Das kann ein fixes Limit sein (a la "xp NUMERIC(10)") oder ein Constraint ("xp NUMERIC CHECK (xp <= 9999999999"). So ein Limit setzt man, um Fehler abzufangen, weil extrem hohe Werte nach menschlichem Ermessen nicht passieren können.
Ich weiß natürlich mangels Insiderwissen nicht, welches Limit der Knackpunkt war, ich verwende unten einfach mal die Erfahrungspunkte.

2. durch die extremen Zusatzboni, die heute morgen eingeschaltet wurde, kam das Feld für einen der Spieler nahe an die Limits. Eben jener Spieler hat dann noch mal 4 oder 9 Jobs abgeschickte.
"extrem" = "eben war ich doch noch 242, und das hat mich schon gewundert. Warum bin ich jetzt auf Level 250?"
Ich hab' da in die Rangliste geschaut, und ich meine, dass der Zähler für #1 kurz vor der nächsten Stelle war. Kurz darauf … bumm.

3. 15 Sekunden später sieht das Programm, das da irgendwo im Hintergrund läuft, dass da ein Job fertig ist, und noch nicht verarbeitet ist.
Es sieht, dass es 2,3 Millionen Erfahrungspunkte eintragen muss, und versucht das dann auch ("UPDATE schlagmichtot SET xp=xp+2300000 WHERE character_id=12345").

4. Die Datenbank sagte dazu, "Fehler. Will ich nicht, darf ich nicht, verletzt Constraint irgendeinname",

5. Das Programm bricht ab.
Was soll das Programm auch anderes machen? Es muss die Sachen in der richtigen Reihenfolge verarbeiten, denn sonst bekommt nicht der Spieler, der als erstes Waupees edle Hose fand, die kleine Ehrung dafür, der erste zu sein, sondern ein Anderer (bei Duellen könnten falsche Reihenfolgen auch interessante Auswirkungen haben.

6. Das Programm wird neu gestartet, und fängt bei #3 wieder ein.

7. Das arme Schwein von Bereitschaftsmensch, das auf einen ruhigen Freitag gehofft hat, darf sich nun darum kümmern. Es sieht dann irgendwann und irgendwo eine Fehlermeldung, die nach Datenbank aussieht, und denkt sich, da muss jemand ran, der sich auskennt.
Was übrigens völlig richtig ist.

8. Montag morgen kommt jemand, der sich auskennt, zur Arbeit, sieht tausend Mails wegen freitäglichen Fehlern auf einem Eventserver, der eigentlich bis Donnerstag gehen sollte.
Die weitere Reihenfolge ist könnte so sein:

9. er wühlt sich durch die Menüs zum Button für "neu aufsetzen", klickt, und macht sich einen Tee oder Kaffee.

10. Irgendwann danach macht der ein Ticket, einen Case oder ein gibt-genug-Namen-dafür auf, und skizziert einen Lösungsweg, wie beispielsweise den contraint zu ändern.

11. Viel, viel später sagt der product owner (das kann ein Manager mit Erfahrung als Erbenzähler sein) "nein, dokumentiere einfach, dass man das nicht machen darf, und gut ist" oder "ja, darfst Du machen" oder "Super Idee, großartige Lösung, das verkaufen wir als Update 2.275".

Dasselbe passiert anderswo auch. Als normalsterblicher Programmierer hast Du ein geistiges Modell, wie das Spiel funktionieren soll, und kommst nicht auf die Idee, dass ein freundlicher GM Boni von 50000% einschaltet, damit die Leute alle Rekorde brechen können, oder genug Geld für Millionen Kisten da ist, damit endlich jemand dieses verflixten Fan-Sattel findet.
Die Wahrscheinlichkeit ist groß, dass der "jemand, der sich auskennt" aus Schritt 8 am Montag in der Küche steht und "so etwas macht man doch nicht" und "wie bescheuert können Menschen eigentlich sein?" denkt.

Stabile Softwaresysteme sind die, die mit Menschen nichts zu tun haben :-)
 

BilllytheKid

Entdecker
Aber wir hatten schon einen Speed Server mit allen Boni auf 50.000 und höher und da haben mehr Spieler gespielt und es ist auch nichts passiert.
 

GAP20

Holzmagier
Kann ich ja nicht glauben das ein paar Zahlen einen Server lahm legen, vor allem weil die frequentierung wohl deutlich niederiger heute war als in den letzten Tagen. Wie machen den das die anderen Spiele anbieter mit ihren viel aufwendigeren Spielen?
Ich spekuliere jetzt einfach mal:

1. in der Datenbank ist ein Limit für die Größe von bestimmten Feldern wie Erfahrungspunkten, Kontostand und Bargeld drin. Das ist so gut wie sicher, weil nahezu jeder Programmierer da irgendwo ein Limit setzt. Das kann ein fixes Limit sein (a la "xp NUMERIC(10)") oder ein Constraint ("xp NUMERIC CHECK (xp <= 9999999999"). So ein Limit setzt man, um Fehler abzufangen, weil extrem hohe Werte nach menschlichem Ermessen nicht passieren können.
Ich weiß natürlich mangels Insiderwissen nicht, welches Limit der Knackpunkt war, ich verwende unten einfach mal die Erfahrungspunkte.

2. durch die extremen Zusatzboni, die heute morgen eingeschaltet wurde, kam das Feld für einen der Spieler nahe an die Limits. Eben jener Spieler hat dann noch mal 4 oder 9 Jobs abgeschickte.
"extrem" = "eben war ich doch noch 242, und das hat mich schon gewundert. Warum bin ich jetzt auf Level 250?"
Ich hab' da in die Rangliste geschaut, und ich meine, dass der Zähler für #1 kurz vor der nächsten Stelle war. Kurz darauf … bumm.

3. 15 Sekunden später sieht das Programm, das da irgendwo im Hintergrund läuft, dass da ein Job fertig ist, und noch nicht verarbeitet ist.
Es sieht, dass es 2,3 Millionen Erfahrungspunkte eintragen muss, und versucht das dann auch ("UPDATE schlagmichtot SET xp=xp+2300000 WHERE character_id=12345").

4. Die Datenbank sagte dazu, "Fehler. Will ich nicht, darf ich nicht, verletzt Constraint irgendeinname",

5. Das Programm bricht ab.
Was soll das Programm auch anderes machen? Es muss die Sachen in der richtigen Reihenfolge verarbeiten, denn sonst bekommt nicht der Spieler, der als erstes Waupees edle Hose fand, die kleine Ehrung dafür, der erste zu sein, sondern ein Anderer (bei Duellen könnten falsche Reihenfolgen auch interessante Auswirkungen haben.

6. Das Programm wird neu gestartet, und fängt bei #3 wieder ein.

7. Das arme Schwein von Bereitschaftsmensch, das auf einen ruhigen Freitag gehofft hat, darf sich nun darum kümmern. Es sieht dann irgendwann und irgendwo eine Fehlermeldung, die nach Datenbank aussieht, und denkt sich, da muss jemand ran, der sich auskennt.
Was übrigens völlig richtig ist.

8. Montag morgen kommt jemand, der sich auskennt, zur Arbeit, sieht tausend Mails wegen freitäglichen Fehlern auf einem Eventserver, der eigentlich bis Donnerstag gehen sollte.
Die weitere Reihenfolge ist könnte so sein:

9. er wühlt sich durch die Menüs zum Button für "neu aufsetzen", klickt, und macht sich einen Tee oder Kaffee.

10. Irgendwann danach macht der ein Ticket, einen Case oder ein gibt-genug-Namen-dafür auf, und skizziert einen Lösungsweg, wie beispielsweise den contraint zu ändern.

11. Viel, viel später sagt der product owner (das kann ein Manager mit Erfahrung als Erbenzähler sein) "nein, dokumentiere einfach, dass man das nicht machen darf, und gut ist" oder "ja, darfst Du machen" oder "Super Idee, großartige Lösung, das verkaufen wir als Update 2.275".

Dasselbe passiert anderswo auch. Als normalsterblicher Programmierer hast Du ein geistiges Modell, wie das Spiel funktionieren soll, und kommst nicht auf die Idee, dass ein freundlicher GM Boni von 50000% einschaltet, damit die Leute alle Rekorde brechen können, oder genug Geld für Millionen Kisten da ist, damit endlich jemand dieses verflixten Fan-Sattel findet.
Die Wahrscheinlichkeit ist groß, dass der "jemand, der sich auskennt" aus Schritt 8 am Montag in der Küche steht und "so etwas macht man doch nicht" und "wie bescheuert können Menschen eigentlich sein?" denkt.

Stabile Softwaresysteme sind die, die mit Menschen nichts zu tun haben :-)
"Dasselbe passiert anderswo auch"naja, das wage ich stark zu bezweifeln. Man erkennt recht deutlich, dass die Systeme hinter "The West" technisch längst in die Jahre gekommen sind und das lässt sich sogar ohne Insiderwissen sehen. Das Spiel läuft auf einer klassischen PHP/MySQL-Struktur aus den 2000ern, was man an den typischen Aufrufen wie game.php?window=......und dem trägen, synchronen Verhalten merkt.
Moderne Spiele arbeiten längst mit API-Strukturen, asynchronen Prozessen und dynamischen Feldgrößen. "The West"dagegen nutzt noch feste Datenbankdefinitionen und sequentielle Abläufe, da reicht schon ein Eventbonus zu viel, und das ganze System legt sich schlafen.
Bei CS2, Battlefield oder GTA etc. laufen tausende Server gleichzeitig unter massiv höherer Belastung, ohne dass sie wegen einer zu großen Zahl komplett abrauchen. Das sind andere Kaliber , moderne Engines mit Fehlerabfangroutinen, dynamischen Limits und stabilen Serverstrukturen. Wenn dort etwas crasht, dann wegen echter Systemlast, nicht wegen einer XP-Zahl mit zu vielen Nullen.
Kurz gesagt: Das Problem liegt nicht bei den Spielern oder beim "menschlichen Faktor", sondern an einer alten technischen Basis, die einfach nicht mehr für heutige Events oder Boni ausgelegt ist. Also nein,"anderswo" passiert das nicht in dieser Form. Nur bei Systemen, die technisch in der Vergangenheit stecken geblieben sind.
 

xyzabcd

Goldgräber
"Dasselbe passiert anderswo auch"naja, das wage ich stark zu bezweifeln. Man erkennt recht deutlich, dass die Systeme hinter "The West" technisch längst in die Jahre gekommen sind und das lässt sich sogar ohne Insiderwissen sehen. Das Spiel läuft auf einer klassischen PHP/MySQL-Struktur aus den 2000ern, was man an den typischen Aufrufen wie game.php?window=......und dem trägen, synchronen Verhalten merkt.

Ist das so? Dass da PHP im Einsatz ist… ja, klar. Aber was das PHP tut? Wieviel Prozent der Arbeit wird dort erledigt, und wieviel Prozent in irgendwelchen nachgelagerten Diensten? Das könnte ich nicht mal raten (man kann übrigens mit Roadrunner oder Frankenphp PHP vortäuschen, und praktisch alles in go erledigen).
btw: Ich meine, da liefe Postgres. Was übrigens beides gut genug wäre.

Trägers, synchrones Verhalten? Träge lass' ich gelten, das kommt vor (ob das an Programmiersprache, Datenbank, Netzwerkanbindung oder einfach zu klein dimensionierten Serverinstanzen liegt, weiß ich nicht).
Aber synchron? Technisch gesehen sind sämtliche Anfragen vom Browser an den Server asynchron, und absolute alle Multiplayer-Spiele müssen synchronisieren.

Ach so, die "klassische PHP/MySQL-Struktur" hat es nie gegeben. Das große Problem mit den PHP-Seiten und -Services aus den 2000ern ist, dass jeder seine eigenen "Strukturen" gemacht hat, oft an jedem Wochentag eine Neue. Wenn das was klassisch war, dann hemdsärmelige Strukturlosigkeit.

Moderne Spiele arbeiten längst mit API-Strukturen, asynchronen Prozessen und dynamischen Feldgrößen. "The West"dagegen nutzt noch feste Datenbankdefinitionen und sequentielle Abläufe, da reicht schon ein Eventbonus zu viel, und das ganze System legt sich schlafen.
TW benutzt asynchrone Prozesse (sieht man an einigen Stellen deutlich), hat APIs (keine irgendwie schönen, aber immerhin), und sequentielle Abläufe sind völlig richtig, wenn man Dinge sequentiell verarbeiten muss, und dynamische Feldgrößen … sorry, da wäre trotzdem eine Sicherheitsabfrage drum. Mal ganz abgesehen von der Frage, ob dynamische Feldgrößen Sinn machen würden.
Und "das ganze System legt sich schlafen" ist eindeutig falsch, weil 99% der Spieler überhaupt nichts gemerkt haben, nur so ein paar Spieler auf einer einzelnen kleinen Spielwelt. Alles Andere lief reibungslos weiter.

Bei CS2, Battlefield oder GTA etc. laufen tausende Server gleichzeitig unter massiv höherer Belastung, ohne dass sie wegen einer zu großen Zahl komplett abrauchen. Das sind andere Kaliber , moderne Engines mit Fehlerabfangroutinen, dynamischen Limits und stabilen Serverstrukturen. Wenn dort etwas crasht, dann wegen echter Systemlast, nicht wegen einer XP-Zahl mit zu vielen Nullen.
GTA Online hatte in den ersten Wochen so massive Stabilitätsprobleme, dass die ihren Spielern eine ziemlich dicke Entschuldigung gaben, und das lag längst nicht nur daran, dass die von der Spielerzahl überrascht waren und Lastprobleme hatten.
CS2 ist dem Vernehmen nach zumindest anfangs auch nicht immer performant gewesen (und das obwohl gegenüber CS:GO einige Features gestrichen worden waren).

Und woran Serverabstürze anderswo liegen (die es auch gibt), wirst Du sowieso nicht erfahren. Das erzählen die nämlich alle nicht (übrigens nicht nur in der Spielbranche - das Phänomen, die Ursachen gerne zu verschweigen, ist in der ganzen EDV unheimlich beliebt. Also da, wo man damit durchkommt).

"Tausende Server" bedeutet nichts, nicht im Zeitalter der Microservices und der Cloud. In den meisten Fällen kann man von draußen gar nicht sehen, wie etwas intern realisiert ist, und was von draußen wie ein Server aussieht, kann innendrin aus hundert kleinen Dingern aufgebaut sein. Das siehst Du nicht. Ich betreue eine Datenbank, an der ein dicker, umsatzkräftiger Internetshop und tausende Straßengeschäfte hängen. Je nachdem, mit wem ich rede, beschreibe ich das von "wir haben da einen Datenbankserver und ein Ersatzsystem" bis hin zu "da laufen einige hundert kleine bis große Dienste auf einer Virtualisierungsplattform auf Basis von soundsoviel physikalischen Servern".

btw: Ein (nicht: der einzige) Grund, warum man auf tausende Server setzt ist, dass die unausweichlichen Instabilitäten immer nur ein Promille der Benutzer treffen.
Wenn einmal am Tag alle eine Million Spieler für fünf Minuten raus fliegen, regen sich alle rauf.
Wenn 1000 mal am Tag 100 Spieler für 5 Minuten raus fliegen, sagen 99% "bei uns funktioniert alles wunderbar".
Obwohl die Situation im Grunde die gleiche ist.


Kurz gesagt: Das Problem liegt nicht bei den Spielern oder beim "menschlichen Faktor", sondern an einer alten technischen Basis, die einfach nicht mehr für heutige Events oder Boni ausgelegt ist. Also nein,"anderswo" passiert das nicht in dieser Form. Nur bei Systemen, die technisch in der Vergangenheit stecken geblieben sind.
Wo habe ich behauptet, dass das Problem bei den Spielern läge?
Wo habe ich behauptet, das Problem läge beim "menschlichen Faktor"?
Wo habe ich behauptet, dass die Technik nicht veraltet wäre? Die ist überaltert, ich sehe das nur an anderen Stellen als Du (und nichts wird besser, wenn ich dauernd wiederkäue), zum Beispiel "Schicksal".
Die technische Basis ist mit ziemlich hoher Wahrscheinlichkeit problemlos in der Lage, mit solchen Boni umzugehen, denn mit hoher Wahrscheinlichkeit ist es genau eine Sicherheitsabfrage, die da Probleme macht. So etwas sagt rein gar nichts über die technische Basis.
 

GAP20

Holzmagier
Ist das so? Dass da PHP im Einsatz ist… ja, klar. Aber was das PHP tut? Wieviel Prozent der Arbeit wird dort erledigt, und wieviel Prozent in irgendwelchen nachgelagerten Diensten? Das könnte ich nicht mal raten (man kann übrigens mit Roadrunner oder Frankenphp PHP vortäuschen, und praktisch alles in go erledigen).
btw: Ich meine, da liefe Postgres. Was übrigens beides gut genug wäre.

Trägers, synchrones Verhalten? Träge lass' ich gelten, das kommt vor (ob das an Programmiersprache, Datenbank, Netzwerkanbindung oder einfach zu klein dimensionierten Serverinstanzen liegt, weiß ich nicht).
Aber synchron? Technisch gesehen sind sämtliche Anfragen vom Browser an den Server asynchron, und absolute alle Multiplayer-Spiele müssen synchronisieren.

Ach so, die "klassische PHP/MySQL-Struktur" hat es nie gegeben. Das große Problem mit den PHP-Seiten und -Services aus den 2000ern ist, dass jeder seine eigenen "Strukturen" gemacht hat, oft an jedem Wochentag eine Neue. Wenn das was klassisch war, dann hemdsärmelige Strukturlosigkeit.


TW benutzt asynchrone Prozesse (sieht man an einigen Stellen deutlich), hat APIs (keine irgendwie schönen, aber immerhin), und sequentielle Abläufe sind völlig richtig, wenn man Dinge sequentiell verarbeiten muss, und dynamische Feldgrößen … sorry, da wäre trotzdem eine Sicherheitsabfrage drum. Mal ganz abgesehen von der Frage, ob dynamische Feldgrößen Sinn machen würden.
Und "das ganze System legt sich schlafen" ist eindeutig falsch, weil 99% der Spieler überhaupt nichts gemerkt haben, nur so ein paar Spieler auf einer einzelnen kleinen Spielwelt. Alles Andere lief reibungslos weiter.


GTA Online hatte in den ersten Wochen so massive Stabilitätsprobleme, dass die ihren Spielern eine ziemlich dicke Entschuldigung gaben, und das lag längst nicht nur daran, dass die von der Spielerzahl überrascht waren und Lastprobleme hatten.
CS2 ist dem Vernehmen nach zumindest anfangs auch nicht immer performant gewesen (und das obwohl gegenüber CS:GO einige Features gestrichen worden waren).

Und woran Serverabstürze anderswo liegen (die es auch gibt), wirst Du sowieso nicht erfahren. Das erzählen die nämlich alle nicht (übrigens nicht nur in der Spielbranche - das Phänomen, die Ursachen gerne zu verschweigen, ist in der ganzen EDV unheimlich beliebt. Also da, wo man damit durchkommt).

"Tausende Server" bedeutet nichts, nicht im Zeitalter der Microservices und der Cloud. In den meisten Fällen kann man von draußen gar nicht sehen, wie etwas intern realisiert ist, und was von draußen wie ein Server aussieht, kann innendrin aus hundert kleinen Dingern aufgebaut sein. Das siehst Du nicht. Ich betreue eine Datenbank, an der ein dicker, umsatzkräftiger Internetshop und tausende Straßengeschäfte hängen. Je nachdem, mit wem ich rede, beschreibe ich das von "wir haben da einen Datenbankserver und ein Ersatzsystem" bis hin zu "da laufen einige hundert kleine bis große Dienste auf einer Virtualisierungsplattform auf Basis von soundsoviel physikalischen Servern".

btw: Ein (nicht: der einzige) Grund, warum man auf tausende Server setzt ist, dass die unausweichlichen Instabilitäten immer nur ein Promille der Benutzer treffen.
Wenn einmal am Tag alle eine Million Spieler für fünf Minuten raus fliegen, regen sich alle rauf.
Wenn 1000 mal am Tag 100 Spieler für 5 Minuten raus fliegen, sagen 99% "bei uns funktioniert alles wunderbar".
Obwohl die Situation im Grunde die gleiche ist.



Wo habe ich behauptet, dass das Problem bei den Spielern läge?
Wo habe ich behauptet, das Problem läge beim "menschlichen Faktor"?
Wo habe ich behauptet, dass die Technik nicht veraltet wäre? Die ist überaltert, ich sehe das nur an anderen Stellen als Du (und nichts wird besser, wenn ich dauernd wiederkäue), zum Beispiel "Schicksal".
Die technische Basis ist mit ziemlich hoher Wahrscheinlichkeit problemlos in der Lage, mit solchen Boni umzugehen, denn mit hoher Wahrscheinlichkeit ist es genau eine Sicherheitsabfrage, die da Probleme macht. So etwas sagt rein gar nichts über die technische Basis.
Du hast in einigen Punkten recht, gerade was asynchrone Prozesse und API-Reste betrifft, das kann man von außen schwer beurteilen. Trotzdem bleibt der Kern meines Arguments bestehen:
The West läuft spürbar auf einer alten Codebasis, die man klar an der Struktur, Performance und Fehleranfälligkeit erkennt. Ob die Datenbank nun MySQL oder Postgres ist, ändert daran nichts , entscheidend ist, wie sie eingebunden ist und wie eng Logik und Datenbank noch miteinander verknüpft sind.
Moderne Systeme trennen diese Schichten sauber, haben Fehlertoleranzen und rollen Transaktionen automatisch zurück, anstatt den Prozess komplett zu blockieren. Wenn ein einzelner Eventbonus eine Welt lahmlegt, zeigt das eben, dass das System empfindlich auf Grenzwerte reagiert und das ist kein Zeichen moderner Architektur.
Klar, GTA oder CS hatten anfangs Performanceprobleme aber das waren Skalierungsfragen bei Millionen gleichzeitigen Spielern, keine Datenbankfehler wegen interner Limits. Heute laufen diese Spiele stabil, weil ihre Systeme modern, modular und fehlertolerant gebaut sind. Das ist ein anderer Maßstab als ein einzelner Eventserver mit einer fehlerhaften Abfrage.
Ich sag’s neutral: The West funktioniert grundsätzlich, aber es basiert auf einem Systemdesign aus einer Zeit, wo solche Limits völlig normal waren und das merkt man heute einfach.
 

GAP20

Holzmagier
Du hast in einigen Punkten recht, gerade was asynchrone Prozesse und API-Reste betrifft, das kann man von außen schwer beurteilen. Trotzdem bleibt der Kern meines Arguments bestehen:
The West läuft spürbar auf einer alten Codebasis, die man klar an der Struktur, Performance und Fehleranfälligkeit erkennt. Ob die Datenbank nun MySQL oder Postgres ist, ändert daran nichts , entscheidend ist, wie sie eingebunden ist und wie eng Logik und Datenbank noch miteinander verknüpft sind.
Moderne Systeme trennen diese Schichten sauber, haben Fehlertoleranzen und rollen Transaktionen automatisch zurück, anstatt den Prozess komplett zu blockieren. Wenn ein einzelner Eventbonus eine Welt lahmlegt, zeigt das eben, dass das System empfindlich auf Grenzwerte reagiert und das ist kein Zeichen moderner Architektur.
Klar, GTA oder CS hatten anfangs Performanceprobleme aber das waren Skalierungsfragen bei Millionen gleichzeitigen Spielern, keine Datenbankfehler wegen interner Limits. Heute laufen diese Spiele stabil, weil ihre Systeme modern, modular und fehlertolerant gebaut sind. Das ist ein anderer Maßstab als ein einzelner Eventserver mit einer fehlerhaften Abfrage.
Ich sag’s neutral: The West funktioniert grundsätzlich, aber es basiert auf einem Systemdesign aus einer Zeit, wo solche Limits völlig normal waren und das merkt man heute einfach.
Die drei Spiele habe ich nur als Beispiel genannt die sind mir auf die Schnelle eingefallen. Es gibt tausende moderne Online-Spiele, von kleinen Indies bis zu AAA-Titeln, die unter ständiger Last laufen ohne dass ein kompletter Server wegen einer Zahl oder einem Eventbonus abstürzt.
 
Oben