Als die Demo lautlos versagte

Ein Absturz sagt einem, dass etwas nicht stimmt. Ein lautloses Versagen liefert eine polierte, leere Hülle an Ihre Nutzer aus – und an Ihre Partner. Die Engine, die Vertrauen gewinnt, ist die, die sich weigert zu flüstern.

Es gibt eine Klasse von Bug, die schlimmer ist als ein Absturz. Ein Absturz sagt einem wenigstens, dass etwas nicht stimmt. Der Bug, mit dem ich mich diesen Samstagmorgen hinsetzte, war die andere Sache. Die Demo bootete. Die Szene lud. Die UI renderte. Das Pause-Menü reagierte nicht. Das Gameplay war ein Platzhalter. Kein Fehler. Keine Exception. Keine Log-Zeile über INFO. Die Engine hatte lautlos versagt und ging höflich durch die Bewegungen eines funktionierenden Spiels.

Das ist der Beitrag darüber, wie man seine Engine dazu bringt, sich zu weigern, das zu tun.

Wie die Demo für einen Nutzer aussah

Bootete sauber. Splash-Screen. Menü-Bildschirm. Klick auf „Play”. Szenenübergang. Eine sauber aussehende Szene. Ein Schiff in der Mitte. Eine Punkteanzeige oben rechts.

Das Schiff bewegte sich nicht. Der Input war tot. Das Pause-Menü war, wenn aufgerufen, visuell präsent, aber reagierte nicht auf Klicks. Der Punktestand sagte null und blieb null. Es gab keinen Gegner, auf den man schießen konnte. Die Welt war eine höfliche, leere, funktionierend aussehende Hülle.

Für einen Entwickler, der das liest, ist die Schlussfolgerung innerhalb von dreißig Sekunden offensichtlich: Das ist ein Platzhalter. Die echten Gameplay-Prefabs fehlen. Die Engine ist in einen degradierten Modus zurückgefallen und hat vergessen, es irgendjemandem zu sagen.

Für einen Nutzer ist das die schlimmste Art von Versagen. Die Anwendung sieht nicht kaputt aus. Sie sieht fertig aus, und schlecht.

Was tatsächlich nicht stimmte

Zwei unterschiedliche Probleme, jedes subtil.

Der Szenen-Loader degradierte lautlos. Der SceneContentLoader ist dafür zuständig, Gameplay-Prefabs zu finden und sie in die aktive Szene zu instanziieren. Wenn die Prefabs fehlen (wegen eines Build-Problems, eines fehlenden Asset-Pakets, oder einer Konfigurationsabweichung), fällt er auf eine Platzhalter-Konfiguration zurück. Der Fallback sollte eigentlich einen klaren Fehler loggen. Er loggte bei INFO. Die Fehlermeldung war in einem ungefilterten Log-Stream neben dreihundert anderen INFO-Zeilen vergraben. Jeder, der die Demo laufen ließ und das Log überflog, sah nichts Alarmierendes.

Dem Pause-Menü-Canvas fehlte ein GraphicRaycaster. Das ist eine Unity-seitige Sache. Ein Canvas, der keine GraphicRaycaster-Komponente hat, kann keine Pointer-Events empfangen. Das Pause-Menü wurde korrekt instanziiert, renderte korrekt, und war völlig taub für Nutzereingaben. Das Fehlen der Komponente hatte sich durch ein Refactor eingeschlichen, das mehrere Canvas-Konfigurationen zu einer zusammenfasste. Die Zusammenfassung ließ den Raycaster bei einem der Canvases wegfallen.

Beide Bugs hatten dieselbe Note. Etwas ging still schief. Der Codepfad lief weiter. Der Nutzer sah etwas, das funktionierend aussah, aber es nicht war.

Wie ich sie fand

Das Audit dauerte länger als der Fix. Der Fix dauerte einen Samstagnachmittag. Das Audit dauerte den Morgen. Das Muster möchte ich festhalten, weil es sich wiederholen wird.

Der erste Hinweis war, dass der Punktestand bei null feststeckte. Ich nahm an, der Bug vom letzten Wochenende (Punktestand-Doppelzählung) sei überkorrigiert worden. Falsch. Der Punktestand war null, weil es keine Gegner gab. Es gab keine Gegner, weil die Gameplay-Prefabs nicht luden. Die Prefabs luden nicht, weil der Szenen-Content-Loader auf einen Platzhalter zurückfiel und das auf INFO-Ebene statt auf ERROR-Ebene sagte.

Sobald ich das wusste, wurde der zweite Bug offensichtlich. Dass das Pause-Menü nicht reagierte, war ein separates Problem in derselben Demo, aufgedeckt in derselben Samstagssitzung. Das Audit-Muster lautet: „Wenn Sie ein lautloses Versagen gefunden haben, suchen Sie nach benachbarten.”

Was ich behoben habe

Eine kleine, aber präzise Reihe von Änderungen.

Die Platzhalter-Warnung auf ERROR befördern. Wenn der Szenen-Content-Loader kein echtes Gameplay-Prefab finden kann und auf den Platzhaltermodus zurückfällt, loggt er jetzt auf ERROR-Ebene mit der Meldung „PLATZHALTERMODUS: Gameplay-Prefabs fehlen, Demo funktioniert nicht korrekt.” Der ERROR-Schweregrad sorgt dafür, dass sie jede vernünftige Log-Filterung übersteht. Der exakte Text „PLATZHALTERMODUS” ist unverkennbar, wenn man das Log grept.

Einen EnsureCrossPlatformInputManager-Schritt hinzufügen. Selbst im Platzhaltermodus sollte das Input-System funktionieren. Wenn ein Entwickler die Demo im Platzhaltermodus testet (weil er an der UI arbeitet, ohne das vollständige Asset-Paket), muss er in der Lage sein, mit den Menüs zu interagieren. Der Bootstrap stellt jetzt sicher, dass in jeder Szene, auch Platzhalter-Szenen, ein CrossPlatformInputManager-Singleton existiert.

GraphicRaycaster automatisch zu Canvases hinzufügen, die ihn brauchen. Der defensive Fix besteht darin, den Canvas-Spawn-Helfer prüfen zu lassen, ob die GraphicRaycaster-Komponente vorhanden ist, und sie hinzuzufügen, falls nicht. Das wird zukünftige Bugs derselben Art nicht übertünchen, aber es schließt diesen konkreten Fehlermodus aus.

Ausführliches Boot-Logging in AutoBootstrap. Wenn die Demo bootet, drucken die Logs jetzt eine kurze Zusammenfassung, welche Szene geladen wurde, in welchem Modus sie geladen wurde (echt vs. Platzhalter), und welche Subsysteme vorhanden sind. Ein Entwickler, der das Log liest, kann die Frage „hat die Demo im erwarteten Modus gebootet” innerhalb von zehn Sekunden beantworten. Vor diesem Morgen erforderte die Antwort, dreihundert Log-Zeilen zu lesen und zu folgern.

Ein Unit-Test für den Canvas-Helfer. Weil der Bug eine fehlende Komponente war, ist die richtige Art von Test einer, der überprüft, dass die Komponente vorhanden ist, nachdem der Helfer läuft. Dieser Test ist jetzt in der Suite. Wenn jemand den Canvas-Helfer so refactored, dass der Raycaster wieder wegfällt, schlägt der Test laut fehl.

Worauf sich das verallgemeinern lässt

Drei Muster, die man aus diesem Morgen mitnehmen sollte.

Lautloses Versagen ist der schlimmste Fehlermodus. Überall dort, wo Ihr Code in einen degradierten Modus zurückfällt, muss der Fallback schreien. Nicht bei INFO. Bei ERROR. Mit einem String, den grep findet. Wenn der Nutzer nicht erkennen kann, ob der Fallback ausgelöst hat, kann es der Entwickler drei Tage später beim Lesen der Logs auch nicht.

Eine fehlende Komponente in einem konfigurationsgetriebenen System braucht einen Test. Unity, Unreal, jede Engine, in der eine Szene aus Komponenten heraus konfiguriert wird: Die Konfiguration kann lautlos abdriften. Die Verteidigung ist eine kleine Reihe von Tests, die überprüfen: „Szene vom Typ X hat Komponenten A, B, C.” Langweilige Tests. Kritische Tests. Es lohnt sich, sie zu schreiben.

Audit per Nachbarschaft. Wenn Sie ein lautloses Versagen finden, schauen Sie sich jedes benachbarte System an. Bugs häufen sich. Dasselbe Refactor, das den Raycaster wegfallen ließ, hat vielleicht auch andere Komponenten bei anderen Canvases fallen gelassen. Derselbe Lapsus in der Logging-Disziplin, der die Platzhalter-Warnung vergrub, hat vielleicht auch andere Warnungen vergraben. Untersuchen Sie die Nachbarschaft, nicht nur die ursprüngliche Sichtung.

Was Partner und Entwickler daraus mitnehmen sollten

Wenn Sie etwas bauen, bei dem die Engine mehrere degradierte Modi hat (Asset fehlt, Netzwerk ausgefallen, Vendor-SDK nicht verfügbar), muss die Engine Ihnen laut sagen, in welchem Modus sie sich befindet, jedes Mal. Stille Degradierung ist ein Defekt.

Wenn Sie eine Engine für eine Partnerschaft evaluieren, fragen Sie das Team, wie sie mit lautlosem Versagen umgehen. Die richtige Antwort ist: „Wir bringen sie auf ERROR-Ebene mit grep-baren Strings zutage, und wir haben Audits, um sie zu finden.” Die falsche Antwort ist: „Dieses Problem haben wir noch nicht gesehen.”

Wenn Sie einen agentengetriebenen Workflow betreiben und Ihre Agenten Refactors durchführen, werden die Refactors gelegentlich versehentlich Komponenten fallen lassen oder den Log-Schweregrad herabstufen. Der Fix ist ein kleines CI-Gate, das überprüft, dass kritische Komponenten vorhanden sind und kritische Log-Meldungen mit dem richtigen Schweregrad überleben. Nicht glamourös. Effektiv.

Samstagnachmittag. Die Demo meldet sich, wenn etwas nicht stimmt. Das Pause-Menü reagiert wieder auf Klicks. Die Party mit der höflichen leeren Demo ist vorbei.

Zurück zum Bauen.