Varlık yapılandırmasını neden komut dosyalarının dışına yerleştirmelisiniz?


11

Komut dosyalarındaki varlık bileşenlerini tanımlayan birçok oyun gördüm, ancak her bir varlığı yapılandırdıklarında ve hangi bileşenlere sahip olduklarını belirlediklerinde, başka bir dosya biçimini (XML gibi) kullanırlar. Bunu neden yapıyorlar?

Çoğunlukla başkalarının mantığının bunun için ne olduğunu görmesini istiyorum. Ben de komutları dışında varlıkları yapılandırmak (XML değil JSON seçtim rağmen). Bunu yapmak için nedenlerim, kaydetme oyunları uygulamamı kolaylaştırmak ve ayrıca bu tür bir yapılandırmanın XML veya JSON gibi bir şeyde daha iyi organize edildiğini düşünüyorum.


@ Christopher Larsen'in yanıtı: Yorum yapmak için çok uzun

Korkarım sorunun konusundan biraz sapmış olabilirsiniz. Tanımladığınız sorunlar hiyerarşiye dayalı varlıklarla daha ilgilidir; soruma göre bileşen tabanlı varlıklar hakkında konuştuğumu söyledim.

İşte sormak istediklerime bir örnek. Aşağıda bir varlığı yapılandırmanın iki alternatif yolu vardır: komut dosyası aracılığıyla ve harici bir JSON dosyası aracılığıyla. Sorum şu, neden bu kadar çok insan varlığı komut dosyası dışında yapılandırmayı tercih ediyor?

Temel bir Entity sınıfı:

class Entity:
    def __init__(self, name):
        pass
    def addComponent(self, comp):
        pass

Senaryo yaklaşımı:

orc = Entity('Orc')
orc.addComponent(PositionComponent(3.4, 7.9))

JSON yaklaşımı:

{
    "name" : "Orc",
    "components":
    {
        "PositionComponent": {
            "x" : 3.4,
            "y" : 7.9
        }
    }
}

Teknik ve örgütsel olan bu yaklaşımı kullanma nedenlerimi daha önce belirtmiştim. Neden bu kadar çok başkalarının (gördüklerimden) kullandığını bilmek istedim.

Yanıtlar:


13

Aklıma gelen en büyük avantaj, konfigürasyonun herhangi bir oyun komut dosyasına dokunmalarını gerektirmeden programcı olmayan bir program tarafından düzenlenmesine / yönetilmesine izin vermesidir.


Bu, sadece iki dosyaya (bir .h ve sonra bir .cpp'ye eşittir) sahip olabilir. Kim bir nesne yaratmak isteyecek bir kişi olacağını merak ediyorum (bu yap-hiçbir şeyin bir vazo gibi görünmediğini ve hiçbir şeyin tereyağlı görünmediğini söylemenin yanı sıra), ona da bir mantık eklemek istemeyeceğim (örneğin Vazoda çiçeklerden polen kaplı kişi varsa, kelebek çekin) İnsan tarafından okunabilir harika ve bunun neden olduğu konusundaki düşüncelerimden biri, ancak yine de JSON, Lua tabloları ve XML'in hepsinin programlayıcı olmayan kişiler tarafından benzer düzeyde okunabilirliğe sahip olduğunu taşıyorum.
James

2
Glest, xml ile modifiye edilmiş bir oyundur. Birçok programcı bunun için modlar yapar. Komut dosyasından xml / json'a sahip olmak kesinlikle daha kolay.
Will

6

Bunun için komut dosyası yerine genellikle bir yapılandırma dosyası kullanmamın bir nedeni:

Bir komut dosyasını doğru olup olmadığını kontrol etmenin tek yolu, örneğin tüm değerleri belirtmek ve bu şekilde çalıştırmaktır.

Komut dosyalarının değerleri yapılandırmasına izin vermek için kod yazmak, komut dosyalarının değerleri doldurması için iskelet nesneleri oluşturmak üzere kod yazmak ve ardından komut dosyasının böyle yaptığını doğrulamak anlamına gelir. Genellikle bir tür doğrulama mekanizmasını destekleyen bir kütüphane kullanarak, düz bir yapılandırma dosyasından yüklemekten daha fazla kod ve hata ayıklayıcı kodu.


5
Ana akım yazılım geliştirme daha iyi olduğunda, bu En Az Güç Prensibi olarak biliniyordu : Günümüzde en güçlü değil en az güçlü çözümü seçmenin nedenlerini takdir etmeliyiz. Bunun nedeni, dil ne kadar az güçlü olursa, o dilde depolanan verilerle o kadar çok şey yapabilmenizdir.

1
@Joe Aslında bu yaklaşımı kullanmamın nedenlerinden biri de oldukça iyi anlatılıyor. İlk başta varlıklarımı komut dosyalarında yapılandırmaya çalıştım, ancak kaydetme oyunlarını uygulamayı zor buldum (bileşenler arasındaki ilişkileri takip edemedim). Harici bir yapılandırma dosyası kullanmak bana çok yardımcı oluyor.
Paul Manta

Bunu zaten başka bir yol olarak görüyorum, zaten bir komut dosyası arabirimi kullanıyorsanız, o zaman şimdi sizin için yapmak için zaten tanımlanmış komut dosyası arabirimini kullanmak yerine yapılandırma dosyası için bir veri doğrulama yöntemi sağlamanız gerekir.
James

2

Varlık yapılandırması yalnızca belirli bir varlığın serileştirilmesi olabilir . Bu, oyun düzenleme ve modifikasyon araçlarının çıktısını kabaca bir oyunu kaydettiğiniz gibi işlemenizi sağlar. Özellikle, belirli bir varlığın oyun tasarrufu sırasında hangi durumda olacağını tahmin edemediğiniz oyunlar için - örneğin yapay zekası nedeniyle veya kısmen prosedürel olarak ilk etapta üretildikleri için - tümünü dökmek yararlıdır kaydedilecek bir bayt akışı olarak bir varlığın "ne" olduğunu ("ne" yerine) tanımlayan veriler.


1

Tanımladığınız kalıp, Veriye Dayalı Sistemin bir uygulamasıdır.

Veri güdümlü sistemler, içerik tanımının kaynağın dışında kapsüllenmesine izin verdiği için oyun geliştirmede yaygın olarak kullanılmaktadır. Bu harici gösterim daha sonra bir varlığın davranış biçimini değiştirmek için kolayca değiştirilebilir (ve hatta değişiklik izleyen bir uygulama tarafından gerçek zamanlı olarak güncellenebilir).

Veriler harici olarak tanımlandıktan sonra, tasarımcıların metin metinlerini doğrudan düzenlemeden (ugh!), Tasarımcının seçimlerini mantıksal, tutarlı ve hatta doğruluk için doğrulanmış ( oyun dengesi perspektifi).

Veriler doğrudan koda gömülmüşse, herhangi bir değişiklik, büyük projeler için orta derecede zaman alıcı olan ve aynı zamanda ikili dosyaların dağıtımı için gereken sürenin (örneğin, yeni ikili dosyaların dağıtılması ve sunucu).

"Ork" adlı sterotipik bir varlığa bir örnek verelim ...

Bizim ork için uygulamak için bir yolu ork için tüm özellikleri ve mantık kodunu tam bir açıklama yazmak olacaktır.

  • maxhealth = 10
  • hasar = saniyede 3 hasar
  • Kaçak = true
  • kaçak = sağlık <10
  • agresif = Gerçek

Orkları başlattığımızda, tüm değerleri tamamen aynı şekilde başlatılır (veya belki de statiktir). Ortaya çıkan sorun, bazı tasarımcıların gelip "Yeni başlayan alanlar için daha az sağlığı olan, asla kaçmayan ve agresif olmayan farklı bir ork türüne ihtiyacımız var. Bu yeni oyuncuların "savaş sistemini öğrenirken artan zorluk ve karışıklık".

Harika, şimdi farklı bir sınıfa ihtiyacınız var (ya da belki ileriye bakıyorduk), bir "acemi" alanında oluştururken orklar oluşturan "fabrika" ya beslediğimiz değerleri ayarlıyoruz. Bu yüzden değişiklikleri yapıyoruz, yeni ikili dosyalar dağıtıyoruz. Sadece oyuncuların geri gelip orkları tek bir vuruşta öldürdüğümüz için yeni sağlık değerlerinin çok düşük olduğunu söylemek.

Sistemlerimiz veri odaklıysa (ve değişiklikler yapıldığında yeniden yüklemeyi destekleyen uygulamalar için bonus puanlar), o zaman tasarımcı ve oyun test kullanıcılarını tatmin etmek için gerekli olan değişiklikler, yeniden derleme / dağıtım gerekmeden basit veri değişikliklerdir. Bu, tasarımcıları mutlu ediyor çünkü kod değişikliklerini beklemek zorunda kalmıyorlar ve programcıları mutlu ediyor çünkü kaynak kodunu sürekli olarak değerleri değiştirecek şekilde değiştiriyoruz.

Veri güdümlü sistemleri aşırıya çıkarmak, oyun seviyelerinden, büyülerden ve hatta görevlerden, kod değişikliği gerektirmeyen verilerinizde yapılan basit değişikliklerle her şeyin uygulanmasına izin verir. Sonunda, oyun içeriğini oluşturmayı, değiştirmeyi ve yinelemeyi kolaylaştırmakla ilgilidir.


2
Komut aynı zamanda en tanımları ile verilerdir
Will

1
-1. Soru, veriye dayalı veya kodlama ile ilgili değil, dinamik kodlama ve statik bildirimlerle ilgili.

@ Christopher, OP'ye uzun bir cevap ekledim. Lütfen kontrol et.
Paul Manta

0

Örneğinizde aslında zaten iki komut dosyası dili kullanıyorsunuz. Bu uzun vadede daha iyi çalışır söyleyebilirim ama kullandığınız komut dosyası dilini birleştirmenizi öneririm. Verdiğiniz komut dosyası örneği Lua'da Json yerine yapıldıysa, nesnenizi oluşturmak için Lua'nın tablolarını kullanın diyebilirim. Sözdizimi aslında benzer olacaktır ve bileşenlerinizi ortaya çıkarmak için bir arabirimi desteklemenize izin verir.

İnsanların neden genellikle XML'de yapmayı seçtiklerine ve ardından mantıkta komut dosyalarına dokunmak için, bunu söylediğinizde mantıklıdır. İşte verilerdeki nesne tanımım, iyi bir veri depolama formatı nedir? Neredeyse her zaman XML'dir (JSON ile de gidiyorum;). Ve sonra mantık eklemek istediklerinde, bu kodlanmış ya da bir kod dosyasına konur.

Yanlış düşünmek değil ama gözlerimde insanlar bir sonraki adıma geçmiyorlar. Herhangi bir tam dile bakın, c / c ++ / c #,. Nesneleri ve mantıklarını tek bir dilde tanımlayabilirsiniz, neden komut dosyası arayüzünüzde aynısını yapmıyorsunuz ... Neredeyse düşündüğünüzde XML'deki sınıflarımızı ve yöntemlerimizi tanımlamamız gerektiğini söylemek gibi. Belki daha eski oyun betikleri dilleri yeterince güçlü değildi ve hala yapıldığı gibi duruyor.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.