Depois de passar um tempo hoje para anotar algumas notas sobre a implementação de paredes no meu jogo baseado em blocos, de repente percebi que não seria tão simples como eu imaginava antes. Embora o estágio atual do meu trabalho não esteja nem perto de realmente criar o código relacionado à parede, criei três maneiras diferentes de fazê-lo. No momento, não tenho certeza de qual das minhas idéias funcionará melhor e se perdi alguma coisa ou não.
Importante: um personagem PODE ficar em um ladrilho que tenha paredes, independentemente de sua forma.
O comum para todas as três variantes: o mapa de mosaico será "mantido" em um contêiner std :: vector (ou similar) de dimensão única. As razões para isso são (espantosamente) explicadas nas respostas a uma pergunta diferente.
Classes de contêineres em jogos baseados em blocos.
De volta às paredes.
A) A abordagem simples.
Nada extravagante aqui. Cada contêiner de bloco pode conter não apenas caracteres, mas um ou vários objetos de parede, que são anexados à borda dentro do bloco.
Prós: fácil de implementar, nada para mudar no mecanismo. Contras: Duas coisas. Um - pode estar na minha cabeça, mas algumas combinações parecem feias. Segundo - essa abordagem permite fazer uma parede dupla a partir de dois ladrilhos adjacentes. A construção será uma parte importante do jogo, e as paredes duplas permitem que os construtores renunciem a atualizar o material das paredes por meios de jogo e apenas aumentem a durabilidade ao dobrar a parede existente. Isso não é desejável. Claro, eu poderia incluir um procedimento que proíbe a parede dupla, mas terá uma sensação ruim.
B) A abordagem inteligente (?).
Em vez de deixar os jogadores dobrarem o mapa inteiro, vou vencê-los. Cada parede tem duas metades que estão presas à borda do ladrilho por dentro. Então, para criar uma única "unidade de parede", terei que criar dois objetos de meia parede em dois blocos adjacentes.
Prós: É simétrico !!! Além disso, nenhuma alteração significativa nas especificações atuais do mecanismo é necessária. Contras: Mais problemas, mais objetos e, é claro, os "limites". Como você pode ver na figura, um canto basicamente chora por um objeto "cap". Eu sou legal com isso, não é tão difícil de adicionar. Ei, eu já tenho um plano para colunas finas feitas de quatro tampas conectadas. Doce. Ainda assim, tenho algumas preocupações em relação a possíveis problemas no campo de visão e na linha de visão.
C) A variante de revisão total.
Ou eu poderia criar bordas e cantos como contêineres separados para objetos do jogo. Bem desse jeito.
Prós: nem tenho certeza. Bem, é simples. Definitivamente. Contras: Isso exigirá uma revisão geral. Felizmente, não do código, mas da mentalidade atual da mecânica do jogo - isso é certo. Os benefícios não são tão óbvios. Além disso, essa abordagem requer muito mais contêineres do que os dois anteriores. A matemática da indexação também será um pouco trabalhosa.
Então, aqui temos - três maneiras distintas de fazer paredes entre azulejos. Se houver alguma alternativa por aí - ficarei feliz em vê-la. Se houver algum benefício / queda em alguma das abordagens que eu não vi - indique-as.