Verilerin nasıl depolanacağını nasıl seçersiniz?

Bir adama balık verin, onu bir günlüğüne besleyin. Balık tutmayı bir erkeğe öğret ve onu ömür boyu besle. - Çin Atasözü

Gerçek projem için ne tür bir veri deposu kullanmam gerektiğini sorabilirim, ancak balık tutmayı öğrenmek istiyorum , bu yüzden her yeni projeye başladığımda balık istemem gerekmiyor .

Bu yüzden oyun dışı projeme veri depolamak için iki yöntem kullanana kadar: XML dosyaları ve ilişkisel veritabanları. NoSQL türünden başka bir veritabanı olduğunu da biliyorum . Ancak, eğer benim için daha fazla seçenek olup olmadığını veya ilk tercihte nasıl bir seçim yapılacağını bir kenara nasıl seçeceğimi bilemem.

Öyleyse soru şudur: Bir oyun projesi için veri depolama türünü nasıl seçmeliyim?

Ve seçim yaparken aşağıdaki kritere ilgi duyacağım:

• Projenin büyüklüğü.
• Oyunun hedeflediği platformun yanı sıra kullanılan geliştirme platformu.
• Veri yapısının karmaşıklığı.
• Birçok proje arasında veri taşınabilirliği eklendi .
• Eklenen2 Farklı proje arasında verilerin anlık kullanımı. (yani Kullanıcı verileri)
• Eklenen verilere ne sıklıkta erişilmelidir?
• Aynı uygulama için birden fazla veri türü eklendi
• Birden çok veri depolama ile2 yapılandırma.
• Ne kullanılacağına karar verirken düşündüğünüz diğer herhangi bir nokta ilgi çekicidir.

EDIT hakkında bildiğim bir oyun içeriğini depolamak için XML / JSON / Metin veya bir veritabanı kullanmak daha iyi olur mu? , ama tam olarak benim açımdan konuşmadığını düşündüm. Şimdi yanılıyorsam, memnuniyetle hatayı kendi yöntemimle gösteririm.

EDIT2 İlgilenebileceğim birkaç nokta daha ekledi . Dahası, başka hangi seçeneklerin uygun olduğunu, düz dosya depolama ve ilişkisel veritabanı dışında bir şeyler duymak isterim. Örneğin ilişkisel olmayan veritabanına ne dersiniz? Böyle bir veritabanını daha önce bahsedilen diğer seçeneklerin üzerinde kullanmak uygun olduğunda?

Sorunuz çok fazla sayıda türden dolayı gerçekten geniş, ancak işte profesyonel bir yazılım geliştiricisinin bakış açısı.

Hangi veri kalıcılık mekanizmasını kullandığınızı belirlemek için kullanmak istediğiniz ölçütlerin bir listesini verdiniz. Bunlar:

• Projenin büyüklüğü.
• Oyunun hedef aldığı platform.
• Veri yapısının karmaşıklığı.
• Birçok proje arasında verilerin taşınabilirliği.
• Verilere ne sıklıkta erişilmelidir?
• Aynı uygulama için çoklu veri türü
• Ne kullanılacağına karar verirken düşündüğünüz diğer herhangi bir nokta ilgi çekicidir.

İlk önce, hangi seçeneklerin bizim için uygun olduğunu belirlememiz gerekir. Bir dil veya teknoloji belirtmediğiniz için tam olarak söylemesi zor, ancak muhtemelen XML ile ilişkisel veritabanı depolaması arasında karar vermeye çalışıyorsunuz .

Yapılması gereken önemli bir ayrım, XML'in bir serileştirme tekniği kadar bir depolama mekanizması olmadığıdır . Oyununuz için hafıza içi yapıları temsil etmenin bir yolu. Olduğu göz önüne alındığında, gerçekten bahsediyoruz düz dosyası vs ilişkisel veritabanı depolama. Bunlar tek seçenek değil, ama en yaygın olanları, bu yüzden onları kullanacağım.

Düz dosyalar için:

• XML
• JSON
• YAML
• XAML
• Düz Metin

Veritabanları için:

• SQL Server
• MySQL
• DB2
• torpil
• Daha fazlası

EDIT: Dosyalardan ve ilişkisel veritabanlarından başka mekanizma türlerini sordunuz. Düzenli olarak gördüğüm diğer önemli veritabanı türü, temelde anahtar-değere dayalı "Berkeley-style" veritabanlarıdır. Bunlar verileri yapılandırmak için B-ağaçlarını kullanma eğilimindedir, bu yüzden aramalar hızlıdır. Bunlar, tam olarak ne istediğinizi bildiğiniz yapılandırma / ayar aramaları için harika (örneğin, bana "Seviye 1" için tüm telemetri verilerini verin).

Artık tüm temel özellikleri çözdükten sonra, bazı kriterlerinize değinelim.

Projenin büyüklüğü.

Bazıları aynı fikirde olmayabilir, ancak projenizin boyutunun veri kalıcılık mekanizmanız üzerinde büyük bir etkisi olmayacaktır. İstediğiniz hangi mekanizmadan veri depolayan / yükleyen, yeniden kullanılabilir bir işlev kütüphanesi oluşturmak isteyeceksiniz. İhtiyaç duyduğunuzda kalıcılık mekanizmanızı kolayca değiştirebilmeniz için bir soyutlama katmanı ( Adaptör modeline bakın ) uygulamanızı bile öneririm .

Küçük projeler için, dosya sisteminde XML kullanmak potansiyel olarak işe yarayabilir, ancak oyuncuların istediği zaman verileri değiştirememeleri için bazı güvenlik kaygılarınızı (yani şifreleme) ele almak isteyeceksiniz.

Oyunun hedef aldığı platform.

Platform da büyük bir sorun olmayacak. Geliştirme platformunuz için hedef platformdan daha fazla endişe duymalısınız. Bunun nedeni, bazı dillerin belirli işaretleme türlerini veya veritabanlarını diğerlerinden daha iyi kullanabilmeleridir. Bu, yukarıdakilerden herhangi birini hemen hemen hiçbir dilde kullanamayacağınız anlamına gelmez, ancak bazen sizin için mevcut olan desteklenen araçları kullanmak en iyisidir. Herhangi bir platform düz dosyaları ve ayrıştırma XML'lerini destekleyecektir, ancak mobil platformlarda mümkünse ikili serileştirmeyi göz önünde bulundurmak veya en azından XML'in depolanması için optimize etmek isteyebilirsiniz.

Veri yapısının karmaşıklığı.

Bu biraz zor bir durum. İlişkisel veritabanları sadece varlıkları ve ilişkilerini depolamak için harikadır. İlişkisel bir depolama deposu kullanarak yapıyı bir dosya sistemindeki dosyalarla yaptığınızdan daha iyi bir yeteneğiniz vardır. Varlıklarınız arasındaki ilişki türlerini ve bunları ne sıklıkta değiştirdiğinizi ya da ilişkili varlıkları bulduğunuzu düşünün. Son derece karmaşık yapılar için veritabanı yoluna gitmeyi öneririm.

Birçok proje arasında verilerin taşınabilirliği.

Taşınabilirlik söz konusu olduğunda, veritabanlarının dosyalardan doğal olarak daha ağır olduğunu göz önünde bulundurmalısınız. Kurulum ve yapılandırma ek yükü var, farklı platformlar için farklı veritabanları mevcut olacak, vb. SQLite bu konuda oldukça iyi bir yoldur. Ancak, taşınabilirlik söz konusu olduğunda, XML gibi dosya tabanlı çözümlerle büyük olasılıkla daha kolay bir zaman geçireceksiniz.

EDIT: Yorumlarınızdan birinde taşınabilirlik hakkında bahsettiğiniz başka endişeler var. Sonuç olarak, verilerinizin herhangi bir ürün veya dosya türüne çok sıkı bir şekilde bağlanmasını istemezsiniz. Sonuç olarak, derleme veya yükleme sırasında bir veritabanı / dosya sisteminde kolayca ayrıştırıp saklayabileceğiniz hisse senedi verilerini (düzeyler, düşmanlar, vb.) Bir tür soyut biçimde (sekmeyle ayrılmış dosyalar, XML vb.) Saklayabilirseniz en iyisidir. saati. Bu, depolama mekanizmanızı bir hevesle değiştirebileceğiniz ve ayrıştırma parçasını yeniden yazabileceğiniz anlamına gelir.

Verilere ne sıklıkta erişilmelidir?

Çok fazla veri erişimi, bir tür önbellekleme mekanizmanız yoksa, çok fazla G / Ç anlamına gelir. Veritabanları yapıları bellekte tutar ve veri işleme ve alma için mükemmeldir. Verileri sürekli olarak devam ettiriyorsanız, bir veritabanına bağlı kalmak isteyebilirsiniz.

Aynı uygulama için çoklu veri türü

Cilt kesinlikle bir değerlendirmedir, ancak binlerce veya milyonlarca nesneyi ısrar etmekten bahsetmiyorsanız, dosya sistemi hala bir çözüm olarak kabul edilebilir.

Oyun tipi

Oluşturduğunuz oyun türünün seçtiğiniz platform üzerinde büyük bir etkisi olabilir. Evet, çoğu müşteri için tek oyunculu oyunlarda, sıkıştırılmış veya şifreli bir dosya sistemi tabanlı çözüm kullanarak iyi olacaksınız. Çevrimiçi bir bileşeni olan oyunlar hakkında konuşuyorsanız, bu çılgınca olurdu. Veritabanı yoluna git ve baş ağrısını kurtar. Sunucunun bir arka uç kümesini kullanarak tüm verilerinizi yönetmesine izin verin.

Umarım bu geri bildirimlerden bazıları yardımcı olur. Hiçbir şekilde tamamen kapsamlı değildir ve nihayetinde karar vermek size bağlıdır, ancak yorumum size düşünmeniz gereken bazı şeyler vermelidir.

EDIT: Bir hibrid yaklaşımı almanın çok anlamlı olduğu bazı zamanlar vardır. Örneğin, bir MMORPG geliştirdiğinizi varsayalım. İstemci tarafında, diğer oyuncularla ilgili önbelleğe alınmış verileri ilişkisel olmayan bir veritabanında saklayabilirsiniz (yukarıda belirtildiği gibi). Sunucu tarafında, tüm oyun verilerini sürdürmek için ilişkisel bir veritabanında saklıyorsunuz. Ve sonra yine müşteri tarafında, daha kolay erişilebilirlik için büyük olasılıkla log / veri, konfigürasyon vb.

Bir başka poster de, bir veritabanında üretim için veri depolasanız bile, geliştirme için düz dosyaları kullanabilmenizin bir yolunu bulsanız bile, bunun güzel olduğunu belirtti ... başka bir ürünü karışımdan çıkarmak daha kolay olabilir .

Son zamanlarda kendimi ilişkisel veritabanlarına katma rijitliği / zorluğu ile sınırlı buldum. Oyunlar, devlet ve esneklik için çok uygun göründüğü için belge tabanlı veritabanlarını (örneğin couchdb) araştırmayı çok isterim. Ancak, küçük bir proje için birden fazla veritabanı türü oluşturmak gerçekten pratik değildir. Sonuç olarak, veritabanının belirli alanlarında yalnızca ikili bir blob alanı kullanmaya benzer bir hack kurdum.

Yaptığım şey, veritabanında json kodlanmış verileri ve verileri json'a dönüştüren ve gerektiğinde geri çeken bir sarıcı kullanmak. Dolayısıyla, temel bir karakter profili veritabanında şöyle görünebilir:

{"char_id":24,"char_name":"tchalvak","level":43,"profile":"Some profile here."}

Json hala veritabanında güzel bir şekilde okunabiliyor, bu yüzden sql ile metale çıplak çalışıyorsanız ve bazen veritabanına doğrudan erişiyorsanız, isterseniz manuel olarak değiştirilebilir.

Şimdi, bunların hepsi bir hack, ve ben bunu kopyalamayı önermiyorum, ama işte genel nokta: Sadece bir sisteme güvenmeyin. İlişkisel bir veritabanı kullanın ve sistemi doldurun. Veya iki farklı türde veri depolama sistemi kullanın (örn. Düz dosya ve ilişkisel veritabanı?), Böylece her ikisinden de en iyi şekilde yararlanabilirsiniz. İnsanların önerdiği veya hangi sistemle çalıştığınızın önemi yok, başka bir yaklaşımın daha iyi çalışacağı koşulları bulacağınız satırında, bir alternatif eklemek ve sizi nereye götürdüğünü görmek için hazırlıklı olun.

RTS geninde, oyun verileri dosyalara kaydedilmiştir.

Birimler ve nitelikler INI veya XML dosyalarında veya diğer metin tabanlı formatlarda saklanmıştır ve modeller, ikili ve hatta metin tabanlı formatların ve doku ve seslerin ve diğer ortamların ana formatlardaki bir karışımı olmuştur. Bazen ham şifrelemeye sahip bir kapta olmuştur - Westwood'un karışım biçimi akla geliyor. Ancak bu çoğunlukla şaşırtmacadır - eğer onların içine bakarsanız, formatları kolayca kullanılabilecek normal dosyalardır.

Çevrimiçi oyunun ortaya çıkmasıyla, genellikle bu hala dosya sisteminde saklanmakla birlikte, oyun verilerinin internet üzerinden kurulum sonrası sağlanması için giderek daha yaygın hale gelmiştir.

Neden bir veri depolama yöntemi kullanıyorsunuz?

Çoğu durumda, dünyaya bıraktığınız oyun, geliştirme sırasında oyunun ihtiyaç duyduğu veri depolama işlevselliğine ihtiyaç duymaz.

İşte bazı sürüm / geliştirme gereksinimlerinin karşılaştırması: -

Requirement      |  Release  |  Development  |  QA
==================================================
Multi user       |    No     |      Yes      |  No
Writable         |    No     |      Yes      |  No
Revision Control |    No     |      Yes      | Yes (but only reading)
Compact          |   Yes     |       No      |  No
Fast             |   Yes     |       No      |  No

İdeal olarak, veri yükleme modülünüze bir arayüz tanımlayacak ve daha sonra her biri özel ihtiyaçlara göre uyarlanmış çok sayıda versiyon oluşturacaksınız.

Uzun yıllar önce çalıştığım bir projede, CD'den yükleme seviyesi verileri çok uzun sürüyordu (HD dışında da büyük değildi). Böylece bir aşağıdaki ile geldi. Seviye verileri yüklemek için üç yöntemim vardı: -

1. Normal yükleme - varlıklar değiştiğinde gelişim süresi için
2. Ön sürüm - normal verileri hızlı yükleme verilerine dönüştürmek için etkin bir yöntem
3. Yayın - yalnızca hızlı veri (düzenlenebilir değil)

Bu yükleme sürelerini dakikalardan saniyelere indirdi.