Oyun motoru: komut dosyası desteği uygulamak için mimari açıdan iyi bir yol mu?

Basit bir oyun motoru geliştiriyorum (önemliyse C # 'da) ve komut dosyası yazmayı mimarlık açısından uygulamak için yeterince iyi bir yol düşünemiyorum.

Savaşlar için özel, mantıktan bağımsız animasyonlarla basit, sıra tabanlı bir stratejidir. Sistem / düşük düzeyli şeyler için küresel bir mimari katmanı ve en önemlisi, bir olay yöneticisi kullanarak iletişim kuran iki ana modül - mantık ve oyun görüntüleme şeyleri - vardır.

Ve şey şu ki, komut dosyalarının hem oyun mantığıyla (birim parametrelerini değiştirme vb.) İlgili şeyleri hem de oyun görünümüyle ilgili şeyleri etkilemesini istiyorum. belirli kodlu tetikleyici.

(Dürüst olmak gerekirse, ideal olarak komut dosyasının oyun akışını kontrol etmesini ve mantığa / görünüme yalnızca temel mekaniği / grafikleri bırakmasını istiyorum, ancak bunun için yeniyim, bu yüzden şu anda yapabileceğimden emin değilim)

Üç seçeneği düşünüyorum:

• Komut dosyası oluşturmanın mantık içinde yaşatmasına izin verin, ancak oyunun grafik tarafı hakkında bilgi verin. Ama bu mantık / bakış bölümünü çok belirsiz yapardı, değil mi ...

• Komut dosyasını, aynı olay yöneticisini kullanarak diğerleriyle etkinlik alışverişinde bulunacak ayrı bir modül yapın. Ancak bu olay senkronizasyonu konusunda çok dikkatli olmayı gerektirir, sanırım ... ve ayrıca yöneticiye çok sayıda olay türü ekler. (Yine de, kişisel favori)

• Komut dosyasını her şeyden önce bir modül yapın, böylece mantık / görünümün işlevlerini doğrudan etkileyebilir / çağırabilir. Bu, tüm olay değişim şemasını vidalama ve betiğin gerçekten olmaması gerektiğinde bir şeyleri kıracağından korkma doğasında daha geniş bir işlevsellik sağlar.

Yani, bunlardan birine karar veremiyorum ya da komut dosyası modülünü eklemenin daha iyi bir yolunu düşünemiyorum ... Herhangi bir öneri veya faydalı bağlantı var mı?

Teşekkür ederim!

Ps soruyu taşıdığınız için teşekkürler, gamedev için özel bir bölüm olduğunu bilmiyordum

Üçüncü seçeneği istediğinize inanıyorum, ancak potansiyel olarak iki yerde gerçekleşen mantıksal olaylara sahip olmanın kötü bir şey olduğunu düşündüğünüzde haklı olduğunu göreceksiniz. Motorun mantık modülünün, 'Şimdi ne yapacağım?' Şeklinde iki soru soran bir güncelleme işareti olmasını istediğinizi göreceksiniz. ve 'Bunu nasıl yaparım?' daha sonra bu soruları yanıtlamak için komut dosyalarını bağlayabilirsiniz.

Gerekli Mantık bileşenlerine erişmek için veri ve API içeren nesneleri açığa çıkararak bunu birleştirin (yani, AI Yolu bulma komutunu yazabilirsiniz, ancak bu, kullanılması ve yeniden kullanılması muhtemel bir kod parçası olduğu için neden olmasın? modülün içine yerleştirip komut dosyası diline maruz kalan API'ye eklensin mi?). Bu size erişilebilirliğin yanı sıra işlerin net olarak tanımlandığı yerleri de sağlamalıdır.

Yine, bunu her zaman yaptığım ifadeyle uyarıyorum. Bitmiş bir ürün, programlamada iyi bir teoriden her zaman daha değerlidir :)

Bu yardımcı olur umarım!

Birçoğu, bu tür esnekliğin hız pahasına geldiğini düşünerek dinamik dillerin gücünü küçümseme eğilimindedir; Bu doğrudur, ancak genellikle maliyet göz ardı edilebilir.

Şahsen ifadeden yararlanan dinamik dilleri kullanarak mümkün olduğunca gelişme eğilimindeyim ve sonra prototipi nerede ve ne şekilde optimizasyonun .

Sizin durumunuzda bu, komut dosyası dili olarak da kullanabileceğiniz uygun bir dinamik dil kullanarak "daha yüksek" kısmı geliştirerek üçüncü seçeneğe geçmeye çalışmanız gerektiği anlamına gelir.

Dinamizmi doğru derinliğe yerleştirdikten sonra birçok desen kullanılabilir. Özel komut dosyalarınız, olay tabanlı bir sisteme geri çağrı sistemi olarak entegre edilebilir, çekirdek geri çağırdığında, komut dosyasının genel durumunu veya tüm sistemin bir alt kümesinin durumunu değiştirebilmesi için uygun bir ortam sağlayabilir.

Komut dosyası ile etkileşim kurabileceğiniz arabirimi Cephe kalıbını kullanarak kapsülleyebilirsiniz. Cephe yöntemlerinde , komut dosyasının bir işlevselliği nasıl kullanabileceğini ve komut dosyası etkileşimini çekirdek uygulamadan soyutlamanın nasıl , ne zaman , yapıp yapamayacağını tanımlayan mantığı koyabilirsiniz .

Komut dosyası arabiriminiz, ilgili fabrika yöntemlerini sağlamalıdır, böylece komut dosyası doğrudan örnek oluşturmadan öğeler oluşturabilir; bu örnekler gerçek nesneler üzerinde sarmalayıcılar olabilir, böylece daha fazla kontrol erişim mantığı uygulanabilir.

Komut dosyası oluşturma nesnesinin veri sağlayacağı diğer nesnelere erişimi olmalıdır. Bu diğer nesneleri doğrudan komut dosyası nesnesine geçirmemeye dikkat edin. Bunu yapmak kırılgan bir arayüz oluşturur. Bu nesne referanslarını yöneten ve komut dosyası nesnesine veri erişimi sağlayan bir arabulucu sınıfı gibi bir şeye sahip olmak isteyebilirsiniz.

Lua, genel amaçlı bir betik dili için popüler bir seçimdir. Lex ve Yacc kullanarak kendi kodlama dilinizi oluşturabilirsiniz (Game Programming Gems 3'teki makaleye göz atın), ancak ihtiyaçlarınızın çoğunun ne kadar büyük veya küçük olursa olsun Lua ile halledilebileceğini söyleyebilirim.