10 for the Developers_ Episode 11

10 for the Developers: Episode 11

Grüße Sternenbürger!

Willkommen zu einer weiteren Episode von 10 for the Developers. Die Fragen werden diesmal von Mark Abent aka „Der BugSmasher“ und Randy Vasquez beantwortet. Das SCNR-Team wünscht euch viel Spaß!


[1:22] Tauchen Bugs in Zyklen auf?

Ja, immer wieder. Den einen Fehler zu beheben bringt einen anderen Fehler wieder zum Vorschein und wenn man diesen behebt, taucht der erste Bug wieder auf. Dies geschah in einigen Fällen mit 2.4.


[3:56] Es gab eine Geschichte über die Bewegungen der Raumschiffe und dass diese Fehlerhaft seien und niemand herausfinden konnte woran das liegt, bis jemand etwas darüber sagte, dass die CryEngine alle so simuliert, als wäre es unter Wasser. Gibt es ähnliche Albtraum-Geschichten die ähnlich leicht zu beheben waren, nur durch das Wissen über bestimmte Eigenheiten der Engine?

Vor 2 Jahren, als John Pritchett aus Kansas flog und jeder daran gearbeitet hat, den Arena Commander fertig zu bekommen, doch die Schiffe anfingen sich komisch zu verhalten. John verbrachte 2 oder 3 Tage damit, herauszufinden, woran das lag. Letztendlich kam er in das Büro der anderen Programmierer und sagte: „Unsere Schiffe sind Unterwasser“. Es stellte sich heraus, dass die CryEngine jedes Level als Unterwasser behandelt hat, dass in der Z-Achse unter 0 liegt, selbst wenn du im Weltraum bist! Nachdem wir das wussten, war es ein einfacher Fix.


[7:24] Was sind die Pro und Kontras einer geschlossenen Entwicklung und BugSmashers offenem Entwicklungsmodell?

Die geschlossene Entwicklung erlaubt eine durchaus detailliertere Arbeit an Features, ohne dabei vom Debugging-Vorgang unterbrochen zu werden.  In der offenen Entwicklung gibt es mehr zu testen, doch kann öfters dadurch gestört werden, die Aufgaben aus der Hand zu geben.


[9:58] Wirst du darauf angesetzt, deine eigenen Bugs zu beheben? Hat CIG ein System um Design „Fehler“ zu beheben? Wie ist das beheben von Code-Bugs und Design-Fehler zu vergleichen?

Jedes Team arbeitet eng mit all den anderen Abteilungen zusammen. Wenn es ein Fehler gibt, worüber du mit jemand anderem reden möchtest, kannst du mit anderen Teams reden um diese beheben zu lassen. Jede Abteilung hat seinen eigenen Prozess, wie sie mit einem Bug umgehen. Wenn man an der Implementierung eines neuen Systems arbeitet, die von anderen Abteilungen genutzt wird, holen sie sich deren Meinungen zum Workflow ein. Jeder hat seine eigenen Prozesse und Bedürfnisse.


[12:51] Hasst ihr es jemals, wenn ihr Bugs findet und diese behebt, doch später die Ursache findet und sie nochmal beheben müsst?

Ja! Es passiert öfters, dass wir einen Bug finden und beheben, doch den wahren Ursprung erst später entdecken. Manchmal dauert es Monate, die Ursache dafür zu finden, wenn wir z.B. ein Feature hinzufügen oder andere Teile des Codes ändern.


[16:30] Wie viele aus dem Unternehmen fiebern dem Release entgegen? Wie viele Leute sind nicht vom Release-Zyrkel betroffen und stellen einfach weiter Content her?

Das hängt vom Release ab. Jeder arbeitet an anderen Sachen die an andere Ziele geknüpft sind. Manchmal wird man von einem neuen Feature abgezogen um dabei zu helfen, Bugs zu beheben. Es ist bei jedem Release anders ─ es sind immer verschiedene Ressourcen von Nöten.


[20:13] Tools die ihr selber entwickelt habt und in Benutzung sind?

Goal Based Tuning ─ hilft den Designern dabei eingehende Informationen in einer Datenbank zu packen hergesellt von John Pritchett.
DataForge ─ Dadurch müssen wir XML-Dateien und einige Skripts nicht mehr von Hand bearbeiten. Item Port Editor ─ Bewegt/Entfernt Dinge in-Game.


[25:22] Wie war der Übergang von einem Entwickler zu einem Produzenten?

Ist immer noch im Gange.


[31:43] Machen die Leute im Live-Team bei fundamentalen Änderungen irgendwelche besonderen Vorbereitungen oder ist das aushändigen vom PTU und dem Q&A der selbe?

Es gibt kein eigenes Live-Team. Die Ressourcen werden Querbeet aus dem Unternehmen genommen, je nachdem was für den Release erforderlich ist ─ i.d.R. leiten die Leute, die mit den Features betraut wurden, die Ziele für den Release. Es gibt jeden Tag eine Aushändigung zwischen UK und US ─ UK verwaltet auch die Dinge aus Frankfurt. Manchmal müssen sie Releases in die PTU veröffentlichen, wo man von vornherein weiß, dass der Build kaputt ist, nur um mehr Debug-Informationen zu bekommen. Manchmal müssen bestimmte Features (wie der Arena Commander) deaktiviert werden um den Testfokus auf einem bestimmten Bereich zu lenken. *Nerfguns tun weh.*


 [35:27] Während PTU und Live-Patches: Machen unsere Bug-Reports wirklich einen Unterschied?

Auf jeden Fall, das Team kann der Community gar nicht genug danken, für ihre harte Arbeit und hingebung beim testen und spielen des Games. Ohne die Unterstützung der Community, würden sie bei weitem nicht an die Testmenge kommen, die das QA benötigt um die Bugs zu jagen. Selbst wenn sie einem nicht auf eine Einreichung antworten, kann es sein, dass sie die Information trotzdem nutzen, doch nicht genug Zeit haben um zu antworten.

Transkript von: CanadianSyrup, Stormy Winters, Sunjammer, NYXT, Desmarius.
Originales Transkript: INN

Übersetzung: Cpt. Adama von und für www.star-citizen-news-radio.de!

Quelle: RSI

Share on FacebookTweet about this on TwitterShare on Google+Share on RedditEmail this to someone


// End Transmission

2 Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *