Por que colocar a configuração da entidade fora dos scripts?

Eu já vi muitos jogos que definem os componentes da entidade nos arquivos de script, mas quando eles configuram cada entidade e especificam quais componentes ela possui, eles usam algum outro formato de arquivo (como XML). porque eles fazem aquilo?

Estou pedindo principalmente para ver qual era a lógica dos outros para isso. Eu também configurar meus entidades fora dos roteiros (embora eu escolhi JSON não XML). Minhas razões para fazer isso são facilitar a implementação de jogos salvos e também porque acho que esse tipo de configuração é melhor organizado em algo como XML ou JSON.

@ Resposta de Christopher Larsen: Muito tempo para postar como comentário

Receio que você tenha se desviado um pouco do assunto da pergunta. Os problemas que você está descrevendo estão mais relacionados a entidades baseadas em hierarquia; Observe na minha pergunta que mencionei que estava falando sobre entidades baseadas em componentes.

Aqui está um exemplo do que eu queria perguntar. Abaixo estão duas maneiras alternativas de configurar uma entidade: por meio do script e por um arquivo JSON externo. Minha pergunta era: por que tantas pessoas preferem configurar a entidade fora dos scripts?

Uma classe de entidade base:

class Entity:
    def __init__(self, name):
        pass
    def addComponent(self, comp):
        pass

A abordagem do script:

orc = Entity('Orc')
orc.addComponent(PositionComponent(3.4, 7.9))

A abordagem JSON:

{
    "name" : "Orc",
    "components":
    {
        "PositionComponent": {
            "x" : 3.4,
            "y" : 7.9
        }
    }
}

Eu já afirmei minhas razões para usar essa abordagem, que são técnicas e organizacionais. Eu queria saber por que tantos outros (pelo que vi) usam isso.

A principal vantagem que me vem à mente é que ela permite que a configuração seja editada / gerenciada por um não programador sem exigir que eles toquem em nenhum dos scripts do jogo.

Uma razão pela qual eu geralmente uso um arquivo de configuração, em vez de um script, é:

A única maneira de verificar se um script está correto, por exemplo, especificando todos os valores e tal, é executá-lo.

Escrever código para permitir que scripts configurem os valores significa escrever código para criar objetos de esqueleto para os scripts preencherem os valores e validar que o script fez isso e aquilo. É mais código e código de falha do que carregar de um arquivo de configuração simples, geralmente usando uma biblioteca que suporta algum tipo de mecanismo de validação.

A configuração da entidade pode ser simplesmente uma serialização de uma entidade específica. Isso permite que você lide com a saída das ferramentas de edição e modificação de jogos da mesma maneira que faria com um jogo salvo. Em particular, para jogos em que você não pode prever em que estado uma determinada entidade estará durante o salvamento do jogo - por exemplo, devido à IA ou porque são parcialmente geradas proceduralmente em primeiro lugar - é útil poder despejar todo dados que definem o que uma entidade "é" (em oposição ao que "faz") como um fluxo de bytes a ser salvo.

O padrão que você descreve é ​​uma implementação de um Sistema Orientado a Dados.

Os sistemas controlados por dados são comumente usados ​​no desenvolvimento de jogos, pois permitem que a definição de conteúdo seja encapsulada externamente à fonte. Essa representação externa pode ser facilmente modificada (e até atualizada em tempo real por um aplicativo que está aguardando modificações) para alterar a maneira como uma entidade se comporta.

Depois que os dados são definidos externamente, você tem todo o tipo de possibilidades em como os designers interagem com eles, desde a edição direta de arquivos de texto (ugh!) Até UIs sofisticadas que orientam as escolhas do designer de maneira lógica, consistente e até verificada para correção (de a perspectiva do equilíbrio do jogo).

Se os dados foram incorporados diretamente no código, qualquer alteração exigiria uma reconstrução do aplicativo que, para projetos grandes, consome moderadamente tempo, bem como o tempo necessário para a implantação dos binários (por exemplo, novos binários devem ser implantados e instalados no servidor).

Vamos dar um exemplo de uma entidade estereotipada, o "orc" ...

Uma maneira de implementar para o nosso orc seria escrever uma descrição completa no código de todas as características e lógica do orc.

• maxhealth = 10
• Dano = 3 de dano por segundo
• fugitivo = verdadeiro
• fugitivo quando = saúde <10
• agressivo = verdadeiro

Quando instanciamos orcs, todos os seus valores são inicializados exatamente da mesma forma (ou talvez sejam estáticos). A questão que surge é que algum designer irá aparecer e dizer: "Precisamos de um tipo diferente de orc para as áreas de novatos, que tem menos saúde, nunca foge e não é agressivo. Isso permitirá que novos jogadores se acostumem a combater sem o maior dificuldade e confusão ao aprender o sistema de combate ".

Ótimo, agora você precisa de uma classe diferente ou (talvez estivéssemos olhando para o futuro) ajustar os valores que alimentamos na "fábrica" ​​que cria orcs ao criá-los em uma área "novato". Então, fazemos as alterações, implantamos novos binários. Apenas para que os testadores de jogo voltem e digam que os novos valores de saúde são muito baixos quando matamos os orcs em um golpe.

Se nossos sistemas foram controlados por dados (e pontos de bônus para aplicativos que suportam recarregar quando são feitas modificações), as modificações necessárias para satisfazer os projetistas e testadores de jogo são simples alterações de dados sem necessidade de recompilação / implantação. Isso deixa os designers felizes porque não ficam presos à espera de alterações no código, e os programadores ficam felizes porque estamos constantemente modificando o código-fonte para ajustar os valores.

Levar os sistemas orientados a dados a extremos permite que tudo, desde níveis de jogo, feitiços e até missões, sejam implementadas por simples mudanças nos seus dados, sem a necessidade de nenhuma alteração no código. No final, trata-se de facilitar a criação, o ajuste e a iteração no conteúdo do jogo.

No seu exemplo, você já está usando duas linguagens de script. Esta é a maneira que eu diria que a longo prazo funciona melhor, mas eu sugiro que você unifique a linguagem de script que está usando. Se o exemplo de script que você deu foi feito em Lua, em vez de em Json, eu diria que use as tabelas de Lua para construir seu objeto. A sintaxe seria realmente semelhante e permitirá que você suporte uma interface para expor seus componentes.

Tocar em por que as pessoas escolhem fazê-lo normalmente em XML e depois em script em lógica é que isso faz sentido quando você diz isso. Aqui está minha definição do objeto em dados, o que é um bom formato de armazenamento de dados? É quase sempre XML (embora eu também vá com JSON;). E então, quando eles querem adicionar lógica, bem, isso é codificado ou colocado em um arquivo de script.

Não é um pensamento errado, mas aos meus olhos as pessoas simplesmente não estão indo para o próximo passo. Veja qualquer idioma completo, c / c ++ / c # ,. Você pode definir os objetos e sua lógica em uma única linguagem, por que não fazer o mesmo em sua interface de script ... É quase como dizer que devemos definir nossas classes em XML e nossos métodos em c # quando você pensa sobre isso. Talvez as linguagens de script de jogos mais antigas não sejam poderosas o suficiente e ainda estejam se mantendo do jeito que foram feitas.