Suponho que você queira dizer geradores de código proprietários, manuseados manualmente para uso interno específico, pois, caso contrário, qualquer coisa que não seja o código da máquina é um gerador de código. Mas aqui vai você:
Eu acho que é muito discutível que o gráfico de nós no Blueprints seja mais fácil de manter e muito menos propenso a erros do que o código GLSL / HLSL que ele gera (e, caso contrário, precisaria ser manuscrito).
Também é muito mais produtivo criar novos shaders, pois você obtém um feedback visual em tempo real de como o resultado final se parece à medida que você altera o gráfico. Definitivamente, prefiro manter milhares de shaders representados com gráficos nodais dessa maneira, em vez do código GLSL / HLSL, e na verdade estou mais familiarizado com a escrita do GLSL / HLSL do que com o Blueprints. Eu acho que é praticamente impossível causar um bug grave, além de talvez algumas pequenas falhas visuais que você provavelmente perceberia imediatamente porque a "linguagem visual" impõe restrições sensíveis com um estilo funcional puro que não permite, por exemplo, bater um shader, pelo menos AFAIK (eu não sou um especialista em Blueprints).
Não há mais "código" para manter mais. Você apenas coloca nós dentro de um gráfico e desenha links entre eles e, voila, gera código de sombreador para você. Quem mantém essas coisas e diz: " Sabe, minha vida seria muito mais fácil e eu teria muito mais tempo livre se isso fosse escrito apenas no código GLSL em vez de usar o Blueprints " . Provavelmente nunca.
Dito isso, encontrei minha parte de geradores de código proprietários que tornaram a vida mais difícil, o que me fez aprender essa meta linguagem estúpida que possui benefícios muito limitados, se houver, sobre a escrita de código no idioma do código gerado. Para mim, um sinal revelador de geração de código é uma merda, que faz pouco mais do que reduzir uma pequena quantidade de clichê e não reduz, digamos, a possibilidade de bugs. Você sabe que é especialmente ruim se ele realmente introduzir novas maneiras de causar bugs que o idioma original não possuía. Mas há casos de geração de código, como o descrito acima, em que o aumento da produtividade é tão grande, tornando coisas meticulosas que custam um tempo enorme agora custam centavos, que ninguém jamais usaria e depois olharia para trás.
Para mim, há um argumento mais legítimo para o desenvolvimento proprietário do Blueprints entre a equipe da Epic do que muitas linguagens de programação supérfluas por aí criadas para o público em geral, que mal trazem algo novo para a mesa.