Supongo que te refieres a generadores de código patentados manejados para un uso interno específico, ya que de lo contrario cualquier cosa que no sea código de máquina es un generador de código. Pero aquí tienes:
Creo que es muy discutible que el gráfico de nodo en Blueprints sea más fácil de mantener y mucho menos propenso a errores que el código GLSL / HLSL que genera (y de lo contrario hubiera sido necesario escribirlo a mano).
También es mucho más productivo crear nuevos sombreadores, ya que obtienes una retroalimentación visual en tiempo real de cómo se ve el resultado final a medida que cambias el gráfico. Definitivamente preferiría mantener miles de sombreadores representados con gráficos nodales de esta manera en lugar de código GLSL / HLSL, y en realidad estoy más familiarizado con escribir GLSL / HLSL que con Blueprints. Creo que en realidad es prácticamente imposible causar como un error importante, además de algún error visual menor que probablemente atraparías de inmediato porque el "lenguaje visual" impone restricciones sensibles con un estilo funcional puro que no te permite, por ejemplo, estrellar un sombreador, al menos AFAIK (ciertamente no soy un experto en Blueprints).
Ya ni siquiera hay un "código" para mantener. Simplemente coloca nodos dentro de un gráfico y dibuja enlaces entre ellos y, voila, genera un código de sombreador para usted. Quien mantiene estas cosas y dice: " Sabes, mi vida sería mucho más fácil y tendría mucho más tiempo libre si solo estuviera escrito en código GLSL en lugar de usar Blueprints " . Probablemente nunca.
Dicho esto, me he encontrado con mi parte de generadores de código patentados que hicieron la vida más difícil, haciéndome aprender este estúpido metalenguaje que tiene beneficios muy limitados, si los hay, sobre escribir código en el lenguaje del código que generó. Para mí, una señal reveladora de generación de código que es una mierda es algo que hace poco más que reducir una pequeña cantidad de repetitivo y en realidad no reduce, por ejemplo, la posibilidad de errores. Sabes que es especialmente malo si en realidad introduce nuevas formas de causar errores que el idioma original no tenía. Pero hay casos para la generación de código, como el anterior, en los que el aumento de la productividad es tan masivo, lo que hace que las cosas meticulosas que cuestan un tiempo enorme ahora cuestan centavos, que nadie lo usará y luego mirará hacia atrás.
Para mí, hay un argumento más legítimo para el desarrollo patentado de Blueprints entre el equipo de Epic que muchos lenguajes de programación superfluos creados para el público en general que apenas aportan nada nuevo a la mesa.