Tenho trabalhado na recriação das mecânicas clássicas do jogo Space Invaders como forma de aplicar os conhecimentos adquiridos. A maior parte do jogo foi reproduzida com fidelidade ao original, porém, deparei-me com um desafio considerável: a simulação da destruição dos bunkers. No jogo original, os bunkers são danificados pixel a pixel, criando um efeito visual realista e gradual. A implementação dessa mecânica específica tem sido o principal obstáculo do projeto.
Depois de pesquisar muito como eu poderia aplicar essa funcionalidade, encontrei na internet essa solução:
Para destruir o bunker, usamos uma textura “splat” e a sobrepomos no bunker. Para cada pixel que é compartilhado entre o bunker e a textura “splat”, esse pixel se torna transparente, criando assim buracos.
Sempre que um projétil entra na área de gatilho de um bunker, temos que verificar a colisão manualmente, vendo se o pixel que foi atingido é transparente ou não. Se o pixel for transparente, o projétil continua se movendo, caso contrário, ele é destruído e causa um “splat” no bunker
Pelo que eu intendi, ele usa outra sprite “Splat” para tornar a sprite do bunker transparente onde ela foi atingida. Porem eu ainda nao tenho conhecimento tecnico para aplicar essa solução. Se alguem souber como fazer e puder me dar umas dicas eu agradeço.
Eu não sei bem como funciona isso no jogo, faz muito tempo que joguei, mas falando em questões de complexidade. Não vale mais você criar uma variável de estado do bunker, e de acordo com o estado atual setar a sprite do mesmo? E então a cada modificação do estado, você substituí a sprite atual do bunker por uma mais deteriorada?
Entendo que não daria o efeito de consumir o pixel exatamente onde a bala encosta, mas acredito que em questão de Game Design e resposta para o jogador, daria a mesma experiência e o mesmo não notaria a mudança, pois teria o feedback visual de qualquer forma.
Agora, se você pretendo mesmo recriar o efeito exatamente onde o pixel colidiu, talvez você poderia criar um gameObject para cada “pedaço” do bunker, e quando o tiro colide com este game object destruir ele.
Dessa forma a próxima colisão seria diretamente no próximo gameObect.
Vendo que é um jogo simples, com poucos bunkers, acho que não teria um impacto na performance.
Essa é uma boa solução! Usar game objects separados para cada “pedaço” do bunker pode funcionar bem, especialmente porque, como o jogo é relativamente simples, o impacto na performance será mínimo. Basicamente, cada parte do bunker seria um objeto independente, e quando o projétil colidir com um desses objetos, você o destrói, criando o efeito visual de dano. Assim, cada colisão subsequente atinge um novo game object, mantendo a lógica de destruição gradual.
A vantagem aqui é que você não precisa manipular pixels ou usar sprites masks complicadas. Só precisa gerenciar a colisão e destruição dos pequenos blocos. Como os bunkers são poucos, o gerenciamento de múltiplos objetos não será pesado para o jogo.
Eu não conhecia o jogo, muito bacana. Não faço ideia como deve ser feito, mas imagino que pode ser por aí, ou, talvez a engine tenha alguma forma de se trabalhar com pixels mesmo, como se cada um fosse um game object, ou ele próprio desenvolveu via script.
Outra coisa que parece, não foquei ainda nas aulas 2D, pois meu foco é o 3D, mas talvez ali esteja usando muitos sistemas de partícula, e isso faz os efeitos ficarem tão legais ali nas destruições e tudo mais. Deve ser uma mistura pra trazer o efeito de destruir pixel por pixel.
Não conhecia esse game. Muito lega! Em relação a essa mecânica de deformação, existe várias formas de fazer isso. Várias mesmo… Particularmetne nunca tentei fazer essa mecânica. Mas pesquisa sobre o assunto agora a pouco achei esse projeto no github:
Ainda não cheguei a testar, mas pelo que lí o autor implementou uma lógica onde o terreno é representado por uma lista de colunas, onde cada coluna contém intervalos de preenchimento de acordo com a imagem de base.
Essas colunas formam chunks, que são pequenos blocos do terreno. Quando o terreno é destruído, apenas os chunks afetados são recalculados, e recria um BoxColliders2D usando Quadtree para se ajustar ao novo terreno.
Parece interessante, quem quiser dar uma olhada o link está acima.
