Bir kule savunma oyununda A * uygulamasında yavaş performans


9

Flash'ta önceden tanımlanmış bir yol olmadan bir Kule Savunma oyunu yapıyorum.

Izgaram 40x40 (küçük?) Olmasına rağmen, her seferinde yeniden hesaplama yaparken A * mücadele ediyor. Bu yüzden, yeniden hesaplamayı kolaylaştırmak için kendi modifikasyonumu yaptım ve dokunulan hücre sayısı 900'e düştü (kökün yakınında değişiklik yaparken). Yeni bir kule yerleştirildiğinde çok kısa, ancak tespit edilebilir bir süre için hala donuyor.

Bu bir uygulama sorunu mu, yoksa 40x40 çok mu fazla?

Düzenle:

Kodumun yapısı:

  • Tüm veriler 2d hücre dizisine kaydedilir.
  • Her hücre üst yolunu yol yönünde (1-8 saat yönünde) ve yolundaki alt öğelerinin bitsel olarak kodlanmış dizisini içerir (her bit bir çocuğu temsil eder).
  • Arama, Öklid mesafesi tahmini ile A * tarafından gerçekleştirilir.

Burada çok daha spesifik olmanız gerekecek. Kodunuzun nasıl göründüğü, nasıl yapılandırıldığı vb. Hakkında hiçbir fikrimiz yok ve bu yüzden onu yavaşlatan şey hakkında herhangi bir sonuç çıkaramıyoruz.
Sean James

1
A * 'yı son kez uyguladığımda, en fazla 1ms'de 64x64 ızgaradan geçtiğini hatırlıyorum . Yani evet, uygulamanızla ilgili bir sorun gibi görünüyor. Size daha fazla yardımcı olabilmemiz için kodunuzu veya özetini göndermenizi öneririm.
Marc Müller

Eklediğim düzenlemeye bakın
Dani

1
40x40 çok yavaşsa, çok yanlış bir şey yapıyorsunuzdur. Kodunuzu gönderin ya da profil oluşturun. Alternatif olarak, ölçeklendirin ve ne olduğunu görün - bir 80x80 ızgara dört kattan daha uzun sürerse, orada son derece kırılmış bir şey var.
ZorbaTHut

Başlık biraz daha bilgilendirici olabilir mi lütfen?
tenpn

Yanıtlar:


4

Yorum yapamam, ancak Flex'teki ilk profil, diğer her şey varsayımdır.


Flash projesini flex'de nasıl profil alabilirim?
Dani

Evet ve hayır. Flash projesini doğrudan yüklediğinizi sanmıyorum. Bence kaynak olmadan swf profil ve yine de fonksiyon seviyesi bilgi almak mümkün olabilir. Ben "esnek bir flash proje profilleme" veya benzeri bir google arama yapardı. Bunu yaptım ve aldım: umut verici görünen flexblog.edchipman.ca/… .
Jonathan Fischoff

Teşekkürler, gerçekten sorunlu kısmı bulmama yardımcı oldu (algoritmada değildi, soruya yorum bakınız)
Dani

13

TD'nin 'Kule Savunma' olduğunu varsayıyorum

Bence A * bunun için biraz abartılıyor.

Oyunun başında, bir hareket haritası oluşturmak için oyun alanını çıkış noktalarından doldurun:

 |---------|
 |5|4|3|3|3|
 |5|4|3|2|2|
->5|4|3|2|1->
 |5|4|3|2|2|
 |5|4|3|3|3|
 |---------|

ve hareket her zaman daha düşük değerli bir kareye doğrudur.

Oyuncu bir kule yerleştirdiğinde, bitişik sekiz karenin her birini güncelleyin: her kare için hareket değerini en düşük bitişik değerden bir taneye ayarlayın. Değer değişirse, güncellenen karede ortalanmış olan işlemi tekrarlayın. Ardından, çıkış yolunun engellenmediğini kontrol etmek için, tüm karelerin daha düşük bir değerin karesine bitişik olduğundan emin olun.

Oynatıcı bir kuleyi çıkardığında, hareket değerini bitişikteki en düşük kareden bir tanesine ayarlayın ve yukarıdaki işlemi tekrarlayın.

Taşkın dolgusunu yeniden yapmak daha basit bir yaklaşım olacaktır.


6
Taşkın dolgusunu yeniden yapmak, en azından algoritmik terimlerle (ve bu Flash olduğu için, bellek düzeni gibi algoritmik olmayan sabitler muhtemelen ' t çok etkili kullanılmalıdır). Bununla birlikte, bu birçok iletişim birimi için çok iyi bir modeldir ve işbirlikçi difüzyon olarak adlandırılır - scalablegamedesign.cs.colorado.edu/wiki/Collaborative_Diffusion .

@Joe Wreschnig: vay güzel bağlantı. Bu tekniği daha önce kullanmıştım ama ne dendiğini hiç bilmiyordum. Teşekkürler.
tenpn

@Joe, haritada en az birkaç engel olduğu sürece bunun A * demekten daha verimsiz olacağını düşünmüyorum. Yani, sadece birkaç üniteli geniş, neredeyse bariyersiz bir harita için daha kötü olabileceğine inanıyorum.
edA-qa mort-ora-y

@edA: Tanımı gereği, bir taşkın dolgu sonunda haritadaki her erişilebilir noktaya dokunmalıdır; A *, kaç noktaya dokunması gerektiğine dair kanıtlanmış üst sınırlar sağlar, bu da haritadaki en erişilebilir her noktadır ve genellikle çok daha azdır. Taşkın dolgusu, Flash'taki bellek düzeni gibi şeyleri optimize etmek için daha basit bir algoritmadır, ancak söylediğim gibi, Flash'ta muhtemelen önemli değil.

@Joe, tartıştığım şey, sadece bir avuç kule ile bile A * 'nın neredeyse tüm alanlara dokunacağıdır. Ancak N canavarlar için, sel dolgusundan daha az verimli olmak için total_squares / N değerini aşması yeterlidir.
edA-qa mort-ora-y

2

Garip, buna cevap verdiğimi sanıyordum, ama cevap gitmiş gibi görünüyor. Arama algoritmanızı birden çok adımda güncellenebilecek şekilde yapın, böylece bir kule yerleştirip bir animasyon oynadığınızda, her kareyi biraz yapabilirsiniz ve güncellemenizi güncellemek için yarım saniye ile saniye A * belirgin bir duraklama olmadan. Gecikme - i hızlandıramıyorsanız, gizlemek için bir yol bulun. Bir kule yerleştirirken bir animasyon oynamak bir oyun için doğal olurdu ve gizlemek için iyi bir yer imo.


Bu genel olarak iyi bir fikirdir, ancak bu özel soru için kötüdür. Böyle küçük bir ızgaradaki A *, neredeyse zaman almalı, önemli miktarda zaman almamalıdır.
davr

Yeterince adil. Yavaşlamaya neden olacak uygulama ayrıntılarını bilmeden sorunu çözebilecek tek cevap bu.
Kaj

0

Başlangıç ​​için dizinizi bir vektöre dönüştürebilirsiniz - size bazı hız iyileştirmeleri yapmalısınız. Kodu gönderin ve daha fazla optimizasyon önerebiliriz.


0

Yavaşlamanızın tüm karakterler için aynı anda bir yol hesapladığınızdan kaynaklandığını tahmin ediyorum. Bir karakter için yol hesaplamak hızlıdır, ancak sahnede iki düzine karakter varsa, bu bataklığa yol açabilir.

Bunun yerine yükü birkaç çerçeveye yaymalısınız. AI güncellemelerinizi farklı karakterlerin yollarını farklı çerçevelerde güncelleyecek şekilde kademelendirin. Bir karakterin bir saniye sonrasına kadar tepki göstermemesi gerçekten göze çarpar, ancak sadece bir kare kötü reaksiyonlara neden olmaz.


Bu neredeyse bir yıl önce cevaplandı ve sadece Grace'in düzenleme çalışmaları nedeniyle çarpıldı. (Çok fazla karakterle ilgisi yoktu.)

Bilmeme izin verdiğin için teşekkürler. Tarihleri ​​fark etmedim.
jhocking
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.