Oyun testçilerinden nasıl faydalı veriler elde edersiniz? [kapalı]

Oynatıcılardan alabileceğiniz birkaç geri bildirim türü var ve her biri için en iyi veriyi nasıl toplayacağımı merak ediyorum ...

1. Kilitlenme Raporları. Birisi oynarken C ++ oyunum çöktüğünde, bunu en iyi nasıl bildiğimi ve daha da iyi olmasını nasıl sağlarım? Bir çökmeye neden olan dosya ve satır numarası kadar basit bir şey bile inanılmaz derecede yardımcı olacaktır.

2. Tasarım Geri Bildirimi. Bir oyun test cihazı oyunu oynarken, eğlenip eğlenmediklerini, neden eğlendiklerini, neden eğlenmediklerini ve ayarlamaya ne kadar zaman harcamamız gerektiğini nasıl anlayabilirim?

İnternet beta test cihazlarından değil, site içi test kullanıcılarından bahsettiğinizi varsayıyorum.

Kural # 1: Onlara yardım etme . Hayal kırıklığı kontrol etmeniz gereken en iyi şey olmalı. İdeal durum, bir taraftaki ekibiniz ve diğer taraftaki playtester, yüzlerinde bir video kamera ve başka bir ekran ile iki yönlü bir ayna olacaktır. Açıkçası bu çoğu insan için mümkün değil, bu yüzden elinizden gelenin en iyisini yapın. Tasarımcılarınızın oturup insanların nerede takıldıklarını izlemelerini sağlamak çok yararlı bilgilerdir. Oyunu eve götürdüklerinde omzunun üzerinde durmayacaksınız, bu nedenle belirli bölümleri nasıl geçeceğiniz konusunda size tavsiyede bulunmanız, ihtiyacınız olan bilgileri vermeyecektir. Düzenleme : koymak için başka bir yol şudur: "Yanlış oynamak" olduğunu sanmıyorum

Kural # 2: Onlara istediklerini vermeyin . Bir playtest oturumundan sonra doldurdukları bir çeşit anketiniz var. Sahip oldukları özel öneriler genellikle nominal değer olarak almak akıllıca değildir. Genellikle çoğu yanıtı tetikleyen bazı temel nedenler vardır ve sadece bunu nasıl ifade edeceklerini bilmezler. Bunu anlayabilirsen, yapman daha iyi olur. Şu anda belirli örnekler bulmakta zorlanıyorum.

Kural # 3: Veriler kraldır . Yapabilirseniz (ve bu gerçekten dürüstçe başka bir istek listesi öğesidir), yapabileceğiniz her şeyi izleyin. Oyuncuların nerede öldüğünü takip edin. Belirli bir silahtan merminin bittiği yeri takip edin. Hangi pikapları kaçırdıklarını takip edin. Hangi yükseltmeleri satın aldıklarını takip edin. Hangi düşmanların onlara zarar verdiğini takip edin. Açıkçası bunlar FPS'ye özgü örneklerdir, ancak yaptığınız oyun için alan adına özel olanlar olduğundan eminim. Herkes bir şey yapıyorsa veya bir şey yapmıyorsa, bunlar genellikle biraz daha fazla zaman harcamanız gereken alanlardır.

Temel olarak, oyuncunun umurumda değil düşünüyorum . Oyuncuların yaptığı ham sayıları almayı önemsiyorsunuz . Oyununuzu görmek ve onları neyin sinirlendirdiğini ve ne yapmaya yönlendirildiklerini söylemek için bakire gözlere ihtiyacınız var.

Çökmeler için, mini pompaları araştırın . Mükemmel değiller, ancak çökmelerin nerede olduğunu bulmak için çok kullanışlı bir araç.

Ayrıca yerleşik bir hata raporlama aracı da düşünün. Kullanıcının ekran görüntüsü alabileceği, açıklama ekleyebileceği ve oyun içinden otomatik olarak birine e-posta gönderebileceği bir şey. Oyununuz destekliyorsa, dünyanın bir anlık görüntüsü (yani hızlı kaydetme veya bir tür bellek dökümü) ile idealdir.

Verileri genişletmek için biraz kral hissi var (Tetrad'a +1!):

Kayıt ve oynatmayı araştırın :

• Oyununuz deterministik ve çerçeve tabanlıysa, sadece başlangıçtaki rastgele bir tohum ve (key/button state, joystick/mouse coords, frame #)giriş durumu değiştiğinde bir demet saklamanız gerekebilir . Oynatma, girişinizi bu akışa yönlendirmek kadar basittir. (Bunu geçmişte birçok platform atlama oyunu için yaptık.)
• Oyununuzda eylemleri gerçekleştirmek için iyi tanımlanmış API'ler veya mesaj sistemleri varsa (sıra tabanlı bir strateji oyunu, kart oyunu, masa oyunu veya benzeri), belirli bir sıkışma noktasında API çağrılarını veya mesajlarını toplayabilirsiniz . (Bunu el platformu için bir kart oyunu için yaptık.)
• Bazı sistemlerde daha zordur (daha az belirleyici, dişli veya keyfi zaman aşımı sistemleri bir acı olabilir) ama yine de verileri kaydetmeye değer olabilir; bazı kullanımlar için "yeterince yakın" sonuçlar alabilirsiniz.

Bu yöntemlere dayanan bir "tekrar" sisteminin birçok avantajı vardır:

• bir hata ayıklama veya başka bir araç veya yapıdaki çökmeleri yeniden oluşturmak için kullanın;
• profil oluşturma altında tekrarları yükleme ve performans veya kaynak kullanım verilerini alma;
• belki farklı bir kamera veya zaman adımı ile "anında tekrar" işlevselliği sağlamak için oyuna bağlayın;
• kullanıcı bir menüde hiçbir şey yapmadan etrafta dolaşıyorsa bir "çekme modu" demo oyunu oluşturun;
• bir duman testi olarak yapı sisteminize koyun: Eğer bu tekrarlamayı çökmeden oynayabilirsem, muhtemelen iyi bir yapıdır;
• ne yaptıklarını ve yapmadıklarını görmek için oynayan insanların örneklerini izleyin.

Kayıtlı bir akış yerine rastgele giriş yapın ve gece boyunca veya geliştirme makineleriniz boştayken ıslatmayı bırakabileceğiniz harika bir maymun testine sahipsiniz.

Ardından, bir olay kaydı yapın . Varsayımsal bir FPS için, "zaman T: X, Z noktasında silah W ile öldürdü" gibi bir şeyle başlayın: günlüğe koyun.

Toplanan bazı verileriniz olduğunda, toplama işlemini otomatikleştirmeyi öğrenin . Geliştirme sırasında zarif olmak zorunda değildir:

• SQL sunucusuna bağlanın ve satır ekleyin,
• bazı basit syslog-ish sunucusunda UDP paketlerini ateşleyip unutun,
• Oyun bir sonraki açılışında günlüğe e-posta gönder,
• yürütülebilir dosyayı bir .log dosyasını ortak bir paylaşılan sürücüye yeniden adlandıran ve kopyalayan bir kabuk komut dosyasına veya toplu iş dosyasına sarın,
• (daha sonra, üretim sürümleri için) kilitlenme verilerini toplamak için Windows Hata Bildirimi'ni veya benzer bir hizmeti kullanın ...

Veri toplayabildiğiniz sürece gerçekten önemli değil.

Şimdi genişletin: çökme dökümlerini toplayın, yığın izlerini ve girdi veya olay kayıtlarını toplayın. Daha fazla etkinlik ve daha fazla veri kaynağı ekleyin:

• Her 10 saniyede bir oyuncu pozisyonunu veya elini örnekleyin, bir harita üzerinde çizin - "hey, kimse bir hafta modelleme geçirdiğim bu köşeyi kullanmıyor, oraya bir powerup koyma zamanı"
• getFreeMemoryBytes() her yarım dakikada bir
• getFPS() periyodik olarak
• kullanıcının bir web kamerası aracılığıyla neler yaptığını gösteren bir fotoğraf veya video çekin (otomatik kullanılabilirlik testi için harika - yalnızca kullanıcı izni ve anlayışıyla)
• sistem bilgilerini al (yine kullanıcı izniyle)

"Haritaya çizin" olayı bir süre sonra gerçekten harika olabilir: RTS veya FPS haritasının havadan görünüşünü hayal edin. Oyunun başlangıcından beri geçen süreyi temsil eden bir kaydırıcı koyun. Bir etkinlik türü seçin ("altın aldı", "birini öldürdü", her neyse). Bir veri kümesi seçin: belki bir oyun, belki de son birkaç ay içinde 500 oyun. Kaydırıcıyı sağa çekmeye başlayın ve etkinliğin haritaya çıkmasını izleyin.

Ve eğer bu konuda size yardımcı olacak iyi kütüphaneler bulamazsanız (burada ve orada birkaç tane var!), Kendinizinkini yuvarlamayı düşünün: iyi bir öğrenme deneyimi ve özellikle zarif olması gerekmez kullanışlı olmak.

Verileri alın, onunla ne yapacağınızı anlayacaksınız. =)

Tabii bu çok şeylere bağlıdır ... a) ne tür bir test yapmak istiyorsunuz ve b) ne tür bir oyun test ediyorsunuz ve c) ne tür test ve altyapılarınız var ...

A) işlevsellik, b) dengeleme c) oyun tasarımı için test ediyorsanız da çok farklıdır.

Ancak genel olarak bu yönleri dikkate almak isteyebilirsiniz ...

* a) İş için doğru kişiyi seçin Söylemek çok basit geliyor, ama birçok kez gördüm ve sadece tekrar canlı gördüm. Her zaman olduğu gibi, insanlar arasında farklı işlerde ne kadar iyi oldukları konusunda önemli farklılıklar vardır. Test yapmaya istekli olan veya belki de istekli olan bazı kişiler, olağandışı (hatta basit) hataları bulabilecek kadar iyi oynamıyor olabilir. Bazıları hataları tanımlamakta iyi değildir. Bazıları dengeleme sorunlarını test etmede daha iyidir, bazıları görsel zayıflıklara daha dikkatlidir, bazıları oyunu alışılmadık şekillerde ve daha gizli gizli / nadir hatalarla oynarken daha yaratıcıdır, bazıları teknik veya görsel kaliteye daha özenlidir, bazıları anlayış yönlerinde daha iyidir ve hatta anlamlı değişiklikler önerebilir (testçilerinizin bunu yapmasını istiyorsanız;).

* b) Bir Sorun-İzleyici / Hata-İzleyici Yazılımı Kullanın Bu araçlar yalnızca sorunlarınızı düzenlemenize yardımcı olmakla kalmaz, aynı zamanda testçilerinizin içinde çalışacakları bir çerçeve oluşturarak ve aldıkları geri bildirimlerden öğrenerek çıktı kalitesini yükseltebilir. geliştiricilerin sorunları hakkında. Test cihazlarınızın çıktı kalitesini, onsuz çalışmanızdan çok daha hızlı artırmaya yardımcı olur. (Ayrıca uzaktan testlerde çok yardımcı olur) Oyun stüdyoları tarafından kullanılan tipik yazılım Mantis, JIRA, (ve tabii ki diğerleri ..) Genel bir liste ve ayrıca SO bu yazı için Wikipedia bakın .

c) Oyun içi test araçları ekleme Tipik olarak oyunun belirli seviyelerini veya bölümlerini test etmek için kullanılan kısayollar bulunur. Test sırasında bu bilgileri hata raporlarına ekleyebilmeleri için oyun sırasında fazladan bilgi görüntüleme. Bu, bir düzeydeki konum, bir sahnedeki etkin nesnelerin sayısı, şu anda kullanımda olan doku-koç veya palet miktarı, geliştiriciler için yararlı bir şey olabilir.

d) Deneyimli test cihazlarını taze kanla birleştirin Oyununuzda çok deneyimli ve tipik sorunların ne olduğunu ve nasıl (yeniden) test edileceğini öğrenen test cihazlarına sahip olmak her zaman iyi bir şeydir. Aynı zamanda, özellikle dengeleme için, arada bir yeni "bakire" oyuncular istiyorsunuz.

e) Test Yöneticisi Olun Süreci koordine eden ve eldeki oyuna, mevcut önceliklere, mevcut test uzmanlarına ve test ortamına uyarlayan biri.

f) Test Planı Belgesi Alın Bu ekstra bir yazıya değecektir.

Tetrad'ın belirttiği gibi, olabildiğince objektif veriler alın. Belirli olayları saklamak ve hepsini bir .csv dosyasına dökmek için kancaları koymak çok zor değildir. Ve Excel'de aldıktan sonra, inekler eve gelene kadar çalışabilir, grafik çizebilir ve çizebilirsiniz.

Ayrıca, cevaplamak istediğiniz belirli sorularınız var. Bilim adamları sadece oturup deneyler ateşlemez ve “bilim yaparlar”. Verileri istedikleri belirli, ölçülebilir soruları var. Aynı yaklaşımı kullanırsanız genellikle oyun testlerinden en iyi şekilde yararlanırsınız. Oyununuzun "iyi" olup olmadığını anlamaya çalışmak çok zor. Ancak, basit eğitim görevinin sadece beklediğiniz 5 dakikayı alıp almadığını veya testçilerin belirli bir bulmacayı çözmek için mücadele edip etmediğini anlamak aslında değerlendirilebilir.

Bazen, test etmenin en etkili yolu kısa patlamalarda yinelemelidir. Birkaç testçinin sabah bir saat kadar gitmesini sağlayın, tespit ettikleri konularda bazı değişiklikler yapın ve ertesi sabah yeni test kullanıcılarıyla tekrar gidin. Açıkçası bir öğleden sonra gelişecek kadar küçük bir özelliğe bakmanız gerekiyor. Ancak özellikle inatçı olan bir sorun için bu yöntem çok başarılı olabilir.

Tetrad Kural # 1 ile Kesinlikle Katılıyorum. Onlara yardım etme. Bir uyarı onlara yardım etmeyeceğinizi açıklamak olduğunu söyleyebilirim ve eğer yardıma ihtiyaç duyarlarsa lütfen sorun. Bu şekilde oyuncu sinirlenmez.

Anket, evet / hayır gibi basit sorular yerine açık uçlu sorular sormalıdır, test edenlerin yaşına ve sayısına bağlı olarak bunlar doldurdukları formlar olabilir veya soruları sorabilirsiniz. Onların geçmişi ve test ettikleri oyun türüne aşinalıkları hakkında sorular sormak da önemlidir; bu, oyununuzla ilgili belirli cevaplarına bağlam katacaktır.

Neyse ki oyunum çöktüğünde bana hatayla ilgili bir bilgi dökümü veriyor, bu yüzden bunun bir resmini çekebilir ve oyuncunun ne yaptığını not edebilirim. Normalde genç yaş gruplarını test ediyorum, böylece bir çarpışma olduğunda onlara harika bir iş çıkardıklarını açıklamayı hatırlamalıyım - oyunu bozduktan sonra üzülebilirler. Playtesters, dev ekibinin oyunu "doğru" şekilde oynayarak asla karşılaşmayacağı belirsiz hataları bulma konusunda gerçekten iyi olduğunu kanıtladı.

Kilitlenmeleri yakalayan ve çağrı yığınını kaydeden bir kod yazmak mümkündür. Bu hata raporlarında çok yardımcı olabilir. Yararlı bir günlük dosyası oluşturmak da yardımcı olur. Kullanıcıdan bu dosyaları bir daha oynattıklarında göndermelerini isteyebilir veya oyun kapatıldıktan sonra çalışan veya isterseniz çöktüğünde bağımsız bir araca sahip olabilirsiniz.

Çökme raporları için, oynatma testçilerine değil ücretli KG personeline güveniyor olmanız gerekir. KG, hataları bulma ve anlamlı bir şekilde bildirme yetenekleri için özellikle işe aldığınız bir kişidir ve iyi bir testçi, ağırlıklarının altın değerine değerdir (ve programcılara kıyasla ağırlıklarının sadece onda birine mal olur!).

Eğer "oh, kazayla bir kaza bulurlarsa, sadece bunun için test etmedikleri için kaçırmak istemeyiz" diye endişeleniyorsanız, ... bu günlüğe kaydetmenin nedenidir. Yeterince iyi bir kayıt sistemi, bir kazayı tam olarak yeniden üretebilmek için yeterli oyun elemanını kaydetmelidir.

Tasarım geri bildirimi için, oyun tasarımcılarınızın gerçekte onları oynatmasını izlemenin yerini alamaz (veya gerekiyorsa video kaydedici vb.). Her ikisi de kötü şöhrete sahip olan playtester hafızasına veya görüşüne güvenmeyin. Ama eğer onları gerçek zamanlı olarak oynarken izliyorsanız, nişanlanmış, sıkılmış veya sinirli olup olmadıklarını sadece yüzlerine ve vücut duruşlarına bakarak açık bir şekilde açıktır.