Kaynak motorda (ve antecessor, goldsrc, deprem) oyun nesneleri dünya ve varlıklar olmak üzere iki tipe ayrılır. Dünya harita geometrisidir ve varlıklar oyuncular, parçacıklar, sesler, skorlar vs.'dir (Kaynak Motoru için).

Her varlığın, o varlığın tüm mantığını yapan bir düşünme işlevi vardır .

Dolayısıyla, işlenmesi gereken her şey düşünme işlevine sahip bir temel sınıftan geliyorsa, oyun motoru her şeyi bir listede saklayabilir ve her karede onu döngüye sokabilir ve bu işlevi çağırabilir.

İlk bakışta, bu fikir makul, ancak oyunun çok fazla varlığı varsa çok fazla kaynak alabilir.

Peki, Kaynak gibi bir motor oyun nesnelerine nasıl bakar (işlem, güncelleme, çizim, vb.)?

Bunu yapmanın başka bir yolu yok - her birkaç karede bir en az bir kez her varlığı döngüye sokup çağırmanız gerekecekthink() .

Varlıkları kendi iş parçacıklarına koyabilirsiniz, ancak daha sonra buna değmeyecek olan tüm durum senkronizasyonu kabusu var.

İlk bakışta, bu fikir makul, ancak oyunun çok fazla varlığı varsa çok fazla kaynak alabilir.

Bu nedenle Kaynak motoru, bir kerede var olabilecek varlık sayısı için kesin bir sınır koyar : 4096 varlık, bunların yalnızca yarısı (2048) ağa bağlanabilir. Bu sınırlardan herhangi birini gözden geçirdiğinizde oyun çökecektir.

Bu nedenle, bir harita oluştururken yaklaşık 800'den fazla varlık kullanmamanızı önerirler.

Bahsettiğiniz bu adımlar büyük olasılıkla ayrı motorlarda yapılır. Sadece basit oyun motorları genellikle bir geçişte var. Sıralamanız

for each object
    do physics
    do game logic
    draw

olur

call physics subsystem
call game logic subsystem
call drawing subsystem

Fizik Motoru pozisyonları ve boyutları dikkate alır.

Oyun Mantık Motor (o ... bazı noktalarını engelleyebilecek) Fizik Motoru ne değiştirdi yorumlama ilgilenir, onlar ne yapmaları gerektiğini hedefleri karakterler var ve hangi davranış , planlandığı komut (bu çalışır düşünüyorum fonksiyonu).

Drawing Engine, hangi nesnelerin görünür olduğunu çizer ve Quake motorlarının burada hile yaptığı için hangi nesnelerin görünür olduğunu bilir (bkz. Çizim bölümü).

Size tavsiyem oyun motorları yerine simülasyonların nasıl yapıldığını incelemektir. Oyun geliştirme ile ilgili büyük bir pop-kültür vardır ve oyun motorları zorunlu dillerde yapılır (gelenek ve hız nedeniyle); bu yüzden iyi ders kitapları (teori yerine) almak bana daha aydınlatıcıydı ve SONRA motorlara bakmak ve saatlerce yaptıklarından ziyade motorlara bakmaktan ziyade motorlara (pratik) bakmak.

Fizik

Tüm varlıkları tekrarlama ve yapmayı düşünme, çizme muhtemelen sorunlara yol açacaktır. Çatışmalar olacak vb. Valve'in Havok olduğuna inanıyorum ve sanırım Havok yeterince doğru fiziğe dikkat ediyor.

düşünmek

Düşünme işlevi, oyundaki bir zaman sonraki düşüncedeki zamana eşit olduğunda çalıştırılır . Quake motorunda bu şekilde çalışır ve Quake motoru Half Life motorlarının temelini oluşturur. Her seferinde çalıştırılmaz.

Dahili olarak, bir varlık listesi üzerinden basit bir yineleme ve düşünme işlevini çağırmak için zamanın geçip geçmediğini kontrol etmelidir. Zaman karmaşıklığı O (N) olacaktır, burada N varlık sayısıdır.

Çok sayıda varlık varsa, fps'yi ne kadar artıracağını ölçmelisiniz. Amdahl yasası nedeniyle potansiyel olarak görünmez bir hız olduğunu unutmayın. Yani, tüm öğeleri sadece yineleme ve bir sayı azaltmak ve kontrol.

Nesneleri nextthink ile sıralayarak hızlandıracağım (objelere işaretçiler listesi oluşturun ve her seferinde sıralayın; varlıklar dizisi değil, çünkü varlıklar bir sonraki düşüncelerini her zaman değiştirebilir, böylece dizide yeniden düzenlemek O (N) yerine O (N) alır 1) listede).

Linux'taki O (1) zamanlayıcısına da bakmalısınız .

Çizmek

Motor, kameranın göründüğü alandan yaklaşık olarak görülebilir olanı çizer. Oyun seviyesi bir ağaca bölünür ve bir alan o ağacın yaprağıdır. Sizi bununla ilgili ayrıntılarla rahatsız etmeyeceğim ... Dolayısıyla, bir varlık görünürse, bir dizi görünür varlık içine konur ve çizilir.

Hangi alanların potansiyel olarak görünür alanlar olduğunu depolarlar. Kısaca "potansiyel görünür görünür küme", PVS denir . PVS'nin görselleştirilmesi var , yeşil kapsül oyuncu ve etrafında PVS'nin içerdiği hale getiriliyor.

Dolayısıyla, işlenmesi gereken her şey düşünme işlevine sahip bir temel sınıftan geliyorsa, oyun motoru her şeyi bir listede saklayabilir ve her karede onu döngüye sokabilir ve bu işlevi çağırabilir.

İlk bakışta, bu fikir makul, ancak oyunun çok fazla varlığı varsa çok fazla kaynak alabilir.

Aslında her şeyi büyük bir listeye koymak genellikle istenenden daha azdır; varlıkları örneğin türlerine göre listeler halinde gruplayacak olursanız, işlemi birden çok iş parçacığı üzerinde daha iyi dağıtabilirsiniz. Örneğin, Foo türündeki tüm varlıkların simülasyon aşaması sırasında hiçbir zaman diğer varlıklarla etkileşime girmediğini biliyorsanız, bunları tamamen boşaltabilirsiniz. Eğer bazı büyük tekil listeler boyunca willy-nilly dağılmışlarsa bunu yapmak çok daha zor olurdu.

Bu noktada her şeyi ortak bir temel sınıftan türetmeniz bile gerekmez; Kaynak, bu bağlamda veri olarak uygulanabilecek şeyler için miras kötüye kullanımı ile oldukça üstündür.

İşi diğer çekirdeklere boşaltmaya başlasanız bile, elbette kare başına işleyebileceğiniz varlık sayısı konusunda her zaman bir üst sınırınız olacaktır. Bunun hiçbir yolu yoktur, sadece uygulamanızda bu sınırın ne olduğu hakkında bir fikriniz olması ve onu hafifletmek için adımlar atmanız gerekir (onlara ihtiyaç duymayan nesneler üzerinde işlem aşamalarının uygun şekilde kaldırılması, nesnelerde aşırı ayrıntıdan kaçınmak, vb. saire).

Dikkate almanız gereken ve önceki cevapların düşünce trenini takip eden şey, performansınızın bu düşünme işlevlerini ne zaman ve nasıl çağırdığınıza da bağlı olacağıdır.

Kaynak motorda yayınladığınız bağlantıya baktığınızda, birinin her biri için düşünme sürelerini ve farklı düşünme bağlamlarını ayarlayabileceğinizi de okuyabilirsiniz, birisinin zaten işaret ettiği açık sınırın yanı sıra, bu daha yüksek performans elde etmenin anahtarı olacaktır performansa aç işlemeyi birden fazla yürütme çerçevesi boyunca dağıtan kademeli güncellemeler oluşturarak veya mevcut bağlama bağlı olarak (yani, oyuncu algısının gerekmediği çok uzaktaki varlıklar) gerekli olmayan işlemeyi keserek daha fazla sayıda varlığa sahip bir oyuncu yakın olan karakterler sadece 2 mil uzakta burnunu alarak bir karakter görmez gibi "ayrıntı düşünmek" aynı seviyede).

Ayrıca, oyun mantığınıza ve durumunuza bağlı olarak daha spesifik optimizasyon seviyeleri vardır.