BUGSMASHERS! Episode 04

Hey alle zusammen, hier ist der Bug-Flüsterer, Mark Abent, um euch “Busmashers 2, the lost World” zu bringen.

 

Hallo zusammen, heute haben wir einen lustigen, kleinen Bug. Ich fange hier mit einer kleinen, lustigen Changelist an, die uns auf den neuesten Stand bringt. Also vor kurzem – genauer gesagt letzte Woche – hatten wir ein Problem mit unseren Items, die sich nicht physisch manifestierten, wenn wir sie von unseren Item-Anschlüssen trennten. Items-Anschlüsse sind im Grunde alles, was an einem Schiff, oder Items untereinander verbindet, wie etwa eine Rakete, die mit einer Raketenhalterung und eine Raketenhalterung, die mit einem Schiff verbunden ist. In diesem Build wurde viel wichtiger Code geändert, was im Grunde all dieses Physikalisierungs-Zeug zerstörte. Und das war nur ein einfacher, schneller Versuch vom guten, alten Paul, um das wieder in Gang zu bringen. Für den größten Teil funktionierte es, mit der Ausnahme, dass es zu einigen Rausschmissen im Mehrspieler führte. Das Problem ist: Wir haben einen Aufsatz-System-Code und einen Physik-Entität-Proxy-Code, von denen beide das physikalische Wesen unserer Raketen oder Items behandeln. Im Einzelspieler ist es ziemlich einfach zu sagen, wer der Besitzer ist, doch im Mehrspieler – durch Pakete, die zu jeder Zeit herauskommen und Probleme anordnen – könnte der Besitz der Physik an dem Aufsatz-System anstatt des Item-Anschluss-Systems sein, oder sogar am Proxy. Und dies kann Probleme auslösen, wenn das Item erwartet dort zu sein. Die Anordnung dieser Dinge ist sehr empfindlich.

 

Was der gute, alte Paul also gemacht hat, wir betrachten den Unterschied, er hat grundsätzlich … lasst uns all diese lustigen, kleinen Dinge überspringen … da wären wir: Jedes Mal, wenn wir einen Item-Anschluss erhalten, deaktivieren wir die Physik, und jedes Mal, wenn wir einen Item-Anschluss verlassen, werden wir die Physik aktivieren. Das Problem dabei ist, dass wir vielleicht serialisiert werden, der Gegenstand wird anordnen, sich zu sagen die Phyikalisierung zu priorisieren, darüber das Item im Item-Anschluss zu haben, oder umgekehrt. Und das verursacht einige lustige Physik-Abstürze.

 

Was ich also gemacht habe … wenn ich meinen ganzen lustigen, kleinen Code zurücknehme … ich habe also etwas eingeführt, das desire Physics (gewünschte Physik) genannt wird. Es durchläuft also immer noch denselben Prozess, es wird sein wie: “Hey, ich möchte dies synchronisieren und physikalisieren!” Wir durchlaufen nun eine Frame-Verzögerung, damit wir nicht dies Probleme haben, wie wenn ich etwas während desselben Frames anbringe und abnehme und es serialisiert, all diese physikalischen seltsamen Zustände drehen durch. Nun wartet es also bis zum nächsten Frame, um zu sehen, ob das passieren sollte. Und für alle Absichten und Zwecke funktioniert das, außer im … voilà: Mehrspieler. Der Grund dafür ist – lasst mich das kompilieren und ich kann euch eine Livedemonstration geben.

 

Ich nehme also den ersten Punkt, da ich vergessen habe, dass dies ein gültiger Zustand ist. Doch hier liegt das Problem. Wir fügen also diese Frame-Verzögerung ein, das Problem ist, dass der Physik-Proxy jetzt noch gar nicht existiert. Wenn es also versucht die Information zu serialisieren, kann es dies nicht, da wir einen null pointer haben, es sagt also: “Hey, Abbruch!” und dies führt zu einem Disconnect für den Spieler. Das darf nicht passieren, was wir also tun müssen ist sicherzugehen, dass … glücklicherweise gibt es in unserem Pysik-Proxy einen weiteren Parameter, der uns erlaubt den Proxy zu erzeugen. Das liegt nur daran, dass wir eine Frame-Verzögerung haben. Zuvor – wann immer wir diese Informationen anordneten – hätte es sofort die Physik erstellt. Aber nun, seit wir diese leichte Verzögerung haben, müssen wir die Physik während der Anordnung genauso erzeugen, damit wir den Typ serialisieren können.

 

Und da gibt es die Möglichkeit, dass die Physik noch nicht erstellt wurde, das ist was dieser Schnappschuss, worum sich auch der Proxy kümmert … es speichert im Grunde diese Information bis es bereit ist sie aufzunehmen wenn es physikalisiert. Lasst es uns also nochmal versuchen.

 

Während das lädt, ist eine erwähnenswerte Sache, dass seit der Aufsatz-Manager und der Entity Physics Proxy beide die Physik handhaben, ist es immer eine bizarre Angelegenheit geworden zu versuchen, dass die beiden sich nicht gegenseitig verpfuschen. Wir haben etwas in der Pipeline um grundlegend sicherzustellen, dass diese beiden Physiken von dem Physik-Proxy geregelt werden, und nicht vom Aufsatz-Manager. Allerdings ist das eine riesengroße Änderung, die immer noch in Arbeit ist und irgendwann herauskommen wird, doch in der Zwischenzeit müssen wir diese kleinen Tricks machen, um sicherzugehen, dass wir ein ordentliches Gameplay haben. Denn wir möchten, dass sich unsere Raketen im Mehrspieler tatsächlich bewegen, bis wir diese andere riesige Änderung aus dem Weg haben.

 

Wie ihr also sehen könnt, konnte ich beitreten, und wenn ich noch einen anderen Charakter hätte, könnte ich jetzt Raketen auf ihn schießen. Fliegen wir also ein kleines Bisschen.

 

Nun, da habt ihr es. Lustige Physikleiden.

In Ordnung, alle zusammen, dieser kleine Bug, war ein lustiger. Wir machen eine Menge bedeutender Änderungen an der Engine und unglücklicherweise, als wir anfingen die Verzweigungen für das nächste Release abzunehmen, hatten wir einige defekte Sachen, die wir aufräumen mussten. Dieses ganze Physik-Problem-Ding, wenn wir etwas von einem Anschluss entfernten, entstand durch eine große Überholung des Item-Anschluss-Systems, und da wir einen Fix für die nächste Veröffentlichung brauchten, setzten wir dieses kleine Ding ein, einfach als eine Methode um zu sagen: “Hey, wir müssen das zum Laufen bringen.” Wir arbeiten an einer ordentlichen Lösung, doch das braucht natürlich Zeit. Da dies nun geklärt ist: Lasst uns zu einigen Fragen kommen.

 

Ardent Hammer: Schönes Video, mach weiter so! Ich habe mich schon immer gewundert, mit so gewaltigen Projekten wie Star Citizen, wie schafft man es bei so einer riesigen Code-Basis den Überblick zu behalten?

 

Also, das ist wirklich eine echte Herausforderung, die wir von Tag zu Tag meistern müssen. Wir machen das auf mehreren Wegen. Wir haben viele Werkzeuge in Visual Studio, wie etwa Visual Assist, das uns erlaubt die Code-Basis nach Sachen zu durchsuchen, die wir wirklich brauchen. Das andere ist unsere Struktur, wie wir die Dinge zusammenhalten. Kern-Engine-Sachen gehen in den Kern-Engine-Ordner, Animations-Dinge gehen in den Animations-Ordner, Rendering kommt zum Rendering und Gamplay in die Gamplay-Sektion. Dies hilft uns die Dinge einzugrenzen. Und dann haben wir auch obligatorische Codeüberprüfungen jedes Mal, wenn wir Zeug übermitteln möchten. Und wir haben auch Eigentümerschaft, wo einige Leute eine bestimmte Sektion des Spiels besitzen. Wenn man also Fragen hat, geht man zu dieser Person. Wir haben auch ein Wiki. Es gibt da alles Mögliche, sogar Skype E-Mails um einfach nur alles zu finden oder Dinge zu beheben. Das ist ein riesengroßes Unterfangen und wir nutzen alle Arten von lustigen, kleinen Hilfsmitteln.

 

Frazziboy: Er möchte wissen, warum man eher Event-Handling nutzen würde, als – sagen wir – einen Wert mit jedem Frame zu überprüfen.

 

Nun, einen Wert mit jedem Frame zu überprüfen kann kostspielig sein. Man braucht vielleicht auch einen Speicher oder einen Pointer (Verweis) oder einen Wert des Dings, das man überprüfen möchte. Es könnte den Aufwand wert sein, oder auch nicht, das kommt darauf an, was man macht. Der Vorteil von Eventhandling-System ist, dass wenn dieses Event passiert, weiß man sofort, dass man diesen Status behandeln kann, anstatt jedes Mal zu überprüfen ob sich dieser Zustand geändert hat. Zu sortieren, was der alte Status war und was der neue Status ist, kann etwas chaotisch werden, doch das kommt immer darauf an, was man versucht zu machen. Manchmal könnte Event-Handling besser sein, als nur auf Aktualisierungen zu überprüfen, oder andersherum. Das hängt wieder davon ab, was man versucht, um das Problem zu lösen.

 

Nochmals: Event-Handling ist großartig für so große Systeme, wie dieses. Denn, wenn zum Beispiel ein Radar eine Signatur aktualisiert hat, dann kann ich ein Update an alle Systeme schicken, anstatt ständig zu prüfen, zu prüfen und zu prüfen, was zu kostspieligen Frameraten führen könnte, da sie alle ihre eigenen Update-Funktionen machen, anstatt nur eines einmaligen Gebens und Nehmens.

 

Ich hoffe ihr hattet hier einige kleine, lustige Antworten und falls ihr noch mehr Fragen haben solltet, dann beantworte ich die beim nächsten Mal.

 

Cheers!


// End Transmission

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.