Como fizemos um jogo de tabuleiro com controle remoto - Parte 2

Na última vez em que falei sobre o componente técnico do nosso jogo de tabuleiro “inteligente”, quais problemas encontramos e o que aconteceu no final.



Hoje eu quero falar com mais detalhes sobre o aplicativo móvel, o primeiro jogo e como criar miniaturas para ele.

O primeiro artigo pode ser encontrado aqui: Como fizemos um jogo de tabuleiro com controle remoto - Parte 1

Atenção! Muitas fotos.

Nos comentários do último artigo, eles observaram corretamente que é melhor não fazer um jogo, mas uma plataforma com base na qual você já pode criar jogos usando a mecânica disponível. Inicialmente, planejamos, mas, como resultado, percebemos que não podíamos fazer algo além do jogo. Só por causa da falta de experiência em design de jogos ou designers de jogos familiares que poderiam nos dizer quais mecânicas deveriam ser suportadas.

Portanto, decidimos que implementaremos todas as funções básicas da plataforma (movimento, destaque dinâmico, prompts) em nosso primeiro jogo, que apresentaremos nós mesmos. E então, usando a experiência adquirida, faremos um construtor de jogos completo.

Aplicativo para celular

Como escrevi anteriormente, todo o gerenciamento de plataforma é realizado através de um aplicativo móvel que se conecta a ele através do protocolo BLE.


De fato, para implementar qualquer jogo, você precisa escrever um aplicativo móvel completo para ele, no qual descreve todas as regras e mecânicas.

No processo de criação do aplicativo, realizamos todos os testes conectando-nos à plataforma, o que não é muito conveniente. Portanto, para simplificar a depuração, criamos um emulador de software simples dentro da estrutura do aplicativo, no qual os dados são exibidos exatamente como seriam exibidos no campo de jogo.


No início, encontramos um problema em que os dados que saem do aplicativo são perdidos. Descobrimos que, ao usar o BLE, o tamanho máximo do pacote que pode ser enviado é de 20 bytes. Portanto, dividimos todos os dados de saída no BLE em pacotes de 20 bytes, o parâmetro "Gate" é escrito no cabeçalho. Este parâmetro ajuda o Arduino a entender a qual componente da plataforma esse pacote pertence. Do lado do Arduino, o processamento desses pacotes é elementar:

if (NewCommandReady) { switch (CurrentGate) { case 1: processLEDCommand(); break; case 2: processDriverCommand(); break; case 3: processMagnetCommand(); case 4: // break; } //  NewCommandReady = false; } 

Depois de dividirmos o fluxo de dados entre o smartphone e o módulo BLE em pacotes de 20 bytes, os dados pararam de desaparecer, mas muitas vezes chegavam ao Arduino de forma distorcida. Descobrimos que não levamos em conta que a porta serial do Arduino possui um buffer de 64 bytes. Quando o buffer excede, os dados são perdidos e os subsequentes são distorcidos. Aumentar o tamanho e criar seu próprio buffer nem sempre ajudou. Eu tive que escrever um protocolo de invólucro em cima do transporte BLE para enviar e receber dados com segurança.

Devido ao uso desse "protocolo", a troca de dados foi um pouco mais lenta, verificando a integridade dos dados transmitidos, no entanto, a confiabilidade é mais crítica para o jogo - será uma pena se a exibição de alguma habilidade AOE estiver incompleta ou se o herói não for movido ao confirmar a movimentação em um telefone móvel.

Para exibir objetos no campo de jogo, usamos o princípio de camadas nos subsistemas da janela do SO:

• Cada objeto ou ação destacada (heróis, obstáculos, a maneira como o herói se move, o escopo disponível da habilidade e o restante) usa sua própria camada.
• Quando camadas são aplicadas (por exemplo, a região AOE sobre o escopo disponível da capacidade), o estado inicial dos LEDs é lembrado. Como resultado, é possível retornar a cor original quando a camada superior desaparecer.

A maior parte dos dados transferidos entre o aplicativo móvel e a plataforma é a repintura dos LEDs. Para fins de otimização, foram adicionados alguns algoritmos:

• Para repodificar diodos, é usado um buffer no qual as alterações são feitas até o momento em que essas alterações devem ser exibidas na placa física.
• A repintura de um único LED no mesmo comando é excluída.
• Ao repintar (por exemplo, o deslocamento da área da capacidade AOE por 1 célula), o estado atual da placa de LED é analisado. Se a cor do LED no novo estado não diferir da anterior, nenhum comando será recebido pelo Arduino para repintá-lo.

Jogabilidade

Então, você decidiu jogar. Abaixo, descreverei como fica de lado:

1. Nós inserimos o plugue na tomada e ligamos o jogo.
2. Em cada partida, uma calibração automática ocorre para determinar o número exato de etapas do motor de passo para mover uma célula.
3. Paralelamente, conectamos o smartphone ao jogo usando Bluetooth.
4. No aplicativo móvel, cada jogador seleciona o personagem que ele quer jogar. Depois que todos fizerem sua escolha, pressione “INICIAR”.
   
   
   
5. Cada um dos personagens tem sua própria cor. O jogo destacará automaticamente a célula onde você precisa colocar a figura do seu herói.
6. O jogo ocorre sequencialmente. A primeira jogada é feita pelo jogador que primeiro escolheu o herói, a segunda - a segunda, etc.
7. Cada herói tem um certo número de Pontos de Ação (DO) que podem ser gastos em movimentar-se pela arena ou aplicar habilidades.
8. Cada habilidade tem seu próprio tempo de recuperação, que é calculado em rodadas. Na estrutura do aplicativo para dispositivos móveis, existem 2 conceitos: Mover - o intervalo do começo ao fim das ações atuais do jogador. Rodada - a soma dos movimentos de todos os jogadores participantes do jogo. Atualmente, o turno de um jogador é limitado a 30 segundos.
9. Obstáculos são colocados no campo pelo qual o jogador não será capaz de passar ou usar a maioria das habilidades. Agora eles são simplesmente destacados em vermelho no campo de jogo, mas no futuro eles terão uma personificação física.
   
   
   
10. Você pode mover o campo com a ajuda de habilidades especiais que todo herói possui. Por exemplo, o teletransporte de um mágico. Ao contrário do movimento padrão, quando um jogador abre a rota de célula por célula do herói, ao usar essas habilidades, o jogador indica apenas o ponto final. Como resultado, é necessário que um algoritmo encontre o caminho mais curto para um ponto especificado, ignorando todos os objetos com os quais a colisão é possível (figuras de outros heróis, figuras de obstáculos, etc.).
    
    
    
    
    Esse problema é resolvido de maneira bastante simples com a ajuda de gráficos e a passagem de BFS pelas células.
    Em resumo, a essência do algoritmo é marcar as células pela distância, da posição atual do herói até a célula especificada (indicada em laranja), na qual o herói deve ser movido.
    
    Depois de encontrar a célula desejada, o caminho de retorno é pesquisado nas células de forma que a distância do ponto inicial à próxima célula seja 1 a menos que a célula atual (a passagem é marcada em amarelo). Após retornar à posição inicial (célula verde), é formada uma sequência de pontos, que é o caminho mais curto. É essa sequência que é transmitida ao Arduino como equipes para mover o herói.
    
11. Após a morte do herói, o jogo move automaticamente sua figura para a "zona de origem". Zona inicial - uma célula na qual a figura é colocada no início do jogo. Cada jogador tem o seu. Depois de iniciar o jogo, você não pode entrar ou usar a habilidade na zona de origem. Isso é feito para que seja impossível pegar o jogador no avivamento. Para um jogador cujo herói é derrotado, o jogo termina em 1 rodada. Depois que ele se junta à batalha.
    
    
    
12. No momento, o jogador cujo herói foi o último a permanecer em campo derrotando os adversários está vencendo. Mas a condição pode ser diferente, por exemplo, quem marcou N frags vence pela primeira vez.

Esta é uma jogabilidade que funciona na versão atual. Devido à falta de experiência em design de jogos, talvez não possamos ver escolas ou oportunidades óbvias. Por exemplo, é sempre doloroso aguardar sua próxima jogada. Na implementação atual, o tempo de espera pode chegar a 1,5 minutos. Na próxima versão do protótipo, planejamos adicionar leitores de etiquetas RFID, o que diversificará a jogabilidade. Por exemplo, use cartões com etiquetas RFID que você pode aplicar fora do seu turno.

Miniaturas

As miniaturas adoram tudo! E não somos exceção. Portanto, paralelamente à coleção de mecânica e programação, estávamos empenhados em inventar nossas próprias miniaturas. Acho que pelas fotos fica claro que nosso jogo é sobre gatos de fantasia brigando na arena.
Porque não sabemos como extrair da palavra, nos voltamos para o nosso amigo, que com grande prazer começou a desenhar "gatos lutadores".

Ela levou nossos animais de estimação como base. Então, na casa dela, vivia um gato enorme e cruel apelidado de "Pirata" - é ele quem está no coração do guerreiro em miniatura.

Depois de algumas semanas, fizemos nossos primeiros esboços.


Pelos artigos sobre a produção de jogos de tabuleiro, percebi que na Rússia a criação de miniaturas é ruim o suficiente e muitos as encomendam na Finlândia ou na Alemanha.

Antes de nos dedicarmos à produção de miniaturas, precisávamos criar modelos mestres de cada herói, o suficiente para um protótipo. A princípio, queríamos transformá-los em argila de polímero, mas, entre nossos amigos, não havia miniaturistas, e os feitos sob encomenda eram muito caros na época. Portanto, decidimos que os imprimiríamos primeiro em uma impressora 3D. Para fazer isso, nosso amigo nos transformou em modelos 3D dos nossos primeiros heróis no Zbrush.


Com a ajuda da impressão FDM, não foi possível imprimir números de qualidade aceitável, o que era bastante esperado.

Felizmente, minha esposa tem impressoras 3D SLA em ação.

Estereolitografia (SLA) é uma tecnologia de impressão 3D que permite converter materiais líquidos em objetos sólidos usando uma fonte de luz, camada por camada, usando o processo de fotopolimerização. A espessura da camada durante a impressão usando a tecnologia SLA é várias vezes menor do que durante a impressão usando o FDM; portanto, a qualidade do produto final é maior.

Alguns dias depois, recebemos nossas primeiras miniaturas.


A qualidade dessas miniaturas é muito maior, mas ainda não atinge a produção obtida por moldagem de plástico. A culpa é do suporte, que após a remoção deixa marcas visíveis. Em teoria, poderíamos "cortar" as figuras em partes separadas e imprimir cada uma individualmente, sem o uso de suportes, e colá-las. Mas levaria muito tempo e, além disso, ainda poderia mudar no futuro.

Cada figura fica em sua própria base, que também imprimimos em uma impressora 3D. Dentro da base é um ímã de neodímio. O tamanho e a espessura do ímã foram selecionados empiricamente para que a figura magnetizasse calmamente o eletroímã no carro da plataforma, mas não reagisse às figuras vizinhas.

Total

No momento, estamos empenhados em melhorar as características físicas da plataforma e a confiabilidade de todos os componentes. Substituiremos o compensado por policarbonato e plástico ABS, melhoraremos a fixação dos componentes da plataforma e tornaremos o campo de jogo removível para que possa ser alterado para um campo de outro fator de forma (por exemplo, hexagonal). O próximo passo é criar um MVP completo, o que não é uma pena para mostrar às pessoas.

Com o jogo um pouco mais difícil. Claro, quero me concentrar completamente na implementação da plataforma, sem referência a um jogo específico. No entanto, estamos cientes de que ninguém está interessado em uma plataforma sem um jogo.

Obrigado a todos por suas críticas / conselhos / interesses. Tínhamos uma ideia sobre a criação de uma versão sem usar mecânica, mas com a capacidade de determinar a posição e o tipo da figura no campo. Eu acho que o próximo artigo será escrito após a criação do MVP .