El día en que nuestros shaders desaparecieron de la build

En el editor de Unity, todo se veía perfecto. En la build final: superficies rosas y efectos que faltaban. Te presentamos una de las trampas más traicioneras de Unity… y a algunos de sus parientes.

El shader stripping. Al compilar, Unity descarta todo lo que en apariencia no se necesita, shaders incluidos. El problema: si cargas shaders en tiempo de ejecución con Shader.Find() (como hacemos nosotros con nuestros más de 20 shaders propios para agua, atmósfera, hologramas y más), Unity no ve ninguna referencia a ellos en ninguna escena. Resultado: el shader está en el editor y desaparece en la build. La solución no tiene nada de espectacular, pero es esencial: cada uno de esos shaders tiene que ir en la lista Always Included Shaders de los ajustes gráficos. Desde entonces, nuestra regla es: ¿shader nuevo? Se añade al momento.

La capa que valía -1. De la misma familia: resolvíamos una capa de física en el código a partir de su nombre. En el editor: funciona. En la build por lotes del servidor de compilación: la capa no existe, la búsqueda devuelve -1, y todo lo que depende de esa capa se comporta mal sin decir ni pío. Desde entonces referenciamos las capas por su índice fijo, no por su nombre.

La moraleja: el editor de Unity y la build final son dos mundos distintos. El editor es benévolo: tiene a mano todos los assets, todos los nombres, todos los shaders. La build es implacable. Por eso, en nuestro caso, cada cambio en el cliente va acompañado de una prueba con una build local real, no solo del botón Play del editor. Lleva más tiempo. Aun así, ya nos ha ahorrado muchas versiones vergonzosas.