Тестирование ролевых игр, Набросок методологии Опции

[Чих]

На прошедшем Менесконе в кулуарах была поднята важная тема: тестирование ролевых игр. В двух словах: тестер может прочитать игровые материалы и указать мастеру на очевидные дырки и проколы, которые обязательно испортили бы игру.
Казалось бы, всё просто: дай тестировщику все материалы и спроси его, что кажется ему плохим. Но в таком подходе есть несколько значительных недостатков:
1. При таком подходе тестирование практически невозможно распараллелить на несколько человек. Если мы нашли нескольких тестировщиков, мы хотим, чтобы каждый занимался своей частью работы. Сразу возникает куча вопросов про границы сфер ответственности, видение общей картины и так далее.
2. Тестировщик может вообразить себя мастером и начать давать указания, как бы он сделал эту игру. Естественно, мастер этого не потерпит, в результате возникнет конфликт на пустом месте и игра останется без тестировщика. Возникают вопросы про границы юрисдикции тестера, про формальный список вещей, которые он делать не вправе.
3. Материалы скорее всего не отображают мастерское видение игры во всей полноте. Большая часть игры находится у мастера в голове, и тестировщик должен задавать много вопросов, чтобы увидеть эту картину. Какие именно вопросы задавать? Как потом делиться этой информацией с другими тестировщиками и членами мастерской группы? Вообще, правила взаимодействия тестеров и разработчиков игры - это очень важный пункт, и бывает очень полезно иметь набор формальных правил.
4. Как документировать найденные баги, чтобы мастерская группа о них не забыла?
5. Что считать багом?

Итак, давайте попробует выработать какую-то методологию тестирования ролевых игр, которая смогла бы избавиться от перечисленных недостатков.
1. Любое тестирование должно начинаться с общего сбора мастеров и тестеров и большого обсуждения концепции игры. Такие сборы следует время от времени повторять, но не делать слишком часто, чтобы участники не начали их игнорировать. Цель таких сборов - выработать и поддерживать общее видение игры. Тестер должен понимать, зачем мастер сделал ту или иную вещь.
2. Должен быть изначально определён порядок обмена информацией. Где хранятся новые легенды, информация о найденных багах, где можно задавать мастерам вопросы. Для этих целей можно организовать выделенный сайт (форум, вики и т.д.), причём его желательно сделать до первой встречи команды.
3. Мастер должен чётко знать, чего он хочет от тестеров. Какие найденные ими вещи он будет исправлять, а какие он считает своим мастерским видением. Насколько глубокие корректировки сюжета он готов сделать по совету тестеров.
Тестер должен чётко знать, какой фидбэк он получит. Будут ли все его замечания учтены, или мастер оставит за собой право игнорировать любые найденные баги. В каких областях более вероятен первый вариант, а в каких - второй.
Эти вопросы необходимо сразу открыто обговорить, чтобы избежать недопонимания и обид.
К примеру: тестер считает, что из определённого набора информации игрок не сделает правильного вывода (потому что информации недостаточно), и его игра провиснет. Мастер может дать игроку больше информации, а может заявить, что в такой ситуации игрок сам виноват.
Другой пример: тестер считает, что данный поворот сюжета неинтересный, и предлагает свой вариант. Мастер может согласиться, а может возразить, что это его игра и только он делает сюжет.
Третий пример: тестер утверждает, что нашёл дырку в технических правилах, из-за которой драка в определённых условиях может выродиться в спор о правилах. Мастер может изменить правила, а может посчитать, что такая ситуация маловероятна, а изменения правил сделают их хуже и запутанее в обычных ситуациях.
4. Разным тестерам можно раздавать разные задачи:
a ) Тестирование технических правил
b ) Поиск грамматических и стилистических ошибок в игровых документах
c ) Проработка определённой сюжетной линии: изучение легенд персонажей, замешанных в ней, построение дерева вариантов, как может развиваться данная сюжетная линия в тех или иных условиях. В случае, если какой-то вариант ведёт к провалу игры для каких-то игроков, тестер предлагает мастерам поменять вводные, чтобы этот вариант исключить.
d ) Проработка взаимодействия сюжетных линий: тестер получает от других тестеров материалы по их сюжетным линиям, складывает варианты развития разных сюжетов, находит варианты, которые ведут к проблемам, предлагает мастерам придумать аварийные планы действий для вот таких и таких ситуаций.
e ) Борьба со скукой игроков: тестер ищет варианты развития игры, при которых игрокам будет скучно. Найденные баги выглядят так: команда А проведёт 3 часа в засаде на заброшенной стройке Х, надо дать им событий на эти 3 часа. Или игрок Б будет сидеть связанный в плену команды А целый вечер на локации У, надо придумать ему развлечения, но при этом не испортить игру команде А, которая долго и усердно ловила игрока Б.
f ) Тестирование скриптовых сцен: тестер должен поставить себя на место игрока и представить, каким нестандартным образом игрок может себя повести. Мастер должен подкорректировать скриптовую сцену в соответствии с придуманными вариантами.
UPD by avis_alba:
g ) Тестирование полигона на соответствие требованиям (расстояние между локациями, наличие подходящих полянок/буреломов/руин
h ) Тестирование времени и дат: если событие произошло в таком-то году, то во всех легендах указан именно этот год. Аналогично: если событие произошло в таком-то городе, то во всех легендах указан именно этот город. И т.д.
5. Мастер должен чем-то мотивировать тестировщиков. Их энтузиазм очевидно меньше, чем у мастера, и он должен его поддерживать: устраивать мотивирующие пьянки, поимённо благодарить и хвалить тестеров в теме игры на форуме, проводить между ними соревнование на звание самого продуктивного и т.д. В противном случае эффективность их работы будет близка к нулю. Если сомневаетесь, вспомните, с какой скоростью у нас пишут легенды к играм.

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

Сообщение отредактировал Чих - Понедельник, 21-oe Мая 2012, 17:04

[Molly]

Молодец, что сформулировал и выложил. Особенно радует пассаж про мотивацию.

[Heruer]

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

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

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

[Mapa]

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

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

[Чих]

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

Leanora
Понятное дело, что придумать, как исправить проблему - это задача разработчиков. Но сначала тестеры должны указать, что есть проблема, которую надо исправить. И проблемы надо искать всюду, в том числе в перечисленных пунктах.

Molly
Спасибо

Heruer
Тестер должен понимать и быть заранее согласным, что его советы могут быть проигнорированы. Это обязательно нужно обговорить. Иначе он может со словами "ну и нахрена вы меня тогда вообще позвали" уйти обиженным.

Mapa
Насчёт "перегореть". Я глубоко убеждён, что процесс производства игры - это тяжёлая рутинная работа, которая очень быстро надоедает. Мне кажется, каждый хороший мастер ненавидит свою игру на финальных стадиях её разработки. Если остановиться, когда тебе надоело - то игра будет сырой и недоделанной (что мы часто можем наблюдать на практике). Мастер и его команда должны быть морально готовы пахать, чтобы сделать хорошую игру. А это значит - регулярные встречи и обсуждения, перепроверки одного и того же, тупая работа до изнеможения, пока наконец количество не перейдёт в качество.
Возможно, я неправильно понимаю, как делаются ролевые игры. Тут не может быть единого общего мнения, у каждого своё дао.

[avis_alba]

Несколько вопросов на поразмыслить:

1. Когда игру считать достаточно отлаженной, чтобы в неё уже можно было играть? Как определить, что тестировать и отлаживать уже "достаточно"?

2. Что вы думаете по поводу моделирования - как тестового прогона всей игры (если она небольшая), так и имитации отдельных её аспекетов (например, тестирование боевых правил путём пробной игровой драки/боя, тестовый выезд на полигон для проверки времени перемещения между локациями и т.п.)?

Сводные таймлайны по основным событиям в легендах и сюжетах могут быть полезны. Когда мы с 4ертом писали игру для поездки в Осло, он заставил меня в легендах делать следующую вещь: прописывать все даты не как "5 лет назад", а "в таком-то году". В итоге это очень сильно упростило сверку легенд и сюжетных линий на непротиворечивость. Этакий тестинг в процессе написания.

[Mapa]

2 Чих

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

Рутинная надоевшая работа - это неизбежный этап, наступление которого можно оттягивать различными способами. Чем больше будет сделано до того, как "работа, которая плющит" перейдёт в "работу, котрая заколебала" - тем больше имхо шансов на то, что проект состоится.
Но каждому своё дао, это да.

2 Альба
п.2 очень зачётен. но вроде тестовые выезды на полигон, чтобы всё отсмотреть и замерять и так все делают... или это я так наивно полагаю?

[Ронин]

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

Единственным и достаточным условием плодотворного сотрудничества в подобном формате является авторитет "тестера" в глазах мастера, причем не авторитет вообще, а в конкретной области знаний. Без этого условия никакая система работать не будет, с другой стороны система особо и не нужна, если это условие выполнено - люди которые друг другу доверяют примерно представляют сильные и слабые стороны коллеги, и знают, чем он может помочь, а чем лучше не надо. Вести дела с посторонними людьми, которые будут искать сто способов почитерить или думать в направлении как бы испортить игру - как по мне не верно идеологически. Лучше потратить эти усилия и время на работу с игроками, в которых сомневаешься, и убедить их вести себя прилично. А всех дырок все равно не закроешь.

[Noiseless]

Насколько я понимаю, есть прецеденты по пунктам a, b, f, g Чиха. Эти вещи хотя бы можно формализровать.

А насколько продуктивным оказывается "битие мыслью" в вопросах сюжета, напряженности игры, логики игроков и их возможных действий - собственно, поиск потенциальных дыр в самом теле лайв-экшена?

[Heruer]

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

[Декстер]

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