Mecanismo de jogo e design orientado a dados

Ouvi falar sobre design orientado a dados e tenho pesquisado sobre isso há um tempo. Então, eu li vários artigos para entender os conceitos.

Um dos artigos é o Data Driven Design, escrito por Kyle Wilson. Como ele descreveu, parece-me que o código do aplicativo (ou seja, o código para controlar recursos como memória, rede ...) e o código lógico do jogo devem ser separados, e o código lógico do jogo deve ser orientado por fontes de dados externas. Nesse ponto, posso imaginar que o desenvolvedor escrevesse algum tipo de editor de jogo que aceite dados externos sobre objetos do jogo (como informações sobre personagens, informações sobre armas, informações sobre mapas ...). O design do cenário será roteirizado por linguagem / ferramenta personalizada, escrita pelo programador, para permitir que o designer do jogo crie interação entre os objetos do jogo. O designer do jogo usará uma linguagem de script existente / personalizada para escrever o script para o jogo, ou a ferramenta de arrastar e soltar para criar o mundo do jogo. Exemplo de abordagem de ferramenta em que posso pensar é o World Editor, que geralmente acompanha os jogos de Bliizard.

No entanto, outro artigo é contra o uso de Design Orientado a Dados, O Caso Contra o Design Orientado a Dados . O autor sugere não deixar o design do jogo guiado por dados, porque levaria mais tempo para desenvolver um jogo, já que o designer do jogo tem o ônus da programação. Em vez disso, haverá um programador de jogos para programar o jogo livremente a partir do desenho do esboço e é verificado pelo designer do jogo após a conclusão da programação do jogo. Ele chama isso de programador. O que penso desse método é semelhante ao que costumava fazer: a lógica do jogo é o próprio aplicativo, em oposição à idéia acima, o aplicativo é o editor do jogo e o jogo real é projetado com base na ferramenta.

Para mim, o primeiro método parece ser mais razoável, pois os componentes do jogo podem ser reutilizados para muitos projetos. Com o segundo método que se opõe ao design orientado a dados, o código do jogo pertence apenas a esse jogo. É por isso que acho que o Warcraft tem tantos gêneros de jogos, como o Warcraft original e vários mapas personalizados, e um dos mais famosos: DOTA, que na verdade define um novo gênero. Por esse motivo, ouvi pessoas chamarem o World Editor de game engine. Isso é verdade como deveria ser um mecanismo de jogo?

Então, depois de tudo isso, eu só quero verificar se há alguma falha no meu entendimento sobre essas idéias (orientadas por dados, acionador de programador, scripts etc ...)?

Tornar os dados do seu jogo (ou qualquer outro produto de software) orientado é quase sempre um benefício. A única vantagem real é que você pode gastar um pouco mais de tempo construindo os sistemas relevantes antecipadamente; embora valha a pena o resto de sua carreira como programador (mesmo que você não reutilize os mesmos sistemas por todo esse tempo, você reutilizará as técnicas que empregou para construí-los).

O desafio e onde a desconexão nesses dois artigos que você vinculou é o que você escolhe colocar nos dados e quem você decide dar acesso a esses dados. Fundamentalmente, o design e o desenvolvimento orientados a dados apenas significam que você coloca informações no armazenamento externo, carrega essas informações em tempo de execução e age sobre elas. O código do aplicativo faz o que os dados externos mandam, em vez de você escrever o código do aplicativo que faz diretamente o que você acha que deveria ser o resultado final. Não é uma ideia complexa.

Você não precisa criar "arquiteturas orientadas a componentes" complexas (como é a moda hoje em dia). Colocar constantes para ajustar a física (força gravitacional, coeficientes de restituição) em um arquivo de texto é orientado por dados. Os scripts (em Lua ou algo mais) são orientados por dados. Descrevendo seus dados de nível em XML. Algo assim.

Você pode conduzir praticamente qualquer componente do software com dados e escolher com quais deseja fazê-lo. O tempo do desenvolvedor é caro; tempo programador especialmente assim. Se você pode economizar tempo de você ou de outros programadores colocando comportamento e dados no armazenamento externo e não exigindo que o jogo seja recompilado a cada pequena alteração, você deve. Você economizará dinheiro e fará as coisas mais rapidamente.

Além disso, você corre um grande risco ao tentar "projetar designers" e fazer com que os programadores "tornem esses projetos realidade", forçando um programador a existir no ciclo de iteração para o trabalho de um designer: você corre o risco de fazer com que o programador se sinta como ele é apenas um macaco de código, fazendo pequenos ajustes triviais para o design constantemente. Isso pode ser extremamente desmoralizante para a grande maioria dos programadores, que desejam trabalhar em desafios técnicos interessantes e não como procuradores de designers.

Para suas perguntas específicas:

Isso é verdade como deveria ser um mecanismo de jogo?

Um "mecanismo de jogo" realmente não tem uma definição fixa. Geralmente, é a coleção unificada de tecnologia subjacente usada para criar um jogo, geralmente suportada por várias ferramentas relacionadas (e, portanto, bastante orientada a dados). Mas isso varia bastante de contexto para contexto.

Então, depois de tudo isso, eu só quero verificar se há alguma falha no meu entendimento sobre essas idéias (orientadas por dados, acionador de programador, scripts etc ...)?

Você parece estar mais ou menos no caminho certo, embora talvez esteja complicando demais o que é o design e o desenvolvimento orientados a dados, confundindo-o com sistemas baseados em componentes.

Como autor do segundo post, gostaria de esclarecer alguns pontos.

1. Como Josh Petrie sugeriu, estruturar seu código para usar dados em vez de codificar apenas tudo é sempre uma vitória. Eu não estava sugerindo o contrário. Eu estava apontando que empurrar tudo no designer não é uma boa ideia. O termo "design orientado a dados" significa coisas diferentes para pessoas diferentes, então eu provavelmente deveria ter sido mais específico quando escrevi o artigo original.
2. Em todos os lugares em que trabalhei, criamos estruturas de dados ajustáveis ​​no mecanismo. Para fazer uma alteração, não precisamos recompilar o jogo. Podemos alterar o número dinamicamente em tempo de execução. As estruturas de dados geralmente são armazenadas no código, mas, dependendo de quem as está alterando, elas podem ser facilmente carregadas de um "arquivo de dados".
3. A maioria dos ambientes de desenvolvimento suporta alguma forma de editar e continuar ou recarregar o módulo para C / C ++.
4. A maioria dos estúdios de desenvolvimento de jogos tem programadores de jogabilidade. O trabalho deles é trabalhar com o designer para criar uma experiência divertida. A principal preocupação deles não são os desafios técnicos, mas a diversão do código. Eu trabalho como programador de jogos há muitos anos, e acho isso mais interessante do que apenas tentar resolver desafios técnicos. Minhas responsabilidades variaram, mas achei meu trabalho mais gratificante quando estou encarregado da implementação e trabalho com os designers na elaboração de algo interessante. O problema com os codificadores ou scripts dos designers é que os programadores geralmente precisam resolver os bugs, o que é uma das coisas menos divertidas que você pode fazer como programador.
5. O que funciona melhor para um estúdio depende do jogo. Se você tem muito tempo para criar um jogo e deseja dar pernas ao jogo para a comunidade de mods e criar algo enorme no escopo, criar um jogo totalmente orientado a dados faz sentido. Muitos jogos não têm esse objetivo. Eles precisam criar um novo jogo em dois anos e, a menos que tenham uma franquia de sucesso, provavelmente é um tipo de jogo diferente do trabalho anterior.
6. O que um "designer" faz pode variar de estúdio para estúdio. Eu já ouvi falar de um estúdio de desenvolvimento que contrata programadores de outros estúdios, os chama de designers e faz o roteiro do comportamento do jogo. Isso evita o problema de ter pessoas que não são treinadas em programação de codificação / script.
7. Sempre deve haver um delineamento entre o código lógico do jogo e o código do mecanismo. Além disso, você normalmente deseja ter algum tipo de editor visual para posicionamento de objeto. Eu nunca trabalhei em um estúdio onde locais inimigos são codificados. Eles são colocados em um editor. Deixe-me propor um exemplo do que estou falando. Digamos que o designer pense em um inimigo. O designer que escreve o comportamento desse novo tipo de inimigo? É isso que considero design orientado a dados (em termos do que Tim Moss escreveu sobre isso). Do jeito que estou propondo, o programador trabalha com o designer, eles formam um inimigo divertido, talvez com parâmetros ajustáveis, e depois são colocados no nível.
8. O código nativo escrito por um programador será executado mais rapidamente em tempo de execução do que um script escrito por um programador, que será executado mais rapidamente do que um script escrito por alguém com conhecimento técnico menos. Esse desempenho pode ou não ser importante, dependendo do tipo de jogo que você está criando e do que está fazendo, mas é algo a considerar.
9. Você pode compartilhar o código do jogo entre os jogos, independentemente do método escolhido. Não tenho muita certeza do que você está conseguindo neste momento. Mesmo se você não estiver usando uma linguagem de script ou ferramenta visual para definir alguns comportamentos, você deve arquitetar seu código de jogo em componentes reutilizáveis, tanto quanto possível. Sempre haverá coisas que não se aplicam ao seu próximo jogo, mas em todos os lugares em que trabalhei, quando começamos o próximo jogo, começamos com a base de código do anterior - mesmo que não seja uma sequência. Depois, mantemos as coisas que fazem sentido e removemos as coisas específicas do jogo.

No final, não há uma resposta certa ou errada. É uma questão de como você e seus colegas de trabalho se sentem à vontade para trabalhar. Quando escrevi esse blog há algum tempo, havia muita conversa sobre como todo o trabalho deveria ser enviado aos designers, e eu queria escrever sobre quantas empresas de jogos bem-sucedidas que conhecia encontraram um equilíbrio diferente.

Além disso, como uma observação lateral, minha entrada no blog tem 5 anos. Parece que muito mais estúdios estão adotando linguagens de script e outros enfeites hoje em dia, mas estão criando ferramentas maduras para depurá-las, o que foi minha principal reclamação. Quando escrevi isso, não acho que o Unreal Kismet existisse, o que não usei, mas parece que eles estão tentando simplificar os scripts e, aparentemente, possui um depurador. (Não faço ideia de como isso funciona)

Para jogos de menor escala, eu definitivamente não acho que você queira tentar usar uma linguagem de script ou funcionalidade semelhante em sua tecnologia, mas se você tiver uma equipe enorme e muito tempo para se dedicar à tecnologia, é possível fazer isso o investimento certo e no tempo pode fazer sentido, dependendo da maneira como sua equipe de desenvolvimento gosta de trabalhar. Pessoalmente, provavelmente vou me apegar ao C ++ pelo maior tempo possível porque, para mim, é o mais fácil e rápido, pois muitas vezes tenho que tentar contornar "recursos", como coleta de lixo.

Você deve procurar o BitSquid Tech Engine . É construído usando conceitos do DOD. O blog de Niklas Frykholm é muito interessante. Existem muitos artigos sobre como esse mecanismo foi projetado.

No GDC 2011, Niklas fez uma apresentação sobre o Data Driven Renderer .