Bagaimana Anda mendapatkan data yang berguna dari playtesters? [Tutup]
19
Ada beberapa jenis umpan balik yang bisa Anda dapatkan dari playtesters, dan saya ingin tahu bagaimana cara terbaik mengumpulkan data untuk masing-masing ...
Laporan Kecelakaan. Ketika game C ++ saya crash saat seseorang memainkannya, bagaimana cara terbaik memastikan bahwa saya tahu tentang itu dan bahkan lebih baik ... apa yang menyebabkannya? Bahkan mendapatkan sesuatu yang sederhana seperti nomor file dan baris yang menyebabkan kerusakan akan sangat membantu.
Umpan Balik Desain. Ketika seorang penguji bermain memainkan permainan, bagaimana saya bisa mengetahui apakah mereka bersenang-senang, mengapa mereka bersenang-senang, mengapa mereka tidak bersenang-senang, dan apa yang harus kita habiskan untuk menyesuaikan waktu?
Saya berasumsi Anda sedang berbicara tentang playtesters di tempat dan bukan penguji beta internet.
Aturan # 1: Jangan bantu mereka . Frustrasi harus menjadi hal utama yang harus Anda periksa. Situasi ideal adalah cermin dua arah dengan tim Anda di satu sisi dan playtester di sisi lain dengan satu kamera video di wajah mereka dan yang lain di layar. Jelas ini tidak layak untuk kebanyakan orang, jadi lakukan yang terbaik yang Anda bisa. Hanya membuat desainer Anda duduk dan menonton di mana orang terjebak adalah informasi yang sangat berguna. Anda tidak akan berdiri di atas bahu mereka ketika mereka membawa pulang permainan, sehingga Anda memberi saran tentang cara melewati bagian-bagian tertentu tidak akan memberi Anda informasi yang Anda butuhkan. Sunting : cara lain untuk menjelaskannya adalah ini: Jangan berpikir mereka "Bermain salah"
Aturan # 2: Jangan berikan apa yang mereka inginkan . Setelah sesi playtest, Anda memiliki beberapa jenis kuesioner yang mereka isi. Saran spesifik yang mereka miliki biasanya tidak bijak untuk dipahami. Biasanya ada beberapa penyebab utama yang memicu sebagian besar respons dan mereka tidak tahu bagaimana mengungkapkannya. Jika Anda bisa mengetahuinya, Anda akan lebih baik melakukannya. Meskipun saat ini saya mengalami masalah dengan contoh-contoh spesifik.
Aturan # 3: Data adalah raja . Jika Anda bisa (dan ini benar-benar item daftar harapan, jujur), lacak semua yang Anda bisa. Lacak di mana pemain mati. Lacak di mana mereka kehabisan amunisi dari senjata tertentu. Lacak pickup apa yang mereka lewatkan. Lacak upgrade apa yang mereka beli. Lacak apa yang dirusak musuh kepada mereka. Jelas ini adalah contoh spesifik FPS, tapi saya yakin ada yang spesifik domain untuk game apa pun yang Anda lakukan. Jika semua orang melakukan sesuatu atau tidak melakukan sesuatu, itu biasanya adalah area yang harus Anda habiskan sedikit lebih lama untuk melihatnya.
Pada dasarnya, Anda tidak peduli apa yang pemain berpikir . Anda peduli untuk mendapatkan angka mentah untuk apa yang dilakukan pemain . Anda perlu mata perawan untuk melihat permainan Anda dan memberi tahu Anda apa yang membuat mereka frustrasi dan apa yang harus mereka lakukan.
Untuk kerusakan, selidiki minidump . Mereka tidak sempurna, tetapi merupakan alat yang sangat berguna untuk mencari tahu di mana crash berada.
Juga pertimbangkan alat pelaporan bug bawaan. Sesuatu di mana pengguna dapat mengambil tangkapan layar, menambahkan deskripsi, dan mengirimkannya kepada seseorang secara otomatis dari dalam permainan. Idealnya dengan snapshot dunia (yaitu penyimpanan cepat atau semacam memori) jika game Anda mendukungnya.
poin yang sangat baik dibuat di sini cookie untuk Anda dan saya harus menyetujui 100% dengan** Don't help them **
Prix
1
Apa yang akan Anda lakukan berbeda untuk umpan balik jika itu adalah penguji beta online? hanya ingin tahu sejak Anda mengatakanon-site playtesters
Prix
Saya tidak punya pengalaman positif dengan itu jadi saya tidak bisa membantu Anda. Saya telah melihat kuesioner online berubah menjadi kekacauan besar dengan statistik yang tidak berarti.
Tetrad 2-10
Jawaban yang bagus, dan untuk menguraikan sedikit tentang "Jangan Beri mereka apa yang mereka inginkan", saya menulis sedikit pendekatan pribadi saya untuk itu di blog pribadi saya sendiri ( doublebuffered.com/2009/06/16/… ). Ini sedikit lebih berorientasi pada mencerna umpan balik papan pesan beta tetapi saya telah menerapkannya pada playtests secara langsung.
Ben Zeigler
Penguji beta daring hanya cukup berguna untuk menjawab pertanyaan spesifik seperti "apakah game mogok saat Anda mencoba menggunakan fitur X?" Anda harus melakukan uji coba sendiri untuk menilai reaksi keseluruhan. Saya ulangi: Anda harus memiliki pengamatan langsung terhadap orang lain selain para pengembang yang memainkan permainan. Bahkan hanya menyerahkan kontrol kepada pengunjung sesekali lebih baik daripada tidak sama sekali.
jhocking
13
Untuk memperluas data adalah sentimen raja sedikit (+1 ke Tetrad!):
Selidiki perekaman dan pemutaran :
Jika game Anda bersifat deterministik dan berbasis bingkai, Anda mungkin hanya perlu menyimpan seed acak awal dan tuple (key/button state, joystick/mouse coords, frame #)kapan saja keadaan input berubah. Putar ulang sesederhana mengarahkan ulang input Anda ke aliran ini. (Kami telah melakukan ini untuk banyak game platform-jumping di masa lalu.)
Jika gim Anda memiliki API atau sistem pesan yang terdefinisi dengan baik untuk melakukan tindakan (gim strategi berbasis giliran, gim kartu, gim papan, atau sejenisnya), Anda mungkin dapat memanen panggilan API atau pesan pada titik jepit tertentu . (Kami melakukan ini untuk permainan kartu untuk platform genggam.)
Ini lebih sulit pada beberapa sistem (sistem timestep yang kurang deterministik, berulir, atau sewenang-wenang dapat menyusahkan), tetapi bagaimanapun juga mungkin layak untuk merekam data; Anda bisa mendapatkan hasil "cukup dekat" untuk beberapa kegunaan.
Sistem "replay" berdasarkan metode ini memiliki banyak keuntungan:
menggunakannya untuk mereproduksi crash dalam debug atau build atau lingkungan yang diinstrumentasi;
memuat pemutaran ulang di bawah pembuatan profil dan mendapatkan data kinerja atau penggunaan sumber daya;
menghubungkannya ke dalam game untuk menyediakan fungsionalitas "pemutaran ulang instan", mungkin dengan kamera atau langkah waktu yang berbeda;
mengatur gameplay demo "mode menarik" jika pengguna tidak melakukan apa-apa pada menu;
letakkan di sistem build Anda sebagai tes asap: jika saya bisa memainkan replay ini tanpa menabrak, itu kemungkinan besar build yang bagus;
saksikan contoh orang bermain untuk melihat apa yang mereka lakukan dan tidak lakukan.
Kirim input acak dari pada stream yang direkam, dan Anda memiliki tes monyet yang hebat yang dapat Anda biarkan berendam semalam atau kapan pun mesin pengembangan Anda menganggur.
Selanjutnya, lakukan beberapa rekaman acara . Untuk FPS hipotetis, mulailah dengan sesuatu seperti "waktu T: X membunuh Y pada titik Z dengan senjata W": masukkan ke dalam log.
Setelah Anda mengumpulkan beberapa data, cari tahu cara mengotomatiskan pengumpulan . Tidak harus elegan selama pengembangan:
terhubung ke server SQL dan masukkan baris,
jalankan dan lupakan paket UDP di beberapa server syslog-ish sederhana,
e-mail log saat boot game berikutnya,
cukup bungkus executable dalam skrip shell atau file batch yang mengubah nama dan menyalin file .log ke drive bersama yang umum,
(nanti, untuk build produksi) gunakan Windows Error Reporting atau layanan serupa untuk mengumpulkan data kerusakan ...
Tidak masalah, selama Anda bisa mengumpulkan data.
Sekarang perpanjang itu: kumpulkan dump crash, jejak stack, dan input atau rekaman acara. Tambahkan lebih banyak acara, dan lebih banyak sumber data:
sampel posisi pemain atau tangan setiap 10 detik, plot di peta - "hei, tidak ada yang menggunakan sudut ini yang saya habiskan seminggu untuk memodelkan, waktu untuk memasukkan powerup ke sana"
getFreeMemoryBytes() setiap setengah menit
getFPS() secara berkala
ambil foto atau video tentang apa yang dilakukan pengguna melalui webcam (bagus untuk pengujian kegunaan otomatis - hanya dengan izin dan pengertian pengguna, tentu saja)
ambil info sistem (sekali lagi, dengan izin pengguna)
Hal "plot it on a map" dapat menjadi sangat luar biasa setelah beberapa saat: bayangkan sebuah foto udara dari peta RTS atau FPS. Letakkan slider di atasnya, mewakili waktu sejak awal permainan. Pilih jenis acara ("dapatkan emas", "bunuh seseorang", apa pun). Pilih satu set data: mungkin satu game, mungkin 500 game selama beberapa bulan terakhir. Mulailah menarik slider ke kanan dan saksikan aktivitas muncul di peta.
Dan jika Anda tidak dapat menemukan lib yang baik untuk membantu Anda dengan hal-hal ini (ada beberapa di sana-sini!), Pertimbangkan untuk menggulung sendiri: ini adalah pengalaman belajar yang baik, dan itu tidak perlu sangat elegan untuk menjadi berguna.
Dapatkan data, Anda akan mencari tahu apa yang harus dilakukan dengannya. =)
Tentu saja ini sangat tergantung pada ... a) pengujian seperti apa yang ingin Anda lakukan, dan b) jenis permainan apa yang Anda uji, dan c) penguji dan infrastruktur seperti apa yang Anda miliki ...
Ini juga sangat berbeda jika Anda menguji untuk a) fungsionalitas, b) menyeimbangkan c) desain game
Tetapi secara umum Anda mungkin ingin mempertimbangkan aspek-aspek ini ...
* a) Pilih orang yang tepat untuk pekerjaan itu
Kedengarannya terlalu mudah untuk disebutkan, tetapi saya sudah melihatnya berkali-kali dan baru melihatnya hidup kembali. Seperti biasa, ada perbedaan yang signifikan antara orang dalam hal seberapa baik mereka di pekerjaan yang berbeda. Beberapa orang yang bersedia atau mungkin ingin melakukan pengujian mungkin tidak bermain cukup teliti untuk menemukan bug yang tidak biasa (atau bahkan sederhana). Beberapa tidak pandai menggambarkan bug. Ada yang lebih baik dalam menguji masalah keseimbangan, ada yang lebih memperhatikan kelemahan visual, ada yang lebih kreatif dalam bermain game dengan cara yang tidak biasa dan menemukan bug yang tersembunyi / langka, ada yang lebih memperhatikan kualitas teknis atau visual, ada yang lebih baik dalam memahami aspek mekanik permainan dan bahkan mungkin dapat menyarankan perubahan yang berarti (jika Anda ingin penguji Anda melakukan itu;).
* b) Gunakan Perangkat Lunak Issue-Tracker / Bug-Tracker
Alat-alat ini tidak hanya dapat membantu dalam mengatur masalah Anda tetapi juga dalam meningkatkan kualitas output penguji Anda dengan memberi mereka bingkai untuk bekerja di dalam dan dengan belajar dari umpan balik yang mereka dapatkan dari pengembang tentang masalah mereka. Ini membantu untuk meningkatkan kualitas output penguji Anda jauh lebih cepat daripada jika Anda bekerja tanpanya. (Ini juga banyak membantu dengan penguji jarak jauh) Perangkat lunak khas yang digunakan oleh studio game adalah Mantis, JIRA, (dan banyak lainnya tentu saja ..) Lihat Wikipedia untuk daftar umum dan juga posting ini di SO.
c) Menambahkan alat pengujian ingame
Khas adalah Pintasan untuk menguji level atau bagian tertentu dari permainan. Menampilkan informasi tambahan selama pertandingan ke penguji sehingga mereka dapat menambahkan ini ke laporan bug. Ini bisa berupa posisi di tingkat, jumlah objek aktif dalam sebuah adegan, jumlah ram tekstur atau palet yang saat ini digunakan, apa pun yang membantu para pengembang.
d) Gabungkan penguji berpengalaman dengan darah segar
Selalu merupakan hal yang baik untuk memiliki penguji yang sangat berpengalaman dengan permainan Anda dan telah belajar apa masalah khasnya dan bagaimana (kembali) mengujinya. Pada saat yang sama Anda ingin pemain "perawan" baru sesekali, terutama untuk menyeimbangkan.
e) Memiliki Test Manager
Seseorang yang mengoordinasikan proses dan menyesuaikannya dengan permainan yang ada, prioritas saat ini dan penguji yang tersedia dan lingkungan pengujian.
f) Memiliki Dokumen Rencana Tes
Ini akan layak mendapat posting tambahan.
Seperti yang disebutkan Tetrad, dapatkan sebanyak mungkin data objektif. Memasukkan kait untuk menyimpan acara tertentu dan membuang semuanya ke .csv tidak terlalu sulit. Dan begitu Anda mendapatkannya di Excel, Anda bisa belajar, membuat grafik dan plot sampai sapi pulang.
Juga, ada pertanyaan spesifik yang ingin Anda jawab. Para ilmuwan tidak hanya duduk, menjalankan beberapa percobaan dan "melakukan sains." Mereka memiliki pertanyaan spesifik, terukur yang mereka inginkan tentang data. Anda akan sering mendapatkan hasil maksimal dari tes bermain jika Anda mengambil pendekatan yang sama. Mencoba mengetahui apakah permainan Anda "baik" sangat sulit untuk diukur. Tetapi mencari tahu apakah misi tutorial sederhana hanya memakan waktu 5 menit yang Anda harapkan, atau jika penguji berjuang untuk memecahkan teka-teki tertentu, sebenarnya dapat dievaluasi.
Kadang-kadang, cara paling efektif untuk menguji adalah berulang dalam waktu singkat. Mintalah beberapa penguji untuk sekitar satu jam di pagi hari, buat beberapa perubahan pada masalah yang mereka identifikasi dan lakukan lagi dengan penguji baru di pagi hari berikutnya. Jelas Anda harus melihat fitur yang cukup kecil untuk diperbaiki di sore hari. Tetapi untuk masalah yang sangat keras kepala, metode ini bisa sangat berhasil.
Pasti Setuju dengan Tetrad's Rule # 1. Jangan bantu mereka. Saya akan mengatakan peringatan adalah untuk menjelaskan kepada mereka bahwa Anda tidak akan membantu mereka, dan jika mereka membutuhkan bantuan untuk bertanya. Dengan cara ini, pemain tidak frustrasi.
Kuisioner harus mengajukan pertanyaan terbuka, alih-alih pertanyaan sederhana ya / tidak, tergantung pada usia dan jumlah penguji, ini bisa berupa formulir yang mereka isi, atau Anda dapat mengajukan pertanyaan. Penting juga untuk mengajukan pertanyaan tentang sejarah mereka dan keakraban mereka dengan genre permainan yang Anda uji; ini akan menambah konteks ke jawaban spesifik mereka tentang game Anda.
Untungnya ketika game saya crash, saya mendapat banyak informasi tentang kesalahan tersebut, jadi saya bisa memotretnya dan mencatat apa yang dilakukan pemain. Biasanya saya menguji kelompok usia yang lebih muda sehingga ketika kita mengalami crash, saya harus ingat untuk menjelaskan kepada mereka bahwa mereka melakukan pekerjaan yang bagus - mereka bisa marah setelah memecahkan permainan. Playtesters benar-benar terbukti hebat dalam menemukan bug yang tidak jelas bahwa tim pengembang tidak akan pernah menemukan permainan dengan cara yang "benar".
Dimungkinkan untuk menulis kode yang menangkap crash dan mencatat tumpukan panggilan. Itu bisa banyak membantu dengan laporan bug. Memiliki file log yang berguna dihasilkan juga membantu. Anda dapat meminta pengguna untuk mengirim file-file ini pada saat mereka bermain, atau memiliki alat mandiri yang berjalan setelah game ditutup atau crash jika Anda mau.
Untuk laporan kerusakan, Anda harus mengandalkan staf QA berbayar, bukan playtesters. QA adalah seseorang yang Anda pekerjakan secara khusus karena kemampuan mereka untuk menemukan bug dan melaporkannya dengan cara yang bermakna, dan seorang penguji yang baik sepadan dengan bobot mereka dalam emas (dan hanya berharga sepersepuluh dari beratnya dalam emas, dibandingkan dengan programmer!).
Jika Anda khawatir tentang "oh, bagaimana jika mereka secara tidak sengaja menemukan kerusakan, kami tidak ingin ketinggalan hanya karena mereka tidak menguji untuk itu" ... inilah gunanya penebangan. Sistem pencatatan yang cukup baik harus merekam elemen permainan yang cukup untuk dapat mereproduksi crash secara tepat.
Untuk umpan balik desain, tidak ada pengganti untuk membuat perancang permainan Anda benar-benar menontonnya bermain (atau menggunakan perekam video jika Anda harus, dll.). Jangan mengandalkan memori atau pendapat playtester, yang keduanya terkenal buruk. Tetapi jika Anda melihat mereka bermain dalam waktu nyata, jelas sekali hanya dengan melihat wajah dan postur tubuh mereka apakah mereka bertunangan, bosan, atau frustrasi.
Staf QA berbayar di luar anggaran untuk sebagian besar pengembang indie, jadi masuk akal untuk 'mengumpulkan-sumber' sejauh mungkin. Dan tidak ada pengganti untuk melihat seberapa baik harga game di alam liar.
** Don't help them **on-site playtestersUntuk memperluas data adalah sentimen raja sedikit (+1 ke Tetrad!):
Selidiki perekaman dan pemutaran :
(key/button state, joystick/mouse coords, frame #)kapan saja keadaan input berubah. Putar ulang sesederhana mengarahkan ulang input Anda ke aliran ini. (Kami telah melakukan ini untuk banyak game platform-jumping di masa lalu.)Sistem "replay" berdasarkan metode ini memiliki banyak keuntungan:
Kirim input acak dari pada stream yang direkam, dan Anda memiliki tes monyet yang hebat yang dapat Anda biarkan berendam semalam atau kapan pun mesin pengembangan Anda menganggur.
Selanjutnya, lakukan beberapa rekaman acara . Untuk FPS hipotetis, mulailah dengan sesuatu seperti "waktu T: X membunuh Y pada titik Z dengan senjata W": masukkan ke dalam log.
Setelah Anda mengumpulkan beberapa data, cari tahu cara mengotomatiskan pengumpulan . Tidak harus elegan selama pengembangan:
Tidak masalah, selama Anda bisa mengumpulkan data.
Sekarang perpanjang itu: kumpulkan dump crash, jejak stack, dan input atau rekaman acara. Tambahkan lebih banyak acara, dan lebih banyak sumber data:
getFreeMemoryBytes()setiap setengah menitgetFPS()secara berkalaHal "plot it on a map" dapat menjadi sangat luar biasa setelah beberapa saat: bayangkan sebuah foto udara dari peta RTS atau FPS. Letakkan slider di atasnya, mewakili waktu sejak awal permainan. Pilih jenis acara ("dapatkan emas", "bunuh seseorang", apa pun). Pilih satu set data: mungkin satu game, mungkin 500 game selama beberapa bulan terakhir. Mulailah menarik slider ke kanan dan saksikan aktivitas muncul di peta.
Dan jika Anda tidak dapat menemukan lib yang baik untuk membantu Anda dengan hal-hal ini (ada beberapa di sana-sini!), Pertimbangkan untuk menggulung sendiri: ini adalah pengalaman belajar yang baik, dan itu tidak perlu sangat elegan untuk menjadi berguna.
Dapatkan data, Anda akan mencari tahu apa yang harus dilakukan dengannya. =)
sumber
Tentu saja ini sangat tergantung pada ... a) pengujian seperti apa yang ingin Anda lakukan, dan b) jenis permainan apa yang Anda uji, dan c) penguji dan infrastruktur seperti apa yang Anda miliki ...
Ini juga sangat berbeda jika Anda menguji untuk a) fungsionalitas, b) menyeimbangkan c) desain game
Tetapi secara umum Anda mungkin ingin mempertimbangkan aspek-aspek ini ...
* a) Pilih orang yang tepat untuk pekerjaan itu Kedengarannya terlalu mudah untuk disebutkan, tetapi saya sudah melihatnya berkali-kali dan baru melihatnya hidup kembali. Seperti biasa, ada perbedaan yang signifikan antara orang dalam hal seberapa baik mereka di pekerjaan yang berbeda. Beberapa orang yang bersedia atau mungkin ingin melakukan pengujian mungkin tidak bermain cukup teliti untuk menemukan bug yang tidak biasa (atau bahkan sederhana). Beberapa tidak pandai menggambarkan bug. Ada yang lebih baik dalam menguji masalah keseimbangan, ada yang lebih memperhatikan kelemahan visual, ada yang lebih kreatif dalam bermain game dengan cara yang tidak biasa dan menemukan bug yang tersembunyi / langka, ada yang lebih memperhatikan kualitas teknis atau visual, ada yang lebih baik dalam memahami aspek mekanik permainan dan bahkan mungkin dapat menyarankan perubahan yang berarti (jika Anda ingin penguji Anda melakukan itu;).
* b) Gunakan Perangkat Lunak Issue-Tracker / Bug-Tracker Alat-alat ini tidak hanya dapat membantu dalam mengatur masalah Anda tetapi juga dalam meningkatkan kualitas output penguji Anda dengan memberi mereka bingkai untuk bekerja di dalam dan dengan belajar dari umpan balik yang mereka dapatkan dari pengembang tentang masalah mereka. Ini membantu untuk meningkatkan kualitas output penguji Anda jauh lebih cepat daripada jika Anda bekerja tanpanya. (Ini juga banyak membantu dengan penguji jarak jauh) Perangkat lunak khas yang digunakan oleh studio game adalah Mantis, JIRA, (dan banyak lainnya tentu saja ..) Lihat Wikipedia untuk daftar umum dan juga posting ini di SO.
c) Menambahkan alat pengujian ingame Khas adalah Pintasan untuk menguji level atau bagian tertentu dari permainan. Menampilkan informasi tambahan selama pertandingan ke penguji sehingga mereka dapat menambahkan ini ke laporan bug. Ini bisa berupa posisi di tingkat, jumlah objek aktif dalam sebuah adegan, jumlah ram tekstur atau palet yang saat ini digunakan, apa pun yang membantu para pengembang.
d) Gabungkan penguji berpengalaman dengan darah segar Selalu merupakan hal yang baik untuk memiliki penguji yang sangat berpengalaman dengan permainan Anda dan telah belajar apa masalah khasnya dan bagaimana (kembali) mengujinya. Pada saat yang sama Anda ingin pemain "perawan" baru sesekali, terutama untuk menyeimbangkan.
e) Memiliki Test Manager Seseorang yang mengoordinasikan proses dan menyesuaikannya dengan permainan yang ada, prioritas saat ini dan penguji yang tersedia dan lingkungan pengujian.
f) Memiliki Dokumen Rencana Tes Ini akan layak mendapat posting tambahan.
sumber
Seperti yang disebutkan Tetrad, dapatkan sebanyak mungkin data objektif. Memasukkan kait untuk menyimpan acara tertentu dan membuang semuanya ke .csv tidak terlalu sulit. Dan begitu Anda mendapatkannya di Excel, Anda bisa belajar, membuat grafik dan plot sampai sapi pulang.
Juga, ada pertanyaan spesifik yang ingin Anda jawab. Para ilmuwan tidak hanya duduk, menjalankan beberapa percobaan dan "melakukan sains." Mereka memiliki pertanyaan spesifik, terukur yang mereka inginkan tentang data. Anda akan sering mendapatkan hasil maksimal dari tes bermain jika Anda mengambil pendekatan yang sama. Mencoba mengetahui apakah permainan Anda "baik" sangat sulit untuk diukur. Tetapi mencari tahu apakah misi tutorial sederhana hanya memakan waktu 5 menit yang Anda harapkan, atau jika penguji berjuang untuk memecahkan teka-teki tertentu, sebenarnya dapat dievaluasi.
Kadang-kadang, cara paling efektif untuk menguji adalah berulang dalam waktu singkat. Mintalah beberapa penguji untuk sekitar satu jam di pagi hari, buat beberapa perubahan pada masalah yang mereka identifikasi dan lakukan lagi dengan penguji baru di pagi hari berikutnya. Jelas Anda harus melihat fitur yang cukup kecil untuk diperbaiki di sore hari. Tetapi untuk masalah yang sangat keras kepala, metode ini bisa sangat berhasil.
sumber
Pasti Setuju dengan Tetrad's Rule # 1. Jangan bantu mereka. Saya akan mengatakan peringatan adalah untuk menjelaskan kepada mereka bahwa Anda tidak akan membantu mereka, dan jika mereka membutuhkan bantuan untuk bertanya. Dengan cara ini, pemain tidak frustrasi.
Kuisioner harus mengajukan pertanyaan terbuka, alih-alih pertanyaan sederhana ya / tidak, tergantung pada usia dan jumlah penguji, ini bisa berupa formulir yang mereka isi, atau Anda dapat mengajukan pertanyaan. Penting juga untuk mengajukan pertanyaan tentang sejarah mereka dan keakraban mereka dengan genre permainan yang Anda uji; ini akan menambah konteks ke jawaban spesifik mereka tentang game Anda.
Untungnya ketika game saya crash, saya mendapat banyak informasi tentang kesalahan tersebut, jadi saya bisa memotretnya dan mencatat apa yang dilakukan pemain. Biasanya saya menguji kelompok usia yang lebih muda sehingga ketika kita mengalami crash, saya harus ingat untuk menjelaskan kepada mereka bahwa mereka melakukan pekerjaan yang bagus - mereka bisa marah setelah memecahkan permainan. Playtesters benar-benar terbukti hebat dalam menemukan bug yang tidak jelas bahwa tim pengembang tidak akan pernah menemukan permainan dengan cara yang "benar".
sumber
Dimungkinkan untuk menulis kode yang menangkap crash dan mencatat tumpukan panggilan. Itu bisa banyak membantu dengan laporan bug. Memiliki file log yang berguna dihasilkan juga membantu. Anda dapat meminta pengguna untuk mengirim file-file ini pada saat mereka bermain, atau memiliki alat mandiri yang berjalan setelah game ditutup atau crash jika Anda mau.
sumber
Untuk laporan kerusakan, Anda harus mengandalkan staf QA berbayar, bukan playtesters. QA adalah seseorang yang Anda pekerjakan secara khusus karena kemampuan mereka untuk menemukan bug dan melaporkannya dengan cara yang bermakna, dan seorang penguji yang baik sepadan dengan bobot mereka dalam emas (dan hanya berharga sepersepuluh dari beratnya dalam emas, dibandingkan dengan programmer!).
Jika Anda khawatir tentang "oh, bagaimana jika mereka secara tidak sengaja menemukan kerusakan, kami tidak ingin ketinggalan hanya karena mereka tidak menguji untuk itu" ... inilah gunanya penebangan. Sistem pencatatan yang cukup baik harus merekam elemen permainan yang cukup untuk dapat mereproduksi crash secara tepat.
Untuk umpan balik desain, tidak ada pengganti untuk membuat perancang permainan Anda benar-benar menontonnya bermain (atau menggunakan perekam video jika Anda harus, dll.). Jangan mengandalkan memori atau pendapat playtester, yang keduanya terkenal buruk. Tetapi jika Anda melihat mereka bermain dalam waktu nyata, jelas sekali hanya dengan melihat wajah dan postur tubuh mereka apakah mereka bertunangan, bosan, atau frustrasi.
sumber