A julgar pelo que @davidluzgouveia comentou no post de forma anônima, vou abrir meu projeto. O caminho a seguir e a localização de caminhos são muito diferentes. A localização de caminhos é mais sobre o que foi publicado anonimamente, e para encontrar informações sobre o algoritmo de Dijkstra. Para o caminho a seguir, eu uso inteiramente meu mecanismo de física de escolha. A maneira como eu o configurei é que cada local em que uma classe de unidade caminha, é configurado na subclasse de processamento através de deslocamentos 2D, sim, eles são 2D e não 3D, é por causa da maneira que eu tenho minha física configurada no meu jogo .
Explicação 3D:
Cada unidade possui apenas um colisor principal configurado exclusivamente para colisão com os objetos do terreno e do mundo. É uma forma de cápsula e tem um raio e altura programaticamente falando. Ele é construído no centro do modelo e deve se estender logo após a frente e a parte superior do modelo. Mas eu também tenho um deslocamento de superfície para a distância que está do chão o tempo todo, e uma quantidade de quanto é permitido deslizar para baixo antes de saltar um pouco de cada vez. Parece que estou aplicando algum tipo de reparo estragado para um problema de colisão de terreno, mas tenho minhas razões.
De qualquer forma, você deve aplicar força nesse objeto da cápsula e ele deve permanecer pairando acima do solo o tempo todo. Isso não quer dizer que não possa ir mais alto, apenas que não pode ir mais baixo. A razão pela qual ele precisa pairar (no meu caso) é porque, em um corpo rígido e em um mecanismo de física de boneca de pano, as pernas das minhas unidades são animadas proceduralmente. Então, aplicando uma força simples à cápsula, as pernas da minha entidade se reposicionarão por conta própria. Eles também terão suas aplicações de gravidade separadas! O que isso faz é permitir que, se meu personagem estiver inclinado, um pé possa estar em uma altitude mais baixa que o outro.
É exatamente assim que você deve fazê-lo. A julgar pelo que você está perguntando, é isso. Se você deseja deixar de fora alguns recursos, tudo bem, obviamente, especialmente se for um RTS ou FPS e ninguém nunca verá unidades ou se importará. Mas, em geral, a unidade deve ter um objeto de colisão PRINCIPAL que funciona quase exclusivamente com o movimento do personagem.
Especificamente em 2D:
Você ainda deve ter um ponto principal, ou apenas algum tipo de referência, para o mecanismo contornar o movimento de uma unidade. Você poderia atribuir a cada unidade uma subclasse de caminho que possui alguns locais necessários, especificá-lo no código de nível (por exemplo, local1 (x, y) local2 (x, y) etc.) da melhor maneira (eu não provavelmente não sabe em que tipo de jogo você está trabalhando) provavelmente seria especificar locais no nível e fazer com que cada unidade os processe na ordem especificada pelo nível e, após atingir cada local, substitua o local desejado por o próximo que ele precisa chegar.
Existem várias maneiras de modificar isso, como ter uma lista de locais em primeiro lugar para cada unidade, pois isso significa que nem todas as unidades precisam ir para os mesmos locais. No entanto, da mesma forma, você também pode fazer isso no código de nível (unit1.location1 (x, y) unit1.location2 (x, y) grunt.l1 (x, y) knight.loc3 (x, y) tanto faz)
Apenas algumas idéias! Eu sugiro que você leia a versão 3D, mesmo que seja muito menos relevante.
Edição: Eu decidi apenas fornecer ambos para quem pode ler isso (Sim, isso é verdade) .... (Eu originalmente apenas passei a sua pergunta e não percebi que era bastante específica em 2D até que eu a relesse>.>)