A primeira etapa no desenvolvimento do meu jogo foi o desenvolvimento do mecanismo RTS. Pretendo escrever uma série de posts sobre os problemas que surgiram e suas soluções neste blog. Neste post, mostrarei como organizei o comportamento das unidades.
Pensando sobre onde iniciar esse mecanismo RTS em geral, cheguei à conclusão de que vale a pena começar com detalhes e passar dele para a abstração. A primeira aplicação que veio à mente foi a coleta de recursos, ou melhor, a extração de madeira.
Normalmente, esse processo, na maioria das estratégias, consiste no fato de que o funcionário, após o recebimento do decreto para cortar a árvore, vai até a árvore, por algum tempo acena uma picareta perto dele com um machado, depois vai para o armazém e recomeça.
Ou seja, o processo se parece com isso:
Para que essa imagem possa realmente reivindicar o nome do autômato, faltam as condições para transições entre estados e o estado inicial e final.
Tudo é simples aqui: a máquina é inicializada com o estado “vou cortar”, e o final do trabalho ocorre durante a mudança. Podemos expressar as transições entre estados usando as seguintes condições: “alcançou a árvore”, “cortou uma pilha cheia de lenha”, “alcançou o armazém”, “recursos entregues”. Se a resposta for sim, a máquina entra no próximo estado; se for negativa, permanece no estado atual.
Em cada um dos estados do autômato, a ação correspondente é chamada durante a iteração. Um conjunto de ações também pode ser executado durante a transição entre estados.
Por exemplo, ao iterar no estado "Entregar", os recursos da mochila da unidade serão transferidos para a loja de recursos do jogador e, ao alternar do estado "Indo para cortar" para o estado "Rublo", a animação correspondente será iniciada.
Também observo que caminhar em si não é uma operação "atômica", é encontrado em muitos comportamentos e é em si um comportamento, e, portanto, o comportamento de extração de árvores realmente usa o comportamento de caminhar dentro de si. Ou seja, um novo autômato pode ser obtido usando a composição de vários outros autômatos finitos.
Ao escrever os comportamentos dessa maneira, obtemos um limite arquitetural entre os detalhes da implementação dos comportamentos e a política de alto nível para gerenciar esses comportamentos. Implementações de comportamentos se tornam essencialmente plug-ins para o resto do jogo, ou seja, alterações neles não afetarão a correção da lógica de alto nível.
Esses comportamentos funcionam chamando o método de iteração do evento Update de objetos do tipo Unit (esse evento dispara todos os quadros). Para se comunicar com o resto do mundo, os métodos IStateMachineListener são chamados.
Este é um exemplo de construção de máquina de estado no meu jogo. Após o recebimento de uma equipe de construção, a unidade vai para o ponto especificado e entra no estado de construção direta, transferindo as unidades de construção para o edifício. Quando o edifício acumula unidades de construção suficientes, a máquina de construção termina e a unidade recebe um novo comportamento, o comportamento padrão.
Isso é tudo. Se você gosta ou não desse formato, escreva sobre ele nos comentários!