Diese Woche sind Randy Vasquez und Mark "Bugsmasher" Abent in 10 for the Developers am Start. Viele Fragen drehen sich um Bugs und deren Behebung sowie ein paar Producer-Fragen eingemischt.  Sie klären die Geschichte auf, dass die CryEngine für Star Citizen auf unter Wasser einstellt gewesen sein soll. Außerdem beschreiben sie einige interne Entwicklungstools und vieles mehr.




Hier die Stichpunkte zu den Fragen und Antworten:

01:20 – Cynical Bugs (Hattet ihr Bugs, die nach dem Fix einen anderen Bug auslösen, und nach dem Fix des Folgebugs wieder den ursprünglichen Bug produzieren?):

• In jedem Fall. Rund um Item System 2.0 gab/gibt es einige davon.

03:54 – Mistakenly Easy Fixes (Simuliert die CryEngine, als ob alles unter Wasser ist? Gibt es weitere solche Anekdoten?):

• Wir hatten darüber am Freitag in der Diskussionsrunde kurz gesprochen. Die Geschichte ist so, dass in der CryEngine automatisch alles, was im Koordinatensystem unter 0 auf der z-Achse ist (also unter der Oberfläche) wird automatisch als "unter Wasser" gekennzeichnet. 

07:21 – Open Vs. Closed Development (Vor- und Nachteile der offenen und geschlossenen Entwicklung?):

• Interessanter Weise sagt Randy, dass er glaubt, dass offene Entwicklung mehr Zeit kostet, als wenn man hinter verschlossenen Türen arbeitet.
• Als Vorteile sieht er die Einbindung der Community in die Entwicklung, zum Beispiel die NDA-Tester.

09:57 – My Own Bug Smashing (Wie unterscheiden sich Code-Bugs von Fehlern im Design?):

• Alle Disziplinen bei CIG müssen zusammenarbeiten, damit sie das Gesamtprodukt bauen können. Designer sind so etwas wie das Bindeglied zwischen Programmierern und Artists und so weiter.

12:47 – Bug Fix Ripple Effects (Hattet ihr Bugs, die eigentlich durch einen anderen Bug ausgelöst wurden, und nach dem Fix dieses Bugs musste der erste Fix wieder entfernt werden?):

• Auch hier ein klares ja. Das neue Item System muss auch hier als Beispiel herhalten. Eigentlich sollte die Physik von Items direkt funktionieren, wenn man sie auf der Oberfläche (abseits von Raumschiffen) verwendet, ging aber nicht. Der Grund war, dass bei der Integration einer neuen Engine-Version für 64 bit ein Stück Code gelöscht wurde, dass diese Funktionalität bereitgestellt hatte.

16:26 – Company Devotion to Releases (Welcher Prozentsatz der Mitarbeiter arbeitet an einem Release, wieviel sind nicht betroffen?):

• Das ist bei jedem Patch verschieden. Je nachdem wie viele Features in dem Patch sind und wie viele Mitarbeiter an den Features gearbeitet haben. Es arbeiten also immer noch Mitarbeiter an anderen Inhalten, die nicht zum aktuellen Release gehören.
• Prozentsätze kann man da nicht wirklich sagen. Viele Mitarbeiter sind auch "Springer". Sie arbeiten eigentlich an neuen Features, aber wenn es beim Release "brennt", dann helfen sie mit dem Release.

20:10 – Internal Development Tools (Welche internen Entwicklungstool habt CIG entwickelt?):

• Sie haben ein Tool, welches es wesentlich einfacher macht, die Physik von Schiffen einzustellen. Für die Engine gibt es sehr viele technische Parameter, welche Designer nicht verstehen können. Das Tool rechnet Eingaben der Designer (in für sie verständlichen Einstellungen) in die eigentlichen Parameter um.
• Andere Tools sind Dataforge für die Eigenschaften von Objekten im Spiel (kein XML mehr),  Item System 2.0 Tools und Tools, um die Hitzeverteilung zu visualisieren.

25:18 – Transition to Producer (Wie kommt Randy mit der Transition von Entwickler zu Producer zurecht?):

• Keine wirklichen Probleme für ihn. Sie scherzen ein bisschen über die üblichen Vorurteile, die Producer über Entwickler haben, und umgekehrt. Randy erzählt dann noch über seine Rolle bei früheren Arbeitgebern. Er hat an einigen MMOs mitgearbeitet. Dort hatte er auch schon quasi Producer-Rollen inne, ohne offiziell den Titel zu haben.

31:39 – Preparation for PTU Push (Wie verschieden ist der Release von 2.4 mit den großen Features im Vergleich zu anderen Patches?):

• Jeder Patch hat seine eigenen Gesetze und Herausforderungen. Je nachdem welche Features drin sind, bestimmt, welche Mitarbeiter aus den verschiedenen Studios zusammenkommen müssen.
• In verschiedenen Abständen gibt es Go/Nogo-Meeting, ob etwas auf den PTU kommt oder nicht. Dazu kommen noch Handoff-Meeting zwischen Entwicklung und QA.

35:20 – Bug Reports (Machen die Bug-Reports der Community einen Unterschied?):

• Ein ganz großen JA!
• Sie bedanken sich für die ganze Hilfe, die sie von der Community bekommen.
• Insbesondere die Schritte, wie Bugs auftreten, helfen ihnen schnell zu dem Punkt zu kommen, wo der Fehler passiert. Intern haben sie dann genug Tools, um den Fehler auszumerzen.

Quelle: Comm-Link