Como criar uma detecção realista de colisão de jogos de representação de personagens em 2D?

Eu sempre quis criar um jogo de interpretação de papéis 2D à moda antiga, como Star Ocean, Final Fantasy, Sword of Mana e até a série “Tales of”, e acho que muitas pessoas o fazem. Mas antes mesmo de escrever uma única linha de código, fiz muita pesquisa, desenho e testes.

Encontrei quase todas as respostas para minhas perguntas, mas há um problema que não consegui resolver: como você cria uma detecção de colisão realista, porém simples , como nos jogos que eu citei antes?

Já conheço várias maneiras de calcular a detecção de colisões, veja os seguintes exemplos:

Nada disso satisfaz minhas necessidades.

• As colisões baseadas em ladrilhos são muito simples e combinam mais com um Zelda do que com um Star Ocean. Além disso, o desenho de cada peça precisa preencher todo o espaço para parecer realista.
• O pixel perfeito possui muitas restrições. Se seu ladrilho tiver algum pixel aqui e ali, o jogador provavelmente ficará preso no meio do nada (ou seja: em alguns jogos, você ficará preso em uma raiz de árvore com 2 pixels de largura).
• E máscaras binárias usam muita memória e configurações.

Eu li muita documentação, mas nunca encontrei algo que parecesse bom para mim. E todos os meus testes não pareciam nem um pouco com o que eu costumava brincar. Portanto, se você tiver bons links ou tutoriais sobre como o RPG 2D evoluído funciona, entre em contato.

Os Tutoriais N podem ajudar aqui. É certo que eles são para um jogo de plataforma no estilo arcade, mas também funcionam para um RPG de cima para baixo; apenas não aplique gravidade. A premissa é testar a colisão em uma coleção de formas básicas - círculos, caixas delimitadoras alinhadas aos eixos, linhas, pontos, etc.

De alguma forma, você decora seu mundo com eles (talvez por meio de um editor de nível personalizado) ou os gera automaticamente (encaixa-se em uma caixa ou círculo mais próximo) - ou ambos (o padrão é a caixa / círculo gerado automaticamente e permite que um designer faça ajustes) .

Onde trabalho, desenvolvemos vários jogos de plataforma e alguns jogos de exploração de cima para baixo. Nós os fazemos desde os dias do GBA. Na maioria das vezes, usamos AABBs para personagens e objetos, ajustáveis ​​em um editor de sprites - e ficamos loucos aqui, permitindo uma tonelada de caixas por sprite, algumas com finalidades diferentes. Poderíamos ter:

• uma ou mais caixas de colisão, descrevendo a forma do objeto para colidir com as coisas;
• possivelmente muitas "caixas de ataque" que só aparecem quando você está no meio de um ataque (e animado com o sprite), talvez até duas ou três por arma, dependendo;
• algumas "caixas vulneráveis" que sofrerão dano quando atingidas pelas caixas de ataque de outras pessoas - por padrão, usamos a caixa de colisão, mas as caixas vulneráveis ​​tendem a se sentir melhor quando são menores que a caixa de colisão e podemos permitir por danos com reconhecimento de local dessa maneira
• uma ou mais "caixas de ativação" na IA que descrevem a região sensível da IA ​​- eles atacarão se o jogador estiver nessa região, por exemplo.

Os níveis são principalmente cadeias de segmentos de linha; temos um pouco de metadados por segmento para descrever superfícies danificadas ou escorregadias etc.

Portanto, a maior parte da detecção e resposta de colisões torna-se AABB-vs-AABB ou AABB-vs-segment. Ocasionalmente, lançamos um círculo-contra-algo para um projétil, embora muitas vezes uma AABB faça aqui também.

Você não precisa de muitas formas básicas para que as coisas pareçam boas e se comportem bem - algumas irão funcionar, desde que você possa ajustar e iterar nelas.

Além disso, não se sinta mal por misturar sistemas; a colisão baseada em blocos pode ser excelente em algumas áreas (representando a maioria do seu mundo), mas horrível para interações objeto-objeto. Isso é bom; use um sistema diferente para objeto contra objeto! Escrever para interações entre os dois sistemas pode ser mais fácil do que você pensa.