Melhor resposta
Ao contrário de outros motores de jogo importantes, como o Unreal Engine, A CryEngine, ou Source, Bethesda nunca procurou transformar o Creation Engine ou seus predecessores em uma fonte de receita secundária, licenciando-o para outros desenvolvedores. (O trabalho de Obsidian em Fallout: New Vegas foi um caso especial; embora fossem um desenvolvedor externo, foram contratados especificamente para fazer um título em uma das franquias da Bethesda.)
Por causa disso, parece haver um registro histórico claro: qualquer nova funcionalidade incluída em sua última edição de seu Conjunto de construção / Kit de criação interno, para incluir recursos da linguagem de script, foi colocada lá para oferecer suporte a um recurso planejado de seu último jogo ou expansão DLC . Eles fazem uma ferramenta que “mal chega” para fazer o jogo que desejam.
De uma perspectiva de fora, parece que quem aloca orçamento e horas de desenvolvedor para melhorar as visualizações de mecanismo e script sutilezas do desenvolvedor como itens de despesa a serem justificados, em vez de um investimento em infraestrutura para o bem da ferramenta em si e, por extensão, o projeto geral.
Portanto, se essa tendência continuar, a única maneira de nós ” veremos Dynamically Sized Arrays ou Unit Testing adicionados à linguagem de script se Fallout 4 ou Elder Scrolls 5 tentarem implementar recursos complexos o suficiente para exigi-los.
Embora isso possa parecer uma notícia deprimente no início , porque “matrizes dinâmicas” não é exatamente o tipo de coisa que os especialistas em marketing podem colocar como um marcador na parte de trás da caixa, ainda há esperança. Pelo que eu ouvi de modders que analisaram Skyrim Linha de missões da Guerra Civil, foi originalmente planejado para ser muito mais expansivo, mas deficiências no Papiro significavam que o produto final teve que ser severamente reduzido. Seria de se esperar que os criadores de scripts que não conseguiram realizar a visão expansiva exigida deles lembrem os contadores de feijão dessa falha quando fizerem lobby para atualizações de linguagem de script na próxima vez.
(Embora eu também suspeite que depois duas décadas e meia, sua prática de fazer ferramentas de desenvolvimento que são “apenas suficientes” e depois jogá-las para a comunidade para ver o que acontece se tornou uma espécie de “Teste Excalibur” para Bethesda. O modder que surgiu com o extensor de script original para Morrowind, para ser capaz de escrever o mod Morrowind Combat Enhanced, acabou sendo contratado pela Bethesda para desenvolver o combate do Oblivion. Este padrão foi repetido algumas vezes desde então.)
Resposta
Como Paul Gettle disse, concordo que a Bethesda escolheu o caminho para realizar o que buscava ser necessário para seu produto. Não o que é necessário para desenvolvedores adicionais ou para vender as ferramentas de desenvolvimento a terceiros.
No entanto, desculpe pela publicidade, mas existem outras maneiras de criar scripts para skyrim. Por exemplo, um projeto que criei há mais de um ano chamado PapyrusDotNet, você o encontrará em zerratar / PapyrusDotNet , é um projeto que permite compilar código C # no Papyrus , então, basicamente. Em vez de escrever seus mods Skyrim usando Papyrus, agora você pode usar C # 🙂 Isso torna mais fácil para as pessoas que já usam o Visual Studio + C # começar a escrever scripts para Skyrim 😉
Já faz um tempo que atualizei o projeto, mas ele ainda funciona conforme o esperado.
Br, Karl