Bir oyun sahnesi grafiğinde neler olmalıdır?

Bir oyun sahnesi grafiğinde tam olarak ne olması gerektiğini açıklığa kavuşturmamda yardımcı olur musunuz? Aşağıdaki listeye bakınız, lütfen:

• Oyun Oyuncuları? (tabii ki evet, durumu değiştiren tüm nesneler Sahne Grafiğinin en büyük dayanağı olmalıdır)
• Basit statik oyun hedefleri? (Yani arka planda canlanmayan yerleri çıkarır, onlar da çarpışmazlar)
• Oyun Tetikleyicileri?
• Oyun Işıkları?
• Oyun Kameraları?
• Silah Mermi?
• Oyun Patlamaları ve Özel Efektler?

Yukarıda ele alınan nesne türleri. Şimdi sahne grafiğinin kapsamına:

• Bir sahne grafiği , seviye başlangıcından beri oyun seviyesi haritasının tamamını içermeli mi yoksa haritanın yalnızca görünür kısmını mı içermelidir ? İkincisi doğruysa, oyuncu hareket ettikçe oyun nesnelerini ekleyerek / kaldırarak sahne grafiğinin sürekli güncelleneceği anlamına gelir. Ancak, haritanın yalnızca görünür olanlarını içermek, geçiş ve güncelleme yapmak için çok daha hızlı olacaktır.

Sanırım diğer sahne grafiği teknolojilerinin ne yaptığını okumak size çok fayda sağlayacak.

Arka plan
Örneğin, Ogre3D açıklamasına bakın. Açık kaynak kodlu bir sahne grafik tabanlı grafik motorudur. Eğiticilere bakmanızı ve sahne düğümlerinin nasıl kullanıldığını görmenizi öneririm (Not: Ogre'nin nasıl kullanılacağını öğrenmenizi söylemiyorum, aksine Ogre'nin sahne düğümlerinde ve sahne yöneticilerinde hangi özellikler mevcut)

SceneNode belgeleri:
http://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_scene_node.html

SceneManager belgeleri: http://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_scene_manager.html

Bakmaya değer başka bir şey şu bağlantıdır:
http://sgl.sourceforge.net/#features

OpenGL tabanlı bir sahne grafiği çözümüdür ve oradaki özellikler sayfası içerebileceği tüm düğümleri gösterir.

Önerilen Düğümler
Bir sahne grafiğinin oyun mantığından olabildiğince soyutlanması gerektiğine inanıyorum, böylece herhangi bir bağımlılık sorununuz yok. Mermi noktalarınızın her biri için şunu söyleyebilirim:

Oyun Oyuncuları
Muhtemelen hayır diyebilirim. Ogre'ye benzer şekilde, nesneyi oluşturmak için uygun bilgileri (Konum, Yön, vb.) Almak için bir temel Entity sınıfı (nesneye özgü mantığı içerecek) ve Entity üye işaretçisiyle bir temel SceneNode olurdu.

DÜZENLEME: Oyun aktörlerinizi buradaki sahne grafiğine dahil etmeyeceğinizi söylemiyorum (aksi takdirde hiçbir şey görünmez: P) Mantıksal oyun aktör sınıfına referansla bir sahne düğümüne sahip olduğumu söylüyorum, hala oyun nesnelerinin render ve güncellenmesi gevşek bir bağlantı var.

Basit statik oyun hedefleri
Evet

Oyun Tetikleyicileri?
Hayır, bu bana oyuna özgü bir mantık gibi geliyor.

Oyun Işıkları?
Evet

Oyun Kameraları?
Evet

Silah Mermi?
Bu konuda tamamen emin değilim, ama muhtemelen evet diyebilirim, ama muhtemelen tüm mermileri çocuk olarak bir "BulletCollection" ebeveyn sahne düğümüne istersiniz, böylece bu pozisyonu önbelleğe alabilir ve sahne grafiği kaldırmak ve render mermi eklemek için çok.

Oyun Patlamaları ve Özel Efektler?
Emin değilim, başkasının buna cevap vermesine izin vereceğim.

Sahne Grafiği Kapsamı
Nispeten küçük bir seviyeniz varsa, tüm seviyeyi bir sahne grafiğinde saklayabilmeniz ve ardından bir Octree (genellikle dış mekan ortamları için) veya BSP ağacı (genellikle iç mekan ortamları için) kullanarak görünürlüğü optimize edebilmeniz gerekir.

Çok daha büyük bir seviyeniz varsa ve herhangi bir seviye yükleme yapmak istemiyorsanız, akış burada devreye girecektir, ancak bu tamamen başka bir konudur. Küçük bir seviye ile başlıyorum ve kademeli olarak performansı olumsuz etkilemeden ne kadar büyük yapabileceğinizi görüyorum.

Sonuç
Bana göre bir sahne grafiği bir oyun döngüsünün Render kısmı içindir. Oluşturma işleminizi ve mantık güncellemelerinizi birbirine çok yakın birleştirmemelisiniz, aksi takdirde can sıkıcı bağımlılık sorunlarıyla karşılaşırsınız.

Eğilim, bir sahne grafiğine daha az şey koymayı önermek . Özellikle Tom Forsyth'ın bu makalesine bakınız: " Sahne Grafikleri - Sadece Hayır Deyin ."

Forsyth'in makalesinin temel noktası, bir grup ilgisiz şeyi büyük bir ana veri yapısına sıkıştırmaya çalışmamanızdır. Bu, oyundaki her şeyi türetmek ve daha sonra hepsini tek bir büyük heterojen listede (yani, kötü) itmekle ilgili olarak bu cevapta dokunduğum fikirlere çok benziyor GameObject.

Dünyadaki nispeten az sayıda nesne gerçekten bir ağaç yapısına uygun olarak güçlü bir ebeveyn-çocuk ilişkisi sergiler. Bir masadaki bir kahve fincanı kanonik örneği genellikle burada kullanılır - elbette, masanın bir 'çocuğu' olarak düşünebilirsiniz ... en azından elenene kadar. O zaman hala masanın çocuğu mu? Bu, 'ağacınızın' bir şekilde oldukça sığ ve bir tür dejenere olabileceği anlamına gelir.

Bu yüzden, birçok şey için birden fazla veri yapısı kullanmanızı öneririm. Örneğin, statik geometri ve ışıklar bir sahne grafiğine girmek için makul bir şey gibi görünüyor. Temsil edilen nesnelerin doğal ebeveyn-çocuk ilişkileri olmasa bile, statik olmaları, asla değişmediklerini bilerek onlara yapısal ebeveyn-çocuk ilişkileri verebileceğiniz anlamına gelir.

Oyun oyuncuları ... Bundan pek emin değilim. Aslında hareket etme eğilimi olan her şey, onları genellikle grafiğin köküne yakın tutmanız veya sürekli olarak yeniden ebeveynlemeniz gerektiği anlamına gelir (bu bir angaryadır ve süper verimli değildir).

Mermiler, tetikleyiciler, özel efektler ve başka yerlerde depolayacağım diğer geçici nesneler. Görsel bir sunum yapan veya görsel temsile sahip hiçbir şey (bir tetikleyici genellikle görünmez bir sınırlama hacmi, mermi genellikle sadece bir ışın dökümüdür) bir render grafiğinde olmalıdır. Oluşturma ve mantık katmanlarını ayırmak için çaba göstermelisiniz .

Değeri ne olursa olsun, akademik olmayan kullanım için oluşturduğum oluşturucuların hiçbirinde ağaç benzeri bir sahne grafiği kullanmadım (açıkçası daha önce ağaç benzeri sahne grafikleri oluşturdum, işte bu sonuca vardım şimdi sizi kabul etmeye çalışıyorum).

Oyunda (a) bu çerçevenin işlenmesi ve (b) oluşturulması gereken oyundaki mantıksal varlıkları gruplamak / itmek için oyun stiline (dört ağaç, oktree, BSP, et cetera) uygun uzamsal bölümleme yöntemleri kullanıyorum. bu çerçeve. Daha sonra (b) listesinden nesne kümesini, açıklamaları oluşturmak için mantıksal nesneleri eşleyen bir sisteme besler ve bu açıklamaları özelliklere dayalı olarak kovalara ayırır (örneğin, saydamlık kullanan her şey "şeyler için kovaya itilir) Sonra her bir kovayı sırayla oluşturuyorum ve her bir kova için her bir tanımlamayı sırayla gerçekleştiriyorum. Sanırım buna "ağaç" diyebilirsiniz, ancak tipik bir durum / geleneksel ağaç yönelimli sahne grafiklerinin yaptığı yayılım yöntemlerini dönüştürür.