Der Tag, an dem unsere Shader im Build fehlten

Im Unity-Editor sah alles perfekt aus. Im fertigen Build: rosa Flächen und fehlende Effekte. Willkommen bei einer der fiesesten Unity-Fallen — und ein paar ihrer Verwandten.

Das Shader-Stripping. Unity wirft beim Bauen alles raus, was scheinbar nicht gebraucht wird — auch Shader. Das Problem: Wer Shader zur Laufzeit per Shader.Find() lädt (wie wir mit unseren über 20 Custom-Shadern für Wasser, Atmosphäre, Hologramme und mehr), für den sieht Unity keine Referenz in einer Szene. Ergebnis: Der Shader ist im Editor da und im Build weg. Die Lösung ist unspektakulär, aber essenziell: Jeder dieser Shader muss in die Liste der Always Included Shaders in den Graphics-Settings. Seitdem gilt bei uns die Regel: Neuer Shader? Sofort eintragen.

Der Layer, der -1 war. Ähnliche Kategorie: Wir haben einen Physik-Layer per Code über seinen Namen aufgelöst. Im Editor: funktioniert. Im Batch-Build auf dem Build-Server: Der Layer existiert nicht, die Abfrage liefert -1, und alles, was auf diesem Layer basiert, verhält sich still und leise falsch. Seitdem referenzieren wir Layer über ihren festen Index, nicht über den Namen.

Die Moral: Der Unity-Editor und der fertige Build sind zwei verschiedene Welten. Der Editor ist gnädig — er hat alle Assets, alle Namen, alle Shader griffbereit. Der Build ist gnadenlos. Deshalb gehört bei uns zu jeder Änderung am Client ein echter lokaler Build-Test, nicht nur der Play-Knopf im Editor. Das dauert länger. Es hat uns trotzdem schon viele peinliche Releases erspart.