Uso de sintaxes padronizadas em jogos: sim ou não?

TL; DR: Usar CSS como elemento na definição de conjuntos de regras em jogos de estratégia baseados em turnos no estilo Civ: Loucura ou simplesmente insanidade antiga?

Pergunta real:

Projetar regras de análise de conjunto de regras é um problema. Cada jogo lá fora parece definir seu próprio conjunto de regras sobre como os conjuntos de regras devem ser analisados ​​(na medida em que o jogo apresenta conjuntos de regras personalizáveis, é claro).

É hora do desenvolvedor do jogo. comunidade para adotar as sintaxes padronizadas para conjuntos de regras?

CSS é uma opção viável para jogos personalizáveis?

Exemplo: considere um Civ-like com conjuntos de regras personalizáveis; quão bom não seria ser capaz de criar conjuntos de regras da seguinte maneira:

artillery:era(modern) {
  range: 2;
  sprite: url(/isophex/artillery.png);
}

artillery:era(classical) {
  range: 1;
  sprite: url(/isophex/cannon.png);
}

Concordo com a sugestão de Michael Stum de manter o XML, para evitar escrever seu próprio analisador de CSS. Se você pode encontrar uma biblioteca de análise CSS existente, isso é legal, mas caso contrário, o KISS .

Veja como seu exemplo pode parecer em XML:

<artillery era="modern">
    <range>2</range>
    <sprite>/isophex/artillery.png</sprite>
</artillery>

<artillery era="classical">
    <range>1</range>
    <sprite>/isophex/cannon.png</sprite>
</artillery>

Não é muito diferente, né? E com uma das muitas bibliotecas de análise XML disponíveis no mercado, garanto que será muito fácil carregar esse arquivo.

Pessoalmente, eu também usaria XML para conjuntos de regras ou outros arquivos de configuração.

Existem algumas outras alternativas, como YAML ou JSON . Geralmente, eles são menores em tamanho de arquivo que arquivos XML (se isso for um problema) e existem analisadores robustos disponíveis para ler esses arquivos. A sintaxe deles também está mais próxima do CSS, se isso é importante para você :-)

Sua linguagem parece CSS, mas não é. É o seu próprio idioma específico do domínio.

Pergunte a si mesmo: Você realmente deseja criar seu próprio formato de arquivo, para o qual precisa escrever um analisador. Esse analisador precisa ser rápido e robusto. Você também precisa documentar seu formato de arquivo e ensinar às pessoas como ele funciona - afinal, é um idioma personalizado. Você precisa estar ciente de que pode encontrar problemas em que nunca pensou - talvez alguém tenha achado uma boa idéia criar um arquivo de 50 MB e o analisador travar, corrompendo um jogo de saves. Ou você decide adicionar um recurso que só pode ser implementado com uma alteração na sintaxe, interrompendo todos os arquivos existentes.

A razão pela qual formatos como XML são tão populares é porque XML tem esses problemas resolvidos. Você pode encontrar muitos ótimos analisadores XML comprovadamente robustos, rápidos e sem vazamentos. Além disso, muitas pessoas conhecem arquivos XML e como editá-los, e por ser uma sintaxe tão genérica, mas bem definida, você pode ter certeza de que poderá estender mais tarde.

Sua motivação parece ser uma edição fácil manualmente, o que é comum nos SDKs da comunidade. Agora, a razão pela qual as pessoas editam esses arquivos manualmente é que elas não têm as ferramentas que os desenvolvedores de jogos usam. Você pode presumir que uma empresa que desenvolve um jogo por vários anos possui algumas ferramentas gráficas para editar esses arquivos - eles podem não ser ótimos e livres de erros, mas eles editam os arquivos para você e os desenvolvedores raramente os editam manualmente para ajustar algo. Essas ferramentas raramente são lançadas nos 'Modding SDKs'; portanto, a maioria dos modders é editada manualmente.

Portanto, minha reação inicial seria: Em vez de gastar tempo desenvolvendo um novo formato não comprovado, fácil de editar manualmente, prefiro usar um formato comprovado em batalha e gastar o tempo escrevendo ferramentas que facilitam a edição.

Mas declarações gerais não funcionam assim. Depende sempre. Se você passa 3 anos ou mais escrevendo um grande jogo com uma equipe de desenvolvedores considerável, pode gastar muito tempo desenvolvendo, testando e ajustando seu sistema. Se você tiver 15000 arquivos para analisar, será importante encontrar maneiras de reduzir o uso de memória.

Mas para jogos pequenos / médios / independentes, eu usaria um formato conhecido e bem suportado, como XML, e uma boa ferramenta para editá-lo.

O que você está propondo não é uma sintaxe padrão. Ele se parece com uma sintaxe padrão, mas não é realmente CSS, eo modelo CSS não se encaixa o que você está tentando fazer. A sintaxe é boa para selecionar estruturas, mas não para descrevê-las.

Parafuso XML. É detalhado, barulhento, chato de analisar, muitos casos complicados e, apesar de todas as suas reivindicações de validação, ninguém realmente faz isso. Eu sugiro YAML . É um formato padrão de descrição de dados, com bibliotecas de análise disponíveis para qualquer linguagem de programação prática.

Então, aqui está a aparência do seu código no YAML - primeiro como uma variante simples sem tipo, depois com tags de tipo opcionais para pessoas que são pedantes demais para realmente fazer o trabalho.

artillery:
    modern:
        range: 2
        sprite: /isophex/artillery.png
    classical:
        range: 1
        sprite: /isophex/cannon.png

--
artillery:
    !Era modern: !Artillery
        range: 2
        sprite: !URI /isophex/artillery.png
    !Era classical: !Artillery
        range: 1
        sprite: !URI /isophex/cannon.png

O segundo formato é péssimo. Na prática, você realmente não se importa se alguém coloca um período! Era ou período! Ou apenas um dicionário sem tipo, desde que ele possua as teclas que você deseja - alcance e sprite. É análogo a digitar em linguagens de programação e torna as coisas muito mais legíveis. Se não tiver as chaves desejadas, é fácil detectá-lo no momento do carregamento, mesmo sem um esquema. O que é ótimo, porque você precisa do código de qualquer maneira, então por que se repetir? (Isso também significa que, desde que o aplicativo saiba resolver URIs, você não corre o risco de alguém chamá-los acidentalmente de URLs e falhar na validação por motivos estúpidos, como já fez.)

Se você realmente precisa ter uma descrição analisável dos arquivos de dados - como, por exemplo, deseja gerar automaticamente folhas de propriedades para editores e, por algum motivo, fazê-lo na mesma base de código que seu mecanismo não é aceitável - você pode usar algo como esquemas do Kwalify .

Pelo que entendi sua proposta, você está falando sobre a criação de uma DSL (Linguagem Específica de Domínio) externa para as regras do jogo, que segue uma sintaxe precisa e padrão.

Da minha experiência na criação de DSLs para conjuntos de regras de jogos e da minha leitura do livro recente de Martin Fowler sobre DSLs , concluo que são necessárias duas partes principais para criar algo como sua idéia:

• Um modelo semântico (ou modelo de negócios) para o que sua DSL representa. Se você fizer POO, seria uma classe para manter as unidades com atributos como época, alcance, força etc. (ainda assim, PO não é obrigatório)
• Um analisador para preencher esse modelo a partir de arquivos de texto que usam a sintaxe escolhida.

Eu acho que o maior esforço é realmente construir o modelo e não o analisador, mas escolher uma sintaxe padrão tornará o analisador muito mais rápido e fácil de construir. Além disso, se a sintaxe for simples e / ou conhecida pelas pessoas que escrevem as regras, será muito mais fácil fazer isso.

Portanto, sim, crie de todos os modos um modelo de negócios rico para seus conjuntos de regras e depois grave-os usando uma sintaxe padrão. De fato, o XML é frequentemente usado nessa capacidade em jogos e em outros lugares, mas geralmente é considerado muito detalhado e é cada vez mais substituído por formatos mais enxutos, como Json ou Yaml (e por que não CSS).

Espero que ajude a colocar sua ideia sob uma luz diferente.

Não tenho certeza se essa é realmente a sintaxe do CSS; portanto, este é mais o formato "$ selector {$ rules;}" do que o próprio CSS. Minha reação instintiva é que a parte "em cascata" do CSS acabaria sendo muito complicada de se trabalhar e acabaria parecendo muito com código nesse ponto.