Pathfinding: Mesh Navigasi Berbasis Ubin

Saya sedang mengembangkan RTS berbasis ubin waktu nyata. Ini adalah contoh peta:

Peta

Peta ini terdiri dari 4 wilayah dengan 256 ubin masing-masing. Ubin biru mewakili hambatan. Unit dapat bergerak dalam delapan arah standar. Unit terikat pada ubin; satu ubin dapat menampung satu unit.

Ini adalah beberapa contoh jalur ideal yang saya cari. Barang-barang A * yang khas:

masukkan deskripsi gambar di sini

Pertanyaan saya adalah: Apakah mesh navigasi berlaku untuk RTS berbasis ubin? Saya hanya melihat peta navigasi yang digunakan dalam game di mana unit bergerak bebas dan tidak terikat ke kotak ubin. Seperti apa jala navigasi pada peta ini? Contoh gambar akan sangat baik.

path-finding rts navmesh

— mario_sunny
sumber

Untuk apa nilainya, saya ingat pernah mendengar bahwa beberapa "keanehan" Starcraft I karena keputusan akhir untuk beralih dari 2d ke isometrik 3d - semua kode lintasan ditulis mengharapkan medan 2d!

— Raven Dreamer

Ya, jerat navigasi masih berlaku untuk game berbasis ubin. Meskipun, mereka terutama akan digunakan sebagai optimasi. Misalnya, saya telah mengonversi kiri bawah gambar Anda untuk menggunakan navigasi mesh:

masukkan deskripsi gambar di sini

Dalam hal ini, setiap kotak hijau akan menjadi simpul navigasi. Seperti yang Anda lihat, ini secara drastis mengurangi jumlah node yang perlu diproses oleh A *. Unit kemudian dapat dengan mudah path ke pusat masing-masing node ini.

Generasi node ini adalah masalah yang berbeda. Ini bisa rumit menentukan bagaimana membentuk node. Ada beberapa pertanyaan di situs tempat Anda mungkin menemukan beberapa ide tentang bagaimana Anda ingin menerapkannya:

Membagi lagi poligon menjadi kotak-kotak dengan ukuran yang bervariasi

Mengidentifikasi pola quad dalam array dua dimensi

/programming/20220215/minimum-number-of-rectangles-in-shape-made-from-rectangles

Jala navigasi ini pada dasarnya juga dapat digunakan sebagai pencarian jalur "pass pertama". Jika jalur ditemukan melalui jala navigasi, Anda tahu bahwa ada jalur. Ini adalah tes yang lebih cepat untuk melihat apakah dua titik terhubung.

— MichaelHouse
sumber

Saya mengalami kesulitan memahami bagaimana ini lebih unggul dari A * murni. Bagaimana navmesh Anda akan mengoptimalkan perhitungan pathfinding untuk jalur hijau di jawaban asli, misalnya?

— mario_sunny

Jalur hijau memiliki 15 node, jalur mesh memiliki 5. Ini bahkan tidak termasuk jumlah jalan buntu yang perlu dianalisis ketika menemukan jalur itu. Titik jala navigasi tidak harus membuat rute yang paling langsung, itu untuk mengurangi jumlah node yang harus ditelusuri oleh A *, sehingga secara dramatis meningkatkan kecepatan A *. Ada strategi untuk menempatkan node di jala navigasi Anda yang dapat menemukan keseimbangan antara jalur langsung dan lebih sedikit node (misalnya, node di setiap sudut semua hambatan). Ada juga optimasi yang dapat dilakukan di jalur yang sudah selesai.

— MichaelHouse

Saya mulai mengerti. Akankah jalur hijau terlihat berbeda dengan optimasi navmesh? Anda tampaknya menyiratkan bahwa unit akan bergerak ke pusat setiap persegi panjang dalam perjalanan ke titik akhir. Apakah Anda menyarankan optimasi pasca-A * akan mempersingkat jalur?

— mario_sunny

Ya, jika Anda menggunakan pusat dari setiap node, path akan terlihat berbeda. Namun, Anda dapat memutuskan untuk menggunakan sesuatu selain pusat (seperti Anda dapat menggunakan sudut setiap node). Atau Anda dapat membuatnya sehingga node Anda tidak lebih besar dari empat kotak (membuat lebih sedikit node tetapi membuat node mengikuti geometri lebih dekat). Atau Anda dapat melakukan beberapa optimasi di jalan agar lebih langsung setelah Anda menemukannya. Anda bahkan dapat menggunakan nav-mesh sebagai pass pertama, kemudian menggunakan A * untuk menelusuri setiap node (memungkinkan Anda untuk "path saat Anda pergi", ketika unit bergerak, menyebarkan dampak kinerja dari waktu ke waktu).

— MichaelHouse