Hey, alle zusammen, willkommen zu Bugsmashers Episode 5. Ich hab’ meinen Kumpel hier, Shia LaBeouf, und wir sind bereit ein paar Bugs zu zerschmettern. Let’s DO IT, Let’s DO IT! (Anspielung auf Shia LaBeofs Motivationsrede)

Hallo zusammen, wir sind hier auf unserem fancy-dancy, gutem alten Mehrspieler-Server, und wie ihr hier sehen könnt wackelt das HUD wie verrückt. Lustiger Weise, hatten wir ein kleines Problem mit unserem Aufnahmeprozess wo, als wir dies aufnahmen – wie ihr jetzt sehen könnt – es aufhörte zu zittern, und dann, als wir die Aufnahme beendeten, fing es wieder an zu hüpfen. Wir fanden einen Trick wo, wenn wir die Maus nicht im Spiel haben, es dann wirklich dieses Schütteln macht. Also irgendwie … oh, es hat aufgehört. Doch was passiert – ungeachtet dessen, ob wir es nicht aufnehmen können – ist, dass unser Helm aus dem FPS-Modul aus irgend einem Grund sehr schnell zittert, und weil dieser bebt, lässt das auch unser HUD durchdrehen, da unser HUD an unseren Helm gebunden ist. Wenn also der Helm wie verrückt wackelt, dann wackelt auch das HUD wie verrückt.

Dies ist eine kleine lustige Sache, die – wie ich glaube – durch die Integration von Wwise (Soundengine) eingeführt wurde. Wir haben also unser Soundsystem von FMOD auf Wwise umgestellt, und deswegen mussten wir eine ganze Menge von Sounds deaktivieren, sodass wir sie langsam hinüber konvertieren konnten. Wir haben ein ganzes Audio-Team, das daran arbeitet. Und in diesem Prozess hat dieser spezielle Bug etwas mit dem guten alten Atmungs-Manager zu tun.

“Wie?” fragt ihr? Nun, der Atmungs-Manager schaut nach … wie ihr hier sehen könnt, ist hier einiges Sound-Zeugs deaktiviert, bis wir Wwise integriert haben. Doch … der Atmungs-Manager erhält eigentlich seine Laufzeit … los geht’s … erhält seine Laufzeit eigentlich, entweder von einigen Parametern aus dem XML, oder von den Sounds selbst, und seitdem die Sounds deaktiviert sind, wurde offensichtlich auch die Atmungs-Dauer auf null gesetzt. Unglücklicherweise kontrolliert dies in unserem kleinen Code, was der Spieler sieht, oder in diesem Fall kontrolliert es den Helm des Spielers, sodass wenn er so atmet … genauer gesagt, denke ich, dass es einige Knochen weiter unten kontrolliert, die sich nach oben hin auswirken. Doch wie auch immer, dies bringt den Helm durcheinander, also wenn du atmest, dann geht es so: rein, raus, rein, raus. Und unglücklicherweise … wenn wir hier einen kleinen Break-Punkt einsetzen, dann wird unser Übergang immer null sein. Unsere Dauer ist auch null, doch wegen Codeoptimierungen wird die Dauer hier eigentlich nicht genutzt. Doch sie ist null, und in jedem Frame erhalten wir nur 0 0 0 0 0. Was wir also machen wollen – lasst uns ins Spiel zurückgehen – ist, sicherzustellen, dass erstens: wir nichts von diesem Zeug ausführen möchten, außer … warum … ? … natürlich geht in der letzten Sekunde alles kaputt.

Was ich also mache: ich kopiere diesen schlimmen Finger – dies stellt sicher, dass sich unser Gleitkommazahl-Wert über dem Minimum-Wert befindet, der vom Gleitkommazahl-Typ erfasst werden kann. Ich könnte auch null benutzen, doch das ist im Grunde ein Standard, der über mehrere Plattformen hinweg genutzt wird, nur um sicherzustellen, dass … grundsätzlich: solange es größer als null ist, dann haben wir eine Dauer. Und falls nicht, dann möchten wir sichergehen, dass wir diesen entzückenden Wert zurücksetzen, der unsere Sicht steuert. Und wenn ihr hier her schaut, was die Dauer macht, dann sagt es: “Hey! Wir updaten … wir wenden einen Ausgleich an, sodass du basierend auf ein paar verschiedenen Parametern ein- und ausatmest.” Und das ist immer auf null gesetzt, also versucht es zum Nächsten, und Nächsten, und Nächsten zu gehen und wird ständig zurückgesetzt.

Also werden wir sagen: “Hey, nein, stopp! Wir haben KEINE Atmungs-Dauer, da unser Spieler anscheinend tot ist, denn unsere Atmung ist mit dem Sound verknüpft, also … warte! Mache nichts von dem, bis wir eine gültige Dauer haben, ansonsten setze alles auf null, sodass es nichts von unseren Verschiebungen modifiziert.

Dem geben wir eine gute alte Neukompilierung durch Recode, und wie ihr sehen könnt, bibbert der Helm nicht länger herum. Das HUD bleibt also eigentlich sehr statisch, und wenn wir … raus gehen … und darüber, sieht man: der Spieler bewegt sich irgendwie, doch das hat eine andere Ursache … doch der Helm bleibt im Grunde am Kopf. Wenn sich also sein Kopf bewegt, dann bewegt sich auch seinen Helm, sodass man das HUD an exakt der gleichen Stelle sehen sollte, was gut ist.

Wenn man nun die umgekehrte Logik anwendet, um es kaputt zu machen, sollten wir seinen Helm durchdrehen sehen. Und das ist jetzt irgendwie schwer zu vermitteln, doch sein Kopf bewegt sich unabhängig vom Helm, und das verursacht diese seltsame Verschiebung. Wenn wir also wieder hier rein gehen, kann man es ein kleines bisschen ruckeln sehen. Und wegen der Aufnahme verlangsamt es das, doch wenn ich … ja, ihr versteht schon.

Da habt ihr also euren kleinen lustigen Fix. Und die andere Sache, die ich machte war innerhalb des Atmungs-Managers. Falls ihr hier bemerkt habt, dass es überprüft, ob diese Gleitkommazahl null ist, wenn sie nichts macht. Wenn wir also null haben, dann geben wir null zurück. Das Problem mit Gleitkommazahlen ist, dass man womöglich niemals nur null erhält. Man könnte sehr, sehr kleine Werte kriegen, also fügte ich hier eine kleinen Codeoptimierung ein, welche die Dauer nimmt, und wenn sie kleiner ist als diese Gleitkommazahl Epsilon, dann geben wir null zurück. Andernfalls teilen wir durch die Dauer.

Das war diese kleine, schnelle Optimierung. Damit und unserem Fix hier wackelt unsere Kamera nicht länger. Das betrifft auch FPS. Wenn du herumrennst auf der Karte, ist das FPS-HUD auch an deine Kamera gebunden, es würde also auch hier und da wackeln. Das beeinflusste also beides: FPS-Modul und Arena Commander. Nun ist das behoben. Hoffentlich verläuft die Wwise-Integration viel reibungsloser.

In Ordnung. Heute sahen wir also ein lustiges kleines Problem mit unseren Helmen, wie sie herum bibberten, was sowohl unsere Schiffe, als auch das FPS-Modul beeinflusste, denn … nun, wenn du einen Helm auf hast, wird dieser dein HUD kontrollieren, und dies wird sowohl für deine Schiffe genutzt werden, als auch … wenn man als Spieler herumläuft.

Dieser Bug wurde eingeführt, als wir den Atmungs-Manager aktivierten, doch dann wurde der Code für die Sounds deaktiviert, da wir Wwise integrierten. Und das waren einfach die richtigen, natürlichen Bedingungen für einen Bug, wenn man etwas aktiviert, das lange Zeit inaktiv war, und man hier und da etwas Code deaktiviert, das kommt zusammen und … “Hey, hier ist ein brandneuer Bug!” Und du fragst dich: “Oh Mist, wo kam der her?”

Es dauerte eine Weile diesem auf die Spur zukommen, da wir auch unser “Große Welt”-Zeugs integrieren und es schien, als so ob: “Ist dies ein 64-Bit-Problem? Ist es etwas anderes?” Und glücklicherweise sagte einer der Illfonic-Jungs: “Hey, das könnte der Atmungs-Manager sein.” Und ich dachte mir: “Heilige Scheiße, das ist es!” Wir schauten es uns an und – Bam – da war es!

Fragen:

WopWop0482 fragt:
Ich frage mich, was die Durchschnittsdauer ist, die jemand Arbeit leisten kann, bis es zum Bournout kommt.

Das ist eine interessante kleine Frage. Das hängt von vielen Faktoren ab. Haben wir eine Krise? Wie viel Schlaf hatten wir? Ist heute viel nerviger Verkehr? Gab es … ich weiß nicht … etwas persönliches, das einen beeinflusst hat? Gab es eine lange Überholung? Da gibt es viel Faktoren. Ich habe – nicht nur bei mir selbst, sondern bei anderen Entwicklern – Sachen gesehen, von: “Heilige Scheiße, es sind schon 16 Stunden vergangen! Ich habe nichts gegessen, doch eine Menge geschafft.” bis hin zu “Okay, ich habe hier um 6 angefangen … nun ist es 6:10 Uhr … ich brauche eine Pause.” Das kommt einfach darauf an, woran man arbeitet, wie die Arbeitsbelastung ist, ob du an der Sache arbeiten möchtest, oder ob du es musst. Darauf kommt es einfach wirklich an. Doch von dem, was ich hier die meiste Zeit über gesehen habe ist, dass sich alle auf etwas konzentrieren und dann feststelle: “Heilige Scheiße! Acht Stunden sind vergangen. Ich muss zu Mittag essen. Ich muss eine Pause einlegen. Und dann steige ich gleich wieder ein.” Doch ein anderer Faktor, der da auch mit hineinspielt: Wenn du früh am Morgen, oder spät am Abend hier bist, dann kannst du dich wirklich in etwas vertiefen und die Zeit vergeht, ohne dass du wirklich ausgebrannt wirst. Doch wenn du hier erst gegen Mitte des Tages auftauchst, jemand auf dich zugeht, oder du einen Anruf erhältst, oder du ein Meeting hast, dann wirst du … unorganisiert, da du nicht an dieser einen Sache arbeiten kannst. Und jedes Mal, wenn du versuchst daran zu arbeiten, dann wirst du genervt. Auf diese Art kann man also ausbrennen, also … es gibt alle Arten von Gründen, wie und warum man ausbrennen kann. Die beste Sache, die man tun kann ist einfach eine schnelle, kurze Pause einzulegen, durchzuatmen, sich eine Limo oder so etwas zu hohlen, und dann gleich wieder weiter zu machen.

Ryan Matthewlick fragt:
Welcher Laufbahn bist du gefolgt im dir selbst einen Platz bei CIG zu verschaffen?

Also bevor ich hier arbeitete, arbeitete ich für ein Unternehmen namens New World Interactive, und sie waren ein winzig kleine Indie-Gruppe, die in Colorado an Insurgency arbeitete. Zu dieser Zeit wollte ich zurück nach Kalifornien ziehen, doch ich wollte weiterhin an Insurgency arbeiten, also … schaute ich mich um, Arbeitssuche um zu sehen, was verfügbar war. Und ich sah Star Citizen und dachte mir: “Oh, das ist Chris Roberts! Er machte Freelancer. Ich liebte das!” Zu der Zeit hatte ich Wing Commander noch nicht gespielt, ich war klein, bitte bringt mich nicht um. Ich habe es später gespielt, ich mag es, doch Freelancer war mein Spiel und ich dachte mit: “Das klingt spaßig. Ich werde mich bewerben. Ich habe nicht so viel Industrie-Erfahrung, doch ich habe viel Indie-Arbeit gemacht. Also das schlimmste, was sie sagen könnten wäre ‘Nein’.” Und ein paar Monate später holten sie mich für ein Gespräch vor Ort, sie mochten mich, und hier bin ich. Ich glaube, dass hat sich für beide Seiten ausgezahlt.

PD12-PD12 fragt:
Welche Art von Design-Schema nutzt du, oder nutzt CIG? Was sind eure EMLs? Welche Art von Standards hat CIG?

Worauf er sich bezieht ist: Bevor man einen Code oder so etwas entwirft, möchte man irgend eine Art von Grundgerüst davon haben, was der Gesamtumfang werden wird. Wie es funktionieren wird, wie es mit Dingen interagieren wird. Und wir nutzen eine Kombination aus Hilfsmitteln. Die beiden größten, die ich nutze sind Visio und … da gibt es ein Plug-In für Visual Studio: Design Patterns UML Toolbox. Doch wir benutzen Visio im Grunde um kleine Code-Blocks zu kreieren, die besagen: “Diese Code-Sektion wird jene Codesektion aufrufen, diese Sektion …” sodass man den Fluss sehen kann. Und dann benutzen wir Confluence um diese Bilder zu posten, und setzen Code an Interfaces fest, und wie es mit Beschreibungen funktioniert. Designer werden das selbe machen, sie haben Code-Blöcke die sagen “Da ist der Fluss, so werden die Sachen funktionieren.” Und sie haben Diagramme und Bilder zusammen mit Worten, die beschreiben wie und wo Dinge passieren sollen. Dies wird im Grunde der Prototyp, oder die Design-Phase sein, wo – sobald dieses angenommen wird, dann wird es zur Design-Implementation gebracht, die üblicherweise von den liebenswerten Produzenten und Leitern ausgeplant wird. Von da an wird es dann in ein Feature integriert, vom QA auf Bugs getestet, und dann schließlich an euch entzückende Leute ausgegeben.

Ich hoffe ihr hattet etwas Spaß mit diesen Fragen. Falls ihr noch weitere haben solltet, kann ich es kaum erwarten sie nächste Woche zu beantworten.

Ich hoffe ihr habt die dieswöchige Episode von Bugsmashers genossen. Wir sehen uns das nächste Mal!

QUELLE: Imperial News Network