главная | статьи | гостевая книга | перекресток миров |

О нет! Бета!
Полезные советы и приемы для бета-тестирования игр в разработке

© C.E. Forman
original from: http://www.xyzzynews.com

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

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

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

Предлагая свои услуги

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

Структура отчета тестера

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

Эти четыре секции служат в качестве хорошего метода для анализа и классификации багов:

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

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

Косметические баги. Опечатки, пустые лишние строки и пробелы, и тому подобное. В действительности это не ошибки, но они важны для общего внешнего вида игры.

Общая обратная связь.

Первые три секции должны состоять из соответствующих частей исходного кода игры (бета-тестеры должны _всегда_ оставлять исходный код), скопированных через буфер обмена, с отброшенными ненужными строчками, чтобы уменьшить путаницу. Если баг, о котором идет речь, может быть описан вкратце, часть исходного кода не требуется. При использовании своих собственных слов, а не кода игры, я предпочитаю брать комментарии в квадратные [] скобки, чтобы автору было легче определить, где начинается текст комментария. В любом случае, вставляйте строку из тире или звездочек, чтобы отделять один баг от следующего, для того чтобы сообщение легко читалось. Также, при работе с опечатками полезно использовать символ карата (^) под словом с погрешностью, чтобы просто отметить, где находится ошибка.

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

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

Следуя этим руководящим принципам, вот вымышленный образец отчета, в котором использованы некоторые ранние баги, обнаруженные в моей собственной игре, "The Path to Fortune" (теперь исправленные):

    "The Path to Fortune" Отчет тестирования игры #1

     -------------------------------------------  
     =====================================================
     1 - Программные баги ================================
     =====================================================

     [Я могу открыть заброшенный ангар с помощью любого
     объекта в игре.]

     ----------------------------------------------------
     >наличные
     Вы без гроша
     >з
     Кузница Бортюра
     >наличные
     У вас есть 12 золотых рэнкинов, стандартных денег в ...
     [Я пока не требовал золота.]

     =====================================================
     2 - Проблемы синтаксического анализатора=============
     =====================================================

     >сделать сверток
     Вы должны точно указать то, что вы хотите сделать.
     [Я попробовал каждый глагол, до которого смог додуматься,
     и не могу  добиться, чтобы это работало. Вы уверены,
     что в коде это предусмотрено?]                     
     =====================================================
     3 - Косметические Дефекты ===========================
     =====================================================

     >осм золото
     Что-то в бесформенном самородке золота нервирует вас.
     Когда вы держите его на свету, самородок очень ярко сетится,
                                                         ^^^^^
     [Должно быть "светится"]

     =====================================================
     4 - Общая Обратная связь ============================
     =====================================================

[...и так далее.]

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

Отзывы на отчеты

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

Также в тему разговора об обратной связи: мнения отличаются, и авторы могут не соглашаться со всем, что вы говорите. Они могут иметь очень хорошие причины не хотеть осуществлять некоторые ваши предложения - некоторые каламбуры синтаксического анализатора могут быть большими проблемами, если иметь с ними дело, чем если их не трогать вообще (особенно в случае новых авторов); некоторые решения могут противоречить другим частям игры (которых вы не могли пока видеть). Спрашивайте, если вы не уверены, но не давите на авторов слишком сильно - если они отклоняют и предлагают, по крайней мере, довольно разумное объяснение, пусть будет так.

Обнаружение багов

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

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

Описание локаций. Игрок должен иметь возможность изучить почти все, на что ссылается текст.

"Реверс решения" Среди авторов общераспространено ненамеренно осуществлять односторонний паззл. То есть имеется решение, которое можно логически возобновить или воссоздать, но никакого кода для этого не существует. Примером этого может быть разбивание одного из зеркал в "Enchanter", а затем его восстановление с помощью заклинания krebf (которое, между прочим, работает).

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

"Исследование синтаксического анализатора" Языковые инструменты IF иногда используют два глагола, которые означают одно и то же, хотя ведут себя по-разному ("передвинуть" и "пихнуть" является хорошим примером). Попробуйте выполнить действия, использующие все возможные наборы фраз, какие вы можете придумать.

Контейнеры и поверхности. Объекты, которые могут содержать другие объекты, могут вызвать много проблем (что подтверждается знаменитым (печально знаменитым?) багом с топором-В-ведре в "Unnkulian Underworld"). Убедитесь, что игроки не могут прятать объекты в тех местах, где они не смогут использовать контейнеры или поверхности, и убедитесь, что все такие объекты содержат тот размер и количество вкладываемых предметов, какими они должны быть в "реальном мире". (Большие контейнеры, использующиеся для управления инвентарем, как, например, рюкзак в "Curses", исключение из последнего правила.)

Одушевленные персонажи. Даже простой NPC стремится стать потенциальным источником багов, так что пробуйте все основные взаимодействия с NPC ("поцеловать", "убить", "показать", "дать", "сказать", "бросить", "спросить о" и "просить"). Убедитесь, что вы даете каждому персонажу приказ или даже два.

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

Жидкости. Жидкости в IF должны быть питьевыми (или иметь специальное сообщение, если вы пытаетесь), и быть способными проливаться на землю, литься в другие контейнеры (предположим, они содержат жидкости) и так далее. Проверьте, чтобы убедиться, что игрок не может держать жидкость в руках.

Многошаговые паззлы. Последние игры больше не прибегают к формату "один объект = один паззл" раннего IF. Часто необходимо решить паззл путем постепенного процесса. Как тестер убедитесь, что состояние объектов меняется, когда одна часть задачи решена, чтобы избегать глупого повторения. Примером этого типа дефекта может быть автомат, который выбрасывает пакет чипсов в бункер после того, как игрок бросит монету и нажмет на кнопку. Проверьте, чтобы удостовериться, что, если игрок снова нажимает кнопку, текст для чипсов не появляется вторично.

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

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

Этика игрового тестера

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

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

Сохраняйте свой опыт работы по тестированию конфиденциальным. Это нормально обсуждать с другими бета-тестирование той же игры, но только когда игра выпущена; не сообщайте игрокам о багах, которые вы обнаружили в бета-версии. Авторы не хотят показаться неаккуратными или глупыми игорной публике, и неразборчивое обсуждение багов, которые уже найдены, может заставить их так себя чувствовать. (Опять же, пусть автор сам начнет разговор подобного рода, если ему этого захочется.)

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

Не давайте подсказки в Usenet'е для игр, которые вы протестировали...по крайней мере, ненадолго. Вы уже, без надобности, увидели путь прохождения, а другие игроки - нет. Дайте им время, чтобы поставить вещи на свои места и чтобы сначала помочь друг другу, а не портя игру и тяжелую работу автора прямо в начале. (По тем же причинам дождитесь нужного момента для написания прохождения или подсказок для игры. И даже если так, убедитесь, что у вас есть согласие автора.)

Вывод

Тестирование игр может быть таким же болезненным процессом для автора...но так не должно быть. С небольшим дополнительным усилием со стороны тестера, это может быть приятным и полезным опытом для обеих сторон.

содержание