Bugsmashers Episode 3

Hey alle zusammen, willkommen zurück zu Bugsmashers! Wir sind bei Episode 3, machen wir uns bereit ein paar weitere Bugs zu zerschmettern!

Hallo zusammen, wir sind wieder in meiner fancy-dancy (extravaganten) Testumgebung, alles schön und spacey, und wir werden uns einen Innenraum-Bug ansehen, der bei einigen Schiffen auftritt. Fürs Erste werden wir uns nur die Aurora anschauen. Wenn ihr euch diese kleine orangene Box anseht, das ist unser Fahrzeug-Inneres. Im Moment ist es als bounding Box (Rahmen) definiert, doch wir haben einige Techniken in Arbeit, womit wir den tatsächlichen Innenraum formschlüssig definieren werden. Und was dieser Innenbereich genau ist … im Grunde ist das unsere lokale Entität, unser lokales physisches Gitter. Wenn man das also betritt und sich das Schiff bewegt, dann bewegt man sich mit. Oder wenn man die Schwerkraft umgekehrt, oder eingeschaltet hat, dann passt das deine Position im Schiff entsprechend an. Das ist also unser Innenraum-Code. Also im Moment ist es nur ein Rahmen.

Wie auch immer … wenn ich das Schiff betreten möchte … spielt es die Ausstiegsanimation ab. Nicht gut. Nicht gut. Es sollte den Einstieg, nicht den Ausstieg abspielen. Also … was passiert da, und warum?

Also hier haben wir unser kleines Codesegment, welches steuert, was passiert nachdem die Tür geöffnet oder geschlossen wurde, und das ist die Tür genau hier [zeigt auf die Steuerbordtür]. Wenn ich also F drücke, öffnet sich die Tür und dann sollte ich die Einstiegsanimation abspielen, oder – wenn ich mich bewege oder umschaue – bricht es die Animation ab, die Tür öffnet sich einfach nur und ich betrete oder verlasse das Schiff nicht. Und was passiert ist, dass wenn ich F drücken würde und meine Maus nur ein kleines Bisschen bewege, dann würde es InitPassenger aufrufen und diesem sagen auszusteigen, denn … während ich versuche reinzukommen bewege ich mich … und es nimmt an, dass es abbrechen soll, weil es wie “hey, ich möchte nicht wirklich da rein gehen, ich möchte bloß die Tür öffnen, also stecke mich nicht da rein” ist. Doch es wird trotzdem diese Funktion aufrufen um eine Menge aufzuräumen, und unglücklicherweise sind die Übergänge standardmäßig in 100% der Fälle aktiviert, was gewissermaßen ein Problem ist. Der Grund dafür ist: Wenn ich all die Dinge kopiere und einfüge … lasst uns die Innenräume im Release-Build finden … da haben wir’s. Das ist also das Release-Build, das ist der Code, den ihr jetzt habt und mit dem ihr spielt.

Wie ihr hier erkennen könnt ist der Übergang nur dann aktiviert, wenn dieses RemoteUsage bestimmt ist, doch hier ist es festgelegt immer true (wahr) zu sein und was passierte war … es gab eine große Überarbeitung der Fahrzeugsitze und dieses RemoteUsage wurde eigentlich entfernt. Dieses RemoteUsage ist eigentlich ein Codeüberbleibsel aus … Crysis 2 schätze ich, das sie damals benutzten und es wurde in unserem Code niemals verwendet, außer für diese kleine Sektion.

Das RemoteUsage wurde hauptsächlich als eine Art Hack genutzt, um zu bestimmen ob man den Übergang abspielen sollte, oder nicht. Seit also die Animationen überall im Code entfernt wurde, als es letztlich hier her kam wurde es einfach auf true gesetzt, weil jemand annahm, dass Übergänge immer eingeschaltet sein sollten, was wir nicht haben möchten.

Also fügen wir einen kleinen bool (boolean = simpler wahr/falsch-Schalter) zu diesem InitPassenger hinzu, sodass wir an anderer Stelle entscheiden können, ob wir diesen Übergang aktiviert haben möchten. Lasst uns also all die Stellen (im Code) finden … . Wenn ich also mit dem einsteigen fertig bin, möchten wir eine Entscheidung, ob wir die Übergangsanimation durchgehen möchten, oder nicht. Und wenn ich aussteige, möchten wir bestimmen, ob wir den Übergang durchlaufen, oder nicht. Und das sind die einzigen beiden Stellen.

Lassen wir also diese Codeänderungen kompilieren … oh, ich liebe Codeänderungen.

Während das arbeitet: Was wir also sehen sollten ist, dass wenn ich F drücke, meine Taste bewege, dann sollte es den Aufräum-Code verwenden um sich zu vergewissern, dass ich nicht im Innenraum bin … und dann sollte nichts passieren. Ich sollte in der Lage sein herumzulaufen und nichts zu tun, es sollte keine Ausstiegsanimation abgespielt werden. Wenn ich nun F drücke und sonnst nichts anfasse, sollte es die Schritte unternehmen um mich ins Schiff zu bringen. Lasst uns also F drücken und uns dann bewegen und herumhampeln … und seht euch das an, es hat mich nicht nach drinnen gebracht, whoo. Hat der Aufräum-Code korrekt funktioniert? Lasst es uns noch einmal versuchen, wheew. Wenn ich nun nichts anfasse, sollte es mich nach drinnen bringen … und ich bin eingestiegen. Es bringt mich nun also korrekt in den Innenraum, und ich kann aussteigen, wenn ich das möchte.

Yay, magische Türen. In Ordnung, das beseitigt diesen Übeltäter. Witzigerweise hatte dieser Bug auch ein Problem mit der Cutlass. Da gibt es eine Leiter an der Seite, und wenn man auf diese Leiter zuging, betrat man den Innenraum, was einen dazu zwang die Einstiegsanimation zu durchlaufen, da die Innenraumanimationen darauf eingestellt waren immer true zu aktivieren. Man konnte also das Innere betreten oder verlassen und der Übertritt würde immer eine Animation erzwingen, obwohl man diese gar nicht immer haben möchte. Wir möchten, dass diese Übergänge nur dann stattfinden, wenn man aktiv die F-Taste drückt während man sich hinein begibt, statt dass man einfach nur darauf zugeht, oder raus läuft. Dann sollte es die Übergangsanimationen nicht abspielen.

Und da haben wir’s. Alles funktioniert wie erwartet, und richtet langsam die Dinge für die nächste Veröffentlichung her. Macht’s gut!

In dem heutigen Bug befassten wir uns also mit den Fahrzeuginnenraum-Übergängen. Wenn man sie betritt und verlässt sollte es nur dann eine Animation abspielen, wenn gezielt die Use(Benutzen)-Taste drückt wird und man durch eine Tür ein- oder austritt. Doch wenn man aus einen Durchgang, oder dem Schiff fällt sollte es nicht diese Übergangsanimationen abspielen, und das war einfach ein Bug, der durch eine gewaltige Umstrukturierung des … ich denke, es war der C Code. Von Zeit zu Zeit schleicht sich so was ein, wenn man diese riesigen Änderungen macht. Man begeht einen winzigen Fehler und es ändert eine ganze Menge Dinge. Das passiert leicht die ganze Zeit über und wir müssen sie einfach beheben, und das war eines der Dinge, die euch gezeigt wurden, doch die ihr niemals selbst erlebt habt.

Letzte Woche habe ich euch gebeten mir einige Fragen zuzuschicken, und ich werde einfach ein paar davon durchgehen. Schnell und einfach. … Und legen wir los.

Also, wir haben einige von Digital Pimp … guter Name. Welche Entwicklungsmethode nutzt ihr Jungs? Also, wir benutzen … hauptsächlich Agile & Scrum. Scrum bedeutet, dass wir uns ab und zu in einer kleinen Gruppe zusammenfinden und nur schnell sagen, was wir im Moment machen, und was wir zu tun gedenken. Agile ist im Grunde kontinuierliche Entwicklung. Wir benutzen Jira, reden mit Leuten über Skype, wir halten Mini-Meetings und so weiter. Ein Haufen kleiner Sachen. Oder wenn im Zweifel, dann rennen wir einfach zu der anderen Person an ihrem Tisch und schreien sie an.

Nächste Frage von Digital: Welche Software benutzt ihr um den Entwicklungsprozess zu managen? Die zwei – eigentlich drei – großen sind: E-Mail, Skype und Jira.

Welche Source Control (Versionsverwaltung) benutzt ihr? Perforce. Das ist eigentlich ziemlich genial.

Nutzt dein Team kontinuierliche Integration, oder kontinuierliche Entwicklung? Im Moment benutzen wir kontinuierliche Integration, womit wir ständig Zeug via Perforce hinzufügen. Täglich tragen Leute Sachen ein. Ich denke, wir arbeiten auf kontinuierliche Entwicklung hin, doch wir haben Verzweigungen, sodass wir all das Zeug in einem Staging (temporärer Zwischenspeicher) fusionieren können, und dieses Staging wird dann in die derzeitige ‘gute Version’ eingearbeitet. Wenn wir auf diese Weise etwas im Staging kaputt machen, dann beheben wir das, bevor es in alles andere einfließt. Wir sind noch nicht ganz so weit, doch wir bereiten das im Moment vor.

In Ordnung, kommen wir zur nächsten Frage von Holovision: Gibt es noch ander Smasher bei CIG, oder bloß Smasher-Padawan-Schüler? Die Bug(Käfer)-Ausbrüter, die noch nicht die wahre Zen-Meisterstufe erreicht haben. Hast du eine Liste von denen, deren Bugs du am meisten behoben hast und zwingst du sie damit dir dein Mittagessen zu kaufen?

Also, die Antwort zur ersten Frage: Ich bin nicht der einzige Bugsmasher. Ich bin einfach nur der Bugsmasher vor der Kamera. Wir haben Bugsmasher in jedem einzelnen Studio. Tatsächlich bin ich in diesem Studio nicht der einzige Bugsmasher. Wir haben Oka, der Grafik-Bugs ausmerzt, wir haben Brandon, der Gameplay- und HUD-Bugs auslöscht, wir haben Chad, der KI-Bugs zerlegt und wir haben Paul – unseren Leiter – der alles vernichtet, was man sich vorstellen kann. Der Arme bekommt jeden einzelnen, und dann erhalte ich das Smash-Frühstück danach. Und wir haben auch Leute in dem GB-Studio, die sich sowohl um Bugs aus Squadron 42, als auch dem Arena Commander kümmern. Dann haben wir das deutsche Studio, dass hinter den Kulissen an einigen Engine-Dingen arbeitet, und auch die entfernen Bugs. Wir haben also Leute von jedem einzelnen Studio, die an Bugs arbeiten.

In Ordnung, der letzte – Onetooth: Kannst du vielleicht die Konzepte der Spiel-Engine und Multithreading erklären, und womöglich auch das Event-Handling genauer darlegen?

Also ich werde diese recht schnell beantworten. Eine Spiel-Engine ist grundsätzlich ein großes, gigantisches Softwarepaket, das alles beinhaltet, was du brauchst um dein Spiel zu machen. Es hat das Zeug zum Rendern, Kram für Mehrspieler, Dinge um tatsächlich ein Spiel zu entwickeln, für Tastatureingabe und solche Sachen. Das ist das Grundgerüst, welches man braucht um ein Spiel zu machen. Multithreading ist … man kann sich das vorstellen wie … Wenn ich eine Abhandlung niederschreiben würde, dann wäre das Singlethreading, wenn ich nur auf einem einzigen Stück Papier schreibe. Doch wenn ich mit beiden Händen auf zwei verschiedenen Papierstücken schreiben würde, dann wäre das Multithreading. Es bedeutet zwei verschiedene Aufgaben zur gleichen Zeit zu erledigen. Und es wird noch viel detaillierter als das, doch das kannst du gerne googeln.

Und die Letzte war zum Event-Handling. Event-Handling ist … sagen wir ich wäre gestorben, dann hätte ich jeden benachrichtigt, dass ich gestorben bin. Man kann sogar noch einen Schritt weiter gehen und sagen: “In Ordnung, ich liste Events auf, also ob ich gestorben bin, oder erschossen wurde, oder … so etwas in der Art und ich lausche auf diese Events.” Wenn nun der Spieler stirbt, dann geht er alle seine Event-Listener durch und sagt ihnen: “Hey, ich bin gestorben!”, “Hey, ich bin gestorben!”, “Hey, ich bin gestorben!” Man kann also solche raffinierten Sachen machen, wie: Wenn die Rakete explodiert, tu dies. Wenn jemand diesen Knopf gedrückt hat, tu das. Das ist also grundsätzlich Event-Handling. Es ist viel besser, als eine Aktualisierungsfunktion zu haben, womit man ständig etwas überprüft. Stattdessen kann man einfach sagen: Wenn dies passiert, dann tu das.

In Ordnung, das waren die heutigen lustigen, kleinen, schnellen Fragen. Wenn ihr Leute noch mehr habt, werde ich versuchen sie nächste Woche zu beantworten. Bis dahin: SMASH.


// End Transmission

Schreibe einen Kommentar

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

Time limit is exhausted. Please reload the CAPTCHA.