Oyun motoru ve veri odaklı tasarım

Veri odaklı tasarım hakkında bir şeyler duydum ve bir süredir araştırma yapıyorum. Bu yüzden, kavramları anlamak için birkaç makale okudum.

Makalelerden biri Kyle Wilson tarafından yazılan Data Driven Design'dır.. Anlatıldığı gibi, bana uygulama kodunun (yani hafıza, ağ ... gibi kaynakları kontrol etme kodu) ve oyun mantığı kodunun birbirinden ayrılması ve oyun mantığı kodunun harici veri kaynakları tarafından yönlendirilmesi gerektiği anlaşılıyor. Bu noktada, geliştiricinin oyun içi nesneler (karakter bilgileri, silah bilgileri, harita bilgileri ... gibi) hakkında dışsal verileri kabul eden bir çeşit oyun editörü yazacağını hayal edebiliyorum. Senaryo tasarımı, oyun tasarımcısının oyun nesneleri arasında etkileşim kurmasını sağlamak için programcı tarafından yazılmış özel dil / araç tarafından yazılacaktır. Oyun tasarımcısı, oyun için komut dosyası yazmak için mevcut / özel bir komut dosyası dili kullanır veya oyun dünyası oluşturmak için aracı sürükleyip bırakır. Aklıma gelen bir araç yaklaşımı örneği, genellikle Bliizard'ın oyunlarıyla birlikte paketlenen World Editor'dır.

Ancak, bir başka makale Veriye Dayalı Tasarımın, Veriye Dayalı Tasarıma Karşı Davanın Kullanımına Karşıdır . Yazar, oyun tasarımının verilerle yönlendirilmesine izin vermemeyi önerir, çünkü oyun tasarımcısının programlama yükü olduğundan, oyun geliştirmek daha fazla zaman alacaktır. Bunun yerine, oyunu eskiz tasarımından özgürce programlamak için bir oyun programcısı olacak ve oyun programcısı bittikten sonra oyun tasarımcısı tarafından doğrulanacaktır. Buna programcının sürdüğünü söylüyor. Bu yöntem hakkında düşündüklerim eskiden yaptığım şeye benziyor: Oyun mantığı yukarıdaki fikre göre uygulamanın kendisidir, uygulama oyun editörüdür ve gerçek oyun araca dayalı olarak tasarlanmıştır.

Bana göre, ilk yöntem daha mantıklı gözüküyor, çünkü oyun bileşenleri birçok projede tekrar kullanılabiliyor. Veri odaklı tasarıma karşı çıkan ikinci yöntemde oyun kodu yalnızca bu oyuna ait. Bu yüzden, Warcraft'ın orijinal Warcraft ve çeşitli özel haritalar gibi pek çok oyun türünün olduğunu ve en ünlülerden biri olduğunu düşünüyorum: aslında yeni bir tarz tanımlayan DOTA. Bu nedenle, insanların Dünya Editör olarak adlandırdıkları oyun motoru olduğunu duydum. Bu bir oyun motorunun nasıl olması gerektiği doğru mu?

Tüm bunlardan sonra, sadece bu fikirler hakkındaki anlayışımda herhangi bir kusur olduğunu doğrulamak istiyorum (veri odaklı, programcı sürücü, komut dosyası vb.)?

Oyununuzu (veya herhangi bir yazılım ürününü) verileri yönlendirmek neredeyse her zaman bir faydadır. Gerçek olan tek şey, ilgili sistemleri kurmak için biraz daha fazla zaman harcayabileceğinizdir; kariyerinin geri kalanını bir programcı olarak öder (her ne kadar aynı sistemleri tekrar kullanmasanız bile, onları oluşturmak için kullandığınız teknikleri tekrar kullanırsınız).

Bağlı Bu iki makalelerde bağlantı kesme play devreye giriyor zorluk ve olduğunu neyi veri koymak ve tercih edenler o verilere erişim sağlamak için seçerler. Temel olarak, veri odaklı tasarım ve geliştirme yalnızca bilgileri harici depolamaya koymanız, bu bilgileri çalışma zamanında yüklemeniz ve üzerinde işlem yapmanız anlamına gelir. Uygulama kodunuz, nihai sonucun olması gerektiğini düşündüğünüzü doğrudan yapan uygulama kodunu yazmak yerine, harici verilerin kendisine söylediklerini yapar. Bu karmaşık bir fikir değil.

Karmaşık "bileşen odaklı mimariler" inşa etmeniz gerekmez (bugünlerde de olduğu gibi). Bir metin dosyasına tweaking physics (çekim kuvveti, restitüsyon katsayıları) için sabitleri koymak veri yönlendirilir. Scriptler (Lua'da veya başka bir şeyde) veriye yöneliktir. XML'deki seviye verilerinizi tanımlama. Böyle bir şey.

Yazılımın hemen her bileşenini verilerle sürebilir ve hangisini yapmak istediğinizi seçip seçebilirsiniz. Geliştirici süresi pahalıdır; programcı saati özellikle bu yüzden. Davranış ve verileri harici depolamaya koyarak ve oyunun her küçük değişiklik için derlenmesini gerektirmeyerek sizi veya diğer programcıları zamandan kazanabilirsiniz. Paradan tasarruf edersiniz ve işleri daha hızlı halledersiniz.

Ayrıca, "tasarımcılar tasarlama" yapma ve programcılara "tasarım tasarlama" yapmalarını sağlamada büyük bir risk altındasınız, bir programcının bir tasarımcının işi için yineleme döngüsünde varlığını zorlama: O sadece bir kod maymunu, sürekli tasarım için önemsiz küçük değişiklikler yapan. Bu, bir tasarımcının proxy'si değil, ilginç teknik zorluklar üzerinde çalışmak isteyen programcıların büyük çoğunluğu için kitlesel olarak moral bozucu olabilir.

Özel sorularınız için:

Bu bir oyun motorunun nasıl olması gerektiği doğru mu?

Bir "oyun motoru" gerçekten sabit bir tanımı yoktur. Genelde, bir oyun yapmak için kullanılan ve genellikle birtakım ilgili araçlar (ve dolayısıyla oldukça veri odaklı) tarafından desteklenen birleşik teknoloji topluluğu. Ancak, bağlamdan içeriğe oldukça geniş ölçüde değişir.

Tüm bunlardan sonra, sadece bu fikirler hakkındaki anlayışımda herhangi bir kusur olduğunu doğrulamak istiyorum (veri odaklı, programcı sürücü, komut dosyası vb.)?

Doğru yolda daha fazla veya daha az gözüküyorsunuz, ancak belki de veri odaklı tasarım ve geliştirmenin bileşen tabanlı sistemler ile birleştirerek ne kadar karmaşık olduğunu düşünüyorsunuz.

İkinci yazının yazarı olarak birkaç noktayı açıklığa kavuşturmak istiyorum.

1. Josh Petrie'nin önerdiği gibi, kodunuzu yalnızca kodlama yerine veri kullanmak için yapılandırmak her zaman bir kazançtır. Aksini önermedim. Her şeyi tasarımcıya itmenin iyi bir fikir olmadığını belirtiyordum. "Veriye dayalı tasarım" terimi, farklı insanlara farklı şeyler ifade eder, bu yüzden orijinal makaleyi yazarken muhtemelen daha belirgin olmalıydım.
2. Çalıştığım her yerde, motorda düzeltilebilir veri yapıları oluşturuyoruz. Bir değişiklik yapmak için oyunu yeniden derlememiz gerekmez. Çalışma zamanında sayıyı dinamik olarak değiştirebiliriz. Veri yapıları sıklıkla kodda saklanır, ancak bunları kimin değiştirdiğine bağlı olarak, bir "veri dosyasından" kolayca yüklenebilir.
3. Çoğu geliştirme ortamı, C / C ++ için bazı düzenleme ve devam etme biçimlerini veya modüllerin yeniden yüklenmesini destekler.
4. Oyun geliştirme stüdyolarının çoğunda oyun programcıları bulunur. İşleri genellikle tasarımcıyla eğlenceli bir deneyim yaratmak için çalışmaktır. Başlıca kaygıları teknik zorluklar değil, kodlardan eğlence çıkarmaktır. Yıllarca oyun programcısı olarak çalıştım ve bunu sadece teknik zorlukları çözmeye çalışmaktan daha ilginç buluyorum. Sorumluluklarım değişti, ancak uygulamadan sorumlu olduğumda işimi en tatmin edici buldum ve tasarımcılar ile havalı bir şeyler yapmak için çalışıyorum. Tasarımcıların kodlaması veya kod yazması ile ilgili sorun, programcıların genellikle programcı olarak yapabileceğiniz en az eğlenceli şeylerden biri olan hataları çözmek zorunda kalmalarıdır.
5. Bir stüdyo için en iyi olan oyuna bağlıdır. Oyun yapmak için uzun zamanınız varsa ve mod topluluğuna oyun ayaklarınızı vermek ve kapsamda büyük bir şey yaratmak istiyorsanız, o zaman tamamen veriye dayalı bir oyun yapmak mantıklıdır. Birçok oyunun bu amacı yok. İki yıl içinde yeni bir oyun çıkarmaları gerekiyor ve çok iyi bir franchise olmadıkça, muhtemelen önceki çalışmalarından farklı bir oyun.
6. Bir "tasarımcı" ne işe yarıyor stüdyodan stüdyoya değişebilir. Oyun programcılarını diğer stüdyolardan işe alan, onları tasarımcılara çağıran ve oyun davranışlarını kodlayan bir geliştirme stüdyosu duydum. Bu, kodlama / komut dosyası programlama konusunda eğitilmemiş insanlara sahip olma sorununu ortadan kaldırır.
7. Oyun mantığı kodu ve motor kodu arasında her zaman bir ayrım yapılmalıdır. Ayrıca normal olarak nesne yerleştirme için bir çeşit görsel editöre sahip olmak istersiniz. Asla düşman konumlarının kodlandığı bir stüdyoda çalışmadım. Bir editöre yerleştirilirler. Neden bahsettiğime dair bir örnek önereyim. Diyelim ki tasarımcı bir düşman düşünüyor. Tasarımcı bu yeni düşman tipinin davranışını betimlemekten daha mı çok? Veri odaklı tasarım olarak düşündüğüm şey budur (Tim Moss'un bu konuda ne yazdığı konusunda). Benim önerdiğim şekilde, programcı tasarımcıyla birlikte çalışır, belki tweakable parametrelerle birlikte eğlenceli bir düşman olurlar ve daha sonra seviyeye yerleştirilirler.
8. Bir programcının yazdığı yerel kod, çalışma zamanında bir programcının yazdığı bir komut dosyasından daha hızlı çalışır; bu, daha az teknik bilgisi olan bir kişinin yazdığı komut dosyasından daha hızlı çalışır. Bu performans ne tür bir oyun yaptığınıza ve ne yaptığınıza bağlı olarak önemli olabilir veya olmayabilir, ancak bu dikkate alınması gereken bir şeydir.
9. Hangi yöntemi seçerseniz seçin oyun kodunu oyunlar arasında paylaşabilirsiniz. Bu noktada ne elde ettiğinizi tam olarak bilmiyorum. Bazı davranışları tanımlamak için bir komut dosyası dili veya görsel bir araç kullanmasanız bile, oyun kodunuzu mümkün olduğunca tekrar kullanılabilir bileşenlere dönüştürmeniz gerekir. Her zaman bir sonraki oyununuz için geçerli olmayacak şeyler olacak, ama çalıştığım her yer, bir sonraki oyuna başladığımızda, önceki bölümden gelen kod temeli ile başlıyoruz - bir devam filmi olmasa bile. Daha sonra mantıklı olan şeyleri tutarız ve oyuna özgü şeyleri kaldırırız.

Sonunda, doğru ya da yanlış cevap yoktur. Bu, sizin ve çalışanlarınızın nasıl rahat bir şekilde çalışabileceğinize dair bir soru. Bir süre önce bu blogu yazdığımda, tüm çalışmaların tasarımcılara ne kadar ittirilmesi gerektiği hakkında çok fazla konuşma yapıldı ve ne kadar başarılı oyun şirketlerinden farklı bir denge bulduğumu bildiğim hakkında yazmak istedim.

Ayrıca, bir not olarak, blog girişim 5 yaşında. Görünen o ki, çok daha fazla stüdyo, senaryo yazma dillerine doğru ilerliyor ve bugünlerde ne olursa olsun, ama benim için temel hata ayıklamam için hata ayıklamak için olgun araçlar üretiyoruz. Bunu yazdığımda, hiç kullanmadığım Unreal Kismet'in var olduğunu sanmıyorum, fakat betik yazmayı basitleştirmeye çalışıyor gibi görünüyor ve görünüşe göre bir hata ayıklayıcı var. (Ne kadar iyi çalıştığını bilmiyorum)

Küçük ölçekli oyunlar için, kesinlikle bir kodlama dilinde ya da benzer bir işlevde teknolojinizi kullanmak istemediğinizi düşünmüyorum, ancak çok büyük bir ekibiniz ve teknolojiye adamak için çok zamanınız varsa, bunu yapmak mümkündür. Doğru ve zaman yatırım geliştirme ekibinizin çalışmak istediği şekilde bağlı olarak mantıklı olabilir. Şahsen, muhtemelen mümkün olduğunca uzun bir süre C ++ 'a yapışacağım çünkü benim için çöp toplama gibi "özellikler" üzerinde çalışmak zorunda olduğum için en kolay ve en hızlı olanı.

Sen bakmak gerekir BitSquid Tech Engine . DOD kavramları kullanılarak inşa edilmiştir. Niklas Frykholm'un blogu çok ilginç. Bu motorun nasıl tasarlandığı hakkında birçok makale var.

GDC 2011'de Niklas, Data Driven Renderer hakkında bir sunum yaptı .