Oyun içeriğini depolamak için XML / JSON / Metin veya bir veritabanı kullanmak daha iyi olur mu?


29

Bileşen tabanlı bir oyunun nasıl uygulanacağını düşünüyorum, çünkü bu sıcak bir şey gibi görünüyor ve bu kadar esnek bir tasarım fikrini seviyorum. Böyle bir tasarımın özelliklerinden biri oyuna yeni şeyler eklemenin, genellikle XML gibi metin dosyaları aracılığıyla içerik yükleme olarak sunulan verilerle yapılabilmesidir. Bu, herhangi bir metin düzenleyicide insan tarafından okunabilir ve kolayca düzenlenebilir olma avantajına sahiptir. Aşağı yönde, metinle başa çıkmak daha yavaş olabilir ve geniş bir veri dosyaları koleksiyonunu yönetmeniz gerekir. JSON veya config dosyaları gibi benzer metin tabanlı formatların da benzer faydaları olacaktır.

Diğer taraftan, SQLite veya Tokyo Cabinet gibi küçük, taşınabilir veritabanları vardır. Doğrudan okunabilir olmasa da, bu dosyaların kolayca arayüzlenebildiğini ve oyun içerik tasarımı için yine de bir çeşit düzenleme aracının tercih edileceğini düşünmüştüm. Bir DB kullanmak, yapılandırma bilgilerinin tutarlı bir şekilde depolanmasını ve kolayca alınmasını sağlar. Ayrıca oyunları kaydetmek için verileri bir DB'ye serileştirebilirsiniz.

Performans açısından, genel olarak XML'in küçük dosyalar için daha hızlı olduğunu ancak bir veritabanının büyük miktarda veriye daha iyi ölçeklendiğini düşünüyorum. Gerçek bir oyunun bir sürü oyun nesnesine sahip olacağını hayal ediyorum.

Öyleyse soru: Tercih edilen yaklaşım hangisidir? DB'ye yaslanıyorum, ancak metin dosyalarına gizli tuzaklar ya da gerçekten güçlü avantajlar olup olmadığını bilmek istiyorum. Veya bunların dışında başka alternatifler varsa (sanırım ikili formatta serileştirmek?)

Yanıtlar:


18

Küçük bir kişisel oyun için çok fazla gelmeyebilir, ancak oyun verisine gelince zor olan bir problem çok kullanıcılı düzenleme / versiyonlamadır. Bir derleme işlemi ile az sayıda ikili blob'a dönüştürülen çok sayıda küçük metin dosyası kullanıyoruz. Bu, iş akışında çok fazla esnekliğe sahip oldukları için tasarımcılar için hayatı kolaylaştırır. ÇKP, bir sayaç örneği olarak, tüm tasarımcıların bağlandığı merkezi bir düzenleme veritabanı kullanır. Bu, derleme adımını gereksiz kılar (ya da en azından çok daha basit) ama bu, tüm versiyonlama ve iş akışı özelliklerini kendiniz uygulamanız gerektiği anlamına gelir, bu yüzden orada bulunan diğer araçlardan daha basit olmaları gerekir. Her iki durumda da performansla başa çıkabilirsiniz, bu nedenle asıl soru, tasarımcı iş akışı için ne istediğinizi ve oraya nasıl gidebilirsiniz?


Bu mükemmel bir nokta. Çok kişiliğin iş akışını ve sürüm kontrolünü çok yakından düşünmemiştim. Bunlar, en azından kaynak bir belge olarak, metin dosyaları lehine çok iyi argümanlardır. Daha kolay takım desteği de. Bu bakış açısı için teşekkürler!
CodexArcanum

Bir veritabanını XML'e dışa aktarmak da oldukça kolaydır. Sadece küçük bir miktar ileri planlama ile bileşen yükleyicinizi bir arayüz olarak yazabilirsiniz - sonra sadece veritabanı okuyucuyu veya xml dosya okuyucusunu takın. Bileşenleri oluştururken, birden çok dosyayı düzenlemekle ilgili tüm veri işlemlerinde hazır GUI'ler bulunduğundan, veritabanı daha kolay olabilir. Daha sonra, son derleme işleminde, veritabanını xml'ye kaydedin, ikili dosyaya kaydedin, vb ... ve oyunun üretim sürümü sadece uygun yükleyiciyi kullanır.
Gecikme

1
Bu nasıl yardımcı olur? Özel bir düzenleyici kullanmak ve daha sonra metin dosyalarına çıkarmak aslında her seçeneğin en kötü kısımlarını verir :-P
kod düzenleyici

7

JSON çok hafif ve anlaşılması kolaydır. Bence bir oyun için daha uygun. cJSON gerçekten çok hoş. aynı zamanda kaynağınıza SQLlite ile aynı şekilde dahil olacaktır.

XML dosyaları, kullanıcıların düzenlemelerini düşündüğünüzden daha zordur. o rotaya giderseniz, halkın ortak tuzaklardan kaçınmasına yardımcı olmak için kullanmaları için bir editör yapmak isteyebilirsiniz.


XML ile mutlu olduğum için JSON’a hiç bu kadar bakmamıştım (XML ne kadar kolay olabilirdi). ağır veri
Spooks

7

Buradaki partiye geç kaldım, ama araştırmaya çok zaman harcadım.

İlk önce aşağıdakileri kullanmıyorum:

XML: Aşırı ayrıntılı. Artıklık ton. Alan isimleri tekrarlanıyor mu? BRÜT

JSON: JSON bir UI düzeni için harika ama veritabanı için cehennem hayır. XML, artıklık ve derin yuvalama gibi aynı sorunlara sahip olacaktır. BRÜT.

SQL : Eğer kurma konusunda baş ağrılarınız varsa, bu harika bir seçenek. Oyun verilerini çevrimiçi olarak bir SQL veritabanında sakladığımız mobil oyunlar yaptım. Tablo formatı güzel. Sorun şu ki, veritabanını çevrimiçi alandan almak zorunda kaldık ve kurulumun bir güçlük olabileceğini belirledik. Ancak SQL iyi bir çözümdür. Birlik bunu yerel olarak desteklemiyor ve denediğim eklentilerde büyük sorunlar var (özellikle sürüm kontrolü ile çalışmak için çalışırken).

Sonunda, kullanmayı seçtiğim çözüm (ve onu seviyorum).

CSV : Basit. Tablo formatını kullanmama izin verin ve güncellemem gerektiğinde kolay bir referans noktam var. Tüm silahlarım için bir masa, tüm nitelikler için sütunlar ve her silah için sıralar alabilirim.

Microsoft Excel'i kullanabilirsiniz, ancak kaydetmeniz gereken her zaman bu aptalca uyarıları dağıtır. Bunu geçersiz kılmak için makroları kullanabilirsiniz, ancak sorununuzu kendiniz kurtarın ve LibreOffice'i edinin derim . Ücretsizdir, CSV düzenlemeyi destekler ve dosyayı açtığınızda, adı eşleştirmek için sütun genişliğini yükler (Excel bunu yapmaz ve beni delirtti).

O zaman CSV dosyalarını oyununuza ayrıştırmanız yeterlidir. Unity kullandım, böylece tek yapmam gereken bulduğum bu şık C # CSV ayrıştırıcısını kullanmaktı:

CSV ayrıştırıcı örneği

CSV dosyalarını oyun veri nesnelerinize dönüştürürsünüz ve gitmeye hazırsınız. Unity ile bunları ScriptableObjects'e dönüştürebilirsiniz . Böylece iş akışım: CSV'yi Güncelle -> CSV'yi Kodlanabilir Nesnelere Ayrıştırma -> Oyunum için ScriptableObjects'ten veri kullan


6

Bunun cevabı, oyun için hangi dili kullandığınıza bağlıdır.

C ++ kullanıyorsanız, mevcut XML kütüphanelerinden birini ( TinyXml veya eXpat gibi ) kullanmanız önerilir .

Diğer taraftan, eğer PHP kullanıyorsanız, MySQL veya SQLite gibi bir veritabanı sunucusunu kolayca kullanabilirsiniz. (Bu rotaya giderseniz daha fazla kaynağa ihtiyacınız olacağını unutmayın; çünkü veritabanı sunucusu ayrı bir işlem olarak çalışacaktır ve MySQL gibi daha büyük veritabanı uygulamaları çalışırken çok fazla RAM tüketebilir.)

JSON, çok fazla ivme kazanıyor ve başvurunuz birden fazla dil kullanılarak yazılmışsa, kesinlikle en iyi seçimdir.

Kısacası, sizin dilinizde neyin kolay kullanılacağına bağlıdır.


1
Herhangi bir DB'yi C ++ ile kullanmakta problem nedir?
Budda

2

Eğer şeylerin XML alanında kalmak istiyorsanız, yük performansını artırmak için İkili XML kullanabilirsiniz .

Örneğin Fast Infoset , ikili xml'nin bir uygulamasıdır.

Biri Hızlı Infoset'i XML için gzip olarak düşünebilir, ancak FI hem belge boyutunu hem de işleme performansını optimize ederken, gzip yalnızca boyutunu optimize eder. Orijinal biçimlendirme kaybedilirken, XML'den FI'ye ve geri XML'e dönüşümde hiçbir bilgi kaybedilmez.


Muhtemelen kullanacağım bir şey olmasa da (XML üzerinden JSON'a yaslanıyorum) bağlantıları takdir ediyorum.
CodexArcanum

1

Yıllardır veritabanları tasarladım ve birçok oyun fikri ile oynadım. Şu an kişisel favorim, bazı metin tabanlı, konfigürasyonlar için okunabilir bir format, fakat bu "yavaş scriptleri" daha çalıştırılabilir bir şeyde ayrıştırıyor. JAVA ve .NET gibi çalışma zamanı bytecode derlendi.

Aynı fikir burada da geçerli. Bileşenlerin "kaynak" bir sürümüne sahibim ve daha sonra derleyici / ayrıştırıcı bunlardan geçiyor. Çok fazla bellek kaparlarsa, bunları hızlı bir SQL veri bankasına yerleştirebilir veya ikili dosya olarak kaydedebilirsiniz. Fakat benim açımdan, belleği veya SQL-veritabanını çalışma alanınız / önbelleğiniz olarak kullanın, böylece komut dosyalarını tekrar tekrar ayrıştırmanıza gerek kalmaz. Derleyiciyi yapabilir, ayrıştırılan dosyaları bir "source-lib" e taşıyabilir ve bu şekilde ön derleyicinin de sürümlendirmeyi yapmasını sağlayabilirsiniz (önceki dosyaları geri alma amacıyla tutar).

Onun hakkında "sınırsız sabit disk alanı" varsa, Dropbox veya Amazon S3 gibi bir şeye kaydolun ve onlarla eşitleyin.

Yani benim için plan şu anda:

  1. Config / scripts / xml (bazı insan tarafından okunabilen formatlar) textfiles (tıpkı kaynak kodu gibi)
  2. Yeni komut dosyalarında çalışan ve kurallara uyup uymadıklarını kontrol eden ayrıştırıcı / doğrulayıcı
  3. İkili ya da SQL satırını orijinal dosyalardan ayıran, derleyicilerin hızlı çalışması ve hızlı çalışması için.

İstikrar konusunda, şu anda veritabanını "ortak yer barındırılacak" ve birden çok konum arasında otomatik olarak bağlanacak şekilde yapıyorum, böylece bir ağ / donanım arızası varsa bir konum varsa diğer sitelerin aynı trafiği kaldırabilmesi gerekir. gamestates.


Özellikle cevabınız yazıldığı günden bu yana ne kadar bulut barındırma sağladığı göz önüne alındığında, ilginç bir çözüm.
rideoutcolin

1

Couchdb kullanıyorsanız , aslında her şeyi bir JSON yapısı olarak kaydedeceksiniz. Couchdb, (çoklu) kullanıcı verilerinizi az ya da çok ağrısız şekilde çoğaltmaya özen gösterir.


0

PHP, MySQL ve C # / JavaScript ile Unity Wiki'de bir prosedür bulabilirsiniz ve amacı için iyi çalışır.

Üç adımdan oluşur

  1. Boş bir MySQL Veri Tabanı ve bir tablo oluşturun.
  2. Bir PHP sunucu tarafı betiği oluşturun (Bu, MySQL tablosuna bağlanır, Unity betiğinden veri alır (3. adım) ve veritabanını sorgular (verilen örnekler veri ekliyor veya seçiliyor)
  3. Unity Denetleyici Komut Dosyası Oluştur (Bu, 2. adımda oluşturulan PHP komut dosyasına bağlanır)
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.