Star Citizen: Star Citizen Live "Tech Talk w/ Benoît Beauséjour"

Das ist der aktuelle Stand

• Auch wenn es immer noch zum Teil größere Probleme bei bestimmten Features des Spiels gibt und noch viel Arbeit vor ihnen liegt, insgesamt ist man bei Cloud Imperium Games mit dem aktuellen Zwischenstand zufrieden.
• Gerade in Bezug auf Star Citizen Alpha 3.23 / 3.24 und der heutigen Version 4.0 ist der Unterschied riesig
  • Damals: Ein Sternensystem, Single‑Server pro Spielwelt, Server komplett ausgelastet, einstellige Server‑FPS, maximal 100 Spielende gleichzeitig pro Server.
  • Heute: Statisches Server-Mesh aktiv. Die Server-FPS liegt im Durchschnitt bei 20 FPS - deutlich bessere Performance. Aktuell bis zu 650 gleichzeitig spielende Nutzer pro Server (Tests mit bis zu 800).
• Dank der multiplen Server pro Spielwelt lässt sich nun auch deutlich besser analysieren, wo es zu Leistungseinbrüchen kommt und wo dringend nachgebessert werden muss.
• In den vergangenen Monaten wurden viele neue Prozesse angestoßen, um die Spielqualität langfristig zu verbessern und vor allem kritische Bugs so schnell wie möglich zu beheben. Bei CIG ist man mit den deren Ergebnissen derzeit sehr zufrieden.
  • Hero Squad
    • Im Februar noch "Joker Card“ genannt.
    • Wenn kritische Probleme auftreten, wird ein Squad aus allen notwendigen Personen gebildet, unabhängig davon, woran sie zuvor gearbeitet haben; dieses Squad konzentriert sich dann auf die Behebung des Problems. Erst danach kehren die Teilnehmenden zu ihren ursprünglichen Projekten zurück.
    • Kürzlich wurde dieses Verfahren für die Frachtaufzüge angewendet, da diese beim Resource-Drive-Event gravierende Probleme offenbarten.
  • Embedded Greenlight QA
    • QA-Mitarbeitende sind nun direkt Teil eines Teams und können dort bereits vor einem Rollout den Stand testen und blockierende Probleme frühzeitig melden.
    • Ziel ist, dass Evocati-Builds bereits stabiler sind und Nacharbeiten reduziert werden.
  • Hygiene Initiative
    • Gezielte Maßnahmen zur Bereinigung und Qualitätsverbesserung der technischen Basis.
    • Dazu gehören das Entrümpeln irrelevanter oder fehlerhaft klassifizierter Log‑/Warn‑/Fehlermeldungen, das Schärfen der Log‑Level (z. B. welche Meldungen wirklich sofortiges Eingreifen erfordern) sowie die Validierung und Korrektur von Spieldaten in der Data‑Core‑Datenbank (z. B. fehlerhafte Schema‑Einträge oder ungültige Objektdefinitionen).
    • Ziel ist es, weniger "Rauschen“ in den Logs zu haben, damit echte Fehler sichtbar werden.
  • Stabilitäts-Score
    • Dabei handelt es sich um eine interne Metrik zur automatischen Bewertung von Builds.
    • Dazu werden verschiedene Faktoren wie Disconnections, Laufzeit und Concurrency herangezogen.
    • Labels wie optimal/stabil/volatile/kritisch/instabil helfen anschließend bei Deployment-Entscheidungen.
  • Branch- & Release-Strategien
    • Ziel dieses Prozesses ist eine stärkere Trennung zwischen Engine- oder Tooling-Updates und reinen Content-Patches.
    • Dadurch sollen weniger destabilisierende Änderungen in Live-Patches auftreten.
• Auch wenn er in diesem Jahr bisher seltener als ursprünglich angekündigt zum Einsatz kam, bleibt der Tech-Preview-Channel ein sehr wichtiger Faktor in der Entwicklung von Star Citizen. In dieser isolierten Umgebung sollen große Änderungen am Spiel unter nahezu Live-Bedingungen getestet werden, ohne den Live-Stand in irgendeiner Form zu gefährden.
  • Aktuelle Tests umfassen die Vulkan‑Integration, grafische Verbesserungen (u. a. Beleuchtung und Texturen), Optimierungen der KI sowie Verbesserungen am Missionssystem (Mission v2).
  • Aktuelle Planungen sehen vor, dass das Engineering-Gameplay (ursprünglich für Alpha 4.0 vorgesehen) noch vor Jahresende in den Tech-Preview-Channel kommt. Das ist jedoch keine Bestätigung, dass es tatsächlich passieren wird.
• Monatliche Patches sind für den Live-Betrieb teilweise vorteilhaft, stellen das Team aber vor große Herausforderungen. Außerdem führen sie dazu, dass wir den Tech-Preview- oder PTU-Channel seltener nutzen, um Funktionen vor ihrem eigentlichen Release zu testen, weil wir auf dem Live-Build bereits mehr als genug zu tun haben. Es ist jedoch notwendig, dass ausreichend von uns Inhalte vor dem Release testen, damit diese so fehlerfrei wie möglich live gehen. Diesen Faktor wird CIG in die Planung für das kommende Jahr einbeziehen.
• Im bisherigen Jahr ist nicht nur die Zahl der gleichzeitig aktiven Spielenden gestiegen, sondern auch die Länge ihrer Sessions.
• Squadron 42 ist weiterhin fest für 2026 eingeplant, wird auf der diesjährigen CitizenCon Direct jedoch kein Thema sein. Alle, die aktuell an der Finalisierung des Spiels beteiligt sind, sollen sich vollständig darauf konzentrieren. Sobald die Marketingkampagne beginnt, werden wir mehr als genug über das Spiel erfahren.

Frachtaufzüge

• Die Frachtaufzüge waren ursprünglich nicht für 2025 geplant. Rückblickend (und das gibt das Team selbst zu) war dies jedoch ein Fehler seitens CIG.
• Gerade beim Resource-Drive-Event sind viele gravierende Probleme aufgetreten:
  • So konnten wir Aufzüge mit Objekten blockieren. Sobald ein Gegenstand zum Beispiel auf dem Dach eines Aufzugs platziert wurde, war dieser vollständig blockiert. Zusätzlich gab es Möglichkeiten, die Aufzugstür zu blockieren.
    • Dies hängt damit zusammen, dass viele Gegenstände einen größeren physikalischen Bereich einnehmen, als sie in ihrer sichtbaren Größe erscheinen. Dadurch konnten bestimmte Objekte, wie Medpens, die Plattform verklemmen, obwohl der Gegenstand selbst nicht sichtbar war. Das wurde natürlich sofort für Exploits ausgenutzt und führte zum Fiasko beim Resource-Drive-Event. Mittlerweile gibt es deutlich mehr Prüfungen, um solche Vorfälle zu reduzieren.
  • Eines der weiteren Probleme mit Frachtaufzügen war, dass der Aufzug aus zwei Komponenten besteht: dem Terminal und der Plattform. Das Terminal beherbergt den Manager, die Plattform ist diesem untergeordnet.
    • Es gab ein Problem, bei dem diese Komponenten getrennt wurden, je nachdem, wie ein Bereich ein- oder ausgestreamt wurde - nämlich wenn dies nicht gleichzeitig geschah. In diesem Fall war der Ort tot und die Komponenten fanden nie wieder zusammen.
    • Das Problem wurde mittlerweile behoben.
  • Aktuell besteht noch das Problem, dass Missionengegenstände zwar erfolgreich über den Frachtaufzug abgegeben werden, diese jedoch nicht für die Mission gezählt werden und die Mission anschließend teilweise blockiert ist.
    • Dies hängt jedoch nicht unbedingt mit dem Frachtaufzug zusammen, sondern eher mit der Kombination verschiedener Systeme, die nicht korrekt miteinander synchronisiert sind.
    • CIG analysiert das derzeit noch; ein Fix wird daher voraussichtlich noch etwas dauern.
• Eine Sache, die CIG bei den Frachtaufzügen wirklich gelernt hat, ist, dass deutlich mehr Multiplayer-Tests nötig sind - nicht nur im PTU, sondern auch als Teil der allgemeinen Tests.

Transit-System

• Dieses System betreibt Aufzüge (jedoch keine Frachtaufzüge) und die öffentlichen Verkehrsmittel in den Landezonen. Die bisherige Integration kommt selbst bei den Entwickelnden von Cloud Imperium Games nicht gut an.
• Seit Anfang des Jahres gibt es ein Hero Squad dafür, bestehend aus einigen sehr erfahrenen Entwickelnden.
• Mittlerweile wurden auch Fortschritte im Live-Betrieb erzielt:
  • Es sollten keine Wagen mehr verloren gehen; falls doch, wird dies recht schnell automatisch behoben.
  • Doppeltüren treten mittlerweile sehr selten auf.
  • Trotzdem gibt es noch immer gravierende Probleme, etwa viel zu lange Zugtimer.
• Parallel zur Behebung der drängendsten Probleme wird an einer kompletten Neuentwicklung gearbeitet, die das bisherige System ersetzen soll.
  • Dabei wird ein ganz anderer Ansatz verwendet, der widerstandsfähiger und robuster sein soll.
  • In internen Builds ist dieses System bereits in der New Babbage-Landezone bei den Aufzügen zu den verschiedenen Habs im Einsatz.
  • Wenn sie mit dem System insgesamt zufrieden sind, werden sie ein Tech Preview starten und es im Verlauf des Previews auf eine komplette Landezone ausrollen (Fahrstühle und öffentliche Verkehrsmittel).
  • Das neue System wird gegenüber dem aktuellen keine sichtbaren Änderungen haben (abgesehen davon, dass es funktioniert).

LTP (Langzeit Persistenz)

• In der 3.x-Ära erschien die erste Version des LTP. Dieses wurde entwickelt, damit wir Gegenstände über Patches hinweg behalten konnten. Zunächst wurde ein sehr kleines System zum Speichern von Objekten gebaut. Der Spielserver sendete zum Beispiel Befehle, dass Charaktere eine Waffe aufgenommen oder fallen gelassen hatten, und das funktionierte zu dieser Zeit gut.
  • Es war nicht skalierbar, aber es funktionierte besser als das aktuelle System.
  • Mittlerweile ist das System deutlich umfangreicher, unter anderem durch Server-Meshing und andere Änderungen in Alpha 4.0. Es ist mit weiteren Systemen verknüpft, die jedes Mal abgefragt werden müssen, damit wir den aktuellen Status eines Gegenstands auch im LTP haben.
• Aktuell werden Gegenstände und Schiffe nur der LTP hinzugefügt, wenn sie korrekt verstaut wurden. Es gibt jedoch viele verschiedene Möglichkeiten, wie Gegenstände in diesem Spiel verstaut werden können.
  • Gerade bei Raumschiffen kommt hinzu, dass nicht nur das Schiff selbst, sondern auch seine Ausstattung und die Gegenstände im Inneren persistiert werden müssen.
  • Um sicherzugehen, sollten wir in unserem Hangar stets unsere im Spiel gekauften Raumschiffe storen, damit sie wirklich dem LTP hinzugefügt werden und nicht mit dem nächsten Patch verschwinden.
  • Bei Raumschiffen, die wir mit Echtgeld gekauft haben, ist das Problem für die einzelnen Schiffe nicht gravierend, da bei jedem Patch zum Neuaufbau der Datenbank auch auf die Store-Datenbank zurückgegriffen werden kann. Nach dessen Veröffentlichung erhalten wir zumindest eine frisch erstellte Variante des jeweiligen Fahrzeugs oder Gegenstands.
• Es wird derzeit daran gearbeitet, das LTP weiter zu verbessern, ohne die zugrunde liegende Architektur zu verändern. Ein Großteil des Online‑Teams ist damit beschäftigt; es gibt noch ein paar Punkte, die wir lösen müssen. Da es sich um Backend‑Systeme handelt, müssen diese sehr robust sein und gut getestet werden.

ATC (Flugverkehrssteuerung)

• ATC ist ein System, was für den Start oder die Landung unserer Schiffe verwendet wird. Dementsprechend ist es auch verantwortlich dafür, dass wir an viel benutzten Orten in Warteschlangen hängen, bis uns ein Landeplatz zugewiesen wurde.
• Aktuell ist man bei CIG noch dabei Informationen zu sammeln und einen finalen Plan zu erstellen.
• Was mittlerweile klar ist, die Interaktion zwischen den instanzierten Hangars und dem ATC System muss geändert werden, da ATC aktuell ansich alles verwalten. Ziel soll es sein die Zuständigkeiten aufzuteilen:
  • Bis zur Hangartür: ATC
  • Alles innerhalb des Hangars: Hangar Manager
• Da dieses System jedoch grundlegend funktioniert ist die Priorität aktuell nicht hoch, dementsprechend werden wir mit Änderungen daran wohl erst kommendes Jahr rechnen können.

NPC-Spawner

• In der Alpha 4.0 gab es viele Probleme mit Overspawning, also dem Auftauchen zu vieler NPCs oder Gegenstände. Viele dieser Probleme wurden behoben. Bei vielen Fällen stellte sich heraus, dass die Einstellung für den jeweiligen Spawner einfach falsch war.
• Dieses Jahr gab und gibt es viele Inhalte, bei denen NPC-Populationen nachspawnen. Aktuell läuft das über das Missionssystem selbst, wobei es dabei zu einem Fehler kommen kann, der eine doppelte Initialisierung auslöst und dadurch die doppelte Anzahl an Spawns zur Folge hat.
• Neben der Behebung der dringendsten Probleme arbeitet CIG nun an einem eigenständigen Bevölkerungsmanagementsystem, das für das Spawnen von NPCs in der gesamten Spielwelt verantwortlich sein wird. Dadurch erhoffen sie sich, die Probleme zu lösen. Gleichzeitig wird dieses System eine andere Logik für das Spawnen verwenden.
  • Aktuell: Ich brauche 5 NPCs, spawn mir 5 NPCs!
  • Zukünftig: Ich brauche 5 NPCs, habe ich 5 NPCs?

Ursache für Probleme mit Quantum Sprung, -Unterbrechung und Notfallbaken

• Vor der Alpha 4.0 simulierte ein Spielserver alles und verfügte dementsprechend über alle Informationen und Entitäten. Inzwischen besteht die Spielwelt aus mehreren Servern, wobei jeder Server nur die Informationen haben soll, die er für seinen Bereich wirklich benötigt.
• Ein Quantum‑Sprung kann jedoch über mehrere Server hinweg erfolgen. Für dessen Unterbrechung ist daher ein neuer Service nötig, der alle Server bedient und gleichzeitig das Gesamtsystem überwacht (von wo bis wo springt jemand, wo versucht jemand anderes genau, jemanden aus dem Sprung zu holen) - und das alles in Echtzeit.
• Auch Notfallbaken greifen darauf zurück. Ziel ist, dass diese serverübergreifend funktioniert, egal wo in der Spielwelt eine entsprechende Bake abgesetzt wird. Die Basis dafür ist bereits vorhanden; sie muss jedoch noch umgesetzt werden.

Systemübergreifende Punkte

• Bei vielen der Systeme, die derzeit überarbeitet werden, kommt zusätzlich eine Selbstheilungsfunktion zum Einsatz.
• Mittlerweile gibt es bei vielen Gegenständen einen Timer: Wenn sie nicht mehr verwendet werden, verschwinden sie nach einer bestimmten Zeit aus der offenen Welt.
  • Für Fahrzeuge liegt dieser Timer aktuell bei etwa zwei Stunden. Stellen wir also ein Fahrzeug in der offenen Welt auf einem Planeten ab und wird innerhalb von zwei Stunden nicht damit interagiert, verschwindet das Fahrzeug.
  • Als Alternative werden Bergungsaufträge genannt. Das Problem dabei ist jedoch, dass sie derzeit das Missionslog überschwemmen würden, da abgestellte Fahrzeuge die Regel und nicht die Ausnahme sind. Außerdem sind weitere Features erforderlich, damit das sinnvoll ist, zum Beispiel Crafting.
• Tägliche Wartungen lösen keine aktuellen Probleme. Sie sind derzeit nur nötig, um Konfigurationen von Meshes oder deren Servern zu ändern.
• Server-Hotfixes werden meist nicht auf bestehende Server aufgespielt. Stattdessen werden neue Server damit erstellt und alte Server abgeschaltet, ohne dass wir Spielende davon direkt etwas mitbekommen.
• Instanziierung wird bereits bei Fahrstühlen und im Hangar verwendet und wird in Zukunft eine größere Rolle spielen.