Б.Н.М. Глава 12. Тесты

1. Что не получится тестировать, а что нужно обязательно?
   - Без доигрового тестирования
   - С доигровым тестированием

2. Что значит тесты на ролевых играх и как их проводить?
   - ИТ и связь
   - Сложные модели
   - Боевая модель
   - Игротехнические взаимодействия
   - Текст правил

Что не получится тестировать, а что нужно обязательно?

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

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

Без доигрового тестирования

У тебя не выйдет оттестировать сюжет игры, пока в него не поиграют реальные игроки в реальных условиях. Всё это может дать тебе не более, чем общие данные. Ты не поймешь, верная ли у игры атмосфера, пока игра не начнется. Да и модели на полигоне могут повести себя совсем не так как на тесте. Все это означат, что нужно внимательно прислушаться к тому, что Кратос повторял Атрею из раза в раз: «Stay focused!». Подходить к началу самой игры ты должен с острым умом, готовым к любым внезапностям и поворотам. Иначе то, как дела повернутся на полигоне, может ввести тебя в ступор, потому что тесты притупили чувство опасности. Помни, дорогой мастер, что многие вещи не поддаются прогнозированию. Но даже там, где поддаются, ты должен помнить «это оттестировано ≠ здесь всё схвачено».

С доигровым тестированием

Теперь поговорим о том, что на твоей игре оттестировать можно и нужно.

Во-первых, все ИТ системы и системы связи. Важно оттестировать их в условиях, максимально приближенных к реальным. Минимум за месяц до игры, чтобы было время внести без суеты правки. Без данного теста максимальная вероятность того, что ваши ИТ и связь на игре пойдут по известному месту. Повезет, если они просто будут работать.

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

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

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

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

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

Что значит тесты на ролевых играх и как их проводить?

Выше описано, что стоит тестировать, если есть такая возможность. Еще раз:

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

Как тестировать ИТ и связь?

В главе 3 “Команда и мастерская группа” описаны, какие специалисты вам могут пригодиться, чтобы организовать ИТ. Посоветуйтесь с ними, как бы они проверили, что все работает.

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

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

Тестирование ИТ может начинаться, когда готова минимальная жизнеспособная версия (MVP). Тестирование ИТ должно быть закончено за значительный срок до игры. На этапе планирования сразу примите решение, какой это конкретно срок. Наша рекомендация - минимум месяц до игры. Если к этому времени у вас нет на 90% работающего ИТ (а мы верим, что за месяц можно либо доделать 10%, либо что и без этих 10% окнорм), у вас на игре вместо ИТ будет испанский стыд. Главный мастер должен быть готов к тому, что мастера по ИТ будут с жаром убеждать его, что они все успеют в последний момент. Это когнитивное искажение, мастера по ИТ хотят убедить сами себя, что столько времени и сил не было потрачено впустую. Не верьте им в моменте. Верьте им с этапа планирования, если тогда вы вместе договорились, что есть точка невозврата - значит так оно и есть.

Если ИТ система поддерживает основную модель игры, без нее игра встанет, рассмотрите такие варианты:

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

Помните, что, если вы не рассмотрите эти варианты самостоятельно, вас советами замучают все вокруг.

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

Несколько примеров. Сначала про связь. На одной игре про современность (год проведения игры совпадал с годом игровый событий), мы хотели все модели максимально завязать на ИТ. Телефоном игрок считывал QR-коды, в веб приложении игрок отмечал, какие действия он сделал, там же читал эффекты, которые получил из-за своих действий или от посещенных локаций (где считал QR-ки). Полигон большой, включал: а) домики, внутри которых работал wifi, б) улицы, на которых не было wifi, но был хороший прием разных мобильных операторов, в) лес, где принимал только один мобильный оператор. Нам было важно, чтобы игрок мог играть везде. Игра была в ноябре. В феврале до начала разработки ИТ-систем, наш мастер обползал весь полигон и выяснил, что полигон делится на три описанные выше зоны. По итогу он порекомендовал нам мобильного оператора, который ловит везде. Мы решили купить всем игрокам симки этого оператора. Задача ушла мастеру АХЧ, когда в марте мы объявили размер взноса, в него были заложены деньги на симки. И только когда мы убедились, что на полигоне будет стабильное интернет-соединение, мы начали планировать разработку ИТ. Мораль: все молодцы, делайте как молодцы.

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

И еще про ИТ систему. Для игры про современность, мы подняли свою социальную сеть. Нам было важно полностью ее контролировать, иметь возможность самим следить, что пишут игроки, и давать доступ к этой переписке игрокам с абилкой “хакер”, поэтому решили делать свою разработку, а не создать дубль-профили в ВК или какой-то другой социальной сети. За 2 месяца до игры социальная сеть заработала и мы начали тестировать ее внутри мастерской группы. Все было хорошо. За месяц до игры мы завели в ней профили всем игрокам и дали им доступ. Социальная сеть упала, нагрузочный тест показал, что она выдерживала онлайн 20 пользователей, но не выдерживает 100 пользователей. Мы порадовались, что есть время на исправления, все исправили. За 2 недели до игры социальная сеть работала и в ней резвились игроки в образе своих персонажей. Мы счастливо сделали бекап и приготовились ждать игру. На второй день игры социальная сеть упала из-за [неразборчиво на программистском]. У нас был бекап только 2х недельной давности, к нему мы и откатили. Мораль: делайте бекапы почаще, лучше автоматизируйте бекапы.

Как тестировать сложные модели?

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

а) Первое. Мысленные эксперименты. Этого слона можно поделить и съесть по частям. И поможет тут метод мысленного эксперимента, известный в народе также как “методика прикладывания хера к носу”.

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

• В каких сценариях что-то сломалось в игре? Это влияет на что-то критичное? (Нет, ну и забейте.) Насколько вероятно, что это произойдет на игре? (Высокая, средняя или низкая вероятность, обязательно исправьте. Ничтожно низкая вероятность, забейте, потратьте конечную мастерскую мощь на что-то другое.) Как это исправить?
• В каких сценариях одни игроки получают преимущество перед другими? Какие дыры есть в модели? Порождает ли она дисбаланс в игре? Порождает ли модель рулежку? Как это исправить? (Дисбаланс и дыры в моделях - повод для богатых срачей, изничтожайте дисбаланс столько, сколько хватит вам сил.)
• Чтобы эта модель минимально работала на игре, какие приготовления нужно сделать? Напечатать тексты, облепить всех игротехников золотыми блестками, привезти на полигон настоящую лошадь, какающую бабочками - что именно? Есть ли у вас все для обеспечения этой модели? Хватает ли вам на это денег? Знают ли про эти расходы ваш мастер АХЧ? А знает ли ваш мастер игротехники про дополнительные приготовления? Есть ли у него нужное количество игротехников? (Если этот ворох вопросов вызывает у вас мычание и упорное смотрение в стену, с вашей моделью все плохо, она не будет работать, надо все переделать.)
• Написаны ли простые и понятные инструкции к сложной модели? Их точно понимает кто-то кроме ее автора? (Если нет, переделывайте, пока не поймет кто-то еще.)

б) Второе. Классические тесты. Не делите слона на части, не прикладывайте ничего мысленно к носу. Проведите сыгровку, выстроенную вокруг модели. Проведите сбор с игроками по модели. Привезите на ролевой конвент мероприятие под название “Тестируем нашу сложную модель вместе”. Все эти подходы работают и действительно помогут сделать вашу сложную модель играбельнее, но при одном условии. Все время проведения сыгровки, сбора или мероприятия на конвенте, несколько ваших мастеров, понимающих модель, фиксируют, что и как надо исправить, а также после теста собирают фидбек с его участников. Потом ваши мастера, понимающие модель, составляют календарный план доработки ошибок. И дорабатывают сложную модель.

Сам факт проведения теста не улучшает модель, только кропотливая работа с итогами теста, только хардкор, сделают вашу сложную модель играбельнее.

Задача тестов - сделать модель лучше, а не научить игроков играть правильно в вашу модель. Это так не работает. Вместо споров с игроками, улучшайте модель.

Как тестировать боевую модель?

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

На полигоне могут быть овраги или ямы. На базе могут быть хрупкие дорогостоящие предметы. Нужна проверка на дурака.

Как тестировать игротехнические взаимодействия?

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

Как тестировать текст правил?

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

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

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

…

И помните, деление на “можно оттестить” и “нельзя оттестить” условное. Все равно только сама игра будет альфа-тестом, прогнать заранее и оттестировать абсолютно все не выйдет никак. Даже одна и та же игра за несколько прогонов может быть совершенной разной, так как помимо мастеров ее делают еще и игроки. Хотя, конечно, если вы ставите одну игру несколько раз или же, например, сериальные игры по общим принципам - то от игры к игре вы сможете отшлифовать все свои слабые места.

Контент распространяется по лицензии Creative Commons (CC BY-SA). Как указывать авторов: Больше не мастерю и другое вранье, 2022. Екатерина (КошкинС) Кулдина, Максим (Margulix) Панкратов, Юрий (Yarrow) Вишняков. vk.com/bnmidv