Alpha 3.11 Obduktion Am 8. Oktober 2020 starteten wir Alpha 3.11 High Impact, das eine Reihe von neuen Features und Änderungen einführte, darunter Frachtdecks, Kraftreaktionen und die erste Stufe der umfassenderen Entfernung der Waffenstillstandszone. Im Folgenden findet ihr eine Obduktion der Senior-Entwickler selbst, die detailliert beschreibt, was geliefert wurde und was sie darüber dachten, wie es gelaufen ist.
Fahrzeug-Team
Die Fahrzeugsäule hatte mit Alpha 3.11 ein viel leichteres Viertel im Vergleich zur Stoßstangenlieferung in Alpha 3.10, aber was wir geliefert haben, hatte hoffentlich einen großen Einfluss auf das Spielerlebnis.
Herkunft 100er Serie
Das Team für Fahrzeuginhalte lieferte die Origin 100 Serie in Alpha 3.11, bestehend aus 100i, 125a und 135c. Die 100er Serie fügt dem Spiel ein alternatives Startschiff sowie einen leichten Jäger und leichten Frachtschlepper hinzu. Dies sind fantastische kleine Schiffe für neue Spieler, mit denen sie ihre Reise als Star Citizen beginnen können. Sie bieten die Möglichkeit, eine Vielzahl von Missionen zu bewältigen und die Weiten des 'Verses' zu erforschen. Raketen & Gegenmaßnahmen
Das Raketen- und Gegenmaßnahmen-Gameplay war im Laufe der Jahre in verschiedenen Zuständen gewesen und war weder auf der Seite des Angreifers noch auf der Seite des Verteidigers wirklich unterhaltsam. Unser Ziel ist es, dies mit dem Raketenoperator-Modus endgültig zu beheben, aber bis es soweit ist, haben wir beschlossen, die Zeit damit zu verbringen, Korrekturen und Iterationen im Gameplay zu implementieren, um einen Vorgeschmack darauf zu geben, was dieses Feature liefern wird. Die Hauptprobleme mit den Raketen vor Alpha 3.11 waren die folgenden:
Gegenmaßnahmen würden nur auf IR-Raketen (Flares) und EM-Raketen (Chaff) wirken Nur Flares funktionierten (manchmal und stark Server-abhängig) Es gab keine Gegenmaßnahmen für Spoof-CS-Raketen Es war extrem einfach, Raketen abzufeuern, und die Verteidigung gegen Raketen war extrem schwierig
Zuerst untersuchten wir, warum nur Fackeln funktionieren würden und Spreu nicht. Das Problem war eine Kombination aus falschen Setup-Daten bei einigen Schiffen, falschen Daten bei einigen Gegenmaßnahmen und Raketen und einem jetzt redundanten Workaround, der ursprünglich für einen bestimmten SQ42-Level erstellt wurde und das ganze Spiel über angeklopft hat.
Nachdem wir diese Probleme behoben hatten, erkannten wir, dass das Signatursystem zwei verschiedene Möglichkeiten hat, Signale zu modifizieren - entweder ein starkes Signal zu erzeugen oder alle Signale in der Umgebung zu dämpfen. Wir entschieden uns, diesen Unterschied zu nutzen, anstatt von den Piloten zu verlangen, "Maulwurfwaffen" zu spielen, indem wir die "richtige" Gegenmaßnahme für den "richtigen" Raketentyp wählten, während wir unter dem Stress standen, einige Sekunden vor dem Einschlag entscheiden zu müssen. Mit diesem Gedanken im Hinterkopf haben wir einige Spieltests mit den folgenden Änderungen durchgeführt: Fackeln würden auf alle Raketentypen wirken Chaff würde in ein Lärmfeld verwandelt werden, das alle Signaturen um das Feld herum dämpft
Sofort bewiesen die ersten Gameplay-Tests, dass dies eine viel ansprechendere Art der Raketenabwehr ist. Wir haben dann die HUD-Elemente des Raketenwarnsystems aktualisiert, ein Widget für Gegenmaßnahmen hinzugefügt und die Keybinds aktualisiert, um einen direkten Start für jede Art von Gegenmaßnahme zu ermöglichen. Die UI- und VFX-Teams sind dann eingesprungen und haben alles verschönert, die Effekte ersetzt und auch ein paar Fehler im Zusammenhang mit VFX behoben (z.B. dass Gegenmaßnahmen im PU unsichtbar sind).
Ein zukünftiger Zusatz, den wir nicht rechtzeitig für Alpha 3.11 machen konnten, war die Änderung der Namen von "Flares" und "Spreu". Beide Namen sind für Flugsimulationsgemeinschaften sehr gebräuchlich, aber wir wollen sie trotzdem umbenennen, um deutlich zu machen, dass Star Citizen unterschiedliche Konzepte zur Verteidigung gegen Raketen verwendet. Dies wird uns dazu zwingen, neue VO-Zeilen aufzunehmen, um die Schiffscomputerstimmen zu aktualisieren. Jedes Fahrzeug darf nur vier Schlösser gleichzeitig haben Nur eine Rakete kann pro Gestell gleichzeitig starten Nur ein Raketentyp (IR/EM/CS) kann gleichzeitig starten Raketen verlieren außerhalb ihres Verriegelungswinkels
Nachdem wir diese Maßnahmen eingeführt hatten, verbesserte sich das Raketenerlebnis in den ersten Tests deutlich. Das Spamming der Raketen wurde deutlich reduziert und die Meta verlagerte sich in Richtung Schiffe, die sehr nahe aneinander herankommen und Raketen auf Entfernungen abfeuern, bei denen der Verteidiger nicht einmal eine Raketenwarnung vor dem Einschlag erhalten würde. Als Ergebnis dieser unerwünschten Änderung führten wir minimale und maximale Zielreichweiten ein. Dadurch wurde das Raketen-Gameplay deutlich über die Reichweite der Geschütze hinaus ausgedehnt, so dass raketenfokussierte Schiffe wie geplant am Rand des Kampfes herumlungern konnten, während engagierte Kämpfer näher an sie herankamen. Dies ermöglichte es uns auch, den Verriegelungswinkel kleinerer Raketen zu erhöhen, so dass Schiffe wie die Constellation (die Raketen nicht nach vorne, sondern leicht aus dem Winkel feuern) wieder Raketen einsetzen konnten.
Viele dieser Änderungen (besonders an den Raketen) sind vorübergehend, um ein besseres Erlebnis zu bieten, bis der Raketenoperator-Modus bereit ist, der das Verhalten wieder ändert und/oder bestimmte Aspekte entfernt, wenn er implementiert wird. Abschließende Gedanken
Das übergeordnete Ziel, das wir im Raketenspiel erreichen wollen, ist es, sowohl den Einsatz von Raketen als auch die Verteidigung gegen Raketen tiefer und lohnender zu machen, mit einem eigenen "Slot" in der Kampfumgebung. Raketen sollen keine Alternative zu Gewehren sein, sondern taktische Waffen, und der Einsatz von Raketen soll eine bewusste Entscheidung mit Konsequenzen sein. Aus dem gleichen Grund wollen wir auch speziellen Raketenbooten, wie der Talonwürger oder dem Freelancer MIS, einen Vorteil verschaffen, wenn es darum geht, Munition einzusetzen. Diese Schiffe werden sich im offensiven Raketen-Gameplay auszeichnen, haben aber in anderen Kategorien offensichtliche Nachteile. Daher wird es in den nächsten paar Versionen mehr Iterationen zu Gegenmaßnahmen und Raketenspiel geben. Im Moment sind wir jedoch sehr froh, dass die Raketenerfahrung die Frustrationen der vorherigen Versionen hinter sich gelassen hat.
John Crewe
Fahrzeug-Direktor
Technik Leinwand-Aufkleber-System Für Alpha 3.11 lieferte das Grafikteam die zugrundeliegende Rendering-Technologie, um das 'Canvas Decal'-System zu unterstützen, das das Building Blocks-System nutzt, um Decal-Texturen zur Laufzeit zu erstellen. Diese Abziehbilder können für die Beschilderung, auf der Kleidung oder sogar für die Beschilderung von Fahrzeugen verwendet werden. Der Vorteil der Abziehbilder, die zur Laufzeit erstellt werden, ist, dass wir Spieldaten wie den Namen des Spielers verwenden oder sogar den Inhalt in die Sprache übersetzen lassen können, in der das Spiel gespielt wird. Um dieses Feature für eine breitere Verwendung in der PU skalierbar zu machen, ist das System eng mit dem Textur-Streaming-System gekoppelt, so dass die dynamischen Texturen mit der gleichen Logik wie Standardtexturen 'hereingestreamt' werden, was sicherstellt, dass wir immer ein festes Speicherbudget haben. Diese Streaminglogik stellt sicher, dass wir die gleichen Funktionen automatisch auch auf Maschinen mit niedriger Spezifikation ausführen können, indem die Texturauflösungen während des Streamens sorgfältig ausbalanciert werden, erlaubt es uns aber auch, die Texturauflösung auf leistungsstärkeren Maschinen so hoch wie möglich zu pushen. Die Integration der Canvas-Aufkleber in das Textur-Streaming führte zu mehreren Abstürzen in der PTU, die sehr schwer aufzuspüren waren und viel Zeit benötigten, um sie zu lösen. Infolgedessen haben wir einige Dokumentationen geschrieben, um zukünftigen Programmierern zu helfen, die Komplexität des Textur-Streaming-Systems zu verstehen, was besonders wichtig sein wird, da wir planen, den Code zu verallgemeinern und ihn auch für das Mesh-Streaming zu verwenden. Planeten-Technologie Auf der Seite der Planetentechnologie haben wir einige Features hinzugefügt, einschließlich Verbesserungen an den Planetenwerkzeugen. Dazu gehören neue Malpinsel, eine überarbeitete Benutzeroberfläche und kombinierte Bodenebenen- und Objektvoreinstellungen, um das Malen von Planeten noch schneller zu machen. Mit den neuen Malwerkzeugen für Planeten ging das Umweltkunst-Team durch alle Planeten und Monde im Stanton-System und malte die Bodenflächen und Objektvoreinstellungen neu. Dies macht uns auch zukunftssicher und erlaubt uns, die Vorteile der neuen Technologie an bestehenden Orten zu nutzen. Auf einer Pro-Objekt-Basis sind wir nun in der Lage, die Verschiebung der HW-Tessellation auf der über das Gelände verteilten Geologie zu unterstützen, um ihr ein detaillierteres und organischeres Aussehen zu geben. Es gab auch einige Verbesserungen im Zusammenhang mit Ozeanen und Wasser, einschließlich des Auftriebs der Bodendecke, die wir in Zukunft weiter ausbauen werden, da während dieses Release-Zyklus nicht genug Zeit war, um größere schwimmende Objekte einzuführen. In den letzten Monaten wurde viel Zeit für die weitere Erforschung und Entwicklung der Atmosphäre und des Wolkenrenderers, einschließlich des vereinheitlichten Raymarchers für die Planetenatmosphäre, aufgewendet. Wir werden mehr ins Detail gehen, sobald das System verfügbar ist. Für den Moment sagen wir einfach, dass wir an verschiedenen Algorithmen gearbeitet haben, um das Raymarchen bei einer Auflösung unter dem Bildschirm zu ermöglichen und das Rauschen und Upsampling der Ergebnisse auf die volle Auflösung zu reduzieren, um die Leistung der kostspieligen Raymarching-Vorgänge zu verbessern. Diese werden mit Reprojektionstechniken und der Bündelung von Raymarching-Anfragen für Pixel, die bei jedem Frame aktualisiert werden sollen, kombiniert, um die Leistung weiter zu verbessern. Zusätzlich unterstützt unsere bestehende Multiscatter-Lösung nun eine deutlich höhere Anzahl an Streuaufträgen, was für sehr dichte Atmosphären wichtig sein wird. Übrigens befinden wir uns jetzt in den allerersten Tagen der volumetrischen Wolken-Rendering-Forschung... Fast als Nebenprodukt dieser Arbeit haben wir verschiedene Verbesserungen an der bestehenden Atmosphären-Rendering-Technologie vorgenommen. Zuallererst wurden einige seit langem bestehende Artefakte, wie z.B. die Falschfarbenwiedergabe in der Dämmerung in der Nähe der Atmosphärenoberseite zusammen mit sehr markanten Halos um die Silhouette der dunklen Seite eines Planeten, angesprochen. Die Generierung von Nachschlagetabellen verwendet nun eine besser geeignete Methode, um Beispielstandorte für die numerische Integration über (Hemi-)Sphären zu generieren. Dies und andere Verbesserungen der numerischen Präzision führten zu genaueren Ergebnissen in diesen Tabellen bei reduziertem Rechenaufwand. Doch damit nicht genug, wir haben noch weitere visuelle Verbesserungen implementiert, die ihr hoffentlich bald genießen werdet. Eine davon ist die Auswertung, wie viel von der Sonnenscheibe sichtbar ist, wenn man berechnet, wie viel Sonnenlicht den Punkt x in der Atmosphäre erreicht. Diese Auswertung ist vollständig in das gesamte Beleuchtungssystem der Atmosphäre integriert und wirkt sich auf die direkte und indirekte Beleuchtung aus. Außerdem haben wir Unterstützung für eine Absorptionsschicht hinzugefügt. Dies erlaubt uns unter anderem, den erdähnlichen Planeten eine Ozonschicht hinzuzufügen, die die Bläue des Himmels betont und eine bessere Schattierung in der Dämmerung ermöglicht (Entfernung der gelben Tönung). Wir beziehen nun auch IRL-Radiometriedaten der extraterrestrischen Sonne mit ein, wenn wir die Lichtsimulation durchführen, anstatt von einer "rein weißen" Lichtquelle auszugehen, sowie eine ungefähre Umrechnung von spektraler Strahldichte (das Ergebnis der Atmosphärenbeleuchtungssimulation) in Leuchtdichte (die im traditionellen Sinne zur Beleuchtung der Szene verwendet wird). Schließlich haben wir die Auswertung der Sonnenstrahlung verbessert, die von Punkten außerhalb der Atmosphäre des Planeten empfangen wird. Sie wirft nun Dämmerungslicht aufgrund der atmosphärischen Streuung und dem Aufprall des Winkelradius der Sonne auf Objekte in der Halbschattenregion eines Planeten. Dies sollte einen netten Touch für Großkampfschiffe oder Monde, die Planeten umkreisen, hinzufügen. Triebwerk Auf der Motorseite wurden einige Verbesserungen vorgenommen. Wir haben unsere Compiler-Toolchain auf VS 2019 aktualisiert, was schnellere Kompilier- und Linkzeiten ermöglichen wird. Außerdem haben wir Unterstützung für den Intel SPMD Program Compiler (ISPC) hinzugefügt. Dies wird es uns ermöglichen, zielgerichteten, SSE-optimierten Code (man denke an HLSL) für Hochleistungs-CPU-Compute-Jobs zu schreiben und die CPU-Fähigkeiten auf jeder einzelnen Maschine, auf der der Code läuft, voll auszunutzen. Mehrere Codepfade in der Physik, der 3D-Engine und dem Zonensystem sind dabei, portiert zu werden. Und, wir haben noch eine weitere Compiler-Optimierung für euch auf Lager. Die Unterstützung für die AVX-Codegenerierung für Clients wurde bereits aktiviert und sollte in der kommenden Alpha 3.12-Version auf die öffentlichen Server kommen. Was die Speicherauslastung der Server und Clients betrifft, haben wir viel Zeit damit verbracht, unsere Tracking-Tools weiter zu verfeinern, um sicherzustellen, dass wir eine gute Übersicht darüber haben, wo wir Speicher verbrauchen. Wir sind jetzt auch in der Lage, die Speichernutzung in Bibliotheken von Drittanbietern korrekt zu verfolgen, die es uns entweder nicht erlauben, die Speicherzuweisung durch unser System umzuleiten, oder die noch nicht aktualisiert wurden, um dies zu tun. Wir planen immer noch, etwas mehr Sichtbarkeit bei der clientseitigen Video-Speicherzuweisung auf der Treiberebene zu erhalten (unterhalb der Ebene, die wir derzeit als Anwendung mit der GPU verfolgen können). Als Ergebnis dieser Verbesserungen, der laufenden Untersuchungen und des Trackings wurden einige kritische Speicherlecks zur Veröffentlichung behoben. Während der gesamten Alpha 3.11 Produktion konzentrierte sich das Core Engine Team hauptsächlich auf Features für spätere Versionen, wie den Gen12 Renderer. Allerdings wurde ein sehr großer Fehler behoben, der dazu führte, dass alle unsere Objekte auf den Clients viel früher als geplant entladen wurden. Objekte auf den Clients sollten nun für deutlich größere Entfernungen gestreamt bleiben. Audio Für die Audiotechnik haben wir die Wise-Version auf 2019.2.4 aktualisiert, wodurch mehrere Probleme behoben wurden. Als Teil dieses Unterfangens haben wir die Speicherverwaltung innerhalb des Audiosystems überarbeitet, indem wir von einer Gruppe von Speicherpools zu einem einzigen Pool übergegangen sind. Dadurch können wir mit den vielen verschiedenen Situationen, die Star Citizen präsentiert, leichter umgehen, indem wir Speicher dort zuweisen, wo er gebraucht wird, wenn er gebraucht wird. Wir haben viel Zeit damit verbracht, unsere Voice-Budgets zu überdenken, um das Gesamterlebnis zu verbessern und den Spielern zu ermöglichen, mehr von dem zu hören, was im Spiel vor sich geht. Die Unterstützung für Waffenfeuer, insbesondere auf große Entfernungen, wurde verbessert und mehrere Probleme mit der Audio-Feuerrate und der Waffenlautstärke wurden behoben. Leinwand-Slicing Dieses Quartal hat das UI-Tech Team an einem System gearbeitet, das Canvas Slicer genannt wird. Dabei handelt es sich um ein Untersystem von Building Blocks, das es den UI-Designern ermöglichen wird, Scheiben von 2D-UI in 3D-Raum zu platzieren. Normalerweise, wenn wir ein 2D UI zeichnen, wird es zu einer Textur gerendert und dann wird diese Textur auf eine Geometrie, wie z.B. ein Monitor Panel oder ein Data-Pad, angewendet. Mit dem Canvas Slicer erstellen wir die Geometrie an einer beliebigen Position im 3D-Raum zur Laufzeit und zeichnen die 2D-UI direkt darauf. Das bedeutet, dass wir in der Lage sein werden, interessante UI-Layer zu erzeugen, wie z.B. holografische Schiffs HUDs und Helmdisplays. Tooltipps Wir haben auch begonnen, unser Tooltips-System für Building Blocks zu entwerfen. Oberflächlich gesehen sah es nach einem einfach zu implementierenden System aus, aber die Anforderungen, um sicherzustellen, dass es superflexibel ist, haben dazu geführt, dass wir über eine ganze Menge nachdenken müssen, bevor wir mit der Implementierung beginnen. Marco Corbetta VP der Technologie
Kern-Gameplay Externes Inventar Externes Inventar ist die erste Iteration unseres gitterbasierten Inventarinterfaces, mit dem Spieler ihre FPS-Waren zwischen Rucksack-, Brust- und Beintaschen verwalten können. Wie der Name schon sagt, können Spieler mit dem Externen Inventar auch direkt mit anderen Lagerbehältern in der Welt interagieren und Gegenstände zwischen ihnen hin- und herziehen. In Alpha 3.11 ist dies nur für das Greycat ROC-Lagerfach aktiviert, damit Spieler ihre FPS-Minengüter verwalten können. Aber in der Zukunft und sobald wir eine echte Item-Lagerung (unterstützt durch iCache) realisieren, wird dies Spielern erlauben, Gegenstände in Fächern, Kisten und anderen solchen externen Inventaren zu lagern. Auch wenn eine neue Inventar-UI und die Möglichkeit, Gegenstände per Drag & Drop zwischen den Lagercontainern hin- und herzuziehen, auf den ersten Blick einfach klingen mag, mussten wir einige kreative und technische Herausforderungen meistern. Die wichtigsten kreativen Herausforderungen drehten sich darum, ein Interface zu haben, das sich taktil und zugänglich anfühlt, ohne sich einfach nur wie ein Standard 2D Interface anzufühlen, das man in den meisten RPGs sieht. Das lag nicht daran, dass diese Inventare schlecht sind, vielmehr wollten wir nicht, dass Spieler, die Inventar-Tetris durchführen, ihre Gegenstände verwalten; wir wollten, dass die Spieler Gegenstände frei zwischen den Lagercontainern bewegen können, ohne sich Gedanken darüber machen zu müssen, wo sie den Gegenstand fallen lassen oder ob ein anderer Gegenstand im Weg ist. Die erste Iteration davon konnten wir mit unserer Building Blocks-Technologie erreichen, die die Gegenstände als Liste und nicht als 2D-Raster speichert. Das bedeutet, dass sich die Gegenstände fließend um deinen Cursor bewegen, wenn du Objekte zwischen den Containern hin- und herziehst. Wir wollen das Gesamtgefühl noch weiter verbessern, aber das Team ist mit der ersten Iteration zufrieden. Mit Building Blocks konnten wir zwar die kreativen Aspekte des Designs umsetzen, aber es stellte auch die größte technische Herausforderung dar. Da sich die Technologie noch in der Entwicklung befindet, bedeutet das, dass sie nicht immer die Dinge unterstützt, die man braucht, um ein Feature zu liefern. Im Fall von External Inventory wollten wir, dass sich die Benutzeroberfläche diegetisch und 3D anfühlt, auch wenn sie es nicht ist. Das bedeutete, dass wir wollten, dass alle Icons holografisch sind, so wie sie in AR direkt vor deinen Augen angezeigt werden. Leider konnten unsere 3D-Symbole nur einen begrenzten Shader unterstützen, was bedeutete, dass wir viele materielle Details der angezeigten Gegenstände verloren haben. Zu diesem Zeitpunkt hätten wir das Feature verzögern können, aber das Team und ich hielten es für wichtig, dass wir live gehen und so viel Feedback wie möglich erhalten, bis wir ein echtes Inventar haben. Wir werden diesen Shader in einem kommenden Patch definitiv aufrüsten. Reaktionen erzwingen Im Kern ist Force Reactions ein System, das entwickelt wurde, um zu simulieren, was ein Charakter tun würde, wenn er von einer Kraft getroffen wird, sei es ein starker Windstoß oder eine Kugel, die in seine Schulter eindringt. Es kann in drei Stufen von Aufprallen unterteilt werden: Geringer Aufprall: zuckt, zuckt zusammen und neigt sich, mittlerer Aufprall: taumelt, hoher Aufprall: niederschlägt. In Alpha 3.10 lieferten wir die erste Iteration von Low-Impact-Reaktionen mit den prozeduralen Zuckungen im FPS-Kampf und Schräglage bei anhaltendem Wind. In Alpha 3.11 fügten wir den Zuckungen mehr "Gefühl" hinzu, mit zusätzlichen Kamera- und Waffenreaktionen und unserer ersten Iteration von Knockdowns, mit der Absicht, dass die Torkel später kommen. Die größte Herausforderung für dieses System war, dass es wirklich systemisch sein musste, da Kräfte von vielen verschiedenen Orten kommen können, nicht nur von Kugeln. Dafür haben wir die Kräfte in drei Hauptkategorien eingeteilt: Direkte Kräfte: alles, was physisch auf den Charakter einwirkt, wie eine Schachtel oder eine Kugel Indirekte Kräfte: die Kraft, die du erhältst, wenn dein Schiff gerammt wird oder von einer Windböe Nachhaltige Kräfte: wo eine Kraft ständig angewendet wird, wie eine G-Kraft oder Wind Das bedeutete, dass wir verschiedene Kräfte mit unterschiedlichen Maßstäben aufteilen konnten und es den Designern erlaubten, die Reaktion des Charakters entsprechend auszugleichen, da die Kräfte, wenn man von einer Kiste getroffen wird, verglichen mit der Beschleunigung eines Schiffes im Weltraum auf 1000m/s sehr unterschiedlich sind. Auch wenn die Reaktionen der Spieler bei geringerem Aufprall nicht die Kontrolle über den Spieler verlieren, waren wir uns der Tatsache bewusst, dass ein Knockdown das tun würde. Wir haben viel Zeit damit verbracht, sicherzustellen, dass die Knockdown-Animationen sehr reaktiv auf die Spielersteuerung reagieren, sobald ihr Charakter auf dem Boden aufschlägt. Wir implementierten auch ein fähigkeitsbasiertes System, das bedeutete, dass wenn man versuchte, ADS auszulösen, bevor man den Boden berührte, eine schnellere Genesungsanimation auslöste, was bedeutete, dass man schneller wieder in die Action einsteigen konnte. Force Reactions in Alpha 3.11 war unsere zweite Lieferung und wird keineswegs unsere letzte sein. Wir arbeiten aktiv an Reaktionen mit mittlerer Wirkung und werden die Balance in Zukunft ständig überprüfen und optimieren, insbesondere im FPS-Kampf. Wurf T1 Das Werfen von Granaten oder anderen Gegenständen war schon immer ein wenig inkonsequent und ist umso enttäuschender, wenn man denkt, dass man die perfekte Multi-Kill-Gelegenheit hat, bei der die Granate nur ein paar Meter von einem entfernt wimmert. Also, das erste, was wir mit T1 erreichen wollten, war, das Werfen viel zuverlässiger zu machen, so dass das Objekt, das man wirft (egal ob Granate oder anderes Objekt) dorthin kommt, wo man es erwartet. Das zweitgrößte Ziel, das eine entscheidende Voraussetzung für das physische Inventar ist, war, dass das Wurfsystem mit dem tragbaren System interagieren und koexistieren kann. Wenn man in Alpha 3.10 eine Granate vom Boden aufhob und dann versuchte, sie zu werfen, gab es für dich keine Möglichkeit, den Stift zu ziehen. Außerdem, wenn du den Hotkey 'Granate werfen' gedrückt hast, hast du die Granate in deine Hand fallen lassen und eine neue aus deinem Anzug gezogen. Offensichtlich ist dies nicht das beabsichtigte Verhalten und war einer der Hauptgründe, warum wir das Werfen geändert haben, um aus einem ausgerüsteten Zustand zu kommen (d.h. die Granate in der Hand zu halten) und nicht direkt aus deinem Anzug. Dieses System wird es uns auch erlauben, in Zukunft Gadgets und Deployables zu liefern. Als Teil von T1 haben wir auch einen UI-'Wurfbogen' hinzugefügt, der es euch erlaubt, die Flugbahn der Granate zu sehen. Derzeit ist dies zwar für alle Helme aktiviert, wird aber erst von Kampfhelmen aus zugänglich sein, wenn wir anfangen, verschiedene Rüstungsarchetypen im 'Vers' zu definieren. Behring Granatwerfer & Behring BR2 Schrotflinte Seitdem ich Waffen dirigiere, versuchen wir sicherzustellen, dass jede Waffe, die wir dem Spiel hinzufügen, einen einzigartigen Zweck oder Spielstil hat, der zu ihr passt. Momentan haben wir bereits mehrere lebende Schrotflinten, die aus nächster Nähe tödlich sind, aber darüber hinaus ineffektiv. Da Behring ein Hersteller ist, den wir in Bezug auf Schaden, Feuerrate und Genauigkeit als Mitte der Straße identifiziert haben, war die BR2 unsere erste Gelegenheit, die Reichweite für eine Schrotflinte zu vergrößern, um im Nahkampf etwas mehr Schwung zu geben, ohne dass sie im Nahkampf dominiert. Während wir mit dem BR2 zufrieden waren, sind wir mit Schrotflinten als Gesamtklasse nicht unbedingt zufrieden, da sie von SMGs unterlegen sind und von Sturmgewehren überrannt werden. Wir werden in einem kommenden Patch ein Update für alle Schrotflinten machen, um ihnen mehr Identität zu geben. Der Behring-Granatwerfer hingegen warf ganz andere Probleme auf. Eine 40mm-Granate im echten Leben hat einen Tötungsradius von etwa 5m mit einem Verletztenradius von etwa 15m. Das sind große Zahlen, wenn man sich unsere Innenräume ansieht, und wenn man bedenkt, dass man mehrere davon in kurzer Zeit abfeuern kann, bleibt einem eine ziemlich mächtige Waffe. Auf der einen Seite wollten wir eine Waffe liefern, die sich schwer anfühlt und dafür ausgelegt ist, Zerstörung herabregnen zu lassen, aber auf der anderen Seite wollten wir die Balance des FPS-Kampfes nicht massiv stören. Mit diesem Ziel haben wir dafür gesorgt, dass die Zahlen sowohl für den Tötungs- als auch für den Verletzungsradius etwas unter denen einer normalen Splittergranate liegen. Aber wenn ich ganz ehrlich bin, würde ich sagen, dass der Granatwerfer im aktuellen Spiel etwas zu mächtig ist. Der Hauptgrund dafür ist, dass die Spieler mit dem PMA Zugang zu einer unendlichen Menge an Munition haben, also mussten wir uns entscheiden, ob wir die Waffe wie beabsichtigt loslassen oder sie massiv nerfen, bis das physische Inventar online ist. Als Team waren wir der Meinung, dass es eher eine Erfahrung war, die Waffe freizugeben, da sie funktionieren sollte, und darauf zu warten, dass die anderen Systeme, wie das Inventar und der physische Schaden, ihre schiere Kraft ausgleichen. Dann müssen sich die Spieler überlegen, wie viel Platz sie für Munition und physischen Schaden einplanen, damit Waffen und Rüstung ihre Integrität verlieren, wenn sie getroffen werden. Das heißt, wenn jemand durch eine Explosion in die Luft gejagt wird, wird ein Großteil seiner Ausrüstung beschädigt, was den Gesamtwert senkt. Ich habe auch die Rückmeldungen bezüglich der Bewaffnungsdistanz gesehen und daran werden wir arbeiten. Abschließende Gedanken Wenn ich auf all die Features zurückblicke, die die Core Gameplay Pillar für Alpha 3.11 geliefert hat, bin ich mit den Ergebnissen zufrieden. Das heißt aber nicht, dass alles gut gelaufen ist, oder wenn ich diese Zeit noch einmal hätte, würde ich alles genauso machen. Das Wichtigste, was ich denke, dass ich ändern würde, wäre, wie wir Force Reactions in den Schiffen implementiert haben. Anstatt sie gleich zu behandeln wie alle anderen Kräfte im Spiel (Wind, Kugeln, etc.) - was auf den ersten Blick Sinn macht - hätte ich sie speziell um den Gravitationsgenerator in den Schiffen herum entworfen. Momentan nehmen wir die Kraft, die auf das Schiff einwirkt und wenden sie dann über Filter je nach Kraft direkt auf den Akteur an, damit dieser entsprechend reagiert. Stattdessen hätte ich lieber die Gravitation selbst auf die Kraft reagieren lassen, die dann den Akteur zu einer Reaktion veranlassen würde. Während es für den Spieler keinen Unterschied gäbe, denke ich, dass es eine sauberere Implementierung gewesen wäre und das System in Zukunft einfacher zu erweitern wäre. Zum Beispiel, wenn wir Gegenstände des Gravitationsgenerators hinzufügen, etc. In den letzten zwei Quartalen haben wir auch zwei Features (Body Dragging und Knockdowns) geliefert, die von einer getriebenen Ragdoll wirklich profitiert hätten. Leider wird dieses Feature nicht von jemandem aus meinen Teams geliefert, also hätte ich nicht unbedingt etwas daran ändern können. Aber wenn ich zurückblicke, hätte ich mehr Aufmerksamkeit auf die Vorteile gelenkt, wenn ich versucht hätte, dieses Feature voranzutreiben. Das ist natürlich eine Herausforderung, wenn man in einem 600-köpfigen Team arbeitet, das über mehrere Kontinente verteilt ist und in mehreren Projekten unterschiedliche Prioritäten hat. Jeder versucht, die besten Features/Inhalte/Techniken in höchstmöglicher Qualität zu liefern, und manchmal stimmen die Sterne nicht überein, wenn es um die Prioritäten geht. In diesem Fall liegt es aufgrund mangelnder Kommunikation rein auf meinen Schultern. Als Entwickler kriegen wir es nicht immer richtig hin, wenn wir mitten im Geschehen sind, aber hoffentlich gibt uns das einen Einblick in unsere Prozesse und wie wir immer 100%ig geben, um zu versuchen, die besten Erlebnisse zu schaffen, die du genießen kannst. Richard Tyrer Haupt-Gameplay-Regisseur
Umgebungen Frachtdecks Für diese Veröffentlichung konnten wir den nächsten Schritt einführen, um die Komplexität unserer Raumstationen zu erhöhen. Die Idee für die großen Stationen, die sich um Planeten herum befinden, ist, dass sie mehr als nur Raststätten sein würden; sie würden ihre eigenen Einrichtungen haben, die anderen Diensten gewidmet sind, wie zum Beispiel der Fracht. Für das Äußere haben wir neue Addon-Komponenten eingeführt, die die Infrastruktur und die großen Containerregale beschreiben, die die Kapazität des Ortes implizieren (die im Moment noch rein visuell ist, in Zukunft würden wir gerne mehr interaktive Elemente einbauen). Im Inneren wollten wir die Traversalrouten erweitern. Dazu haben wir die Idee einer Station mit einem Haupttransitnetz eingeführt, das die verschiedenen Elemente der Station miteinander verbindet - Handelsdecks, Frachtdecks, etc. Für das Innere des Frachtdecks wollten wir ein paar Elemente einbauen. Erstens wollten wir für den Hub-Bereich eine thematische logistische Erfahrung für den Spieler beschreiben. Dazu gehört ein Bereich eines Versandlagers, der in Zukunft eine Sandkiste für Missionsinhalte sein wird. Für den Haupteinkaufsbereich wollten wir ein paar Elemente in einen größeren Shop integrieren. Jetzt sehen wir den Ladungsabgabe- und Abholschalter, der sich in einem Mini-Logistiksortierraum befindet, den Schiffsverleihraum an der Seite und den Gilden- und Vorratsraum in der Ecke. Insgesamt bietet dies dem Spieler eine abwechslungsreichere Erfahrung, anstatt all diese Elemente in separate Läden zu trennen. Inhalt des Planeten In diesem Quartal konnten wir die Planeten und Monde im Stanton-System mit den neuesten Tools und Technologien, die wir für den Aufbau des Pyro-Systems verwenden, auf den neuesten Stand bringen. Der Anfang davon war die Durchführung eines globalen Neumalungspasses für alle Planeten und Monde. Im Grunde treibt dieser Malprozess eine Menge der neuesten Features an, wie wir Objekte vereinigen, also mussten wir, um das ins Spiel zu bekommen, in den sauren Apfel beißen und den ersten Pass über alles machen. Im letzten Patch haben wir die neuen Höhenkarten eingeführt, und jetzt wird der neue Maldurchgang all diese neuen Daten nutzen. Das zweite Element, das wir einführen konnten, war eine globale Verbesserung all unserer Geologie-Packs. Wir haben jetzt die Möglichkeit, die Geländefarbaufnahme für Assets zu spezifizieren, was es ihnen ermöglicht, die Farbe des Geländes oder des Untergrunds prozedural anzupassen. Außerdem konnten wir die Mosaikierung und die Verschiebung von Objekten auf Objektbasis hinzufügen, was bedeutet, dass wir den Objekten, die die Verschiebungsparameter steuern, Höhenkarten zuweisen können. Kurz gesagt bedeutet das, wenn der Spieler in die Nähe eines Assets kommt, sollte die Auflösung der Geometrie wesentlich höher sein, so dass eine komplexe Silhouette gelesen werden kann. Zuletzt haben wir alle unsere Terrain-Shader durch gescannte Daten ersetzt. Das ist etwas, mit dem wir uns schon seit einiger Zeit beschäftigt haben, da die Qualität der Ergebnisse extrem hoch war, aber mit der neuesten Technologie konnten wir es in unsere Pipeline implementieren. Wir haben über 70 Basis-Shader neu erstellt, indem wir die gescannten Daten miteinander kombiniert und gemischt haben, um die Ergebnisse zu erhalten, die wir wollten. Für die Zukunft haben wir Ambitionen, eine dedizierte Scan-Ausrüstung einzurichten, um unsere eigenen Daten zu verarbeiten, die wir bei unseren Exkursionen sammeln werden. Wir wollen sicherstellen, dass wir eine vielfältige und wunderbare Palette für zukünftige Star-Citizen-Standorte erstellen können. Abschließende Gedanken Wir waren in der Lage, eine Menge neuer Tech in dieser Veröffentlichung einzuführen, sowie die zweite Runde der polnischen Updates auf den Planetenoberflächen zu zeigen. Außerdem haben wir mit der Einführung der gescannten Daten für unsere Oberflächen einen erheblichen Qualitätssprung gesehen. Allerdings waren einige der globalen Maldurchgänge nicht so detailliert und aufwändig, wie wir es uns gewünscht hätten. Das liegt hauptsächlich an den Zeitbeschränkungen im Quartal. Ein Teil der Geologie, die mit den neuen Bibliotheken an die Oberfläche kommt, könnte auch für die Biome/Region besser geeignet sein. Bei den Frachtdecks hätten wir die Trennung zwischen Innen- und Außenbereich bei der Trennung der kommerziellen Decks vorhersehen müssen. Um die Erfahrung zu verbessern und dem Spieler einen Kontext zu geben, würden wir uns wünschen, dass dieses Transitnetzwerk in Zukunft physisiert wird. Dadurch wird die Sicht aus der Transitkabine auf die Außenseite der Station, während sie sich ihrem Ziel nähert, gewährleistet. Ian Leyland Star-Bürger Art Director
Gestaltung Waffenstillstands-Zonen Die Entspannungen der Waffenstillstandszone sind der erste Schritt, um alle willkürlichen Beschränkungen aus dem Spiel zu entfernen, sobald wir in der Lage sind, die verschiedenen Bereiche des Spiels richtig zu verteidigen und zu überwachen. Dies war an den Raststätten möglich, weil wir nicht nur die bestehenden Türme der Größe 4 und Wachposten der Größe 6 wiederverwenden, sondern auch einen völlig neuen Turm der Größe 10 geschaffen haben. Zusammen sind diese in der Lage, mit jedem Schiff fertig zu werden, das im Spiel geplant ist. Und anstatt noch eine weitere willkürliche Beschränkung aufzuerlegen, haben wir die Verteidigungsanlagen vollständig zerstörbar gemacht, obwohl ihre Respawn-Zeit mit 5 Minuten sehr schnell ist. Dieses Respawn-System wird in Zukunft weiter entwickelt werden, um wahrscheinlich auf Reparaturen angewiesen zu sein. Zusammen mit der Verteidigung haben wir die erste Iteration eines Sicherheitsreaktionssystems hinzugefügt, das, obwohl es noch recht simpel ist, die CrimeStats aller Spieler in der Gegend addiert (intern als "Heat" bekannt) und als Reaktion darauf Sicherheitsschiffe von steigender Anzahl und Stärke hervorbringt. Das System reagiert schnell auf den Anstieg der Hitze in einem Gebiet, indem es neue Schiffe laicht und schwächere Schiffe, die sie ersetzen, despawnen lässt. Das System reagiert langsamer auf die Tötung seiner Mitglieder (sollte die Hitze dadurch nicht erhöht werden) und noch langsamer auf eine Abnahme es in der Hitze. Wir werden dieses System in Zukunft weiterentwickeln, um auch die Schiffe, die die Spieler benutzen, und die gezeigte Aggression zu berücksichtigen. Wir werden es auch auf andere Orte wie Außenposten ausrollen, obwohl Grim HEX eine komplexere Lösung benötigt, da die dortigen Verteidigungsanlagen nur auf Verbrechen reagieren sollen, die in ihrem Zuständigkeitsbereich begangen wurden und nicht in anderen. Olisar wird eine Anomalie bleiben, da es ein veralteter Standort ist, der keine Waffenstillstandszone mit dem erforderlichen Radius unterstützen kann. Das Live-Team musste extrem wachsam sein und schnell auf Probleme reagieren, angesichts der kurzen Zeit, die Alpha 3.11 in der PTU lief. Ein Beispiel für ein Problem, das uns auffiel, waren Spieler, die die Wachen stahlen, indem sie sie in der Ladebucht ihrer 890 Sprünge verschluckten und mit ihnen davonflogen. Wir berichtigten dies, indem wir selbstzerstö