Wir haben Euch den letzten “Monthly Report June” vollständig ins Deutsche übersetzt. Viel Spaß beim Lesen!
Wer sich für eine deutsche Zusammenfassung interessiert, sollte sich die NewsCrash-Episode von Sawyer ansehen: hier geht’s zum Video auf YouTube.

---

 

Monatlicher Statusbericht für Juni

Seid gegrüßt Bürger,

endlich ist es Sommer (zumindest in der nördlichen Hemisphäre), wir sind aber natürlich nicht im Urlaub: denn es passieren große Dinge bei CIG! Von innen betrachtet ist es sehr befriedigend, zusehen zu können, wie all die Teile, die Star Citizen formen werden, nach und nach zusammenkommen. Wichtige Teile, über die wir schon lange sprechen, wie zum Beispiel die größeren Karten, gehen intern online; es liegt ein Hauch Aufregung in der Luft, weil vieles, das wir schon lange planen und auf das wir hingearbeitet haben, endlich Wirklichkeit wird.
Wir wollen unsere Fortschritte unbedingt mit Euch teilen, nicht nur um das FPS Modul Star Marine zu pushen, sondern auch um Euch Informationen zu den Themen Multicrew und persistentes Universum zu liefern. Ihr könnt Euch auf die nächsten Berichte freuen!
Wie immer haben wir unsere Projektleiter gebeten, individuelle Berichte für die Community zu erstellen, um Euch wissen zu lassen, woran die jeweilige Abteilung diesen Monat gearbeitet hat. Lest weiter!

 

CIG Santa Monica

Hallo allerseits! Wir hatten einen außergewöhnlichen Monat voll spannender Arbeit hier im sonnigen Santa Monica. Wir lieben es, alles, woran wir arbeiten, mit Euch zu teilen. Also genießt diesen Bericht und lasst uns wissen, wenn Ihr Fragen oder Gedanken dazu habt!

 

Technik

Unser Technikteam war diesen Monat richtig beschäftigt. Mit allen möglichen Dingen, von der Datenbereinigung über die Erstellung des neuen Charakter-Material-Systems, bis hin zu den Updates der großen Karten. Dann lasst uns beginnen:

Wir haben einige frühe Implementierungen für die Vehikelparameter vorgenommen, durch die wir das ständige Laden der Fahrzeuge mit Hilfe des Parsen der entsprechenden XML-Datei bei jedem Spawn durch das Parsen einer einzigen XML ersetzen konnten. Diese nutzen wir seitdem zum Bauen von Fahrzeugen. Uns war auch nur ein Weg bekannt, wie wir ein Schiff erstellen können: wir haben es spawnen lassen und nachgesehen, was in der XML Datei steht. Jetzt können allerdings auch andere Systeme einfach die Parameter auslesen und daraus ein Schiff erstellen. Das heißt, wir müssen jetzt nicht mehr jedes Schiff unterhalb des Hangars spawnen lassen – und das war eine wirklich große Änderung für uns.
Wir haben uns auch um viele Integrations-Fehlerbehebungen für das FPS Modul & den Arena Commander gekümmert. Außerdem konnten wir weiter am Radarsystem 2.0 arbeiten, das wir von einem rein entitätsbasierten, zu einem System geändert haben, das praktisch alles auf dem HUD anzeigen kann, das die Designer benötigen. Die Arbeit am Backend ist abgeschlossen. Jetzt müssen wir noch das HUD und andere Fahrzeugkomponenten für den Umgang mit solchen Objekten verändern. Dann werden die Designer bestimmt ausflippen! Wir haben auch vieles im Fahrzeug-Code bereinigt, indem wir unbrauchbaren Code löschten. Das führt zu einer Beschleunigung einiger der langsamen Bits, bleibt aber ein kontinuierlicher Optimierungsprozess.

Das Team für das User Interface hat unglaublich hart an den bevorstehenden Schiffsentwürfen und -ausführungen gearbeitet; vor allem an den Glitch Effekten und dem Booten des Vanduul Systems. Wir haben auch einen Verbesserungsvorschlag für die Interaktion mit dem Cockpit überprüft und mit den Vorbereitungen am HUD begonnen, um verschiedene Aktionen und Rollen auf unterschiedlichen Sitzplätzen zu unterstützen.

Außerdem haben wir einige der Datenspeicher bereinigt, doppelten Code entfernt, Wildwuchs im Code vereinheitlicht und mit den Vorbereitungen für Multicrew Spawning / Multiplayer Hangars begonnen. Wir haben das Spawnen von Objekten auch vom Spawnen des Spielers in der Lade-Phase des Levels/Hangars getrennt.

Zusätzlich arbeiteten wir an einem Multilayer Materialsystem. Wir wollen mit einer festen Bibliothek für Basismaterialien enden, die frei übereinander gelegt werden können (bis zu vier Lagen), um möglichst komplexe Materialien mit minimalen Draw Calls zu schaffen. Diese Texturen Bibliothek und die grundlegenden Shader-Funktionen sind weitgehend fertig, dadurch wird jetzt an der Basismaterial Bibliothek gearbeitet. Sie verbindet die Renderressourcen mit den gemischten Materialien.

Auf Seiten der KI haben wir einige Fehlerbehebungen an den Schiffen vorgenommen, vor allem im Bezug auf den Piloten, der ein KI Schiff bemannt und verwaltet. Wir haben auch an den Kommandos für die Flügelmänner, wie etwa „Verteidige das Ziel“, gearbeitet, einem Aspekt der KI, die in der Nähe nach Bedrohungen Ausschau hält, damit Eskorten wissen, wen sie angreifen müssen.

Bzgl. größerer Karten haben wir verschiedene Probleme mit Auslösebereichen beheben können, zum Beispiel wurde das +/- 16km Limit für alle Auslösebereiche entfernt und zusätzliche Grenzvoraussetzungen korrigiert.

Wir haben das Interface für Matrix34 / Quat leicht bereinigt und die Bedingungen ermittelt, um den wiederkehrenden Teil all dieser geometrischen Primitiven gleiten zu lassen. Wir haben Korrekturen an der Informationsbar für die Position und den „GOTO“-Positionsdialog vorgenommen. Zusätzlich haben wir die Kamerageschwindigkeit bei der Erstellung von großen Karten in der Sandbox erhöht. Schließlich haben wir das Laden sog. „thread-safe-texture“ mit „thread-safe-shader“-Parsing abgeschlossen und auch die „thread-safe-Shader“-Ressourcenerstellung ist fast fertig.
Puh, wir hatten einen tollen Monat und freuen uns schon auf den nächsten!

 

Design

Das hiesige Designerteam bleibt mit all den bevorstehenden Schiffen, Modi, Gameplaybedürfnissen, usw. reichlich beschäftigt. Einer unserer größten Schwerpunkte war der Genesis Starliner. Wir wollten alles durchdacht haben, bevor wir Euch dieses fantastische Schiff vorstellen. Wir mussten uns diesen Monat durch viel Arbeit kämpfen, z.B. die Bereitstellung des initialen Plans für die Gameplay Balance, der auch mögliche Updates für Statistikwerte, Funktionen, Spielemodi, HUD, Steuerung, Raketen, und vieles mehr beinhaltet. Hier sind einige tiefgreifende Details des letzten Monats:

Wir haben ein Problem mit der RSI Constellation Andromeda gelöst, deren alte hangar-ready Version den Hangar abstürzen ließ. Oops! Wir änderten auch den Hauptzugang für den Aufzug, der bisher eine Tür war, zu einer zentralen Stelle, die das Betreten/Verlassen durch verschiedene Türen erlaubt, ohne den Animationsstatus zu ändern. Zusätzlich haben wir die Positionen der Hände im oberen, sowie unteren Gefechtsturm korrigiert. Auch die Thruster wurden mit dem Ziel, sie flugfähig zu bekommen, überarbeitet.

Beim Scythe Dogfighter haben wir ein Problem gefunden, bei dem das „Multilight“ nicht in den „light port“ geladen wurde und der Archetyp dann den Client abstürzen ließ. Wir haben dabei gleich unnötigen KI-Code für das Raumschiff entfernt und die Scythe aktualisiert, um den „Scythe_Swarm“ Modifikationsblock nutzen und die Lebensenergie anpassen zu können.

Bei der Hornet-F7CM fixten wir ein Problem, das einen der Schubdüsen-Hardpoints falsch benannt hat, wodurch der Thruster nicht ans Schiff montiert werden konnte. Zudem kombinierten wir die „bound geometry“ und das „Weight Transfer Tool“, während wir das Kontrollschema ein wenig überarbeiteten.

Bei der Mustang Delta haben wir die Benutzung der Standardanimationen entfernt, die zu Kollisionen und Problemen führten (zum Beispiel zu falsch platzierten Einstiegsluken und fehlenden Öffnungs-/Schließanimationen). Außerdem fügten wir Animationen beim Betreten und Verlassen des Pilotenplatzes in der AEGIS Retaliator hinzu und aktualisierten das Interieur. Das ist lediglich ein kleiner Teil dessen, was diesen Monat bei uns passiert ist. Wir sind schon für den kommenden Monat Juli bereit!

 

Art

Insgesamt war es ein anstrengender Monat für unser Art Team in Santa Monica. Die Vehikel-Künstler waren mit der Merlin beschäftigt, die gerade durch die finale Art Phase gekommen und an die Designabteilung übergeben worden ist, die sie flight-ready machen. Darüber hinaus hat unser Senior Fahrzeug Künstler Paul Forgy damit begonnen, das Exterieur des Bengal Carriers zu whiteboxen und in die Engine zu übertragen. Wir können diese Großkampfschiffe kaum erwarten! Die LA Künstler haben hart daran gearbeitet, sicherzustellen, dass die bereits flugfähigen Schiffe das überarbeitete Schadenssystem, das gerade online geht, auch unterstützen. Die Scythe ist eines der ersten Schiffe, das mit der vollen Schadensunterstützung ausgestattet wurde. Schaut Euch das in naher Zukunft auf jeden Fall mal an! Allerdings ist das nicht das einzige Update der Scythe. Das Cockpit wurde für die menschliche Bedienung überarbeitet. Erwartet sie bald im Arena Commander!

Neben den Kollegen in Austin/Texas, haben auch wir im LA Studio bei der Überarbeitung der Charaktere geholfen – nicht nur an den Charakteren des FPS Moduls, sondern an allen Charakteren quer durch alle Module. Omar Aweidah steht kurz davor, den ersten „Goldstandard“ fertigzustellen, der die neue Shader Technologie verwendet, die auf dem von unserem Kollegen Okka Kyaw geschriebenen Multi-LayerBlend basiert. Jetzt sind wir bereit, die visuelle Darstellung der Charaktere zu steigern und damit einen gewaltigen Zukunftsprung der Charakterentwicklung im Star Citizen Universum zu wagen.

Wenn wir schon von Charaktermodellen sprechen: unser Produktionsdesigner für Charakterkonzepte Rob McKinnon steigert unsere Konzeptentwicklung wirklich enorm. Wir machen tolle Fortschritte bei den Charakterstilen in Star Citizen. 3D-Skulpturen, die von Rob McKinnon und seinem Team bereitgestellt wurden, haben uns einen ersten 3D-Eindruck der Marineuniform gegeben. Egal ob Brückenoffizier oder BDU, die Marines sehen erstklassig aus. Die Marines haben viele Rollen und Verantwortlichkeiten und wir haben für jede von ihnen ein Outfit. Vom Offizier auf Deck bis zum Notfallsanitäter, alle Marineuniformen sehen heiß aus und sind für die 3D-Produktion bereit.

Trotz der Begeisterung, mit dem Meridian Transit reisen zu können, haben wir dafür gesorgt, dass Ihr auch einen Drink bekommt. Mit dem Genesis Starliner gibt es jetzt die aller ersten Konzeptentwürfe für Flugbegleiter.
Auch die Vanduul werden durch die neuen Versionen der Rüstungssets um einiges taffer. Die Vanduul sehen jetzt böser denn je aus. Auch die Bereiche unter der Rüstung wurden mehrfach überarbeitet, um die Haut dieser Alienrasse zu finalisieren.

Und das war es für diesen Monat aus dem Santa Monica Studio. Vielen Dank, dass Ihr Euch die Zeit genommen habt, alles über die harte Arbeit des Teams zu lesen und die Erstellung des Spiels zu unterstützen. Nichts davon wäre ohne Eure kontinuierliche Unterstützung möglich und wir fühlen uns geehrt, dieses Spiel mit Euch erschaffen zu können. Wir schätzen Eure Rückmeldungen und Gedanken, also lasst sie uns weiterhin wissen.

 

CIG Austin

Hallo allerseits!

Es war ein ungewöhnlich verregneter und kalter Juni in Texas und wir haben es genossen. Wir hatten eine Reihe von Besuchern aus anderen Studios und wir haben uns auf einige Produktionsprioritäten konzentriert. Wir haben an einer Reihe von Fronten gute Fortschritte erzielt, aber wir haben noch viel harte Arbeit bis zum Ende des Sommers vor uns. Hier kommen ein paar detaillierte Berichte von den Abteilungsleitern:

 

Persistentes Universum Team

Art

Das PU Konzeptart Team hat diesen Monat die meiste Zeit Details größerer Funktionen ausgearbeitet. Ted Beargeon und Ken Fairclough fertigten Stücke, die die Eigenschaften der Nyx>Delamar>Levski Landezonen definieren. Wir haben Konzepte von Statuen und großen Maschinen an BHVR übergegeben, um sie dort modellieren zu lassen. Ebenso wurde der Levski Marktbereich ausgearbeitet, um das Einkaufserlebnis dort zu verbessern, gerade weil es etwas ganz anderes sein wird, als wir bisher gemacht haben. Megan Cheever hat ihre gesamte Zeit damit verbracht, Detailverbesserungen an verschiedenen Konzepten von militärischem Personal vorzunehmen. Sie half beim Definieren von Abzeichen, Medaillen und anderen Sachen, die Ihr im finalen Spiel sehen werdet. Megan konzeptionierte außerdem den Charakter des Flugbegleiters, den Ihr im Starliner Verkauf sehen konntet.

Unser PU Umgebungsteam hat den finalen Detaildurchlauf für Levski abgeschlossen. Lee Amarakoon und Emre Switzer haben dabei Unterstützung im Bereich VFX und Licht geboten. Levski fängt dank ihrer Arbeit an, richtig dunkel und düster zu wirken. Lee hat auch begonnen, die Customs Scanner Effekte zu überarbeiten, die Ihr letztes Jahr auf der CitizenCon zu sehen bekommen habt. Unsere Abteilungsleiter Cort Soest und Patrick Thomas arbeiten mit BHVR zusammen, um die Umgebung an sich zu optimieren und liefern damit die letzten zehn Prozent zur Finalisierung. Nächsten Monat sollten wir Levski fertigstellen und später auch zeigen können.

Auch die Stanton>ArcCorp>Area18 Landezone stand diesen Monat im Fokus. Das Layout der Umgebung wurde leicht überarbeitet, um den generellen Optimierungen des Social Moduls gerecht zu werden. Mark Skelton hat mit Tony Zurovec zusammen gearbeitet, um die korrekte Richtung für diese Änderungen vorzugeben. Diese Umgebung wird besser als je zuvor aussehen.

Das Charakter Team hier in Austin hat gerade erst einige SATABall Charaktere und Helme fertiggestellt… und sie sehen großartig aus! Das war einer der ersten Charaktere, die wir von Anfang bis Ende unter Verwendung unserer Next-Gen Charakterpipeline erstellt haben. Diese neuen Techniken haben sich beim Erstellen von Charakteren im Star Citizen Universum als effektiv erwiesen. Wir freuen uns darauf, David Jennison und Billy Lords Arbeit bald zeigen zu können.

Das Animationsteam in Austin hatte wieder einmal alle Hände voll mit den verschiedenen Teilen des Projekts zu tun. Wir haben diese Woche Arbeiten am neuen weiblichen Skelett unter Dach und Fach bringen können. Das ermöglicht uns, bald endlich einige Damen in das Spiel zu integrieren! Außerdem hat Illfonic bei der Implementierung und beim Feinschliff der Animationen für das FPS und Social Modul geholfen. Zusätzlich haben wir an der Standardisierung der Animationsvorlagen für die Schiffscockpits und Einstiegs-/Ausstiegssequenzen gearbeitet, um die Modellierungszeit für weitere Schiffe zu reduzieren. Etwas, das Ihr schon bald sehen solltet, sind die überarbeiteten G-Force Animationen im Cockpit. Jay Brushwood, Sean Tracy und Jeff Zhu haben fantastische Arbeit geleistet, sie auf das nächste Level zu bringen.

 

Design

Das PU Design Team hat viel Zeit mit Brainstorming und der Fertigstellung von Entwürfen für zukünftige Berufsmöglichkeiten im PU verbracht. Unter Tonys Führung haben wir die ersten Berufsentwürfe für Kopfgeldjäger, Händler und Piraten überarbeitet. Auch für Schmuggler- und Such- & Rettungsberufe haben wir erste Entwürfe erstellt. Der von Tony Zurovec entworfene Personentransport war aber der größte, der in diesem Monat entworfenen Berufen. Falls Ihr noch keine Möglichkeit hattet, den Post des Starliner Verkaufs zu lesen, solltet Ihr das unbedingt HIER nachholen.

Außerdem haben unsere Designer diesen Monat am neuen „Usable Editor“ gearbeitet. Der Usable Editor ist Teil von Tonys Subsumtion des „friedlichen NPC KI Systems“. Es ist der erste größte Schritt in Richtung Tonys Vision, wie NPCs mit Objekten in Star Citizen interagieren werden. Es ist ein sich wiederholender Vorgang, bei dem die Designer mit dem Usable Editor herumspielen und Feedback geben, Gameplay-Programmierer Tom Davies darauf basierend Anpassungen vornimmt, und dann geht’s wieder von vorne los. Wir freuen uns, den Usable Editor zum ersten Mal in Aktion sehen und auch prüfen zu können, wie weit wir die Grenzen strecken können.

Schließlich haben wir uns mit den ersten Layouts/Entwürfen für die nächste planetare Landezone beschäftigt, mit der BHVR nach Fertigstellung von Levksi weitermachen soll. Wir konzentrieren uns auch auf andere planetare Landezonen in Stanton zwischen Hurston, MicroTech und Crusader. Welche Landezone wollt IHR als nächstes online sehen?

 

Technik

Der Juni wurde für den kontinuierlichen Fortschritt einiger unserer langfristigen Ziele, für die Planung und Unterstützung unserer bevorstehenden Releases und GamesCom Demo verwendet.

Es gab viele Überlegungen, wie die Serverperformance optimiert werden kann und dabei gab es großartige Fortschritte für die bevorstehenden Arena Commander, FPS und Social Modul Releases. Wie letzten Monat bereits berichtet, ist unser Generic Instance Manager (GIM) fast fertig. Der GIM beinhaltet einen großen Umbau der Gruppen- und Matchmakingsysteme und wird durch mehrere Iterationen gehen, bevor wir damit zufrieden sein werden. Die erste Iteration wurde von unserem QA Team bereits durchgeführt und sie waren beim Senden von Bugs nicht zurückhaltend. Wir beheben sie schnell und kommen dem, was eventuell GIM v1.0 sein könnte, immer näher. Wir freuen uns auf den Zeitpunkt, an dem wir all das mit Euch teilen können. Es ist ein mit Spannung erwartetes System hier bei CIG.

Die Kollegen drüben bei Wyrmbyte waren, abgesehen davon, dass sie ein wichtiger Faktor für unsere Untersuchung des Optimierungspotentials der Server waren, in ihren iPredictor Code vertieft… fleißig daran arbeitend, die verbliebenen Knoten zu lösen. Währenddessen war unser Tool Team mit Bugs und Featurerequests beschäftigt, um dem Team bei der Erstellung des Spiels zu helfen. Sie haben keine freie Minute, da es keinen Mangel an neuen Anforderungen für unsere Werkzeuge gibt… und sie sind glücklich sie liefern zu können! Ein paar Spieleprogrammierer arbeiten auch weiterhin an einigen Proof-of-Concept Funktionsprototypen von Berufen. Es ist aufregend, zusehen zu können, wie aus ersten Formulierungen fertige Berufe im persistenten Universum werden.

Leider ist der Report diesen Monat etwas kürzer. Das liegt aber nicht daran, dass in der Arbeit geschlafen wird, sondern daran, dass das Team an langfristigen Aufgaben arbeitet und dabei machen sie großartige Fortschritte! Viele davon können wir hoffentlich in den kommenden Monaten ausrollen.

Bleibt dran!

 

Live Operations

Qualitätssicherung

Diesen Monat führte die Star Citizen Qualitätssicherung erfolgreich drei studioübergreifende FPS Spieletests durch. Tyler Witkin hat bei der Koordination der Spieletests und dem anschließenden Einsammeln des Feedbacks großartige Arbeit geleistet.

Die automatisierte Entwicklung ist erhöht worden. Melissa Estrada und Tyler Witkin nutzen den „Sandbox Editor“ und „Flow Graph Editor“, um Levels zu bauen, die den sog. „Feature-Tester“ nutzen. Diese Gebiete werden verwendet, um verschiedene Schiffs- und FPS-bezogene Funktionen zu testen.

Dank dem sehr informativen Feedback von Senior Technical Designer Rob Reininger konnten wir unsere Editortests signifikant verbessern, vor allem da wir mehr Tests im Bereich Tools und Leveldesign zusammenfassen konnten.

Dank den Bemühungen von Todd Raffray sind auch die Tests am Social- und Planetside Modul fortgesetzt worden. Sobald ein System oder ein Tool entwickelt worden ist, stellt Todd sicher, dass es als Szenario in unser ausführliche Planetside Testliste aufgenommen wird. Die neueste Ergänzung ist der „Usable Editor“. Der Usable Editor wird verwendet, um NPCs die Fähigkeit zur Interaktion mit Objekten zu geben. Der Useable Editor ist Teil des gesamten Subsumtionssystem (friedliche NPC KI).

Jeffrey Pease hat dafür gesorgt, dass der General Instance Manager (GIM) während seiner offiziellen Einführung in die Alphaversion 1.2.0 ordentlich getestet wurde. Der GIM stellt die Umgestaltung unseres Backend-, Lobby- und Matchmakingsystems dar. Jeffrey leitet zudem die Recherchen zur Vermeidung möglicher Hacks und Exploits und hat unseren technischen Leitern sehr wertvolle Informationen geliefert. Sie haben jetzt einen Aktionsplan, um diese Probleme anzugehen.

Wir gratulieren Andrew Hesse, der die Rolle der QA Leitung in Austin übernommen hat. Andrew hat beim Testen aller Spielaspekte einen fantastischen Job geleistet und war unseren technischen Schiffsdesignern sowie unseren hier ansässigen Schiffsspezialisten eine große Hilfe. Außerdem können wir diesen Monat einen neuen Zuwachs im QA Team begrüßen: Andrew Rexroth. Rex hat umfangreiche QA Erfahrung und ist bereits jetzt eine große Hilfe bei den Star Marine Testläufen.

Nächsten Monat führen wir unsere Tests der Alpha 1.2.0 fort und freuen uns auf die Multiplayer Hangars, deutlich größere Karten, das Multicrew System und viele weitere Dinge.

 

Spielesupport

Die Zeit im Juni wurde vom Game Support weitgehend für das Designen, Überprüfen und Bauen von Infrastrukturen & Prozessen verwendet, die unseren Backern in allen Servicebereichen helfen werden.

Besonders hilfreich wird unser systemweites, administratives Broadcasttool sein, das uns erlaubt, allen mit dem Liveservice verbunden Spielern ein Kommunikationsverfahren zu liefern, das essentiell ist, um Euch während des Spielens mit topaktuellen Informationen versorgen zu können. Wir arbeiten außerdem an einem neuen System für die forumbasierte „Live Service Notification“ Seite, das letztlich eine eigene Webseite sein wird, die einen Serverstatus für alle Umgebungen (Arena Commander, Star Marine, PTU, Patches, etc.) beinhalten wird. Dadurch haben wir ein effektives Werkzeug zur Hand, mit dem wir alle Spieler über den Zustand der Dienste informieren können.

Zusätzlich haben wir nach wie vor dabei geholfen, Probleme im veröffentlichten Build 1.1.3 von Mai zu sichten. In diesem aktuellen Release konnten wir Probleme identifizieren sowie kommunizieren und dadurch aktiv mit dem Produktionsteam daran arbeiten, sie zu priorisieren & zu beheben; dazu zählten auch einige der Raketen- und Schiffsschadensprobleme.

Zuletzt haben wir begonnen, Ideen und Designs für Dinge auszuarbeiten, die wir für den Support unserer unterschiedlichen Umgebungen und insbesondere das Persistente Universum benötigen. Die Art, wie Spieler Support erhalten, hängt in der Regel vom Typ des Spiels ab, aber Star Citizen wird alle drei Modi haben (Einzelspieler, Multiplayer und PU)! Wir haben uns selbst also gefragt: Welche technischen Schwächen haben wir heute beim Supporten der Spieler? Was werden die erwarteten Verhaltensweisen im Spiel sein und welche Dienstleistungen machen sie erforderlich? Wie gehen wir mit einer Flut von gehackten Accounts um, die es in jedem PU gibt und welche Tools benötigen wir, damit sich die Spieler selbst schützen können? Wie können wir Spieler davon abhalten, auf einem zweiten Schwarzmarkt zu handeln, ohne sie komplett einzuschränken?

Noch haben wir nicht auf jede dieser Fragen eine Antwort, aber wir beschäftigen uns intensiv mit ihnen. Denn im Zusammenhang mit einer jeden Online Community und vor allem der des BDSSE sind es wichtige Fragen!

 

IT/Operations

Es war ein aufregender Monat für das IT Team. Wir haben weitere Leistungsoptimierungen an unserem Buildsystem vorgenommen und während wir auf jede Verbesserung stolz sind, kommen wir doch an einen Punkt, an dem jede Verbesserung, so wichtig sie auch ist, immer weniger Ausbeute mit sich bringt.
Nicht jede Steigerung kommt von der Hardware; wir arbeiten wieder eng mit dem DevOps Team zusammen, um die zu bewegende Datengrößen und ebenso wichtig, die benötigte Zeit zum Verschieben dieser Daten zu reduzieren. Eine der verbleibenden Herausforderungen ist unser Asset Buildsystem. Es gibt grafische Assets, die für jeden Build gerendert werden müssen und aufgrund unserer Treue zu unseren Zielen ist das ein sehr großer Teil des Buildprozesses. Diesen Monat haben wir mit der Aufteilung dieses Jobs in viele kleinere Unterjobs begonnen, um die Gesamtdauer der Erstellung dieses Teils der Builds durch eine parallele Abarbeitung zu verringern. Das DevOps Team kümmert sich um die Logik hinter dem Buildsystem und das IT Team stellt die Hardware für die Aufgaben zur Verfügung.

Neben dem Tuning des Buildsystems hat die IT einige Reisen unternommen. Paul aus Austin und Hassan aus Manchester sind zum Studio in Frankfurt hin und her gependelt, um bei der Logistik für deren Umzug in ein neues Büro zu helfen. Ein solcher Umzug benötigt viel Planung und Vorbereitung, aber so weit ist alles im Zeitplan.

Sie haben sich um alles von der Elektrik und Kühlung bis hin zu den IP Adressen und VPN Tunnel gekümmert. Aufgrund ihrer harten Arbeit sollte der Umzug an einem Wochenende durchführbar sein; deshalb erwartet das Entwicklerteam keinen Ausfallzeiten.

Dennis aus LA und Chris aus Austin bauen weiterhin basierend auf dem Feedback, das wir im Forum erhalten, an benutzerdefinierten Setups für Testzwecke. Wir beschaffen nicht länger nur gemeldete Ausrüstung für die QA Tests. Dennis und Chris bauen inzwischen kundenspezifische Systeme (wieder) auf, um Probleme mit denselben Komponenten testen zu können, bei denen die Hardware ein möglicher Problemfaktor zu sein scheint. Sie haben übrigens auch mit frühen Windows 10 Tests begonnen.

Juni war also ein aufregender und lohnenswerter Monat für die IT, allerdings haben wir für Juli noch größere Pläne.

 

Dev Ops

Dev Ops hat sich im Juni im Wesentlichen mit drei große Projekte beschäftigt: der neue Launcher, der neue Build Server und unser „Phoenix“ Umgebungsprojekt.

Der neue Launcher wurde bereits in mehrere Codesegmente aufgeteilt, an denen gleichzeitig gearbeitet wird. Während der aktuelle, öffentliche Launcher die Version 1.6 hat, wird Version 2.0 in der Firma und für die FPS Spieletests genutzt. An Version 2.1 wird bereits für den Rollout kommende Woche gearbeitet; diese wird einen schnelleren Download, kleinere inkrementelle Patches und einige Verbesserungen der Downloadgeschwindigkeit bieten. Version 2.2 wird direkt im Anschluss mit weiteren Funktionen kommen und Version 3.0 wird entwickelt, während der gesamte Rest dieses Prozesses stattfindet. Version 3.0 ist die komplette UI Überarbeitung und sollte viel näher am finalen Ergebnis liegen.

Der neue Build Server ist fast fertig. Die Freigabe mit den ersten Builds peilen wir intern für Mitte Juli und für die Öffentlichkeit für September an. Die Spieler sollten von der Umstellung eigentlich nichts merken. Für die Firma und die Entwickler jedoch sollten die Verbesserungen gewaltig sein. Es erlaubt uns nicht nur, mehrere Builds parallel zu erstellen und damit den Arbeitsdurchsatz zu erhöhen, sondern auch die Dauer, die die Entwickler auf einen Build warten müssen, zu reduzieren; der gesamte Buildprozess wird also beschleunigt. Zur Zeit dauert der Bau eines Builds vier Stunden und wir müssten zwischen sechs und acht Builds pro Tag erstellen, damit die Entwicklung adäquat voranschreiten kann. Wie ihr also erkennen könnt, benötigen wir mehr Zeit, als ein Tag zur Verfügung stellt. Dadurch staut sich die Builderstellung, arbeitet langsam und manche müssen übersprungen werden. Der neue Buildserver lässt uns zwei bis vier Builds gleichzeitig bauen; damit sollten sich die vier Stunden deutlich verkürzen. Um sagen zu können, wie lange eine Builderstellung dann wirklich dauern wird, müssen wir zu erst noch genaue Messungen durchführen.

Wie Chris Roberts in seinem letzten „Letter from the Chairman“ erwähnt hat, arbeiten wir an einem dynamischen Umgebungssystem namens „Phoenix“. Jedes Mal, wenn das Team einen neuen Build von Star Citizen startet, werden alle Daten, die der Server benötigt, automatisch auf Festplatten bei Google kopiert: ein Snapshot unserer Spieldateien also. Diese Daten teilen sich in: Base Image (das Betriebssystem plus ein paar andere Dinge), Logdateien und die Serverdateien (Code und Assets). Wenn wir eine Umgebung bauen, hängen wir Duplikate dieser Platten in eine VM (virtueller Server) ein, die wir nach Belieben hochfahren können. Kopien dieser Snapshots werden sehr schnell erstellt, ungefähr 45 Sekunden für 200 GB.
Wir haben ein Skript geschrieben, das automatisch Kommandos auf der VM ausführt und damit den Server entsprechend seiner Aufgabe konfiguriert (Game, Matchmaking, Party, etc.). Während des Prozesses wird dem Server ein neuer DNS Eintrag hinzugefügt, der auf der Version der hochgeladenen Daten basiert. Wenn also ein neuer Build erstellt wurde und wir ihn schnell hochladen müssen, lösen wir den Befehl aus: dieser fährt dann automatisch alle VMs herunter, dupliziert die Festplatten des Base Images und der Serverdaten (Logfiles werden für die Fehlersuche immer behalten), hängt sie aus und fährt dann den Server mit den neuen Kopien auf Basis des neuen Snapshots wieder hoch; die Umgebung läuft nun auf der neuen Version.

Der gesamte Prozess dauert ungefähr acht Minuten. Wenn wir eine auf diese Weise gebaute QA Umgebung verwenden wollen, um sie auf die PTU Umgebung auszurollen, senden wir einen Befehl an unsere Bereitstellungsschicht. Der Befehl wird weiter an Google gesendet, um mehr VMs bereit zu stellen: es werden mehr Kopien gebaut, die Snapshots eingehängt, der Adminbefehl ausgeführt, um sie zu konfigurieren, die DNS Einträge hinzugefügt und sie in bestehende Infrastruktur integriert. Ab diesem Zeitpunkt haben wir unsere PTU Umgebung. Wir wiederholen den Prozess zur Erstellung der Liveumgebung. Jedes Mal, wenn wir eine Serverumgebung erweitern, dauert es acht bis zehn Minuten, je nach Typ der Umgebung und der benötigen Konfigurationsanpassungen.

Der Vorteil dieser dynamischen Erstellung und der Umgebungserweiterung ist dreiteilig. Erstens: jede geänderte Konfiguration, verstellte Optionen oder defekter Prozess wird komplett entfernt, wenn die VM unter Verwendung der neuen Images wieder aufgebaut wird. Jede Konfigurationsänderung, die bestehen bleiben muss, sollte auf Adminebene vorgenommen werden. Zweitens: wir können absolut sicher sein, dass sich die PTU- und Liveumgebung in genau demselben Zustand befinden, in dem sie die Qualitätssicherung durchliefen; dadurch sollte es keine seltsamen Unterschiede geben, die wir im QA nicht erwischt haben. Der dritte Vorteil ist einfach Geschwindigkeit. Es ist deutlich schneller, Umgebungen auf die Schnelle dynamisch wieder aufzubauen als jedes Mal die Daten neu zu kopieren. Die letzten beiden Punkte sind wirklich wichtig. Wenn uns die Geschichte eines lehrt, dann, dass eine konsistente Testumgebung, die schnell ausgerollt werden kann, von entscheidender Bedeutung ist… und das neue System ist ziemlich schnell. Es ist ein riesiger Kraftmultiplikator für unsere Fähigkeit, Testversionen schnell zu iteratieren; das bedeutet, dass die Qualitätssicherung und damit schlussendlich auch unsere Unterstützer schneller abwechslungsreiche Dinge testen können. Je fehlerfreier wir Versionen für unser QA und unsere Backer zur Verfügung stellen können, desto besser können wir das Spiel letztendlich machen.

Juli sollte ein sehr spannender Monat werden, wenn einige dieser Großprojekte aus der Entwicklung in die Produktion gehen.

 

Foundry 42

Grüße Bürger,

Foundry 42 ist energiegeladen und bereit, weiter hart zu arbeiten! Wir waren mit der Unterstützung des P-Cap Shootings in London, der eigenständigen Entwicklung von Squadron 42 und den fortlaufenden Technikaufgaben für den Multicrew Arena Commander beschäftigt. Hier sind die Details unserer Abteilungsleiter:

 

Animationen

Wir haben damit begonnen, einige systematischen KI Animationen für gegnerische Aktionen aufzulockern. Dazu gehören Dinge wie Treppensteigen und von verschiedenen Winkeln in Deckung zu laufen oder auf Granaten zu reagieren und ihnen aus dem Weg zu gehen. Außerdem hat das Team einige der Mechaniken überarbeitet, die momentan ins Spiel eingebaut werden, um das Bewegungsgefühl zu verbessern, während die realistischen Motion Capture Daten beibehalten werden. Wie immer stehen wir hier bei Foundry 42 parat, dem Art und Design Team alle Block-Out Mechaniken und Umgebungsanimationen zur Verfügung zu stellen.

 

Technik

Es gibt zwei Bereiche, in die wir hier in der UK mehr und mehr involviert werden und über die ich diesen Monat gerne sprechen möchte, das User Interface und die KI.

Auf Seiten der KI nehmen wir eine aktivere Rolle in dessen Entwicklung ein und haben gemeinsam mit unseren Kollegen in Frankfurt und bei Moon Collider viel der grundlegenden Arbeit erledigt, das neue CIG KI System aufzusetzen und zum Laufen zu bringen. Wir haben uns auch unser neues Kommunikationssystem näher angesehen und wie wir es in Verbindung mit der jetzigen Dialoglogik nutzen können, um die Basisfunktionen zu erweitern, die den KI Charakteren Warlord und Vixen im Überlebensmodus des DFM gegeben wurde, und um das Cockpit Audio System (a.k.a. Bitching Betty) intelligenter zu machen.

Wir übernehmen auch einige der Cry-KI Funktionen in unser System und ändern diese dann ab, damit sie besser zu unseren Anforderungen passen. Vor kurzem haben wir so das Tactical Point System eingebaut, das Dinge wie Deckung und ein Gruppen KI System beinhaltet, das uns mehrere KI Objekte besser und einfacher handhaben lässt, vor allem in visuellen Gameplay Skripten (oder Flussgraphen, was auch immer Ihr präferiert!).

Am UI arbeiten wir schon eine geraume Zeit, jetzt haben wir aber mehr Verantwortung und mehr Arbeit übernommen. Wir vergößerten das Team mit einem neuen Künstler und einem Techniker. Mit dem neuen Techniker haben wir nun jemanden, der sich alleine auf die Erstellung der UI Anforderungen für Squadron 42 konzentrieren kann. Einige der vielen Funktionen, die wir auf diese Weise erstellen konnten, sind die Entwicklung des Interfaces für das taktische Visier und für das Plündern. Sie werden unterschiedliche Augmented Reality Einblendungen und Post Process Effekte benötigen, um Menschen und Gegenstände hervorzuheben und dem Spieler zusätzliche Informationen über die Welt um ihn herum zu geben. Wir haben außerdem eine Iteration für das Visier Display für Star Marine durchgeführt, weil jeder Helmtyp sein eigenes Aussehen und sein eigenes Feeling haben wird, die wiederum individuelle UI Setups benötigen.

Unser neuer Künstler arbeitet zur Zeit an der Stilentwicklung für die Schiffshersteller; parallel dazu wird dem Schiffs-UI Code viel Planungsarbeit unterzogen, damit er auch mit den Multicrew Schiffen und all den anderen Herausforderungen umgehen kann, die sich uns in den Weg stellen, z.B. die Fähigkeit des Kapitäns, verschiedene Steuerungsmöglichkeiten an den Copiloten oder den Geschützturmschützen zu delegieren (oder sie davon auszuschließen). Wir kümmern uns auch um die Planung, Spielern die Möglichkeit zu geben, ihre Display-Ausgaben in ihrem Cockpit zu individualisieren, indem sie verschiedene Ausgaben auf unterschiedliche Displays übertragen können. All diese Planung ist für die zugrundeliegende Struktur notwendig, um benötigte Funktionen unterstützen zu können; deshalb muss auch der UI Code neu überdacht und ein klein wenig refaktorisiert werden. Wir haben bereits den Großteil des hart-codierten Setups des UIs entfernt und es datengetriebener aufgestellt (durch Nutzung des DataForge Tools), aber wir wollen es noch flexibler gestalten, damit jedes Teil des HUDs an alles „angeheftet“ werden kann, das ein UI-Elemente anzeigen kann. So wird es plötzlich ziemlich einfach, das Radar aus dem Visier auf die Cockpitanzeige zu schieben. Das wird großartig!

 

Grafikabteilung

Das Grafikteam hat sich diesen Monat auf mehrere Bereiche konzentriert. Die technische Arbeit zum Zusammenführen der Meshes ging voran und wird nun in größeren Umgebungen wie Asteroidenfeldern getestet, um sicherzustellen, dass sie mit jeglicher Objektmenge umgehen kann. Das geht gut voran… die Technik sollte sehr bald für die Produktion bereitstehen; die Verwendung in den öffentlichen Releases wird Euch eine bessere Performance in den neuen Leveln bieten.

Wir haben einen neuen Senior Programmierer eingestellt, der am Rendering von volumetrischen Gaswolken, an Untersuchungen für das Rendering von dichten Wolken und dezentem Nebel mit anisotropischer Belichtung (der helle Rand, den ihr an Wolkengrenzen seht) arbeitet. Das wird eine Langzeit-Aufgabe sein, da es unglaublich komplex ist, allerdings ist es etwas, das wir unbedingt ins Spiel bringen wollen. Wir sehen uns auch Technologie für Gesichtsanimationen an, prüfen verschiedene Setups, um herauszufinden, wie weit wir diese Technik vorantreiben können, ohne dass die Framerates einbrechen. Dazu gehören Tests mit einer verschiedenen Anzahl von Polygonen, Gesichtsknochen/gelenken und Posen/Blend-Shapes (Veränderungen der Geometrie), die jeder Charakter nutzen kann. In diesem Rahmen haben wir auch unsere Möglichkeiten untersucht, wie wir das Rendern der Gesichter verbessern können; das ist keine leichte Aufgabe, wenn man gleichzeitig viele Charaktere auf dem Bildschirm darstellen muss. Wir können mit der Forschung und Entwicklung für dieses Gesichtsrendern hoffentlich nächsten Monat starten und freuen uns darauf, die Ergebnisse mit Euch zu teilen (gute, wie schlechte!).

 

Design

Juni war aufgrund der nahenden GamesCom ein arbeitsreicher Monat für uns. Wir arbeiten noch immer mit Hochdruck an Squadron 42, indem wir das Performance-Capture-Shooting mit kurzfristigen Levelanpassungen unterstützen, um sie so fantastisch wie nur irgend möglich aussehen zu lassen. Alle Gebiete sind mehr und mehr feingeschliffen, werden mit einem stetigen Strom großartig aussehender Gebäudeteile, die das Team für die Umgebungen solange überarbeiten, bis sie fantastisch aussehen, erweitert, während die Leveldesigner trotzdem die Möglichkeit haben, die Gebiete in einer glaubhaften Art und Weise zu entwerfen.

Wir hatten ein internes „Zeige-und-Erzähle“-Event diesen Monat, da viele neue Kollegen noch nicht den ganzen Star Citizen Plan in seiner gesamten Tiefe gesehen haben und ich kann wohl sagen, dass es erstaunlich gut lief, mit viel Staunen wegen der geplanten Spieltiefe. Es war einfach großartig zu sehen, wie viel Arbeit eigentlich in einer so kurzen Zeit bereits erledigt wurde.

Das technische Design Team wurde vergrößert und übernimmt nun Aufgaben vom FPS Waffen Balancing bis hin zur Implementierung der Vanduul Flotte in die Engine, von Großkampfschiffen bis hin zu Jägern.

Das Arena Commander Team hat inzwischen den „large-world“ Code von der Technik bekommen und fängt an, zu begreifen, was im Bezug auf die Größe des Universums alles erreicht werden kann; es sollte reichen zu sagen, dass ihr die Früchte ihrer Arbeit bald selbst sehen werdet.

Die Systemdesigner haben die Spezifikationen für mutlifunktionale Displays im Cockpit finalisiert, so dass die Funktionalität für alle Schiffe erweitert werden kann und vom Einsitzer bis hin zum Großkampfschiff völlig skalierbar ist. Das ist eine weitere dringende Aufgabe, die wir bis zur GamesCom erledigt haben möchten. Hoffentlich können wir Euch hierzu bald mehr Details zeigen.

Außerdem versuchen wir die erste Version des „Quantensprungs“ fertigzustellen, um für die Navigation durch die neuen großen Welten eine schnellere Reise zu ermöglichen; die Fortschritte sehen sehr vielversprechend aus.

Alles in allem war es ein bedeutender Monat für uns, aber ich habe das Gefühl, dass wir in den kommenden Monaten noch beschäftiger sein werden. Vielleicht wird es Zeit, eine Hängematte im Büro aufzuhängen. Wie immer vielen Dank an alle.

 

Art

Konzepte

Die Knüller diesen Monat waren die überarbeitete Bengal Brücke und der Minenbot, sowie die fortlaufenden Arbeiten an der Behring Ballistik Shotgun, dem Xi’an Transporter, der Vanduul Flotte und weiteren Konzeptvorschlägen für die Shubin Minen Basis und einige Piratenbasen, die für die Squadron 42 Geschichte benötigt werden (keine Spoiler!).

Schiffe

Es wurde diesen Monat weiter an der Retaliator gearbeitet, um sie flugfähig zu bekommen – das sind aufregende Zeiten! Argo RUV erreichte die finale Art Phase (ausgenommen dem Pod, der weiterer Überarbeitungen für die Filmsequenzen benötigt); auch die Idris sieht soweit gut aus, wir können es kaum erwarten, etwas von ihr zu zeigen. Die Cutlass kam unter Berücksichtigung der neuen Design Überarbeitungen in die Greybox Phase, der Minenbot befindet sich in der Textur- und Materialphase. Mit der Starfarer… geht es leider langsamer voran, als uns lieb ist; es ist eine Frage der Ressourcen, wir brauchen mehr talentierte Leute, die uns helfen, dieses Schiff zu bauen, da es komplexer als erwartet ist. Mit der Brücke der Bengal beginnen wir, sobald die Konzepte abgesegnet sind.

Umgebungen

Nur ein kurzes Update diesen Monat, da unsere Arbeit vorerst geheim bleiben muss. Wir kommen mit unserer VS Umgebung, den Hangars, Kontrollräumen, Korridoren, Luftschleusen und den Außenlandeplätzen gut voran – all das könnt ihr nahtlos durchlaufen. Hoffentlich können wir Euch bald einige der wirklich coolen Dinge zeigen, an denen wir gearbeitet haben, also bleibt dran!

Requisiten

Wir bekommen deutliche Angaben, die wir direkt extern beauftragen können, beschäftigen uns mit den Techniken, die für die Materialien nötig sind und uns momentan Probleme bereiten, aber nächsten Monat sollten wir durchstarten können.

 

VFX

Das VFX Team hat hart daran gearbeitet, mehr Schiffe flugfähig zu machen – das schließt Effekte für Triebwerke, Waffen und Beschädigungen ein. Vor allem die Effekte der Scythe sehen ziemlich „badass“ aus! Wir überarbeiten auch weiterhin die Umwelteffekte – sowohl innen wie außen – für den „Vertical Slice“. Wir haben uns auf die Waffen VFX in Star Marine konzentriert, um sicherzustellen, dass sie der Gesamtqualität der Level, Charaktere und natürlich Waffen entsprechen. Wahrlich aufregende Zeiten, um VFX Künstler bei Foundry 42 zu sein!!

 

Audio

Hallo zusammen! Dieser CIG Audio Community Report könnte sich etwas ziehen, es ist eine Menge los, aber ich denke, das sollten die interessantesten Teile sein.

Erstens Wwise: Was die Masse an Asset-Konvertierungen/Reengineering betrifft, sind wir fast fertig; zumindest ist das Ende in Sicht. Deshalb haben Stefan, Darren und ich etwas Zeit damit verbracht, mehr darüber nachzudenken, wie wir die Dinge so einstellen, dass wir das Spiel möglichst gut abmischen können. Wir können nicht die typische Strategie wählen, die wir für einen einmaligen Release verfolgen würden, weil sich das Spiel in einem ständigen Wandel befindet. Wir sollten die Grundlagen dessen haben, das uns gut dienen wird, und wir berücksichtigen die sich ständig verändernde Projektstruktur.

Auf audiotechnischer Seite stellen wir nach wie vor sicher, dass Dinge, die mal funktioniert haben, auch wieder funktionieren; und wir bügeln immer noch weitere aufkommende Bugs/Schwächen aus, die natürlich noch vorhanden sind. Es liegt auch eine gewisse Ironie in dem was wir tun, denn je mehr individuelle Sounds wir auf allen möglichen Systemen zum Laufen bringen, desto mehr tragen wir zu dem Problem bei, dass zu viele Sounds gleichzeitig abgespielt oder auf derselben Ebene verarbeitet werden müssen. Wwise hat zwar einige Möglichkeiten, mit solchen Situationen umzugehen, aber ideal wäre es, sicherzustellen, dass Wwise beim Verarbeiten von Elemente, die außerhalb der Interessenssphäre des Spielers liegen, gar nicht erst hängen bleibt. Im Kern geht es darum, etwas, das zu weit weg ist, um es hören zu können, in einen festhängenden Zustand zu bringen, aber nur in dem von uns benötigten Maße, um es, sobald es doch abgespielt werden muss, korrekt ablaufen zu lassen. Dabei gibt es alles Mögliche zu beachten, aber das ist unser momentaner Stand im Bezug auf die Kernaudiotechnik. Es ist nicht glamourös, ich weiß, aber es lässt die Dinge früher oder später runder laufen, wenn wir es richtig gemacht haben.

Es sind einige neue Schiffe auf dem Weg, an einem davon arbeitet Darren recht viel. Es benötigt neue Sprachaufzeichnungen für den Schiffscomputer und er prüft den UI Aspekt, entwirft Klänge und schaut, wie er sie am besten zusammen bekommt. Also viele der UIs im Spiel sind heutzutage irgendwie flash-basiert und das kann beim Implementieren des Sounds problematisch werden, wodurch wir nicht einfach Iterationen durchführen können. Deshalb müssen wir während dieser Arbeiten, auch über Möglichkeiten nachdenken, diese Pipeline zu verbessern.

Übrigens bzgl. des Origin Schiffscomputers: ich muss zugeben, dass ich beim Erfassen der vorherigen Essenz dessen, was den Schiffscomputer dieser Origin-Modelle so besonders gemacht hat, versagt habe. Im Grunde haben wir auf Euch gehört und das Feedback aufgenommen, das Ihr uns zu dem neuen Sound gegeben habt – und ich bin fest entschlossen, diese Essenz zurückzugewinnen. Ich bin nicht glücklich damit und es wird geändert!
Zum persistenten Universum können wir noch nicht so viel sagen, außer dass wir weiterhin beim Umgebungssound helfen.

Zum FPS: So viel davon ist an Wwise gebunden, es sind eine Menge neuer Inhalte für das FPS im Bezug auf Waffen, Charaktergeräusche und Dialoge notwendig, aber es geht gut voran. Wir können auch eine Menge neuer Musikinhalte für das FPS fertigstellen. Dementsprechend haben wir einen Arbeitsablauf getestet, bei dem unser Komponist, Pedro Macedo Camacho, in seinem Studio mit Wwise arbeitet und wir all seine Arbeiten bei uns nur noch importieren. In Bezug auf die Logistik ist es nicht sinnvoll, ihm vollen Zugriff auf unser Wwise Projekt zu geben (das ununterbrochen wächst), deshalb hat sich der Test dieses Ablaufs, bei dem er uns lediglich seine Projektdatei zur Verfügung stellt, wirklich gelohnt.

Es war eigentlich überraschend einfach, seine Arbeitseinheiten in unser Wwise Projekt zu importieren und hat mich denken lassen, dass es für diejenigen in unserer Modding Community, die ihre Mods/ihr Material in Star Citizen importieren möchten, auch ein passender Weg sein könnte. Neue Assets könnten durchaus von Moddern in Wwise produziert, dann für die Einbindung in das Wwise Projekt an uns geschickt werden, daraufhin exportieren wir die Sound Banks, etc. und schicken die Eventauslöser an Euch zurück. Auf den ersten Blick könnte es ein wenig unhandlich wirken, aber ich denke, letztlich ist es der einzige Weg, um eine qualitativ hochwertige Erfahrung sicherzustellen und mit der Community zusammen zu arbeiten – ich würde es liebend gerne ausprobieren.

Arena Commander (oder Dogfighting Modul): eine ganze Reihe Material wurde konvertiert oder in einigen Fällen auch komplett neu erstellt, damit es besser als bisher arbeitet. Als Audio Direktor kann ich derzeit nicht oft an Audioentwürfen arbeiten, das natürlich auf gewisse Weise eine Schande ist, ist es doch das, was mich im Kern ausmacht. Deshalb hat es sehr gut getan, Zeit für Arbeiten an Schiffssachen wie den Schubdrüsen zu arbeiten und auf materielle Weise zu einigen Thrusterentwürfen beizutragen! Luke hat meine Ergebnisse genommen und sie etwas verbessert; er ist sehr im Audioaspekt der Schiffe vertieft, daher ist es beruhigend, dass er meine Implementierungen in Ordnung gebracht hat. Generell bindet vieles von diesem Material die Zeit unserer Sounddesigner, da es im Moment der Löwenanteil von Star Citizen ist, es ist einfach viel zu tun, aber wir beißen uns gut durch.

Zurück zum Dialogsystem für Squadron 42. Unser Dialog Superman (kein offizieller Titel) Bob Rissolo ist in London immer noch fleißig. Er packt bald zusammen, zumindest vorerst; denn er wird bald fest hier bei Foundry 42 einziehen. Das ist ein großer Schritt für ihn, wir sind ihm nach wie vor enorm dankbar, dass er das sonnige San Diego für das eher, naja, variable Klima Manchesters eintauscht!

In Bezug auf unser Soundstudios: wenn Ihr das hier lest, werden wir bereits die neuen Türen dafür eingebaut haben. Ich weiß, es scheint so offensichtlich zu sein, Türen zu haben, und natürlich sind sie das auch, wenn man nicht gerade versucht, den Rest des Studios mit FPS Waffen Soundeffekten, Explosionen, usw. zu bombardieren. Aber wir mussten eine Weile auf die Herstellung eines bestimmten Satz Türen warten; wir hatten einfach Pech aufgrund werksseitiger Produktionsprobleme, weil jede Türe eine andere Farbe erhalten sollte. Ich weiß, das scheint albern zu sein, aber wenn ihr eine Reihe von isolierten Räumen habt und aus einer anderen Disziplin stammt, spart es Zeit, jemand zum „orangen Tonstudio“ zu schicken als ihm einen spezifischen Raum zu nennen, in dem jemand sein könnte oder auch nicht. Das bedeutet auch, dass wir die Zimmer in einem gewissen Maß tauschen können. Mein eigenes Büro wird als Referenzraum für den Rest des CIG Audio Teams verwendet, um zum Beispiel unsere Surround-Abmischungen testen zu können.

Momentan müssen wir auch auf die Verbesserung unserer Tools achten. Je besser unsere Tools sind, desto einfacher ist es für uns, Dinge zu optimieren. Wwise ist ein ereignisbasiertes System und von externen Ereignissen jeglicher Art Auslöser abhängig, um Töne auf bestimmte Weisen auszulösen. Zum Beispiel wollen wir neben der regulären Soundausgabe für Schubdüsen für den Übergang von Null- auf Vollschub bestimmte einmalige Sounds abspielen. Und dann verschiedene einmalige Ereignisse auslösen, wenn die exakt selbe Schubdüse von Voll- auf Nullschub zurückschaltet. Und das ist ehrlich gesagt, etwas schwierig „in the box“ umzusetzen, in diesem Fall ist die Box Wwise. Deshalb wollen wir in der Lage sein, diese Ereignisse einfacher und eher als Designer denn als Programmierer zu erstellen; es gibt also ein komplettes Tool-Set, um das wir uns in Anbetracht der Logikdefinition kümmern müssen. Das ist nur eines der vielen Tools, die wir für notwendig erachten.

Wir bereiten uns darauf vor, wieder zu Pinewood zurückzukehren, um eine ganze Reihe notwendiger Bausteine für die Schiffe aufzunehmen. Ihr werdet Euch vielleicht erinnern, dass sie bereits gemeinsam mit uns an den Charaktergeräsuchen für das FPS gearbeitet haben. Es gibt eine neue Bibliothek von rasslenden, bebenden Materialien, die wir uns auch ansehen werden (man kann nie genug Quellen haben), aber wir wollen auch sicherstellen, dass unsere Bibliotheken etwas mehr auf unsere konkreten Anforderungen zugeschnitten sind. Dafür werden wir uns „den Arsch aufreißen“, das ist sicher.

Ich bin mir sicher, dass ich in diesem Update noch Dinge vergessen habe, tut Euch keinen Zwang an und stellt uns im „Ask a Dev“ Forum mehr Fragen; wir tun weiterhin unser Bestes, darauf zu antworten. Vielen Dank fürs Lesen!

 

Qualitätssicherung

Das UK QA Team musste seine Bemühungen diesen Monat aufteilen, um sich mit den kommenden Großveranstaltungen und Releases befassen zu können. Star Marine (FPS Modul) und die Vorbereitungen für die GamesCom stehen in naher Zukunft an und die Tests an Squadron 42 gehen unverändert weiter.

Im Fokus stand Star Marine, um dort die großen Multiplayer Bugs aufzuspüren und alle generellen Verbesserungsmöglichkeiten zu finden. Glenn Kneale aus GB und Tyler Witkin aus Austin/Texas haben zusammengearbeitet, um sicherzustellen, dass dieser Spielmodus ausführlich getestet wird. Es gibt über verschiedene Studios hinweg Stresstests, um die Stabilität sicherzustellen, bevor es online geht.

Wir konzentrieren uns darauf, die Abschnitte zu testen, die auf der GamesCom gezeigt werden sollen. Unglücklicherweise können wir Euch hier nicht mehr erzählen, aber wir sind alle sehr aufgeregt wie Ihr das, was bisher geplant ist, aufnehmen werdet.
Abschließend widmen wir Squadron 42 immer mehr Testzeit, da das Spiel kontinuierlich fortschreitet und wir gewährleisten müssen, dass die neuen Mechaniken und Alpha Levels funktionieren. Wir wenden auch etwas mehr Zeit für die Erstellung der Dokumentationen auf, um die Squadron 42 Tests ausweiten zu können.

Steven Brennon hat Euer Feedback gesammelt und sichergestellt, dass es entsprechend aufbereitet an die relevanten Personen weitergeleitet wird.

Leider verlieren wir Chris „Chill“ Hill am Ende des Monats. Wir wünschen ihm alles Gute, da er, seit er letztes Jahr zu uns gestoßen ist, einfach fantastisch war; wir werden aber Steven Brennon zu einem würdigen Nachfolger ausbilden.

 

Foundry 42 Frankfurt

Juni war für alle Abteilungen ein arbeitsreicher Monat und dabei wächst das Team noch rasant. Wir haben diesen Monat viele Bewerbungen erhalten und wir arbeiten uns langsam Stück für Stück vor. Außerdem haben wir unsere neuen Büroräume geplant, soweit ist alles vorbereitet und am 1. Juli erhalten wir den Schlüssel für unser neues permanentes Büro! Wir sorgen dafür, dass jeder von der neuen Location erfährt, falls mal jemand vorbeikommen und Hallo sagen möchte… mit Vorankündigung natürlich.

 

Technik

Das Frankfurter Technikteam konnte dem Hauptcode im Juni einige wichtige und bereits geplante Elemente hinzufügen. Wie letzten Monat bereits erwähnt, haben die großen Welten (Konvertierung des Codes in 64 Bit Koordinaten), die relative Kameraführung (Rendern der Koordinaten relativ zur Kamera, wodurch das Rendern einer Galaxie ohne Präzisionsverlust ermöglicht wird) und das Zonensystem (das neue Star Citizen Raumaufteilungsschema, das CryEngine Octree ablöst) den Weg in den Hauptcode von Star Citizen gefunden; damit dürften sie bald auch in den verschiedenen Star Citizen Modulen auftauchen.

Während wir das schreiben, werden die relevanten CryEngine 3.7 SDK Teile zusammen mit unseren eigenen Änderungen in den Hauptcode integriert. Zusätzlich war die Unterstützung der Multi-Crew Schiffe diesen Monat sehr anstrengend: im Kontext der Steuerung eines beweglichen Schiffes wurde in Kombination mit dem Zonensystem am lokalen Physiknetz, einem Physik Debugger, Entitäten und Fertigbauten sowie der Unterstützung der neuen 3D VisArea Shapes gearbeitet. Unter anderem enthüllte die MultiCrew Entwicklung einige Bugs und falsche Funktionalitäten, die schon seit Jahren in der Codebasis der CryEngine vorhanden sind…

Wir arbeiten weiterhin an der Optimierungen, der Verbesserung des Speicherformats, Bugfixes, Aufräumarbeiten und der generellen Engine Unterstützung für andere CIG Studios.

 

KI

Das KI Entwicklungsteam hat sich im Juni hauptsächlich auf das Basissystem konzentriert, das für die Bewegungsmöglichkeit der menschlichen Charaktere durch die gesamte Spielwelt nötig ist.

Wir haben die Integrationsphase des CryEngine MNM Navigationssystems und des multithreaded MNM Pathfinders (Wegfinder) abgeschlossen. Außerdem konnten wir das CryEngine Bewegungssystem mit dem derzeitigen Verhaltensbaumsystem verbinden. Das Bewegungssystem achtet darauf, die Wege, die vom MNM Pathfollower zurückgegeben werden, zu analysieren und einen Plan festzulegen, wie die dafür nötige Bewegung ausgeführt werden muss.

Stellen wir uns einen Charakter vor, der sich in Deckung begeben muss, der NPC muss also einem Weg folgen, bis er die Deckung erreicht hat und dann in die richtige Haltung gehen, um auch tatsächlich hinter der Deckung zu sein. Das Bewegungssystem ermöglicht einen korrekten Zusammenhang zwischen der Anforderung und der Ausführung der Bewegung, wodurch wir die notwendigen Schritte vorhersagen können, die der NPC vornehmen muss, um am Ende auch in der „hinter der Deckung“-Position zu sein.

Wir befinden uns mitten in der Integration unserer neuen Verhaltensweisen in das CryEngine „Tactical Point System“. Das Tactical Point System (TPS) ist ein Abfrage-System, das uns erlaubt, bestimmte Positionen mit spezifischen Eigenschaften abzufragen.

Neben der Entwicklung dieser Systeme kümmern wir uns auch um die Erstellung des gesamten Verbindungscodes zwischen den Systemen, um den NPCs die bestmögliche Erscheinungsqualität zukommen zu lassen.
Und wir werden auch weiterhin die Verbesserungen des Kythera Verhaltensbaumsystem und dessen Integration in DataForge koordinieren.

 

Design

Diesen Monat hat das DE Design Team die meiste Zeit damit verbracht, an vier Themen zu arbeiten: dem Bau eines Levels für Squadron 42, dem Unterstützen des FPS Modul Releases, dem Erstellen von KI Verhaltensbäumen für das FPS Modul, Squadron 42 und das Persistente Universum, sowie dem gemeinsamen Arbeiten mit dem UK Team an Squadron 42 Level Feedback. Wir bewerten a) die Mission & Begegnung, welche sie zum Testen gebaut haben, b) den Nutzen von Instrumenten für ein Level, c) die Level Gestaltung und d) spontane Spielideen.

 

Animationen

Derzeit gibt es im DE Büro nur einen Animator, der sich voll auf die Filmsequenzen konzentriert. Diesen Monat hat er an der Erstellung der Szenen für die geskripteten Events und in-game Cutscenes, an der Identifizierung von Pipeline Tools und an der Dokumentation und dem Review des Squadron 42 Skripts (gemeinsam mit dem Cinematic Director) gearbeitet, um die Szenen auszusortieren, die für die Filmsequenzen genutzt werden sollen.

 

Filmsequenzen

Hannes ist von einem langen Cinematic Shooting zurück. Er wird ab nächstem Monat auch etwas im Monthly Report schreiben können. Sie hatten einige wirklich talentierte Schauspieler am Set, die unglaubliche Leistungen abgeliefert haben. Wir freuen uns intern darauf, das alles auf die Beine stellen zu können, und ich bin mir sicher, die Backer tun das auch.

 

Audio

Im Audiobereich gibt es diesen Monat nicht viel neues, wir arbeiten noch immer an der Wwise Umstellung, die letzten Monat begann. Wir haben die EVA Thruster und Effekte der Schiffsschilde bereits an Wwise angebunden und einige durch den Sound verursachte Bugs behoben. Wir haben nun damit begonnen, die distanzbasierte Keulung (culling) von aktiven Soundquellen zu verbessern, damit die Sound Designer mehr detaillierte Klanglandschaften erstellen können, ohne die Sound Engine zu überlasten.

 

Build System

Im Juni besuchte der Senior Build Techniker unser Studio in Austin/Texas (ATX) für drei Wochen und arbeitete eng mit dem Dev Ops/IT Team an vielen Aspekten unseres Buildprozess, an Optimierungen und an dessen studio-übergreifender Auslieferung. Neben vielen anderen Dingen war das Hauptziel die Dauer, die für den Bau eines Build, eines Patches, der Bereitstellung eines Servers, usw. zu verkürzen.

Wir haben beschlossen, vom aktuellen Buildsystem zu Gunsten von etwas Neuem abzurücken; wir sind zuversichtlich, dass uns das neue System deutlich mehr Anpassungsmöglichkeiten bietet, um es unseren Spielbedürfnissen maßzuschneidern. All das befindet sich zwar noch im Aufbau, viel haben wir aber bereits geschafft und in den nächsten Wochen wird noch viel mehr folgen.

 

FX

Im letzten Monat haben wir hart an verschiedenen Squadron 42 Effekten gearbeitet. Einer dieser Effekte ist ein riesiger Plasmabohrer. Es wird dafür genutzt, Asteroiden für die Rohstoffgewinnung in kleinere Stücke zu brechen.

 

BHVR

Grüße Bürger!

Ein weiterer kompletter Monat ist vorbei und wir waren sehr beschäftigt!

 

Technik

Wie immer hat sich ein Teil des Teams auf die Entwicklung kurzfristiger Ziele konzentriert, wie der Unterstützung für die FPS Lobby. Langsam aber sicher kommen wir davon aber weg, da es alles kann, was die erste Version können sollte, und beginnen mit der Implementierung von MultiCrew-Schiffen in die Oberfläche der Lobby.

Der Monat Juni brachte uns ein paar großartige Funktionen von anderen Studios, die uns erlauben, uns zeitgleich um mehrere Funktionen für den Online Hangar zu beschäftigen. Wir arbeiten hart an dem derzeit integrierten Holotable, um die Anzahl der Schiffe zu reduzieren, die im Spiel gespawnt werden müssen, um den Arena Commander nutzen zu können. Das erlaubt uns, sowohl die Ladezeiten als auch den Verwaltungsaufwand für auf den Servern gehostete Hangars zu reduzieren. Wir haben auch einen Teil der Flair Integration überarbeitet und deren Spawnen im Hangar sollte dahingehend nun richtig funktionieren.

Das Planetside Modul wurde sich natürlich nicht selbst überlassen, wir haben noch daran gearbeitet, weitere Funktionen hinzuzufügen und das Level der Augmented Reality (AR) Erfahrung mit dem mobiGlas sowie die Shoppingerfahrung als Ganzes zu verbessern.

 

Design

Das Design Team hat sich um die Einrichtung der Aufzüge und Türen für das System Nyx und verschiedene Funktionen (zum Beispiel dynamisches Spawning, mobiGlas AR Tags und Text String Lokalisierungen) für die im Casaba Outlet vorkommenden Gegenstände gekümmert. Darüber hinaus haben wir uns auch mit den Folgearbeiten der Shopping Erfahrung, den Flair Objekten und den Leveldesign-Bauplänen für Hurston, Crusader und Microtech beschäftigt.

 

Art

Diesen Monat haben wir jede Menge Arbeit in das Aufpolieren der Nyx Asteroidenkarte, der Verbesserung von Materialien/Texturen und dem Füllen der Umgebung gesteckt, um sicherzustellen, dass jeder Raum seine eigene Geschichte erzählt. Wir arbeiteten auch an der Verbesserung einer unserer vorherigen Karten, überarbeiteten das Layout, um die Navigation und Performance zu verbessern.

Auch dem Shopsystem wurden zusätzliche Anstrengungen zuteil. Wir haben für die bessere Erkennung durch Spieler die Platzierungsdetails der Kleidung in Regalen hinzugefügt.

Schließlich haben wir, wie immer, das nächste Flair Objekt fertiggestellt. Viel Spaß!

 

Benutzerinterface

Das UI Team hat ein wenig Frühjahrsputz betrieben (dafür ist es nie zu spät!). Wir haben an einer gründlichen Überprüfung des Ablaufs für das neuen Holotable Design gearbeitet, um die gesamte Benutzererfahrung zu verbessern und verschiedene Bildschirme zu vereinheitlichen. Dasselbe gilt für das Simpod Interface (auch bekannt als Electronic Access). Wir haben auch einige der niedrig priorisierten Aufgaben abgearbeitet, die langsam aber sicher Überhand genommen hatten.

Bis zum nächsten Mal, Bürger!

 

Illfonic

Hallo Bürger!

Ein weiterer Monat, ein weiteres Update. Im letzten Monat ist ziemlich viel passiert. Im Moment haben wir drei Gäste von CIG (Sean Tracy, Steve Bender und Jason Hutchins) hier in Denver zu Besuch, die uns so gut sie können helfen. Wir konzentrieren uns derzeit darauf, die zentralen Fortbewegungsmöglichkeiten so stabil wie möglich zu bekommen, während sie gleichzeitig noch sowohl in der ersten als auch dritten Personenansicht großartig aussehen sollen. Das ist mit den vorhandenen Mitteln gar nicht so einfach, deshalb haben wir Verstärkung bekommen! Ihr könnt weitere Informationen zum FPS Modul in den letzten Star Marine Status Updates erhalten.

 

Technik

Im letzten Monat hat sich die Technik hauptsächlich auf die zentralen Fortbewegungsanimationen und das Start/Stop/Finten-System konzentriert. Das setzte eine enge Zusammenarbeit mit den Animatoren und Designern voraus, um die absolut bestmögliche Balance zwischen Bewegungsrückmeldung und Animationsqualität zu finden. All das musste dann erstens funktionieren und zweitens auch für die erste und dritte Personenansicht optimiert werden. Ergänzend zu den zentralen Fortbewegungsanimationen, wurden auch Regeln für Star Marine erstellt, damit es auf dieselbe Weise wie der Arena Commander, Statistiken für das Leaderboard und den Erhalt von REC meldet. Schließlich wurden fünf verschiedene Bewegungsgeschwindigkeiten implementiert. Dadurch bewegt man sich mit einem Controller sehr flüssig und variabel, je nachdem wie stark man den Stick neigt.

 

Animationen

Das Animationsteam hat sich vollständig drauf konzentriert, alle Start-, Stop- und Fintenbewegungen so gut wie möglich aussehen zu lassen. Dafür war vor allem eine schnelle Rückmeldungsrunde mit Steve Bender nötig: sein Feedback erhalten, Änderungen umsetzen und ihm alles zurückschicken – solange, bis jeder mit dem Ergebnis zufrieden war. Das sicherzustellen ist viel Arbeit, aber das Team hier hat sehr gut gearbeitet und das Tempo unserer Arbeit ist beinahe täglich gestiegen, nachdem wir die entsprechenden Prozesse verstanden hatten.

 

Art

Das Art Team arbeitete an der Verbesserung aller Assetstücke für die Gold Horizon Station und der Feinabstimmung dieser Assets, damit sie zu den Maßen passen, die drüben bei Foundry 42 genutzt werden. Das ist nicht unbedingt die interessanteste Arbeit, aber sie ist auf lange Sicht für das Persistente Universum und Squadron 42 nötig.

 

Design

Das Design Team hat auf Bitten von CIG zahlreiche Optimierungen am Gold Horizon Level vorgenommen. Dazu gehören Verbesserungen an den Standorten für Munition- und Energieauffüllung, die Entfernung einiger Türen und einige andere Verhaltensänderungen im Level. Zusätzlich wurden die Sichtlinien und Deckungsmöglichkeiten im gesamten Bereich optimiert.

Das ist alles, was ich diesen Monat für euch Jungs und Mädels habe. Bis zum nächsten Mal!

 

Turbulent

Das ist letzten Monat bei uns passiert:

 

Jump Point Interview

Vorab: unser Team hatte diesen Monat die Möglichkeit, an einem Interview für die nächste Jump Point Ausgabe teilzunehmen. Dadurch konnten wir einige unserer Projekte, an denen wir für Star Citizen arbeiten, ausführlicher darstellen und etwas Licht ins Dunkel bringen, was als nächstes kommen wird. Vielen Dank an David Ladyman, dass wir sehr viel detaillierter (und auf leicht informelleren Wege) den Prozess der Neugestaltung des globalen Websitendesigns eingehen konnten.

 

Starmap

Diesen Monat haben wir den Hauptteil des Starmap Viewers inkl. Galaxie- und Systemansichten fertiggestellt. In Bezug auf das Interface haben wir signifikante Änderungen sowohl am HUD als auch den Filteroptionen (Sensoren und Hitzesignaturen) vorgenommen.

Außerdem konnten wir gute Fortschritte beim modellieren der Daten für die bevorstehende Galactapedia erzielen. Wir arbeiteten auch an unseren Verwaltungstools, damit wir Daten aus dem Star Citizen Universum importieren können. Das funktioniert für alle möglichen Himmelskörper, die bereits ein Galactapedia Format besitzen.

An der 3D Front haben wir mit der Produktion verschiedener Assets begonnen, die im WebGL Viewer (Planeten, Sprunglöcher, Weltraumstationen, etc.) angezeigt werden. Das ist sehr arbeitsintensiv und das, was der Benutzer auf seinem Bildschirm sehen wird, deshalb werden wir daran auch die nächsten paar Monate noch arbeiten.

 

Issue Council

Wie beim letzten Mal berichtet, haben wir das Issue Council kontinuierlich weiter entwickelt, um sicherzustellen, dass die Menge an Zeit und Aufwand für jeden, der darin involviert ist, drastisch reduziert werden kann. Wir haben auch versucht, sicherzustellen, dass sie nicht durch große Benutzergruppen (wie Organisationen) beeinflusst werden. Wir haben einige Funktionen hinzugefügt, das Layout neu organisiert, Dinge von einer auf eine andere Seite verschoben, Seiten entfernt, uvm. – wir haben so viel gemacht, dass wir einen Schritt zurücktreten mussten, um zu sehen, dass das Interface nicht länger intuitiv zu handhaben ist. Also haben wir ein großes Team um ein Whiteboard versammelt und an Lösungen gearbeitet.

Die ausgearbeitete Hauptaktualisierung war eine überarbeitete Version des Flows der Benutzer. Sobald man beim Issue Council landet, können die Benutzer auf drei Arten das System betreten:

• Beiträge leisten, indem versucht wird, Probleme zu replizieren und ungültige Tickets (Duplikate, Feature Requests, schlecht Geschriebenes, usw.) zu markieren.
• Bestätigte Tickets priorisieren, um den Entwicklern zu zeigen, was der Community wichtig ist.
• Nach allen Tickets suchen, die je erstellt wurden.

Wir sollten bald einen Entwurf haben, den wir mit Euch teilen können, aber um Euch jetzt schon mal einen Einblick zu geben, findet Ihr hier ein Foto von Benoits Whiteboard Designs.

 

Community Hub

Der Community Hub hat seine finale Phase erreicht; unsere Entwickler haben eigentlich den gesamten Monat an seiner Implementierung gearbeitet. Die erwähnenswerteste Hauptunternehmung an diesem speziellen Projekt bestand in den untergeordneten Strömen. Diese erlauben Euch, Bilder hochzuladen, eigene Galerien zu erstellen, Eure YouTube Spielesessions einzubetten oder interessante Links zu teilen, die Ihr irgendwo gefunden habt; all das erfordert eine hohe technische Flexibilität von der Website selbst. Noch viel interessanter war, dass wir uns einige Zeit mit der Ausarbeitung von Filter- und Sortierungs-Algorithmen beschäftigt haben, die auf der Menge und Häufigkeit der geschriebenen Inhalte und auf der Popularität basieren, die durch Votes und Kommentare beeinflusst wird. Es ist immer eine spannende Herausforderung, einen Weg zu entwickeln, wie die Website ihre eigenen Inhalte darstellen kann und sie dabei so schlank und aktuell wie möglich zu halten.

 

Moderation Tools

Ein anderes Projekt, an dem wir gearbeitet haben und das inzwischen bereits gestartet ist, waren die neuen Moderationstools für das dedizierte Moderatorenteam der Website. Diese Werkzeuge geben ihnen jetzt mehr Einblicke in die gekennzeichneten Inhalte, Wiederholungstäter und verrufene Wiederholungstäter sowie eine schnellere Möglichkeit, den Forenzugang zu managen. Das erlaubt ihnen, die Foren, Kommentare und Organisationen deutlich geschmeidiger und effizienter am Laufen zu halten. Mit ihrer Hilfe haben wir ein Toolset entwickelt, das sich erweitern lässt, um alle von Benutzer erstellte Inhalte abzudecken – natürlich auch inkl. aller Aspekte des bevorstehenden Community Hubs.

Der Konzeptsale diesen Monat war eine Kurzgeschichte, die den von Meridian Transit betriebenen Genesis Starliner präsentierte. Diese kurzen Schnulzen (los, lest die Postkarten) wurden von Star Citizens eigenen Autoren geschrieben und gemeinsam mit einigen ziemlichen coolen Künstlern und Stimmen aus dem Communityteam erstellt – wir hatten wirklich viel Spaß dabei. Dadurch ist es schnell zu einer der am skript-lastigsten Seiten auf der Website geworden, mit Minikomponenten wie dem Abflugbildschirm oder den tollen Postkarten. Der Abflugbildschirm selbst basiert auf einem sehr frühen Konzept für Eventblocks auf der Website, die wir gerne schon veröffentlicht hätten; sie sind aber zu anspruchsvoll für die aktuellen Browser. Deshalb waren wir wirklich froh, dass sie zumindest als Teil der Kurzgeschichte verwendet werden konnte.

 

What you didn’t see

Genau wie in jedem anderen Monat waren unsere Programmierer wieder mit Verbesserungen und Korrekturen beauftragt, die unbemerkt blieben – glücklicherweise. Das prominenteste Beispiel im Juni sind unsere verwendeten Bezahlmethoden: Amazon hat ihr gesamtes Bezahlsystem migriert, wodurch wir Anpassungen vornehmen mussten, bis hin zur Umstellung auf eine völlig neue Art des Umgangs mit Abonnements. Auch eine andere Methode, die eig. ungenannt bleiben sollte, *hust* PayPal *hust* hatte einige interessante Überraschungen für uns parat, auf die wir ziemlich schnell reagieren mussten. Zusätzlich haben wir der Bereitstellung neuer Tools für den Kundenservice etwas Zeit gewidmet, damit sie noch effektiver mit Problemtickets umgehen können.

 

Moon Collider

Das war ein weiterer arbeitsreicher Monat bei Moon Collider, also lasst uns sofort beginnen:

 

Technik

Es ist eine bekannte Redensart, dass kein Plan den Feindkontakt übersteht und ich denke, das gilt ebenso für „kein Tool übersteht den Designerkontakt“! Egal, wie gut man ein neues Tool plant, in dem Moment, in dem die Designer anfangen damit rumzuspielen, findest du sehr schnell heraus, was noch verbessert werden muss. Letzten Monat erst gaben wir den Designern die Möglichkeit, Verhaltensbäume mittels eines in DataForge (das selbsterstellte Datenmanagementtool für Star Citizen) integrierten Editors zu schreiben. Wir hatten versucht, dies so schnell wie möglich in die Hände der Designer zu übergeben, deshalb hatten wir bereits eine entsprechende To Do Liste mit nötigen Verbesserungen, aber ein paar Stunden realer Benutzung des Tools durch einen Designer schaffen Klarheit, welche Probleme kleinere Ärgernisse sind und welche häufig ihre Arbeitsabläufe unterbrechen oder sie daran hindern, bestimmte Aufgaben durchzuführen.

Wir verbrachten etwas Zeit mit dem Einsammeln von Feedback der Designer und dem Durcharbeiten ihrer Prioritätsliste der Probleme mit dem neuen Editor. Das beinhaltet teils so einfache Dinge wie dem Schreiben weiterer Dokumentationen, wie bestimmte Bestandteile funktionieren, das Umbenennen, Rekategorisieren und Neufärben der BT Knoten, um für einen intuitiveren Umgang für die Designer zu sorgen. Wir haben aber auch bestimmte Funktionsstücke aus dem Standardarbeitsablauf entfernt, wodurch es zwar umständlicher ist, diese selten benötigte Features zu nutzen, aber dafür die häufig benutzten Features gestrafft werden. Wir dürften das Tool im nächsten Monat durch weiteres Feedback der Designer weiter verbessern können.

Jetzt, da die Designer selbst mit Verhaltensbäumen in DataForge arbeiten können, war es der perfekte Augenblick, unserem webbasierten Debugging Tool „Kythera Inspector“ eine Live Ansicht für Verhaltensbäume hinzuzufügen. Dabei handelt es sich um eine Website, die Designer aufrufen können und der ihnen direkten Zugriff auf den Status ihrer KI im Spiel gibt; wir erweitern ihn ständig mit neuen Funktionen, um das Debuggen der KI noch einfacher zu machen. Bisher haben wir uns auf einige einfache Bildschirmtexte zum Debuggen verlassen, um den aktuellen Stand des KI Verhaltensbaum zu verstehen; das funktioniert für einen kleinen und einfachen Baum recht gut, war aber für größere Bäume sehr viel weniger nützlich und auch in der Informationsdarstellung beschränkt.

Die neue Liveansicht im Inspector erlaubt es Designern, den Stand eines Verhaltensbaums jeder KI während des laufenden Spiels zu sehen. Im nächsten Monat fügen wir weitere Funktionen hinzu, durch die Designer Konfigurationsfehler in ihren Bäumen besser nachverfolgen können; nutzen sie zusätzlich noch die bereits vorhandenen Möglichkeiten des Aufnehmens und Abspielens von Verhaltensbäumen, erhalten sie eine umfassende Toolsammlung zum Debuggen ihrer Verhaltensbäume.

Ein Problem, mit dem wir uns etwas herumschlagen mussten, ist eine technische Funktion, die wir „string hash“ nennen. Das ist etwas, das in Kythera integriert ist und uns im Grunde erlaubt, jede Textzeichenfolge im Code beim kompilieren in eine numerische Kennung zu konvertieren. Das macht es einfach und effizient, Strings dem Code zu übergeben und sie zu benutzen, ohne sich Gedanken darüber zu machen, wie schwierig die Abgleiche sind; das ist nämlich eig. bei der Benutzung von Strings der Fall. Und das bedeutet, dass viel mehr beschreibender Text an den Code übergeben werden kann als nur einfache Zahlen; das wiederum vereinfacht die Arbeit mit dem Code und dessen Debugging.

Weil das eine so nützliche Funktion ist, wurde der restlichen Star Citizen Codebasis eine ähnliche Version hinzugefügt. Wir versuchten herauszuarbeiten, wie diese zwei verschiedenen Versionen der String Hashes am besten vereinheitlicht werden können, um die Kosten der Umwandlung zwischen ihnen zu verringern. Es gibt verschiedene Einzelheiten, die eine befriedingende Lösung schwierger gestalteten als es anfänglich schien; also haben wir Zeit damit verbracht, das Problem mit den Codern in einigen der anderen Studios auszuarbeiten und können aktuell einige mögliche Lösungen testen und prüfen, ob damit in der Praxis Probleme auftreten.

Nun lasst uns über Schiffe sprechen!

Letzten Monat fügten wir eine Funktion hinzu, die es Schiffen erlaubt, bestimmten Splines zu folgen. Diesen Monat haben wir das gleich in Form von „retreat stunt splines“ genutzt (Rückzugs-Routen). Stunt Splines sind Pfade, die von Designern im Level vorgegeben sind und der KI ermöglichen, durch enge Bereiche zu fliegen, die sie sonst aufgrund ihres Kollisionswarnungssystem meiden würden (wie zum Beispiel durch einen Tunnel in einem Asteroiden oder Lücken zwischen Abschnitten einer Raumstation).

Eines der Hauptziele dieser Stunt Splines ist es, dem Spieler die Möglichkeit zu geben, KI Gegner durch interessante und aufregende Bereiche zu jagen. Wir fügten sie dem KI Rückzugsverhalten hinzu, wodurch ein KI Schiff versucht, einen nahegelegenen Stunt Spline zu nutzen, sollte er von seinem Verfolger fliehen wollen. Um das glaubhaft darstellen zu können, wird die KI diese Splines nur wählen, wenn sie schnell dorthin kommen kann, damit sie nicht erst große Veränderungen an Geschwindigkeit oder Richtung vornehmen muss, um sie nutzen zu können.

Wir können sie auch verwenden, um KI Elite Piloten von Rookies zu unterscheiden, indem jedem Spline ein bestimmtes Skilllevel hinzugefügt wird. Ein richtig haariges Manvör kann also so markiert werden, dass es nur für die besten Piloten verfügbar ist. Das bedeutet auch, dass Du dich, wenn Du ein flüchtendes Elite Schiff verfolgst, in einer Verfolgung befindest, in der Du für einen Abschuss nicht gut genug sein kannst; dann musst Du eine schnelle Entscheidung treffen, wie verrückt Du als Pilot wirklich sein willst!

Sobald die Designer die Möglichkeit hatten, mit dieser Funktion zu arbeiten, planen wir, einige Anpassungen an dem Spline-Auswahl-Prozess vorzunehmen, um eine gute Balance zu finden, bei der die Splines nicht zu viel, aber auch nicht zu wenig genutzt werden. Es ist wichtig, dass die KI für einen Spieler, der die Karte kennt, nicht zu vorhersehbar wird. Auf der anderen Seite kann es aber auch zu vorhersehbar sein, wenn Du ein Schiff siehst, dass ausbricht und auf einen Tunnel zufliegt, von dem Du weißt, dass es spaßig sein wird, hindurchzufliegen.

Wie immer bei neuen Funktion freuen wir uns darauf, sie in die Hände von echten Spielern bringen zu können und uns dann die Geschichten, die daraus entstehen, anzuhören!

 

Community

Grüße Bürger,

wir sagen ständig, dass es ein arbeitsreicher Monat für das Community Team war, aber dieses Mal… welcher Monat ist nicht arbeitsreich?

Wir waren ziemlich glücklich, den ersten Jahrestag Around the Verse feiern zu können! AtV war ein interessantes Projekt für uns; letztes Jahr haben wir uns ein wenig davor gefürchtet, in die Fußstapfen der beliebten Show „Wingmans Hangar“ zu treten… aber wir nahmen uns Zeit, herauszufinden, was Euch wichtig ist. Dank Eurer Rückmeldung (und Eurer Unterstützung!) können wir auf das, was aus der Show geworden ist, stolz sein… und wir versuchen weiter, sie noch besser zu machen. In Episode 50, die letzte Woche ausgestrahlt wurde, gab es ein besonderes Segment, in dem Designer Randy Vasquez den Bauprozess des Starliner Interieurs zeigte. Ihr könnt in Zukunft mehr solcher Segmente erwarten, da wir es für unser bisher bestes Video halten.

Außerdem haben wir das Community Team gebeten, interaktivier im Forum zu sein. Wir sind genauso begierig auf den Star Marine Release wie der Rest der Community; wir geben unser Bestes, da raus zu gehen und nicht nur Farbe zu bekennen, sondern auch unsere Antworten und Gedanken mit Euch allen zu teilen.
Ein Community Manager kann Eure Fragen nicht immer beantworten… aber wir sind hier, um alles zu thematisieren, was wir können, Eure Sorgen anzuhören und sicherzustellen, dass sich die Entwickler all dessen bewusst sind. Und noch besser: wir arbeiten an einem Relaunch des „Ask a Dev“ Prozesses, der hoffentlich dazu führt, dass Eure Fragen auch vom richtigen Experten beantwortet werden.

Das gesamte Team hatte mit dem Genesis Starliner Verkauf einen großen Tag. Wir wollten vermitteln, wie viel Tiefe es bei dem Schiff gibt; das gesamte Team arbeitete zusammen, um die Teile der Präsentation, die wir am interessanten für Euch fanden, zusammenzufügen. Von Jareds Postkarten bis hin zu Ryans Sicherheitskarten, wir wollten Euch mehr als nur die Größe der Waffen zeigen (und mal ehrlich, die Waffen sind eigentlich nicht so groß).

Schlussendlich sind wir sehr traurig, eine der unsrigen zu verlieren. Chelsea Day, Managerin des Customer Service Teams, hat CIG wegen eines Umzugs verlassen. Chelsea war eine gute Freundin und eine tolle CS Managerin; wir werden sie alle vermissen! Patrick Probst, den ihr vielleicht schon im Forum getroffen habt, wird in der UK die Position des CS Managers übernehmen. Damit herzlichen Glückwunsch – wir wissen, dass du dich an Chelseas Beispiel orientieren wirst!