Hedef geçilmez olduğunda A * 'nın daha hızlı bitmesini nasıl sağlayabilirim?

A * ("A star") yol bulma algoritmasını kullanan basit bir karo tabanlı 2D oyun yapıyorum. Tamamen doğru çalışıyorum ama aramada performans problemim var. Basitçe söylemek gerekirse, geçilmez bir döşemeye tıkladığımda, algoritma görünüşte geçmez döşemeye giden bir rota bulmak için haritanın tümünden geçer - yanında dursam bile.

Bunu nasıl aşabilirim? Sanırım ekran alanına giden yolu azaltabilirim, ama belki burada bariz bir şeyleri özlüyorum?

Tamamen başarısız yollarla sonuçlanan aramalardan kaçınmaya ilişkin bazı fikirler:

Ada Kimliği

A * aramalarını daha hızlı bir şekilde bitirmenin en ucuz yollarından biri hiç arama yapmamaktır. Alanlar tüm ajanlar tarafından gerçekten geçilmezse, sel her alanı yükte (veya boru hattında) benzersiz bir Ada Kimliği ile doldurun . Yol bulmayı yaparken , yolun orijininin Ada Kimliği’nin Ada kimliği hedef. Eşleşmiyorlarsa, aramanın hiçbir anlamı yoktur - iki nokta birbiriyle bağlantısı olmayan adalardadır. Bu, yalnızca tüm ajanlar için gerçekten geçilemez düğümler varsa yardımcı olur.

Sınırı üst sınır

Aranabilecek maksimum düğüm sayısının üst sınırını sınırlarım. Bu, geçilmez aramaların sonsuza dek yayınlanmamasına yardımcı olur, ancak çok uzun süren bazı fena aramaların kaybedilmesi anlamına gelir. Bu sayının ayarlanması gerekiyor ve gerçekten çözülmiyor ve sorunu , ancak uzun aramalarla ilişkili maliyetleri azaltır.

Eğer bulduğunuz şey çok uzun sürüyorsa, aşağıdaki teknikler kullanışlıdır:

Asenkron ve Limit Yinelemeleri Yap

Arama, her bir karede ayrı bir iş parçacığında ya da bir bitte yayınlansın, böylece oyun aramayı beklemiyor. Karakterin çizilme kafası veya damgalama ayaklarının animasyonunu veya aramanın bitmesini beklerken uygun olanı gösterin. Bunu etkili bir şekilde yapmak için, araştırmanın durumunu ayrı bir nesne olarak tutacağım ve birden fazla devletin var olmasına izin vereceğim. Bir yol istendiğinde, bir serbest durum nesnesini alın ve onu aktif durum nesnelerinin kuyruğuna ekleyin. Yol bulma güncellemenizde, etkin öğeyi sıranın önünden çekin ve A * işlemini tamamlayana kadar ya da B. bazı yineleme sınırlarının çalışmasına kadar çalıştırın. Tamamlandıysa, durum nesnesini serbest durum nesneleri listesine geri yerleştirin. Tamamlanmadıysa, 'aktif aramaların' sonuna koyun ve bir sonrakine geçin.

Doğru Veri Yapıları Seçin

Doğru veri yapılarını kullandığınızdan emin olun. İşte StateObject'imin çalışması. Tüm düğümlerim performans nedenlerinden dolayı sonlu bir sayıya - 1024 ya da 2048 - diyelim. Düğümlerin tahsisini hızlandıran bir düğüm havuzu kullanıyorum ve aynı zamanda u16'lar olan veri yapılarımda işaretçiler yerine indeksler depolamamı sağlıyor (ya da bazı oyunlarda yaptığım 255 maksimum düğümüm varsa u8). Yol bulucum için, işaretçileri Node nesnelerine depolayarak, açık liste için bir öncelik sırası kullanıyorum. İkili öbek olarak uygulanır ve kayan nokta değerlerini tam sayılar olarak sıralarım, çünkü platformum her zaman pozitifdir ve platformumda yavaş kayan nokta karşılaştırılır. Kapalı haritam için ziyaret ettiğim düğümleri takip etmek için bir karma tablo kullanıyorum. Önbellek boyutlarından tasarruf etmek için Düğümleri değil, Düğümleri saklar.

Önbellek Yapabilecekleriniz

Bir düğümü ilk ziyaret edip hedefe olan mesafeyi hesapladığınızda, Durum Nesnesinde depolanan düğümde önbellekleyin. Düğümü tekrar ziyaret ederseniz, tekrar hesaplamak yerine önbelleğe alınmış sonucu kullanın. Benim durumumda, tekrar ziyaret edilen düğümler üzerinde karekök yapmamaya yardımcı olur. Önceden hesaplayabileceğiniz ve önbellekleyebileceğiniz başka değerler de vardır.

Araştırabileceğiniz diğer alanlar: iki taraftan da aramak için iki yönlü yol bulma kullanın. Bunu yapmadım ama başkalarının da belirttiği gibi, bunun yardımcı olabileceğini, ancak bunun uyarıları olmadığını söyledi. Listemde denenecek diğer şey, hiyerarşik yol bulma veya kümelenme yolu bulma. HavokAI belgelerinde ilginç bir açıklama var Burada , burada açıklanan HPA * uygulamalarından farklı olan kümeleme kavramlarını açıklar .

İyi şanslar ve ne bulduğunuzu bize bildirin.

AStar, eksiksiz bir planlama algoritmasıdır, yani düğüme giden bir yol varsa, AStar'ın onu bulması garanti edilir. Sonuç olarak, bu gerekir hedef düğümün erişilemez olduğuna karar vermeden önce başlangıç ​​düğümünden çıkan her yolu kontrol . Çok fazla düğümünüz olduğunda bu çok istenmeyen bir durumdur.

Bunu hafifletmenin yolları:

• Eğer biliyorsanız önsel bir düğüm ulaşılamaz olduğu (örneğin hiçbir komşuları vardır ya da işaretlenmiş UnPassable, geri dönüşü) No Pathhiç Astar uğramadan.

• Sınırlama sonlandırılmadan önce AStar'ın genişleyeceği düğüm sayısını sınırlayın. Açık seti kontrol edin. Çok büyürse, sonlandırın ve geri dönün No Path. Ancak, bu AStar'ın bütünlüğünü sınırlayacaktır; bu yüzden sadece maksimum uzunluktaki yolları planlayabilir.

• Sınırlayın zaman Astar bir yol bulmaya sürer. Süresi bitiyorsa, çıkın ve geri dönün No Path. Bu, önceki strateji gibi bütünlüğü sınırlar, ancak bilgisayarın hızıyla ölçeklenir. Birçok oyun için bunun istenmediğini unutmayın, çünkü daha hızlı veya daha yavaş bilgisayarlara sahip olan oyuncular oyunu farklı deneyimler.

4. Hedef düğümden aynı döngü içinde aynı anda hem de ters sırada ikili A * araması yapın ve çözülemeyen bulunur bulunmaz her iki aramayı da iptal edin

Hedefin çevresinde yalnızca 6 kare erişilebilirse ve orijinli 1002 kare erişilebilir varsa, arama 6 (ikili) yinelemede duracaktır.

Bir arama diğerinin ziyaret ettiği düğümleri bulur bulmaz, arama kapsamını diğerinin ziyaret ettiği düğümlerle sınırlayabilir ve daha hızlı bitirebilirsiniz.

Sorun varsayalım, hedef ulaşılamaz. Ve gezinti ağının dinamik olmadığı. Bunu yapmanın en kolay yolu, çok daha seyrek bir navigasyon grafiğine sahip olmaktır (tam geçişin göreceli olarak hızlı olmasına yetecek kadar seyrek) ve yalnızca ayrıntılı bir grafik varsa, ek mümkün olduğunda kullanın.

Farklı özelliklere sahip çoklu algoritmalar kullanın

A * bazı ince özelliklere sahiptir. Özellikle, varsa, her zaman en kısa yolu bulur. Ne yazık ki, bazı kötü özellikler de buldunuz. Bu durumda, hiçbir çözüm bulunmadığını kabul etmeden önce tüm olası yolları ayrıntılı olarak araştırması gerekir.

A * 'da keşfettiğiniz "kusur", topolojiden habersiz olmasıdır. İki boyutlu bir dünyaya sahip olabilirsin, ama bunu bilmiyor. Bildiği kadarıyla, dünyanızın en köşesinde, dünyanın hemen altında hedefine getiren bir merdiven.

Topolojinin farkında olan ikinci bir algoritma oluşturmayı düşünün. İlk geçiş olarak, dünyayı her 10 veya 100 alanda bir "düğüm" ile doldurup ardından bu düğümler arasındaki bağlantı grafiğini koruyabilirsiniz. Bu algoritma, başlangıç ​​ve bitişe yakın erişilebilir düğümler bularak yolunu bulur, ardından eğer varsa grafik üzerinde aralarında bir yol bulmaya çalışır.

Bunu yapmanın kolay bir yolu, her döşemeyi bir düğüme atamaktır. Her döşemeye yalnızca bir düğüm atamanız gerektiğini göstermek önemlidir (grafikte bağlı olmayan iki düğüme asla erişemezsiniz). Daha sonra grafik kenarları, farklı düğümlere bitişik iki kiremitin herhangi bir yerinde olduğu gibi tanımlanır.

Bu grafiğin bir dezavantajı var: optimum yolu bulamıyor. Bu sadece bulur bir yol . Ancak, size şimdi A * 'nın en uygun yolu bulabileceğini göstermiştir.

Ayrıca, A * işlevini yapmak için gereken hafife almaları geliştirmek için bir sezgisel görüş sağlar, çünkü artık manzaralarınız hakkında daha fazla şey biliyorsunuz. İlerlemek için geri adım atmanız gerektiğine karar vermeden önce çıkmaz bir yeri tam olarak keşfetme olasılığınız daha düşüktür.

Yukarıdaki cevaplara ek olarak bazı fikirler:

6. A * aramasının önbellek sonuçları. Yol verilerini A hücresinden B hücresine kaydedin ve mümkünse yeniden kullanın. Bu statik haritalarda daha uygulanabilir ve dinamik haritalarla daha fazla iş yapmanız gerekecek.

7. Her hücrenin komşularını önbelleğe alın. Bir * uygulamasının her bir düğümü genişletmesi ve komşularını arama yapmak için açık kümeye eklemesi gerekir. Bu komşular önbellek yerine her seferinde hesaplanırsa, aramayı önemli ölçüde yavaşlatabilir. Zaten yapmadıysanız, A * için bir öncelik sırası kullanın.

Haritanız statikse, ayrı bölümlerin her birinin kendi kodları olabilir ve A * 'yı çalıştırmadan önce bunu kontrol edebilirsiniz. Bu harita oluşturulduktan sonra yapılabilir veya haritada kodlanabilir.

Geçilmez karoların bir bayrağı olmalıdır ve bunun gibi bir karoya giderken A * çalıştırmamayı ya da erişilebilir bir karo seçmeyi tercih edebilirsiniz.

Sık sık değişen dinamik haritalarınız varsa, hemen hemen hiç şansınız kalmaz. Kararınızı vermeden önce algoritmanızı durdurmanız ya da bölümleri kontrol etmenin sık sık kapatılmasını sağlamanız gerekir.

A * 'nın daha hızlı bir şekilde bir düğümün geçilmez olduğu sonucuna varmasını nasıl sağlayabilirim?

Profilinizi Node.IsPassable() fonksiyonu, en yavaş bölümden saptamayla, onları hızlandırmak.

Bir düğümün geçirilebilir olup olmadığına karar verirken, en muhtemel durumları en üste koyun, böylece çoğu zaman daha karanlık olasılıkları kontrol etmek için rahatsız etmeden fonksiyon hemen geri döner.

Ancak bu, tek bir düğümü kontrol etmeyi hızlandırmak içindir. Düğümleri sorgulamak için ne kadar zaman harcandığını görmek için profil oluşturabilirsiniz, ancak sizin sorununuz gibi sesler çok fazla düğümün kontrol edilmesidir.

geçilmez bir döşemeye tıkladığımda, algoritma görünüşte geçilmez döşemeye giden bir rota bulmak için haritanın tümünden geçer.

Hedef döşemenin kendisi geçilmez ise, algoritma hiç döşemeyi kontrol etmemelidir. Yol bulma işlemine başlamadan önce, hedef döşemesini sorgulayıp sorgulamaması gerekir, eğer mümkün değilse kontrol edin.

Hedefin kendisinin pasif olduğunu, ancak geçilmez karolarla çevrelenmiş olduğunu, yani yol bulunmadığını kastediyorsanız, A * 'nın tüm haritayı kontrol etmesi normaldir. Başka yolu olmadığını nasıl bilebilirdi?

İkinci durum söz konusuysa, iki yönlü bir arama yaparak hızlandırabilirsiniz - bu şekilde hedeften başlayan arama, yolun olmadığını hızlıca bulabilir ve aramayı durdurabilir. Bu örneğe bakın , hedefi duvarlarla çevreleyin ve çift yönlü ile tek yönlü yönleri karşılaştırın.

Geriye doğru yol bulma işlemini yapın.

Yalnızca haritanızda erişilemez çinilerin büyük sürekli alanları yoksa, bu işe yarar. Ulaşılabilir haritanın tamamını aramak yerine, yol bulma yalnızca ekteki ulaşılamayan alanı arar.

Müzikçaların bağlı olduğu alanlar (telsiz vb. Değil) ve erişilemeyen alanlar genellikle çok iyi bağlanmamışsa, ulaşmak istediğiniz düğümden başlayarak A * 'yı kolayca yapabilirsiniz. Bu şekilde, hedefe giden herhangi bir olası rotayı hala bulabilirsiniz ve A * ulaşılamayan bölgeleri hızlı bir şekilde aramayı durduracaktır.

when I click an impassable tile, the algorithm apparently goes through the entire map to find a route to the impassable tile — even if I'm standing next to it.

Other answers are great, but I have to point at the obvious - You should not run the pathfinding to an impassable tile at all.

Bu algodan erken bir çıkış olmalı:

if not IsPassable(A) or not IsPasable(B) then
    return('NoWayExists');

Grafikte iki düğüm arasındaki en uzun mesafeyi kontrol etmek için:

(tüm kenarların aynı ağırlığa sahip olduğu varsayılarak)

1. BFS'yi herhangi bir köşeden çalıştırın v .
2. Uzaktaki bir köşe seçmek için sonuçları kullanın v, onu arayacağım d.
3. 'Den BFS'yi çalıştırın u.
4. En uzaktaki tepe noktasını bulun u, biz buna ad verelim w.
5. Arasındaki mesafe uve wgrafikte uzun mesafedir.

Kanıt:

                D1                            D2
(v)---------------------------r_1-----------------------------(u)
                               |
                            R  | (note it might be that r1=r2)
                D3             |              D4
(x)---------------------------r_2-----------------------------(y)

• Arasındaki mesafeyi düşünelim yve xbüyüktür!
• Sonra buna göre D2 + R < D3
• Sonra D2 < R + D3
• Sonra arasındaki mesafe vve xdaha büyüktür vve u?
• O zaman uilk aşamada seçilemezdi.

Prof için kredi. Shlomi Rubinstein

Ağırlıklı kenarlar kullanıyorsanız, en uzak tepe noktasını bulmak için BFS yerine Dijkstra'yı çalıştırarak polinom zamanında aynı şeyi başarabilirsiniz.

Lütfen bunun bağlı bir grafik olduğunu farz ediyorum. Ben de yönlendirilmemiş olduğunu farz ediyorum.

A *, basit bir 2d döşeme tabanlı oyun için pek kullanışlı değil çünkü doğru anlarsam, yaratıkların 4 yöne hareket ettiğini varsayarsak, BFS aynı sonuçları elde eder. Yaratıklar 8 yöne hareket edebilse bile, hedefe daha yakın düğümleri tercih eden tembel BFS aynı sonuçları almaya devam edecektir. A *, BFS kullanılarak hesaplanmasından daha pahalı olan bir değişiklik Dijkstra'dır.

BFS = O (| V |) sözde O (| V | + | E |) ama gerçekten yukarıdan aşağıya bir harita söz konusu değil. A * = O (| V | log | V |)

Sadece 32 x 32 karolu bir haritamız varsa, BFS en fazla 1024'e mal olacak ve gerçek bir A * size büyük bir 10.000'e mal olabilir. Bu, 0,5 saniye ile 5 saniye arasındaki farktır, muhtemelen önbelleği hesaba katarsanız daha fazla. Bu yüzden A * 'nın istenen hedefe daha yakın karoları tercih eden tembel bir BFS gibi davrandığından emin olun.

A * navigasyon haritaları için faydalıdır, karar alma sürecinde kenarların maliyeti önemlidir. Basit bir karo tabanlı oyunlarda, kenarların maliyeti muhtemelen önemli bir husus değildir. Varsa olay (farklı döşemelerin maliyeti farklıdır), karakteri yavaşlatan döşemelerin içinden geçen yolları erteleyen ve cezalandıran değiştirilmiş bir BFS sürümünü çalıştırabilirsiniz.

Yani evet BFS> A * çoğu durumda çini geldiğinde.