Як ви отримуєте корисні дані від гейтерів? [зачинено]

Є кілька типів зворотного зв’язку, який ви можете отримати від гейтерів, і мені цікаво, як найкраще зібрати дані для кожного з них ...

1. Звіти про збої. Коли моя гра C ++ виходить з ладу, коли хтось у неї грає, як мені найкраще переконатися, що я знаю про це, а ще краще ... що це спричинило? Навіть отримати щось таке просте, як номер файлу та рядка, що спричинило збій, було б неймовірно корисним.

2. Відгуки про дизайн. Коли тестер грає в гру, як я можу зрозуміти, чи веселяться вони, чому вони розважаються, чому їм не весело, і на що ми повинні витрачати час на коригування?

Я припускаю, що ви говорите про місцевих гейтерів, а не про бета-тестери в Інтернеті.

Правило №1: Не допомагайте їм . Розчарування має бути головним, що ви повинні перевірити. Ідеальною ситуацією було б двосторонне дзеркало з вашою командою на одній стороні та плейстером на іншому з однією відеокамерою на обличчі та іншою на екрані. Очевидно, що це неможливо для більшості людей, тому робіть все можливе. Просто корисна інформація ваших дизайнерів сидіти і дивитися, де люди застрягають. Ви не збираєтеся стояти через плече, коли візьмуть гру додому, тому ви, даючи поради щодо того, як пройти певні розділи, не дадуть вам необхідної інформації. Редагувати : ще один спосіб сказати це: не думайте, що вони "грають неправильно"

Правило №2: Не давайте їм того, що вони хочуть . Після сеансу відтворення у вас є якась анкета, яку вони заповнюють. Конкретні пропозиції, які вони мають, зазвичай не розумно приймати за номінал. Зазвичай є якась першопричина, яка викликає більшість відповідей, і вони просто не знають, як це висловити. Якщо ви зможете це зрозуміти, вам буде краще це зробити. Хоча на даний момент у мене виникають проблеми придумати конкретні приклади.

Правило №3: Дані є королем . Якщо ви можете (а це справді ще один пункт побажань, чесно), відстежуйте все, що можете. Простежте, де вмирають гравці. Відстежуйте, де у них закінчено боєприпаси із конкретного пістолета. Відстежте, які пікапи вони пропускають. Відстежте, які оновлення вони купують. Простежте, як вороги завдають їм шкоди. Очевидно, що це специфічні для FPS приклади, але я впевнений, що існують конкретні домени для будь-якої гри, яку ви робите. Якщо кожен щось робить чи не робить, зазвичай це сфери, на які слід витратити трохи більше часу, дивлячись.

В основному, тобі все одно, що думає гравець . Ви дбаєте про отримання необроблених номерів для того, що роблять гравці . Вам потрібні незаймані очі, щоб побачити вашу гру і розповісти, що їх розчаровує і на що їх ведуть.

На предмет аварій слід розслідувати міндуми . Вони не є ідеальними, але є дуже корисним інструментом для визначення місця аварій.

Також розглянемо вбудований інструмент звітування про помилки. Щось, де користувач може зробити скріншот, додати опис і надіслати його електронному листу автоматично комусь із гри. Ідеально з оглядом світу (наприклад, quicksave або якийсь дамп пам'яті), якщо ваша гра підтримує це.

Щоб розширити дані, це настрої короля трохи (+1 до Тетрада!):

Дослідження запису та відтворення :

• Якщо ваша гра є детермінованою та на основі кадру, можливо, вам потрібно буде зберігати лише початкове випадкове насіння та кордон (key/button state, joystick/mouse coords, frame #)будь-якого часу, коли вхідний стан зміниться. Відтворення настільки ж просто, як і перенаправлення вашого вводу в цей потік. (Ми це робили для багатьох ігор-стрибків на платформі в минулому.)
• Якщо у вашій грі є чітко визначені API чи системи повідомлень для виконання дій (покрокова стратегічна гра, карткова гра, настільна гра тощо), ви зможете просто збирати дзвінки та повідомлення API у певний момент. . (Ми зробили це для карткової гри для портативної платформи.)
• У деяких системах складніше (менш детерміновані, потокові або довільні системи часових кроків можуть бути болем), але можливо, варто зафіксувати дані в будь-якому випадку; ви можете отримати «досить близькі» результати для деяких застосувань.

Система "повтор", заснована на цих методах, має низку переваг:

• використовувати його для відтворення збоїв у налагодженню або іншим способом інструментальної збірки чи середовища;
• повтор завантаження під складання профілю та отримання даних про продуктивність чи використання ресурсів;
• підключіть його до гри, щоб забезпечити функцію «миттєвого перетворення», можливо, за допомогою іншої камери або кроку часу;
• налаштувати ігровий процес демографічного режиму "режим притягування", якщо користувач не дотримується нічого в меню;
• помістіть його у вашу систему збирання як тест на дим: якщо я можу зіграти через цю повтор без збоїв, швидше за все, це буде хороша збірка;
• перегляньте приклади людей, які грають, щоб побачити, що вони робили, а що не робили.

Підключіть випадковий вхід, а не записаний потік, і у вас є чудовий тест на мавпу, що ви можете залишати замочування протягом ночі або коли ваші машини розвитку не працюють.

Далі зробіть деякий запис подій . Для гіпотетичної FPS почніть з чогось типу "час T: X вбив Y у точці Z зі зброєю W": покладіть його в журнал.

Після того, як ви збираєте деякі дані, з’ясуйте, як автоматизувати збір . Він не повинен бути елегантним під час розробки:

• підключитися до сервера SQL і вставити рядки,
• запустіть і забудьте пакети UDP на простому сервері syslog-ish,
• електронною поштою журналу при наступному завантаженні гри,
• просто загортайте виконуваний файл у сценарій оболонки або пакетний файл, який перейменовує та копіює .log файл на загальний спільний диск,
• (пізніше, для створення виробництв) використовуйте Windows Error Reporting або аналогічну службу для збору даних про збої ...

Це насправді не має значення, якщо ви можете збирати дані.

Тепер продовжте це: збирайте звалища, а також записуйте вхідні записи чи події. Додайте більше подій та більше джерел даних:

• випробовуйте позицію чи руку гравця кожні 10 секунд, малюйте її на карті - "ей, ніхто не використовує цей куточок, який я провів тиждень на моделюванні, час, щоб поставити туди живлення"
• getFreeMemoryBytes() кожні півхвилини
• getFPS() періодично
• сфотографуйте або відео, що робить користувач за допомогою веб-камери (відмінно підходить для автоматизованого тестування зручності користування - звичайно, лише з дозволу та розуміння користувача)
• схопити інформацію про систему (знову ж таки, з дозволу користувача)

Річ "побудувати це на карті" через деякий час може стати надзвичайно приголомшливою: передбачте вид з повітря на RTS або FPS. Поставте на неї повзунок, який відображає час з початку гри. Виберіть тип події ("отримав золото", "когось убив", будь-що). Виберіть набір даних: можливо одна гра, можливо 500 ігор за останні кілька місяців. Почніть тягнути повзунок праворуч і дивіться, як активність з’являється на карті.

І якщо ви не можете знайти хороших лайків, які б допомогли вам у цьому (все-таки тут є небагато!), Подумайте про те, як власноруч: це хороший досвід навчання, і він не повинен бути особливо елегантним бути корисним.

Отримайте дані, ви зрозумієте, що з ними робити. =)

Звичайно, це багато в чому залежить від ... а) якого типу тестування ви хочете зробити, і б) якої гри ви тестуєте, і в) якого випробування та інфраструктури у вас є ...

Він також сильно відрізняється, якщо ви тестуєте на а) функціональність, б) врівноваження в) ігровий дизайн

Але загалом ви можете розглянути ці аспекти ...

* a) Виберіть потрібну людину для роботи Звучить занадто просто, щоб згадати, але я бачив її багато разів і просто бачив її в прямому ефірі. Як завжди, між людьми існують значні відмінності щодо того, наскільки вони хороші на різних роботах. Деякі люди, які бажають або, можливо, прагнуть зробити тестування, можуть не грати достатньо ретельно, щоб знайти незвичайні (або навіть прості) помилки. Деякі не добре описують помилки. Деякі кращі у тестуванні питань балансування, деякі уважніші до зорових слабкостей, деякі більш креативні у грі в незвичні способи та виправлення прихованих / рідкісних помилок, деякі більш уважні до технічної чи візуальної якості, деякі краще розуміють аспекти ігрового механіка і може навіть запропонувати змістовні зміни (якщо ви хочете, щоб це зробили ваші тестери;).

* b) Використання програмного забезпечення для відстеження проблем / помилок для відслідковування цих інструментів Ці інструменти можуть не тільки допомогти в організації ваших проблем, а й у підвищенні якості результатів роботи ваших тестерів, надавши їм кадр для роботи всередині та навчаючись на основі зворотного зв’язку. від розробників про їхні проблеми. Це допомагає набагато швидше покращити якість роботи ваших тестерів, ніж якщо ви працюєте без цього. (Це також дуже допомагає віддаленим тестерам) Типовим програмним забезпеченням, яке використовується в ігрових студіях, є, наприклад, Mantis, JIRA, (і, звичайно, багато інших.). Див. Вікіпедію для загального списку, а також цю публікацію про ТАК.

c) Додавання інструментів для тестування iname. Типовими є ярлики для тестування конкретних рівнів або розділів гри. Відображення додаткової інформації під час гри тестерам, щоб вони могли додати цю групу до груп. Це може бути позиція на рівні, кількість активних об'єктів на сцені, кількість текстурних рам або палітри, які зараз використовуються, що-небудь корисне для розробників.

г) Поєднуйте досвідчених тестерів зі свіжою кров'ю Завжди добре мати тестерів, які мають великий досвід у вашій грі та дізналися, що є типовими проблемами та як їх (повторно) перевірити. У той же час ви хочете раз у раз нових «незайманих» гравців, особливо для врівноваження.

д) Майте Тест-менеджера Хтось, хто координує процес та адаптує його до гри, поточних пріоритетів та наявних тестувальників та тестового середовища.

f) Майте документ із тестового плану. Це варте додаткової публікації.

Як згадував Тетрад, отримайте якомога більше об'єктивних даних. Розмістити гачки для зберігання певних подій і скинути їх на .csv не дуже складно. І як тільки ви отримаєте це в Excel, ви можете вивчати, графікувати та планувати, поки корови не повернуться додому.

Також у вас є конкретні запитання, на які ви хочете відповісти. Вчені не просто сідають, запускають експерименти і «займаються наукою». У них є конкретні, вимірні питання, про які вони хочуть отримати дані. Ви часто будете отримувати максимум результатів від тестування, якщо будете використовувати один і той же підхід. Намагатись зрозуміти, чи гра ваша «хороша» дуже важко оцінити. Але з'ясування того, чи не простий місія підручника займає лише 5 хвилин, які ви очікуєте, або якщо тестувачі намагаються вирішити певну головоломку, насправді можна оцінити.

Іноді, найефективніший спосіб тестування - це ітеративні дії на коротких сплесках. Попросіть пару тестувальників пройти годину або близько ранку, внесіть деякі зміни в проблеми, які вони виявляють, і наступного ранку знову перейдіть з новими тестерами. Очевидно, що ви повинні дивитися на функцію, досить малу, щоб покращитись у другій половині дня. Але для проблеми, яка була особливо впертою, цей метод може бути дуже успішним.

Безумовно, згодні з Правилом № 1 Тетрада. Не допомагайте їм. Я б сказав, що застереження - пояснити їм, що ви їм не будете допомагати, і якщо їм потрібна допомога, будь ласка, запитайте. Таким чином гравець не закінчиться розчаруванням.

Опитувальник повинен задавати відкриті запитання замість простих так / ні, залежно від віку та кількості тестувальників це можуть бути форми, які вони заповнюють, або ви можете задавати питання. Також важливо задавати питання про їхню історію та їхнє ознайомлення з жанром гри, яку ви переглядаєте; це додасть контексту їх конкретним відповідям щодо вашої гри.

На щастя, коли моя гра виходить з ладу, це дає мені датчик інформації про помилку, тож я можу сфотографувати це і зробити помітку про те, що робив гравець. Зазвичай я тестую молодші вікові групи, тому, коли ми трапимо аварію, я повинен пам’ятати, щоб пояснити їм, що вони роблять чудову роботу - вони можуть засмутитися після розриву гри. Playtesters справді виявився чудовим у пошуку незрозумілих помилок, що команда розробників ніколи не зіткнеться зіграти в гру «правильним» способом.

Можна написати код, який вловлює збої та записує стек викликів. Це може дуже допомогти у звітах про помилки. Створений корисний файл журналу також допомагає. Ви можете запропонувати користувачеві надсилати ці файли наступного разу, коли вони грають, або мати автономний інструмент, який запускається після закриття гри або аварійного завершення роботи.

Для звітів про аварійну ситуацію слід покладатися на оплачуваного персоналу з контролю якості, а не на плейстерів. QA - це хтось, кого ви наймаєте спеціально для їхнього вміння знаходити помилок і докладно повідомляти про них, а хороший тестер вартує ваги золота (і коштує лише десяту частину ваги золота, порівняно з програмістами!).

Якщо ви переживаєте з приводу "ой, що, якщо вони випадково виявлять аварію, ми не хотіли б пропустити лише тому, що вони не тестують на це" ... це те, для чого ведуть журнал. Досить хороша система ведення журналу повинна записувати достатньо елементів гри, щоб можна було точно відтворити аварію.

Щодо зворотного зв’язку щодо дизайну, заміни на те, щоб ваші ігрові дизайнери насправді спостерігали, як вони грають (або використовуйте відеореєстратор, якщо потрібно тощо). Не покладайтеся на пам'ять чи думку гравців, які обоє є, як відомо, бідними. Але якщо ви спостерігаєте, як вони грають у режимі реального часу, це очевидно, просто дивлячись на їх обличчя та поставу тіла, чи вони заручені, нудьгують чи розчаровуються.