Как вы получаете полезные данные от Playtesters? [закрыто]

Есть несколько типов отзывов, которые вы можете получить от плейстеров, и мне интересно, как лучше собрать данные для каждого из них ...

1. Отчеты о сбоях. Когда моя игра на C ++ падает, когда кто-то в нее играет, как мне лучше убедиться, что я знаю об этом и даже лучше ... что вызвало это? Даже получение чего-то такого простого, как файл и номер строки, вызвавшей сбой, было бы невероятно полезным.

2. Обратная связь Когда игровой тестер играет в игру, как я могу выяснить, веселятся ли они, почему они веселятся, почему они не веселятся, и на что нам следует потратить время, чтобы приспособиться?

Я предполагаю, что вы говорите о тестировщиках на сайте, а не о бета-тестерах в Интернете.

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

Правило № 2: не давайте им то, что они хотят . После сеанса тестирования у вас есть какая-то анкета, которую они заполняют. Конкретные предложения, которые у них есть, обычно неразумно принимать за чистую монету. Обычно есть какая-то первопричина, которая вызывает большинство ответов, и они просто не знают, как это выразить. Если вы можете понять это, вам будет лучше сделать это. Хотя в данный момент у меня возникают проблемы с конкретными примерами.

Правило # 3: Данные короли . Если вы можете (и это действительно еще один список пожеланий, если честно), отследите все, что можете. Трек, где умирают игроки. Отследите, где у них кончаются патроны от конкретного пистолета. Отслеживайте, какие пикапы они пропускают. Отслеживайте, какие обновления они покупают. Отслеживайте, какие враги наносят им урон. Очевидно, это специфичные для FPS примеры, но я уверен, что есть конкретные для каждой игры, в которую вы играете. Если все что-то делают или не делают, обычно это те области, на которые вам следует потратить немного больше времени.

По сути, вам все равно, что думает игрок . Вы заботитесь о получении необработанных чисел за то, что делают игроки . Вам нужны девственные глаза, чтобы увидеть свою игру и сказать, что их расстраивает и к чему их ведут.

Для сбоев исследуйте мини-дампы . Они не идеальны, но очень полезны, чтобы выяснить, где происходят сбои.

Также рассмотрите встроенный инструмент сообщения об ошибках. Что-то, где пользователь может сделать снимок экрана, добавить описание и автоматически отправить его по электронной почте кому-то из игры. Идеально с моментальным снимком мира (например, быстрое сохранение или какой-то дамп памяти), если ваша игра это поддерживает.

Расширить данные - немного король настроения (+1 к Тетраду!):

Исследовать запись и воспроизведение :

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

Система «воспроизведения», основанная на этих методах, имеет ряд преимуществ:

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

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

Затем сделайте запись некоторых событий . Для гипотетического FPS начните с чего-то вроде «время T: X убило Y в точке Z с оружием W»: поместите это в журнал.

Как только вы соберете некоторые данные, выясните, как автоматизировать сбор . Это не должно быть элегантно во время разработки:

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

Не имеет большого значения, пока вы можете собирать данные.

Теперь расширьте его: собирайте аварийные дампы, следы стека и записи ввода или событий. Добавьте больше событий и больше источников данных:

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

«Поместить его на карту» может через некоторое время стать действительно потрясающим: представить вид с воздуха на карту RTS или FPS. Положите на него ползунок, представляющий время с начала игры. Выберите тип события («получил золото», «убил кого-то», что угодно). Выберите набор данных: возможно, одну игру, возможно, 500 игр за последние несколько месяцев. Начните тянуть ползунок вправо и наблюдайте, как игра всплывает на карте.

И если вы не можете найти хороших библиотек, которые могли бы помочь вам с этим (хотя их здесь и там немало!), Подумайте о том, чтобы кататься самостоятельно: это хороший учебный опыт, и он не должен быть особенно элегантным. быть полезным.

Получите данные, вы поймете, что с ними делать. знак равно

Конечно, это во многом зависит от ... а) какого рода тестирование вы хотите провести, и б) какую игру вы тестируете, и в) какие тестеры и инфраструктуру вы имеете в наличии ...

Это также сильно отличается, если вы тестируете на a) функциональность, b) балансировку c) игровой дизайн

Но в целом вы можете рассмотреть эти аспекты ...

* а) Выберите подходящего человека для работы. Звучит слишком просто, чтобы упоминать, но я видел это много раз и просто видел его снова вживую. Как всегда, между людьми существуют значительные различия в том, насколько они хороши на разных работах. Некоторые люди, которые хотят или, возможно, хотят пройти тестирование, могут не играть достаточно тщательно, чтобы найти необычные (или даже простые) ошибки. Некоторые не очень хорошо описывают ошибки. Кто-то лучше тестирует проблемы с балансировкой, кто-то более внимателен к визуальным слабостям, кто-то более изобретателен в игре необычными способами и находит скрытые / редкие ошибки, кто-то более внимателен к техническому или визуальному качеству, кто-то лучше разбирается в аспектах игровой механики и может даже предложить значимые изменения (если вы хотите, чтобы ваши тестеры сделали это;).

* b) Используйте программное обеспечение Issue-Tracker / Bug-Tracker. Эти инструменты могут помочь не только в организации ваших проблем, но и в повышении качества результатов ваших тестировщиков, предоставляя им рамки для работы в рамках и извлекая уроки из обратной связи, которую они получают. от разработчиков о своих проблемах. Это помогает улучшить качество вывода ваших тестеров намного быстрее, чем если бы вы работали без него. (Это также очень помогает с удаленными тестерами). Типичным программным обеспечением, используемым игровыми студиями, является, например, Mantis, JIRA (и, конечно же, множество других). См. Общий список в Википедии, а также этот пост на SO.

c) Добавить инструменты для тестирования в игре. Обычно это ярлыки для тестирования определенных уровней или разделов игры. Отображение дополнительной информации во время игры для тестировщиков, чтобы они могли добавить ее к сообщениям об ошибках. Это может быть положение на уровне, количество активных объектов в сцене, количество используемых в настоящее время текстурной памяти или палитр, что-нибудь полезное для разработчиков.

г) Объединяйте опытных тестеров со свежей кровью. Всегда хорошо иметь тестеров, которые имеют большой опыт в вашей игре и узнали, каковы типичные проблемы и как (повторно) протестировать их. В то же время вы хотите, чтобы новые «девственные» игроки время от времени, особенно для балансировки.

e) Иметь менеджера по тестированию. Тот, кто координирует процесс и адаптирует его к текущей игре, текущим приоритетам и доступным тестерам и среде тестирования.

f) Имейте документ плана испытаний. Это будет стоить дополнительного поста.

Как упоминал Тетрад, получите как можно больше объективных данных. Вставить хуки для хранения определенных событий и выгрузить их все в .csv не очень сложно. И как только вы получите его в Excel, вы можете изучать, строить графики и строить графики, пока коровы не вернутся домой.

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

Иногда самый эффективный способ тестирования - итеративный, короткими пакетами. Попросите пару тестеров пойти на час или около того утром, внесите некоторые изменения в выявленные проблемы и снова отправьтесь с новыми тестерами на следующее утро. Очевидно, вы должны смотреть на функцию, достаточно маленькую, чтобы улучшить ее во второй половине дня. Но проблема, которая была особенно упорной, этот метод может быть очень успешным.

Определенно согласен с правилом № 1 Тетрада. Не помогай им. Я бы сказал, что предостережение состоит в том, чтобы объяснить им, что вы не будете им помогать, и если им нужна помощь, пожалуйста, спросите. Таким образом, игрок не будет разочарован.

Анкета должна задавать открытые вопросы, вместо простых, да / нет, в зависимости от возраста и количества тестеров, это могут быть формы, которые они заполняют, или вы можете задать вопросы. Также важно задавать вопросы об их истории и их знакомстве с жанром игры, которую вы тестируете; это добавит контекст к их конкретным ответам о вашей игре.

К счастью, когда моя игра вылетает, она дает мне кучу информации об ошибке, поэтому я могу сфотографировать ее и записать, что делал игрок. Обычно я проверяю младшие возрастные группы, поэтому, когда мы сталкиваемся с аварией, я должен не забывать объяснять им, что они делают отличную работу - они могут расстроиться после нарушения игры. Playtesters действительно доказали свою способность находить неясные ошибки, которые команда разработчиков никогда не встретит, играя в игру «правильным» способом.

Можно написать код, который перехватывает сбои и регистрирует стек вызовов. Это может помочь с отчетами об ошибках. Создание полезного файла журнала также помогает. Вы можете предложить пользователю отправить эти файлы в следующий раз, когда они играют, или иметь автономный инструмент, который запускается после закрытия игры или сбоя, если хотите.

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

Если вы беспокоитесь о «о, что, если они случайно обнаружат сбой, мы не хотим пропустить это только потому, что они не проверяют это» ... вот для чего нужна регистрация. Достаточно хорошая система регистрации должна записывать достаточно элементов игры, чтобы точно воспроизвести сбой.

Что касается обратной связи с дизайном, ничто не заменит того, чтобы ваши игровые дизайнеры действительно смотрели, как они играют (или, если нужно, используйте видеомагнитофон и т. Д.). Не полагайтесь на память или мнение плейстера, оба из которых, как известно, бедны. Но если вы смотрите, как они играют в режиме реального времени, это становится очевидным, если просто посмотреть на их лицо и осанку, независимо от того, заняты они, скучны или разочарованы.