Cüce Kalesi, performans kaybetmeden bu kadar çok varlığı nasıl takip eder?

Cüce Kalesi'nde, her biri kendi karmaşık AI ve yol bulma rutinleri olan herhangi bir zamanda oyunda yüzlerce Cüceler, hayvanlar, goblinler, vb. Olabilir. Benim sorum şu, nasıl gözle görülür bir yavaşlama üretmiyor? Her cüce kendi dişinde mi çalışıyor?

Bu kadar çok karakterden her biri için bir iş parçacığı olan herhangi bir sistemde çok hızlı bir şekilde kaynak tükenir. İş parçacığı size ekstra işlemci çekirdeği erişimini sağlayabilir, ancak kendiliğinden daha verimli bir şey yapmazlar ve başlarına gelirler.

Basit cevap, oyunda her varlık işleme konusunda verimli olmaktır.

• Her varlığı her kareyi işlemeyin.
• İşlemeyi, sık sık yapılması gereken ve sık sık yapması gerekmeyen şeylere ayırın.
• Diğer sistemlerde işlemeyi engellememeleri için uzun süre çalışan algoritmaları birden fazla kareye dağıtın.
• Verimli algoritmaların ve veri yapılarının kullanıldığından emin olun.
• Tekrar kullanılması muhtemel ise pahalı hesapların sonuçlarını önbelleğe alın.

Cüce Kalesi açık kaynak değildir ve tüm işlerin nasıl yürüdüğünü belirleyebilecek çok fazla varsayım ve tersine mühendislik varken, bunun yerine, bir 3D (3D grafik, 3D dünya) roguelini optimize etmek için bazı temel tekniklere odaklanacağım. aynı tip.

Tüm video oyunlarında olduğu gibi, karmaşıklık yanılsamasını basit kural ve sistemlerden yaratan çok fazla duman ve ayna vardır. Bunlar, yolsuzluk hareketi için basit rasgele sayılar kullanmaktan, yol bulma için üst düzey bir düğüm ağını önceden pişirmeye kadar uzanır.

hareket

Yol bulma hakkında konuşursak, bu genellikle bir DF haritası gibi büyük alanlar için çözülmesi zor bir problem olabilir (768x768x64 IIRC'ye kadar), ancak problem şu şekilde basitleştirilebilir ve hızlandırılabilir:

• Önceden pişirilmiş düğüm ağı: Harita oluşturulduğunda dünya, parçalara bölünebilir ve her bir parça kendi çıkışlarını ve girişlerini haritalandırabilir. Bir duvar inşa edildiğinde olduğu gibi bir yığın güncellendiğinde, yalnızca bu yığının ağının güncellenmesi gerekir.
• Aşamalı Yol Bulma: Hücre için tüm harita üzerinde bir yol çalıştırmak, hücre için çok fazla zaman alacaktır, bunun yerine, büyük parçalar arasındaki ağ yolunu bulursunuz; öbekten ötekine geçiyor. Bu sizin için 2 şey yapar. Bir çok küçük parçaya bölünerek yol bulmayı hızlandırır ve bir yığın güncellendiğinde ünitenin yol boyunca yol boyunca yön değiştirmesini sağlar. Güncelleştirmeyi geçmesi gereken düğümlerden herhangi biri olması durumunda, büyük ağ üzerinde yeniden yol alacaktır.
• Rastgele direksiyon: Bir hedefe giderken, ünitenin sadece amaçsızca yürümesi gerekir. Birçok roguelik, üniteyi rasgele bir yöne hareket ettirir, bu doğal olmayan bir şeydir. Çeşitli direksiyon teknikleri kullanılabilir, basit olanlar düz bir çizgide hareket etmeyi tercih eder ve sadece% 1 şansı olacak olan, arkaya yayılan yönlerde hareket etme şansı daha az ve azdır. Böylece ünite bazen yönü tamamen tersine çevirir, ancak nadiren.

Ben yol bulmanın temellerini örtmeyeceğim. Çoğu roguelikes A * kullanır, ancak kediyi kaplamanın başka yöntemleri de vardır. Mmmm Cat deri ..

Kişisel Görevler

DF birimlerini pop ve canlı hissettiren en önemli şeylerden biri kişisel hedef listesidir. Gerçekte, birçok roguelike oyun bu temel düzeyde var. Temel olarak, her birim bir arzu listesine sahiptir (ve dorf'larınız için, yapmayı isteyeceğiniz görevler olabilir) ve kişiliklerine göre (statüler) onlardan seçecektir.

Bazı görevlerin gereksinimleri vardır. Deri bir etek yapmak için dorf, X öğelerine sahip bir dükkanda olmayı gerektirir. Böylece hepsi kontrol edilir ve görevlerine görev olarak eklenir. Bu kadar basit.

Bir birimin transit olacağı çoğu zaman, hangi birimlerin yapıldığına dair kontroller çok hızlı olabilir, herhangi bir anda sadece birkaç birim bir seçim yapacaktır ve bu nedenle genel olarak yüzlerce süre boyunca yavaşlama olmaz. binlerce birim. Unutmayın, DF'de arılardan başböceklerine kadar ağaçlara kadar her şey birimlerdir.

Bazı ek araştırmalar yaparken, DF'nin, genel olarak korkunç bir yol bulma işi yaptığı açıktır. Haritayı parçalara ayırmıyor, haritayı bağlı olan bölümlere veya alanlara bölüyor, (ki bu kesinlikle hiçbir şeyden daha iyi değil), bu yüzden yukarıdaki değerlendirmem, DF'nin düşündüğümden daha iyi çalıştığını gösteren bir örnek. :) DF'nin milyonlarca nedenden ötürü şaşırtıcı olmayan bir şey olduğu söylenemez.

Bir oyunda önemli olanın oyun olduğunu göstermek için gider. Grafik değil, harika programlama, harika yazma, harika müzik değil, arayüz bile değil; oyunun kendisi kadar önemli bir şey bile% 1 kadar önemli değil.

Gönderen bu sayfada :

Eh, [yol bulma] benim açımdan inanılmaz görünüyor, çünkü hepsini aynı anda yapan bir metrik ton karakter var.

TA: Cüceler kendileri çoğunlukla eski sokak mesafesi sezgisel olarak, A * ile hareket ederler. İşin zor yanı, önceden oraya ulaşabileceklerini bilmiyorlarsa gerçekten A * diye arayamayacakları ya da haritayı su basar ve işlemciyi öldürürler.

Bunun kesinlikle “haritayı su basmasını” nasıl önlediğini bilmiyor muyum , ancak oyunlarda bunu yapmanın genel yolu, Hierarchical Path-Finding A * veya HPA * olarak adlandırılan A * değişikliklerini kullanmaktır . Fikir, ızgarayı daha az sayıda ama daha büyük parçalara bölmek, ardından her bir yığından komşu parçalarına giden en iyi yolu bulmak için A * 'yı kullanmaktır. Bunu, her ünite için A * 'nın çalıştırılacağı daha küçük bir grafik oluşturmak için kullanabilirsiniz.

Bu parçaları, "hiyerarşik" nin geldiği yer olan daha büyük boyutlarda da gruplandırabilirsiniz.

Bu algoritma sadece en uygun yolları bulur, fakat genellikle sorun olan Cüce-Kale gibi oyunlar için. Varsa hala bir yol bulması garanti edilir; ve hiçbir yol olmadığında, sadece küçük grafiği doldurur ve çok fazla zaman kazanır.

Ayrıca, bazı arazilerden geçebilecek, ancak diğerleri dışında (hava birimlerinin geçebileceği, ancak zemin birimlerinin yapamayacağı uçurumlar gibi) birimlerle ilgilenen bir HPA * soyutlaması da vardır . Buna HAA * deniyor ve burada açıklayan çok erişilebilir bir makale var .

Burada çeşitli yol bulma algoritmaları hakkında daha fazla bilgi edinebilirsiniz .

Eğer bir şey varsa, tam tersidir - her şey tek bir iplik üzerinde çalışır ve şimdi bunun engelleyici faktör haline geldiği noktayı vurmaktadır (son kontrol ettiğimde!)

Hızlı olmasının nedeni süslü grafiklerin olmaması. Aldatıcıdır, ancak işleri yavaşlatan en önemli şey şeyleri çizmektir (AAA başlıklı bir karenin üçte ikisini yukarı doğru düşünün). Cüce kalesi oldukça basit olduğundan, o zamanın geri kalanını ilginç şeyler yapmaya adamıştır.

DF'nin nasıl kodlandığını bilmiyorum ama AI'lerin miktarı beni gerçekten etkilemiyor, çünkü insanların AI'nın hassasiyetine ihtiyaç duymadığını sıklıkla denetliyorlar . Çoğu şeyi yalnızca birkaç saniyede bir yapmak oldukça uygun. Ayrıca kesin olmayan hesaplamalar kullanmak da geçerlidir. Kusurluluk, çok fazla performans kazandırır . Her 100 ms'de 100 birim karar verme rutinini çalıştırabilir veya her saniyede 1000 birim çalıştırabilirsin, aynı miktarda CPU zamanı alacaktır, ama iyi ... 10 birime sahipsin.

İşte size bir çok birimi nasıl idare edebileceğinin basit bir örneği:

int curUnit;
Array<Unit> units;
[...]
while([...]) // Game Loop
{
  [...game logic...]
  // process 10 AIs per Frame
  for(int i=0; i++; i<10)
  {
    curUnit++
    if(curUnit == units.length()) curUnit=0;
    if(curUnit < units.length())
      units[curUnit].processAI();
  }

  // Update the position of all units, this should be as optimized as possible
  foreach(Unit& unit in units){ unit.move(); };

  [...graphics...]
}

AI ne kadar fazla olursa o kadar az tepki gösterecek, fakat oyuncu ancak zor durumlarda farkedecektir.