Bir Oyun Motorunda Etkinlikle İlgili İletişim: Evet mi Hayır mı?

Game Coding Complete'i okuyorum ve yazar, oyun nesneleri ve modülleri arasında Event Driven iletişimini önermektedir .

Temel olarak, tüm canlı oyun aktörleri, dahili bir olay mesajlaşma sistemi aracılığıyla ana modüller (Fizik, AI, Oyun Mantığı, Oyun Görünümü vb.) İle iletişim kurmalıdır. Bu, etkin bir etkinlik yöneticisi tasarlamak zorunda kalması anlamına gelir. Kötü tasarlanmış bir sistem, özellikle mobil platformları etkileyen CPU döngülerini yiyor.

Bu kanıtlanmış ve önerilen bir yaklaşım mı? Kullanıp kullanmamaya nasıl karar vermeliyim?

Bu bir genişleme benim yorumum önerildiği gibi, tam bir cevaba.

Evet , sade ve basit. İletişimin olması gerekiyor ve “Henüz orada mıyız?” Durumları varken. -tip türü yoklama gerekir, genellikle başka bir şey yapmaları gerekip gerekmediğini kontrol etmek için zaman harcarlar. Bunun yerine, yapmaları söylenen şeylere tepki vermelerini sağlayabilirsiniz. Ayrıca, nesneler / sistemler / modüller arasında iyi tanımlanmış bir iletişim yolu, paralel kurulumları önemli ölçüde artırır.

Yığın Taşması ile ilgili bir olay mesajlaşma sistemine üst düzey bir genel bakış verdim . Okuldan profesyonel oyun başlıklarına ve şimdi de her zaman kullanıma uygun hale getirilmiş oyun dışı ürünler olarak kullandım.

EDIT : Hangi nesnelerin mesajı alması gerektiğini nasıl bildiğiniz konusunda bir yorum sorusunu ele almak için : Nesnelerin kendilerine Requestolaylar hakkında bilgilendirilmeleri gerekir . Sizin EventMessagingSystem(EMS) Register(int iEventId, IEventMessagingSystem * pOjbect, (EMSCallback)fpMethodToUseForACallback)eşleştirmenin yanı sıra Unregister( iEventIdnesne işaretçisi ve geri arama dışında bir öğe için benzersiz bir giriş yaparak ) gerekir. Bu şekilde, bir nesne bir mesaj hakkında bilmek istediğinde Register(), sistemde olabilir. Artık olaylar hakkında bilgi sahibi olması gerekmediğinde,Unregister(). Açıkçası, bu geri arama kayıt nesnelerinin bir havuzunu ve bunları listelerden eklemek / çıkarmak için etkili bir yol istersiniz. (Genelde kendi kendini sıralayan dizileri kullandım; kullanılmayan nesnelerin bir havuz yığını ile gerektiğinde boyutlarını değiştiren diziler arasında kendi tahsisatlarını takip ettiklerini söylemenin süslü bir yolu).

EDIT : Bir güncelleme döngüsü ve bir olay mesajlaşma sistemi ile tamamen çalışan bir oyun için, eski bir okul projemi incelemek isteyebilirsiniz . Yukarıda bağlantılı Yığın Taşması direği de buna karşılık gelir.

Bence oyununuzu yapmaya başlamalı ve rahatladığınız şeyi uygulamalısınız. Bunu yaptığınız gibi kendinizi MVC'yi bir yerlerde kullanarak bulacaksınız, başkalarını değil; bazı yerlerde olaylar olur, diğerlerinde değil; bazı yerleri birleştirir, ancak diğerlerini miras alır; bazı yerlerde temiz tasarım, bazılarında tasarım özgürce.

Ve bu sorun değil, çünkü işiniz bittiğinde aslında bir oyuna sahip olacaksınız ve oyun mesaj gönderme sisteminden çok daha iyi.

Daha iyi bir soru, hangi alternatifler var? Fizik, AI vb. İçin uygun şekilde bölünmüş modüllere sahip böyle karmaşık bir sistemde, bu sistemleri başka nasıl düzenleyebilirsiniz?

Mesaj iletme bu sorunun en iyi çözümü gibi görünüyor. Şu anda alternatifleri düşünemiyorum. Ancak pratikte iletilen birçok mesaj örneği var. Aslında, işletim sistemleri işlevlerinden bazıları için mesaj iletmeyi kullanır. Gönderen Vikipedi :

Mesajlar ayrıca süreçler arası iletişim aracı olarak aynı anlamda kullanılır; diğer yaygın teknik, verinin bunun yerine temel veri öğeleri dizisi olarak gönderildiği akışlar veya borulardır (sanal devrenin üst düzey sürümü).

(İşlemler arası iletişim, işletim sistemi ortamında işlemler arasındaki (yani programların çalışan örneklerini) arasındaki iletişimdir)

Yani bir işletim sistemi için yeterince iyiyse, muhtemelen bir oyun için yeterince iyidir, değil mi? Başka faydaları da var, ancak Wikipedia'dan geçen ve geçen mesajla ilgili makalenin açıklama yapmasına izin vereceğim .

Ayrıca Stack Overflow, "Bir programdan geçen mesaj için veri yapıları?" , okumak isteyebilirsiniz.

Mesajlar genellikle şu durumlarda iyi çalışır:

1. Mesajı gönderen şey alınsa bile aldırmaz.
2. Gönderenin, alıcıdan anında yanıt alması gerekmez.
3. Tek bir göndereni dinleyen birden fazla alıcı olabilir.
4. Mesajlar nadiren veya öngörülemeyen olarak gönderilir. (Başka bir deyişle, her nesnenin her karede bir "güncelleme" mesajı alması gerekiyorsa, mesajlar sizi pek satın almaz.)

İhtiyaçlarınız o liste ile eşleştikçe, uygun iletilerin daha iyi olması gerekir. Çok genel düzeyde, oldukça iyiler. Yoklama ya da diğer küresel çözümlerin aksine hiçbir şey yapmamak için CPU döngülerini boşa harcamamak için iyi bir iş çıkardılar. Onlar her zaman yardımcı olan bir kod temeli parçalarını ayırma konusunda harika.

James ve Ricket'ten bugüne gelen harika cevaplar, sadece dikkat notu eklemek için cevap veriyorum. İleti iletme / olaya dayalı iletişim, geliştiricinin cephaneliğinde kesinlikle önemli bir araçtır, ancak kolayca aşırı kullanılabilir. Bir çekiçiniz olduğunda, her şey bir çiviye benziyor, vb.

Kesinlikle,% 100, başlığınızın etrafındaki verilerin akışını düşünüyor olmalı ve bilgilerin bir alt sistemden diğerine nasıl geçtiğinin tam olarak farkında olmalısınız. Bazı durumlarda mesaj atma en iyisidir; diğerlerinde, bir alt sistemin paylaşılan nesneler listesi üzerinde çalışması, diğer alt sistemlerin de aynı paylaşılan listede çalışmasına izin verilmesi daha uygun olabilir; ve bunun yanında birçok yöntem.

Her zaman, hangi alt sistemlerin hangi verilere erişmesi gerektiğini ve ne zaman erişmeleri gerektiğinin farkında olmalısınız. Bu, paralelleştirme ve optimize etme yeteneğinizi etkilemenin yanı sıra, motorunuzun farklı parçaları çok fazla dolandığında daha sinsi sorunları önlemenize yardımcı olur. Verilerin gereksiz yere kopyalanmasını en aza indirmeyi ve veri düzeninizin önbellek kullanımınızı nasıl etkilediğini düşünmeniz gerekir. Hepsi, her durumda en iyi çözüme yönlendirecektir.

Olduğu gibi, üzerinde çalıştığım her oyunun hemen hemen hiç senkronize olmayan mesajlaşma / olay bildirim sistemi vardı. Karmaşık ve hızla değişen tasarım ihtiyaçları karşısında bile, kısa ve özlü, verimli bir bakım kodu yazmanıza olanak tanır.

Eh, bu yazının oldukça eski olduğunu biliyorum ama dayanamadım.

Geçenlerde bir oyun motoru yaptım. Render ve fizik için 3 boyutlu parti kütüphaneleri kullanıyor, fakat varlıkları ve oyun mantığını tanımlayan ve işleyen temel kısmı yazdım.

Motor kesinlikle geleneksel bir yaklaşım izler. Tüm varlıklar için güncelleme işlevini çağıran ana güncelleme döngüsü vardır. Çarpışmalar, doğrudan varlıklar üzerindeki geri aramalarla rapor edilir. Varlıklar arasındaki iletişim, varlıklar arasında değiştirilen akıllı işaretçiler kullanılarak yapılır.

İlkel bir mesaj sistemi vardır, motor mesajlarına yalnızca küçük bir varlık grubunu işler. Bu mesajların bir oyun etkileşiminin sonunda (örneğin bir varlık yaratma veya yok etme) işlenmesi tercih edilir çünkü güncelleme listesine karışabilirler. Böylece, her oyun döngüsünün sonunda küçük bir mesaj listesi tüketilir.

İlkel mesaj sistemine rağmen, sistemin büyük ölçüde "güncelleme döngüsü tabanlı" olduğunu söyleyebilirim.

İyi. Bu sistemi kullandıktan sonra çok basit, hızlı ve iyi organize olduğunu düşünüyorum. Oyun mantığı görünürdür ve varlıkların içinde bulunur, bir mesaj quewe gibi dinamik değildir. Olayı yönlendirmek istemezdim çünkü bence olay sistemleri oyun mantığına gereksiz bir karmaşıklık kazandırıyor ve oyun kodunun anlaşılmasını ve hata ayıklamasını çok zorlaştırıyor.

Ancak, benim gibi saf bir "güncelleme döngüsü tabanlı" sistemin de bazı sorunları olduğunu düşünüyorum.

Örneğin, bazı anlarda bir varlık "hiçbir şey yapma" da olabilir, oyuncunun yaklaşmasını ya da başka bir şeyi bekliyor olabilir. Bu durumların çoğunda, işletme hiçbir işlem yapmadan işlemci zamanını yakar ve varlığı kapatmak ve belirli bir olay gerçekleştiğinde açmak daha iyidir.

Bu yüzden, bir sonraki oyun motorumda farklı bir yaklaşım benimseyeceğim. İşletmeler güncelleme, çizim, çarpışma algılama vb. Motor işlemleri için kendilerini kaydedeceklerdir. Bu olayların her biri, gerçek varlıklar için ayrılmış varlık arayüzleri listelerine sahip olacaktır.

Evet. Oyun sistemlerinin birbirleriyle iletişim kurması çok etkili bir yoldur. Olaylar, birçok sistemi birleştirmenize yardımcı olur ve hatta birbirlerinin varlığını bilmeden, işleri ayrı ayrı derlemenizi mümkün kılar. Bu, sınıflarınızın daha kolay prototip edilebildiği ve derleme sürelerinin daha hızlı olduğu anlamına gelir. Daha da önemlisi, bağımlılık karışıklığı yerine düz bir kod tasarımı ile bitirdiniz.

Olayların bir diğer büyük yararı, kolayca bir ağ üzerinden veya başka bir metin kanalı üzerinden yayınlanmasıdır. Daha sonra oynatmak için bunları kaydedebilirsiniz. İmkanlar sonsuzdur.

Başka bir avantaj: Aynı olayı dinleyen birkaç alt sisteminiz olabilir. Örneğin, tüm uzak görünümleriniz (oyuncular) taraf oluşturma etkinliğine otomatik olarak katılabilir ve sizin tarafınızdan çok az çalışma yaparak her müşterideki varlıkları yaratır. Olayları kullanmasaydınız, ne kadar iş olacağını düşünün: bir yere Update()arama yapmak veya view->CreateEntityOyun mantığından (görüşle ilgili bilginin ve hangi bilgiye ihtiyaç duymadığı) ait olmak zorundasınız . Olayları olmadan bu sorunu çözmek zor.

Olaylarla, yalnızca olaylara abone olan ve oyununuzda bir şey olduğunda onların işini yapabilen sınırsız çeşitlilikteki sonsuz sayıda nesneyi destekleyen zarif ve ayrık bir çözüm elde edersiniz. Bu yüzden olaylar harika.

Daha fazla detay ve burada bir uygulama .

Gördüğüm kadarıyla, tamamen mesajlaşmaya dayalı bir motora sahip olmak pek yaygın görünmüyor. Tabii ki, ağ oluşturma, GUI ve muhtemelen diğerleri gibi, böyle bir mesajlaşma sistemine kendilerini iyi borç veren alt sistemler var. Genel olarak, düşünebildiğim birkaç sorun var:

• Oyun motorları büyük miktarda veri ile uğraşır.
• Oyunlar hızlı olmalı (20-30 FPS minimum olmalıdır).
• Genellikle bir şeyin yapılıp yapılmadığını veya ne zaman yapılacağını bilmek gerekir.

“Oyun mümkün olduğunca verimli olmalı” ortak oyun geliştiricisi yaklaşımıyla, böyle bir mesajlaşma sistemi bu kadar yaygın değildir.

Ancak, devam edip denemeniz gerektiğine katılıyorum. Böyle bir sistemde kesinlikle pek çok avantaj var ve bilgisayar gücü bugün ucuza temin edilebilir.