MMO sunucuları için oyun günlüğü biçimi


12

Tüm küme / kırık için oyun olaylarının günlüğü (hata / hata ayıklama günlüklerinin aksine), canlı bir üretim ortamında bulunan ve müşteri hizmetleri için hayati destek sağlayan ve geçmiş analitik araçlar sağlayan ticari bir MMO için çok yararlıdır.

Şu anda üzerinde çalıştığım proje, tüm oyun olay günlüklerini saklamak için ilişkisel bir veritabanı kullanıyor ve bu yöntem iyi çalışıyorken, günlüklerin salt okunur, kronolojik doğasının daha verimli bir depolama biçimine izin vereceği anlaşılıyor. .

Ancak, özel ikili günlük biçimleri oluşturma hakkında nereden öğrenmeye başlayacağımdan emin değilim. Özel günlük biçimleri veya konuyla ilgili önerilen makaleler / makaleler oluşturma deneyimleriniz nelerdir?

Yanıtlar:


7

In Stendhal'ın onları işleyerek daha sonra bir sıraya oyun olayları ekleyerek ve performans sorunu çözüldü arka planda uyumsuz .

Bizim durumumuzda olaylar sadece kayıtlar değil, biraz mantığı olan nesnelerdir, çünkü bazı durumlarda aralarında bağlantı bulunan iki ekleme yapmamız gerekir. Örneğin bir oyunda ilk kez ele alındığında, bir item-event günlüğünün kaydedilebilmesi için önce item tablosuna eklenmesi gerekir.

Ancak günlüğü yazmak sorunun sadece bir tarafıdır:

Günlüklerle hangi soruları cevaplamak istiyorsunuz?

Tüm günlüğü kronolojik sırayla okumak kolaydır; veya bir oyuncu için filtrelemek.

Ancak aşağıdaki gibi sorular olabilir:

  • Anton dün Beth tarafından alınan hangi eşyaları yere koydu? Hangi oyuncu şimdi onlara sahip? (Anton öğesinin çalınmasından şikayet etti)
  • Ortalama bir oyuncunun 100. seviyeye ulaşması için ne kadar zamana ihtiyacı var? Hangi oyuncular önemli ölçüde daha hızlı? sadece ilk karakterler için mi?
  • Büyük miktarlarda oyun parasıyla ilgilenen oyuncular var mı? Hangi oyunculara geçildi? Karşılığında değerli bir şey olmadan?
  • Zayıf oyuncular, yasal olarak öldürmemeleri gereken güçlü yaratıkları öldürebilir mi?
  • ...

Stendhal'da, oyun günlükleri için ilişkisel bir veritabanı kullanıyoruz, çünkü bu, performansa yönelik geçici sorgulara izin vermenin en kolay yolu. Özel bir günlük biçimi kullanırsanız, temelde tüm bu sorguları gerektiğinde kodlamanız gerekir. Ve bunu yeterli performansla yapmak oldukça zorlaşıyor.

GameEvents tablonuz 51.429.139 satır (geçen yıl) ve 15.393.831 öğe için 60.360.657 satır (her zaman) içeren özel bir itemlog tablonuz var.


Veritabanınızda arama ne kadar hızlı? Günlüklerle benzer bir veritabanım var ve üç ay sonra yaklaşık 100.000.000 satır var. Depolama olarak MySQL kullanıyoruz ve performansı kötü. Bir oyuncunun (yalnızca 20.000) satırın tüm eylemlerini listeleyen basit sorgu genellikle 60 saniyeden fazla sürer.
Balon

1
Dizin sütunlarındaki basit sorgular anında gerçekleşir. Karmaşık sorgular biraz zaman alabilir, 60 saniyelik sorgular olabilir, ancak bunlar çok nadirdir. Tabloyu çok yoğun bir şekilde dizine ekledik ve eklemedeki cezayı eşzamansız yaparak telafi ettik.
Hendrik Brummermann

Hmmm Benim sorunum, sonuç setinin oldukça büyük olması, genellikle bir oyuncu için 3000 ila 150000 kayıt arasında olmasıdır. Bu yüzden bu kadar uzun zaman almasının nedeni olabilir, çünkü küçük sonuç kümeleri için çok hızlı çalışır.
Balon

4

Verimlilik ile ne demek istiyorsun? İster disk boyutunda ister sorgu hızında olsun, bir ilişkisel veritabanı neredeyse kesinlikle özel ikili biçiminizi yenecek veya eşitleyecek ve kullanımı çok daha kolay ve daha esnek olacaktır.

İlişkisel bir DB'de kullandığınız her tablo, satır başına ne kadar alana izin vereceğinizi tam olarak baytla belirtmenizi sağlar. Düz metin günlüğe kaydetmiyorsanız - ve "oyun olaylarının günlüğü (hata / hata ayıklama günlüklerinin aksine)" , sizin ilişkisel veritabanı alan açısından oldukça optimal, bu onları ilk etapta oldukça hızlı yapar. Üstelik ilişkisel veritabanları, çok hızlı erişim için dizin oluşturmada ve sorgulardan en iyi şekilde yararlanmak için optimize etmede oldukça kullanışlıdır.

Bu yüzden sahip olduklarınıza sadık kalmanızı tavsiye ederim.


Yanıt için teşekkürler (ve aşağıda cevapları gönderen diğer kişilere teşekkürler)! Bu konuda ne kadar çok düşünürsem, RDBMS'ye o kadar çok benziyor, bu özel günlük kaydı için uygun bir seçimdir. Temel arama türleri için iyi endekslenmiş özel bir günlük biçimi tasarlamak çok zor olmaz, ancak CSR'ler ve oyun analitiği tarafından sıklıkla kullanılan karmaşık sorgular ile daha genel bir yaklaşım gereklidir - bu noktada yerleşik bir ürün çoğu durumda daha iyi performans gösterecektir.
Charles Ellis

Özel olay günlüğü kurulumu kesinlikle kronolojik çalma ala FPS demo kayıtları için kullanışlı olacaktır, ancak bu çok farklı bir problemdir. Herkes çok oyunculu istemci-sunucu oyunları için demo kayıtlarına benzer bir şey geliştirme konusunda deneyime sahip mi?
Charles Ellis

Sunucu tarafındaki mantık işleme modelinize bağlı olarak, yalnızca sunucuya varış zamanı ile damgalanan ve yeniden oynatılabilen her girişi depolamak mümkün olabilir. Sorun, her bir girdiyi yeniden oynatmanın yanı sıra başka bir faktörü (örn. Rastgele tohumlar, gecikmeye bağlı olarak değişen şeyler gibi zımni girdiler vb.) Modellemeniz gerektiğinden, oynatmada ortaya çıkma eğilimindedir. Ancak burada tek bedene uyan bir sistem yoktur - sunucunuzun nasıl çalıştığına bağlıdır.
Kylotan

3

Muhtemelen özel bir formatla birkaç bayt kaydedebileceğiniz veya sadece gzip edilmiş metinler saklayabileceğiniz doğrudur, depolama ucuzdur, bu yüzden artık artık optimize etmeye değmez. Daha da önemlisi, her ikisi de hazır bir SQL sunucusunun muhtemelen oldukça iyi yaptığı G / Ç arabellekleme ve sorgulama gibi şeylerle uğraşmaktır. Bu cephelerde senin için çalışıyorsa, onunla koşardım. Özel dosyalara yazan ve daha sonra sorgular için bir veritabanına okumak için ayrı bir ayrıştırıcı programına sahip olan kendi arabelleğe alma günlük sunucumuzu yazdık, bunu tavsiye etmem.


0

Bu günlerde ilişkisel veritabanları verimsiz olduğu için çalıyor, ancak bahsettiğiniz günlüklerin türünü depolarken, verimliliğe ihtiyacınız yok çünkü oyun veya kullanıcıları tarafından sürekli olarak erişilmeyecek - sadece ekibinizin ihtiyacı olacak veri okumak için.

Yani "verimlilik" o kadar önemli değil. Daha da önemlisi, verileri kullanıcıların oyunda neler yaptığını anlatacak şekilde sıralamaktır. Geliştiricilerinizin genellikle bu verileri tüketmesi ve analistler için okunması kolay bir arayüzde göstermesi gerekir ve analistlerin bazen kullanıcı davranışını derinlemesine incelemek için verileri sorgulamaları gerekir. Örneğin, oyuncular bir güncellemeden önce belirli bir öğeyi satın alıyor, ancak bir güncellemeden sonra satın almayı durduruyorsa, bir analist, kullanıcıların neden artık satın almadığını belirlemek için satın alma işlemini çevreleyen davranışla ilgili belirli sayıları ortaya çıkaran belirli sorgular yazarak fayda sağlayacaktır. İyi belgelenmiş standart bir sorgu diline sahip olmaları en iyisidir. Bu sorguları özel bir ikili biçimde yapmak zorunda kalırlarsa, işleri ÇOK daha zor hale getirilecek,

Genellikle oyun etkinlikleri buna benzer (bu özellikle DeltaDNA'nın biçimidir)

{
 "eventName":"specific event code – eg. gameStarted",
 "userID":"ABCD1-4321a879b185fcb9c6ca27abc5387e914",
 "sessionID":"4879bf37-8566-46ce-9f3b-bd18d6ac614e",
 "eventTimestamp":"yyyy-mm-dd hh:mm:ss.SSS",
 "eventParams":
  {
   "platform":"WEB",
   "param1":"stringParam",
   "param2":true,
   "param3":1234,
   "param4":["a","b","c"]
  },
}

Olay genellikle bir olay adı, bir kullanıcı kimliği, bir oturum kimliği, zaman damgası ve o olayı çevrelemek için yararlı bulduğunuz verileri kaydetmenizi sağlayan parametreler içerir. Deneyimlerime göre, ilişkisel veritabanı formatları böyle bir yapıyı kaydetmek için en iyisidir.

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.