Oyun Tasarımında Etkinlik Başına Mesajlaşma ve Çerçeve Başına İşlev Çağrıları

Geleneksel oyun tasarımı bunu bildiğimiz gibi, kullanır biçimlilik ve sanal fonksiyonlar güncelleme oyun durumlarını nesneleri için. Başka bir deyişle, aynı sanal işlevler kümesi, oyundaki her nesne üzerinde düzenli (ör: kare başına) aralıklarla çağrılır.

Son zamanlarda, oyun nesnelerinin durumlarını güncellemek için başka bir olay güdümlü mesajlaşma sisteminin olduğunu keşfettim . Burada, nesneler genellikle çerçeve başına güncellenmez. Bunun yerine, oldukça verimli bir olay mesajlaşma sistemi oluşturulur ve oyun nesneleri yalnızca geçerli olay mesajı alındıktan sonra güncellenir.

Olay Odaklı Oyun Mimarisi iyi tanımlanmıştır: Mike McShaffry tarafından Komple Oyun Kodlama .

Aşağıdaki sorularla ilgili yardım isteyebilir miyim:

• Her iki yaklaşımın da avantajları ve dezavantajları nelerdir?
• Biri diğerinden daha iyi nerede?
• Etkinlik odaklı oyun tasarımı evrensel ve tüm alanlarda daha mı iyi? Bu nedenle mombile platformlarında bile kullanılması tavsiye edilir mi?
• Hangisinin daha verimli ve hangisinin geliştirilmesi daha zor?

Açıklığa kavuşturmak gerekirse, sorum polimorfizmi bir oyun tasarımından tamamen kaldırmakla ilgili değil. Ben sadece farkı anlamak ve oyun durumunu güncellemek için sanal işlevlere düzenli (çerçeve başına) çağrılar vs olay güdümlü mesajlaşma kullanarak faydalanmak istiyorum.

Örnek: Bu soru burada biraz tartışmaya neden oldu, bu yüzden size örnek sunmama izin verin: MVC'ye göre, oyun motoru üç ana bölüme ayrılmıştır:

1. Uygulama Katmanı (Donanım ve İşletim Sistemi iletişimi)
2. Oyun Mantığı
3. Oyun Görünümü

Bir yarış oyununda, Oyun Görünümü, ekranı mümkün olan en kısa sürede, en az 30 kare / saniye olarak oluşturmaktan sorumludur. Game View, oyuncunun girdisini de dinler. Şimdi bu olur:

• Oyuncu yakıt pedalına% 80 basar
• GameView "Araba 2 Yakıt Pedalı% 80'e Basıldı" mesajını oluşturur ve Game Logic'e gönderir.
• Game Logic mesajı alır, değerlendirir, yeni arabanın konumunu ve davranışını hesaplar ve GameView için aşağıdaki mesajları oluşturur: "Car 2 Fuel Pedal Draw 80% Press", "Car 2 Sound Acceleration", "Car 2 Coordinates X, Y" .. .
• GameView mesajları alır ve buna göre işler

Ben buluşun annesi olmanın gereğine inanıyorum. İhtiyacı net ve iyi tanımlanmış olmadığı sürece hiçbir şeyi kodlamayı sevmiyorum. Projenize bir olay mesajlaşma sistemi kurarak başlarsanız, yanlış yaptığınızı düşünüyorum. Sadece altyapınızı oluşturup test ettikten ve projenize tüm parçaları iyi tanımlanmış, çalışan modüllere sahip olduktan sonra, bu modülleri birbirine nasıl bağlayacağınıza odaklanmanız gerektiğine inanıyorum. Her bir modülün şeklini ve gereksinimlerini anlamadan önce bir olay mesajlaşma sistemi tasarlamaya çalışmak bozuk.

Her iki yaklaşımın da avantajları ve dezavantajları nelerdir?

Bazı insanların orada kurulmaya ve kullanılmaya hazır iyi mesajlaşma sistemleri olduğunu iddia edeceğini düşünüyorum. Belki de bu doğrudur. Kesinlikle ihtiyaçlarınıza özel olarak uyarlanmış özel yapım bir çözümün performansı, genel amaçlı bir mesaj veriyolundan daha yüksek olacaktır. Büyük soru şu ki - daha önce inşa edilmiş bir şey kullanmaktan ziyade bir mesajlaşma sistemi oluşturmak için ne kadar zaman harcayacaksınız. Açıkçası, tam olarak ihtiyacınız olan özellik kümesine sahip bir tür olay sistemi bulabilirseniz, bu oldukça kolay bir karardır. Bu yüzden bu kararı vermeden önce tam olarak neye ihtiyacım olduğunu anladığımdan eminim.

Biri diğerinden daha iyi nerede?

Burada hafıza ve kaynaklar hakkında konuşabiliriz. Sınırlı kaynaklara sahip herhangi bir donanım için geliştiriyorsanız, bunu önemli ölçüde kesecek bir olay sistemi kullanmak kesinlikle bir sorundur. Gerçekten de, bence sorun ihtiyacınız olana geliyor, daha önce de belirttiğim gibi, tüm parçaların neye benzediğini görene kadar bilmediğiniz bir şey. Tüm parçaların nasıl görüneceğini önceden bildiğiniz bu sistemleri oluşturmak için yeterli deneyime sahipseniz, bu soruyu da önceden cevaplayabilirsiniz. Sanırım bu deneyime sahip değilsiniz, çünkü eğer bu soruyu sormazdınız.

Etkinlik odaklı oyun tasarımı evrensel ve tüm alanlarda daha mı iyi? Bu nedenle mobil platformlarda bile kullanılması tavsiye edilir mi?

Evrensel ve tüm alanlarda daha iyi mi? Böyle güzel bir battaniye ifadesi kolayca reddedilir. Genel gider ekleyen her şeyin iş yükünden payını taşıması gerekir. Tasarımın yükünü garanti edecek olayları kullanmıyorsanız, yanlış tasarımdır.

Hangisinin daha verimli ve hangisinin geliştirilmesi daha zor?

Verimlilik, nasıl uygulandığına bağlıdır. İyi geliştirilmiş geleneksel bir tasarımın haftanın her günü etkinlik tabanlı bir sistem gerçekleştireceğini düşünüyorum. Bunun nedeni, parçalar arasındaki iletişimin mikro yönetilebilmesi ve süper verimli hale getirilebilmesidir. Tabii ki, bu aynı zamanda onu tamamlamak ve daha verimli hale getirmek için gereken deneyim ve zaman açısından tasarlamayı daha da zorlaştırır. Öte yandan, bu deneyimden yoksunsanız veya uygulamayı iyi geliştirecek zamanınız yoksa, ihtiyaçlarınıza uygun etkinlik tabanlı bir tasarım kullanmak daha verimli olacaktır. Olay tabanlı bir yapıya kolayca sığmayan özel olay gereksinimleriniz varsa, olay tabanlı yapının tasarlanmasını çok zorlaştırabilir - özellikle de tasarımı verimli tutmak için.

Sanırım burada elma ve portakalları karşılaştırıyorsunuz. Çok biçimliliğin yerini mesajlaşma almaz. Muhtemelen olayların / mesajlaşmanın gevşek bağlı bileşenleri bağlamasını istersiniz. Örneğin. bir çarpışma olduğunda bir varlıktan mesaj göndermek, oyuncu skorunu güncellemek veya belki bir ses efekti tetiklemek için. Böylece bu sınıflar diğer sınıfları tanımıyor ve sadece mesaj gönderiyor ve / veya işliyor.

Ancak oyununuz bir yerde bir güncelleme döngüsüne sahip olacak ve bu güncelleme döngüsüne sahip olduğunuzdan, her karede güncellenmesi gereken tüm oyun varlıklarını güncellemek için kolayca kullanılabilir. Bu mesajlaşmayı kullanmanızı engellemez ...

Oyun varlıklarını eklediğiniz / kaldıracağınız bir tür yapınız varsa , bunları her kareye bir güncelleme mesajı göndermek yerine güncelleme döngünüze dahil edebilirsiniz . Peki , oyununuzun farklı alt sistemlerini bağlamak için mesajlaşmayı kullanırken neden oyun varlıklarınızda güncellemeyi çağırmıyorsunuz? Olay benzeri sistemler için Sinyal / Yuva kavramını da ( qt örneğine bakın ) seviyorum.

Alt satır: Daha iyi bir yaklaşım yok, onlar da özel değil.

Bu, bummzack'in cevabına bir yorum olarak başladı, ancak uzun sürdü.

Aslında eşzamansız yapmadığınız sürece (yeni bir iş parçacığında olaylar gönderir), nesneleriniz yine de notu eşzamanlı olarak alır. Olay dağıtıcınızın, hücrede bağlantılı bir listeyle temel bir karma tablo kullandığını varsayarsak, sıra, nesnelerin o hücreye eklenme sırası olacaktır.

Ayrıca, herhangi bir nedenden dolayı işlev işaretçileri kullanmaya karar vermedikçe, ileti alan her nesne IEventListener'ı (veya her ne çağırırsanız) uygulamalı olduğundan, sanal işlev çağrılarını kullanmaya devam edersiniz. Olaylar, polimorfizm kullanarak oluşturduğunuz yüksek düzeyli bir soyutlamadır.

Oyundaki farklı sistemleri senkronize etmek veya çeşitli nesnelerin ve sistemlerin tepkilerinin söz konusu olayların açıkça tanımlanamaması veya istediğiniz şekilde senkronize edilmesi için çeşitli oyun içi olaylar için bir çamaşır yıkama yöntemi listesini çağırmak zorunda kaldığınız olayları kullanın. gelecekte söz konusu olaylara daha fazla tepki eklemek.

Onlar harika bir araç, ancak bummzack'in dediği gibi, polimorfizm ve olayların aynı sorunu çözdüğünü varsaymayın.

Birini ya da diğerini seçmenin oldukça yanlış olduğunu söyleyebilirim. Bazı nesnelerin her kareyi çağırması gerekir, bazıları gerekmez. Oluşturmak istediğiniz bir nesneniz varsa, her karede bir render araması yapmanız gerekir . Olaylar bu değişikliği yapamaz. Aynı şey objelerden herhangi zamana dayalı fiziği için de geçerlidir gerekir her çerçeve diyoruz.

Ancak, nesne yönetimi nesnelerime veya kullanıcı girdi nesnelerime veya bunun gibi herhangi bir şeye her kareyi aramıyorum. Çerçevedeki her nesneye toplu sanal çağrılar korkunç bir fikirdir.

Herhangi bir nesne için kullanılan tasarım bu nesneler ihtiyaçlarına göre ve gerektiği değil, bir bütün olarak sistemin bir ideolojiye göre.

İlk cümlemde daha açık olacak şekilde düzenlendi.