EVE Evolved: Tech Chat with CCP Chimichanga and CCP Blaraka

EVE Online: Technische Modernisierung durch Quasar-Technologien im Fokus

CCP
- 20.02.25 - 01:05:43 - 6.366 - EVE Online

• Zusammenfassung
• Original

Der 'EVE Evolved' Stream beleuchtet die Modernisierung von EVE Online durch Quasar, ein Ökosystem aus Docker, Kubernetes und Golang. Ziel ist die Ablösung des Monolithen, um Ressourcen effizienter zu verwalten, die Stabilität zu erhöhen und die Downtime zu reduzieren. Verbesserungen im Chat-System und neue Features sind geplant.

EVE Online

00:00:00

Der Stream 'EVE Evolved' fokussiert auf technologische Veränderungen, grafische Updates und Audio-Anpassungen in EVE Online, die nicht direkt spielgestalterische Änderungen betreffen. CCP Chimichanga und CCP Blaraka erläutern ihre Rollen bei CCP und die Modernisierung von EVE Online. CCP Chimichanga konzentriert sich auf die Nutzung neuer Technologien zur Lösung bestehender Probleme und die Integration dieser in EVE Online. CCP Blaraka arbeitet an der schrittweisen Modernisierung von EVE, um die Einschränkungen der alten Infrastruktur zu überwinden. Quasar dient als Oberbegriff für verschiedene Technologien wie Docker, Kubernetes und Golang, die es ermöglichen, Dienste aus dem 'Monolith' von EVE Online herauszulösen und horizontal zu skalieren. Dies ermöglicht es, Ressourcen effizienter zu verwalten und die Stabilität des Spiels zu erhöhen, indem einzelne Komponenten isoliert werden. Ein konkretes Beispiel ist die problemlose Bereitstellung von Erweiterungen, bei denen im Bedarfsfall zusätzliche Hardware hinzugefügt werden kann, ohne das gesamte System zu beeinträchtigen. Quasar ist ein Ökosystem, das es mehr Ingenieuren ermöglicht, sich in verschiedenen Bereichen einzubringen und Technologien schneller zu nutzen, was zu einer höheren Dynamik führt.

Quasar wird als ein Umbrella-Begriff für moderne Technologien wie Docker, Kubernetes und Golang verwendet, die eine Plattform für die einfache Entnahme von Diensten aus dem EVE Online-Ökosystem bieten. Der Begriff 'verteilt' bezieht sich auf die Fähigkeit, Services horizontal zu skalieren, um Ressourcenprobleme zu vermeiden, die durch ein vollständig vernetztes System entstehen könnten. Statt Mikroservices, die oft schwer zu definieren sind, konzentriert man sich auf Domain Services, wie z.B. einen Service speziell für Souveränität, der alle zugehörigen Funktionen bündelt. Der Vorteil der Ausgliederung aus dem Monolithen besteht darin, dass mehr Ingenieure in verschiedenen Bereichen arbeiten können und Technologien schneller eingesetzt werden können. Dies führt zu einer höheren Dynamik und ermöglicht es, Komponenten des Spiels zu trennen, sodass Probleme in einem Bereich nicht den gesamten Cluster beeinträchtigen. Die Isolierung von Komponenten ermöglicht es auch, einzelne Teile bei Bedarf horizontal zu skalieren, ohne das gesamte System zu beeinflussen. Durch die Trennung von Services können Fehlerbehebungen schneller bereitgestellt werden, ohne den gesamten Cluster neu starten zu müssen. Die separate Services erleichtern die Optimierung, Modifizierung und Änderung des Backend-Codes durch klare Schnittstellen.

Die ursprüngliche Server-Tick-Rate von EVE Online betrug 1 Hz, um den Anforderungen von Spielern mit langsamen 56k-Modems gerecht zu werden. Bei der Entwicklung von Third-Party-Skins wurde beschlossen, ein neues System auf Basis von Quasar zu verwenden, um die Server nicht zusätzlich zu belasten. Dieses System ermöglichte es, Skin-Änderungen zu testen, ohne den Testserver zu beeinträchtigen, da der gesamte Datentransfer über Quasar und AWS abgewickelt wurde. Durch die Arbeit an den Skins wurde erkannt, dass deutlich mehr Daten schneller übertragen werden können als zuvor. Die Herausforderung bestand darin, ein System für Third-Party-Skins zu entwickeln und gleichzeitig die Datenübertragung effizienter zu gestalten. Quasar musste lernen, wo sich jedes Schiff befindet, um Skin-Änderungen an die entsprechenden Clients zu übermitteln. Dies eröffnete auch neue Möglichkeiten, wie das gezielte Senden von Simulationsdaten und die Entwicklung von NPC-Verhaltensweisen, die nicht auf dem EVE-Server laufen müssen. Ein weiteres Ziel war es, die Auswirkungen von Spam auf die Server zu messen und möglicherweise ein System zu entwickeln, das die Spieler beschäftigt, ohne den lokalen Chat zu überlasten.

Quasar ist mit Carbon vergleichbar mit Online-Subsystem-Modulen in der Unreal Engine, wobei Carbon ein Client des Quasar-Ökosystems ist. Der Fokus liegt zunehmend darauf, das gesamte Ökosystem als Client des Universums zu betrachten, was sich in der Weiterentwicklung des Launchers zeigt. Die Third-Party-API war der Ursprung von Quasar und wird weiterhin stark genutzt. Das kommende ESI-Blog wird sich mit der Überarbeitung und Vereinheitlichung von ESI befassen. Es gibt verschiedene Community-Plattformen für Third-Party-Entwickler, darunter Discord und Slack. Ein Wunsch aus der Community ist die Synchronisierung von Client-Einstellungen über verschiedene Computer hinweg, was durch die Entwicklung neuer Datentransfermethoden ermöglicht werden könnte. Ein weiteres Ziel ist es, die Art und Weise zu ändern, wie Daten an den Client gesendet werden, sodass nicht bei jeder Änderung an Schiffsdefinitionen ein Server- und Client-Patch erforderlich ist. Dies soll durch dynamische Verfügbarkeit von Daten für den Client erreicht werden, was sich bereits in der Lazy Loading-Funktion der UI zeigt.

Ein lange bestehender Bug, bei dem Capital Ships beim Abdocken von Player-Owned Structures im Nirgendwo landeten, wurde behoben. Die Reproduktion dieses Bugs war schwierig, selbst mit automatisierten Tools. Freiwillige des Interstellar Service Department (ISD) halfen bei der Identifizierung des Problems. Der Fix wurde mithilfe eines neuen Feature-Flagging-Systems von Quasar implementiert, das es ermöglicht, Code im laufenden Betrieb zu testen und bei Bedarf ohne Deployment zu deaktivieren. Die Tests zur Auslieferung von Skins wurden während der gleichen Massentests durchgeführt, bei denen auch versucht wurde, den Bug zu reproduzieren. Bei der Entwicklung von Skinner wurde zunächst eine Grundlage geschaffen, um zu verfolgen, wer sich in einem Grid befindet und Informationen an Clients in diesem Grid zu senden. Während der Massentests gab es einige Probleme, die jedoch gelöst werden konnten. Die Entwicklung von Skinner war eine Erfolgsgeschichte, die viele Möglichkeiten für zukünftige Entwicklungen eröffnet.

Es wird über technische Innovationen diskutiert, die zur Reduzierung von Time Dilation beitragen könnten. Der Wechsel zu Python 3 hat bereits zu einer Leistungssteigerung von 23% geführt. Weitere Verbesserungen werden durch die Optimierung von Serialisierung, Übertragung und Multiplexing von Nachrichten erwartet. Durch die Auslagerung von Simulationsdaten vom EVE-Server und die Nutzung von Proto-Buff für die Serialisierung, gRPC für die Übertragung und einem separaten Service für das Multiplexing könnten weitere Leistungssteigerungen erzielt werden. Es wird geschätzt, dass diese Maßnahmen zu einer Gesamtleistungssteigerung von etwa 50% führen könnten. Das nächste Ziel ist die Optimierung der Rules Engine von EVE Online. Es wird auch die Möglichkeit diskutiert, die Reaktionsfähigkeit des Clients zu verbessern, sodass Aktionen schneller ausgeführt werden und Verzögerungen reduziert werden. Das Ziel ist es, die Serverleistung so weit zu steigern, dass die Clients Schwierigkeiten haben, mitzuhalten.

Es wird die Möglichkeit von Hot Code Deployments in verschiedenen Bereichen des Spiels diskutiert, ohne dass ein vollständiger Serverneustart erforderlich ist. Es gibt verschiedene Methoden, darunter das Live-Bearbeiten von Code auf TQ unter Verwendung eines 'Cowboyhuts', was jedoch selten genutzt werden sollte. Das Quasar-Ökosystem ermöglicht es, Updates kontinuierlich auszurollen und zu testen. In Sovereignty konnten Designer Änderungen an planetarischen Ressourcen in Echtzeit vornehmen, ohne dass ein Client-Update oder Serverneustart erforderlich war. Das Ziel ist es, Designern die Möglichkeit zu geben, Änderungen per Knopfdruck zu veröffentlichen. Updates zu Quasar-Domain-Services sollten idealerweise ohne Synchronisation um 11 Uhr erfolgen, wobei Feature Flags verwendet werden, um neue Funktionen zu aktivieren. Die 11-Uhr-Tradition, die auf die tägliche Downtime zurückgeht, ist tief in der Kultur von EVE Online verwurzelt, obwohl die Notwendigkeit dafür durch moderne Technologien reduziert wurde. Es wird auch über die Experimente zur Abschaffung der Downtime diskutiert, bei denen der Server über 11 Uhr hinaus betrieben wurde, um Probleme zu identifizieren und zu beheben. Das Endziel von Quasar ist es, eine Downtime überflüssig zu machen.

Es wird betont, dass das Ziel nicht nur die Reduktion der Downtime ist, sondern vielmehr die Symptome einer größeren Errungenschaft zu behandeln. Die kulturellen und technischen Aspekte spielen eine wesentliche Rolle bei der Downtime-Problematik. Es wird untersucht, wie lange der Cluster ohne Reset laufen kann und welche anderen Bereiche im EVE-Client verbessert werden müssen. Das Ziel ist es, neue Funktionen zu entwickeln und den Designern mehr Möglichkeiten zu geben, ohne sich auf Downtime verlassen zu müssen. Ein Event, das um Mitternacht startet, soll ohne Downtime stattfinden können. Persönliche Erfahrungen mit Downtime in der australischen Zeitzone werden geteilt, wo Downtime oft mitten in der Primetime auftritt und Spieler in wichtigen Spielmomenten unterbricht. Es wird erörtert, wie sich die Meta verändert, wenn Echtzeit-Schlachten ohne Bedenkzeit möglich sind, und wie dies das Design von Spielkomponenten beeinflusst. Spawn- und Respawn-Mechaniken sollen unabhängig von Downtime funktionieren.

Das In-Game-Chat-System ist ein schwieriges Thema. Ein kürzlicher Versuch, den Chat zu verbessern, führte zu Problemen, wie langsamer Populationsrate in Systemen und Farbänderungen der Texte. Der alte Chat wurde schnell wiederhergestellt, um die Situation zu beruhigen. Der Chat war einer der ersten Dienste, der aus dem Eve-Server ausgelagert werden sollte, was aufgrund mangelnder Erfahrung zu Fehlern führte. Die Authentifizierung erfolgte weiterhin über Proxys, was zu Problemen führte. Es wurden Verbesserungen vorgenommen, um eine stabilere Umgebung zu schaffen. Nun wird versucht, das Konzept der Kommunikation und Informationsbeschaffung zu entkoppeln, um Designern mehr Möglichkeiten zu geben. Dies ermöglicht es, Systeme in einen verzögerten Modus zu schalten oder mehr Spieler in einem lokalen Chat anzuzeigen, als tatsächlich vorhanden sind. Die Integration des Chats in Quasar ist geplant. Die Verfolgung der Spielerpositionen, die erstmals bei den Shipskins eingesetzt wurde, ist wichtig für den lokalen Chat.

Das Chat-Fenster enthält viele Informationen, wie Charakterportraits, Namen, Standings, Corporation- und Allianzmitgliedschaften, Kontaktstandings und Kriegserklärungsstandings, die alle miteinander verbunden sind. Es wird versucht, diese Komplexität zu entwirren und die Funktionalität wiederherzustellen, bevor mit neuen Iterationen begonnen wird. Es wird mit der Idee gespielt, was möglich wäre, wenn man beispielsweise Radar Scrambler hätte, die falsche Einheitenanzahlen anzeigen. Das Ziel ist es, die kleinen Stellhebel, die die Interaktion verschiedener verteilter Systeme steuern, korrekt funktionieren zu lassen. Die notwendigen Bausteine sind vorhanden und es wird erwartet, dass es funktionieren wird. Es wird gehofft, dass die Verbesserungen bald umgesetzt werden.

Es wird angekündigt, dass der dritte Teil der Eve Evolved Dev-Blog-Serie bald veröffentlicht wird und sich mit ESI beschäftigt. CCPE Stroopwafel hat einen langen, technischen Dev-Blog zu diesem Thema verfasst. Ein weiterer Massentest ist für den 28. geplant. Massentests sind sehr wertvoll, um beispielsweise den Undocked-Bug zu finden. Es wird dazu aufgerufen, am morgigen Lift to Feed teilzunehmen, einem wöchentlichen Dev-Room, in dem das Community-Team in Raumschiffen durch New Eden fliegt und beschossen wird. Es wird CCP Chimichanga und CCP Blaraka für ihre Teilnahme und die Beantwortung der Fragen gedankt. Ebenso wird dem Twitch-Chat für das Zuschauen gedankt. Es wird auf die nächsten Blogs hingewiesen.