Как сделать игру тест
7 платформ для создания тестов
Получайте новости почтой:
Без тестов сегодня не обходится ни один преподаватель, будь то школьный учитель или профессор многотысячного онлайн-курса. Выбор варианта из нескольких – не единственная возможность: в опросы можно вставлять картинки и видео, менять форматы задания почти до бесконечности. Edutainme выбрали семь сервисов, которые облегчат подготовку и проведение тестирования.
Google Формы
Google Формы — часть офисного инструментария Google Drive. Пожалуй, это один из самых быстрых и простых способов создать свой опрос или тест: пишем задание, выбираем тип ответа (выбор из нескольких вариантов, написание собственного) — готово! Получившийся тест можно отправить студентам по электронной почте или встроить на свой сайт с помощью специального кода. Для ускорения работы рекомендуем добавить плагин Flubaroo — он автоматически проверяет ответы учеников и ставит оценки по заданным критериям. Формы совершенно бесплатны — для использования ресурса нужно только иметь аккаунт Google.
Quizlet
Proprofs
Proprofs готовит тесты на любой вкус — можно предложить на выбор один или несколько вариантов, попросить заполнить пропущенное слово или написать развернутый ответ. Сервис позволяет вставлять в задания текстовые документы и презентации, файлы PDF, а также изображения, аудио- и видеофайлы. Завершив работу над тестом, можно оставить его в общем доступе на сайте Proprofs или встроить на свою страницу.
Kahoot!
Kahoot! позволяет подавать в формате опросов и тестов чуть ли не весь учебный материал. Чтобы наладить обратную связь с учениками, можно обыграть новые темы в форме простых вопросов и ответов, а закрепить знания с помощью более подробного тестирования. Kahoot! рассчитан на применение в классе — преподаватель показывает материал на главном экране, а в это время школьники отвечают на вопросы и обсуждают информацию, используя специальный клиент для компьютеров или браузер на смартфонах (Android, iOS, Windows Phone). Для того чтобы войти в виртуальную классную комнату, ученики должны ввести специальный код, который пришлет преподаватель. Сервис позволяет узнать, как отвечал на вопросы каждый студент, или строить диаграммы успеваемости всего класса. Сами же ученики могут следить за своими результатами в специальных таблицах. Kahoot! бесплатен и полностью доступен после регистрации.
ClassMarker
В ClassMarker можно делать опросы с разными форматами ответов — помимо привычных вариантов, есть даже эссе. Для начала работы преподавателю нужно создать виртуальный класс и разослать пригласительные коды ученикам. ClassMarker хранит результаты всех проведенных тестов, ведя статистику успеваемости. Если у преподавателя есть собственная веб-страница, он может встраивать тестовые задания на нее.
Plickers
Мобильное приложение для преподавателей, помогающее устраивать опросы прямо в классе. Студентам выдаются специальные бланки с вариантами ответов (A, B, C и D) — услышав вопрос, они поднимают нужные карточки, которые учитель сканирует камерой смартфона. Plickers позволяет анализировать результаты отдельного студента или изучать статистику по всему классу. Приложение работает на Android и iOS, а загружается бесплатно.
Easy Test Maker
Бесплатная версия Easy Test Maker позволяет создать 25 тестов без возможности экспорта в «бумажные» форматы. В тарифе Plus ($44.95 в год) доступна проверка англоязычного правописания, создание неограниченного количества тестов и экспорт в офлайн-форматы. С подпиской Premium ($74.95 в год) сервис будет автоматически проверять результаты, а также разрешит выставлять временной лимит на прохождение заданий и прикреплять к опросам графические файлы.
Тестирование игр
Эксперт OTUS Дмитрий Шадрин приглашает всех желающих на бесплатный демо-урок курса «Game QA Engineer», в рамках которого расскажем про то как устроено современное тестирование игр, обсудим перспективы развития специалистов в сфере геймдева, а также рассмотрим основные отличительные черты в тестировании игр.
Чем занимаются тестировщики игр?
Официально вакансия называется QA tester, или, по-русски, тестировщик. QA означает «quality assurance», то есть «обеспечение качества» видеоигры. Эти слова описывают цель работы и отражают разницу между простым прохождением игр и их тестированием.
А суть работы состоит в поиске багов.
Ваша задача при тестировании — сломать игру. Необходимо выловить весь код, который работает неправильно. Для этого проходить игру и проверять ее на прочность нужно весьма изобретательно.
Задумайтесь: в игре масштаба Skyrim возможны миллионы последовательностей действий игрока. Взаимодействия с предметами, персонажами и окружением происходят в разном порядке и разных сочетаниях.
Тестировщик должен перебрать как можно больше таких комбинаций, чтобы проверить, что они работают корректно. А для этого нужно в том числе нестандартно мыслить. Вы должны взаимодействовать с миром неожиданным, даже немыслимым для разработчиков образом. Вспомните известные вам баги в играх. Сразу оговоримся, что существуют халтурные поделки, разработчики которых словно сдались, не доведя работу до конца.
В играх любого жанра найдется бесконечное число багов с предметами и уровнями. Просто потому, что нетипичных игровых действий куда больше, чем могут предвидеть разработчики.
Задача тестировщиков игр — найти максимально возможное число подобных ошибок.
Сколько времени занимает тестирование игры?
Чтобы отловить все баги до единого, тестировщики проверяют абсолютно все возможные комбинации игровых элементов. Возьмем файтинг: каждый из доступных персонажей должен встретиться со всеми остальными на всех существующих уровнях.
Если персонажей в такой игре 12, драка каждого с каждым выльется в 144 матча. Однако уровней тоже больше одного, а значит, 144 драки повторятся на каждой из карт. Всего пять уровней, и вам предстоит уже 720 матчей. Как видите, даже небольшие цифры и ограниченный по функционалу жанр предполагают много дней работы тестировщика.
Если перспектива сыграть в файтинг тысячу раз вас все еще вдохновляет, то вы, наверное, представляете себе свою любимую игру. Скажем, Marvel vs Capcom, Dead or Alive или Mortal Kombat.
Но что если придется взяться за файтинг по мотивам мультика «Кунг-фу Панда»? В играх, которые вам не по вкусу, тоже нужно искать баги! Хватит ли вам силы воли, чтобы вложить сотни часов в тестирование подобного шедевра? Горькая правда такова: как правило, выбирать игры будет кто-то другой. Если повезет, может выпасть увлекательная новинка. Вероятнее всего, обязательства свяжут вас с играми, не вызывающими восторга.
Придется встретиться и с распределением нагрузки. Иные проекты слишком велики, чтобы каждый тестировщик мог пройти их целиком. Поэтому вам выдадут на тестирование определенный фрагмент, и вы должны будете досконально проверить все возможности в этой узкой зоне ответственности — чтобы ваши 10 % игры работали на все сто.
«Тестировать игру» не значит «просто играть», точно так же как «заниматься монтажом кинофильма» не значит «смотреть кино». Вам придется многократно повторять одни и те же действия. Бывает, одну и ту же локацию перепроходишь месяцами!
Монотонность усугубляется тем, что для составления отчета вам нужно суметь воспроизвести любой баг. Даже если ошибка приводит к вылету из игры, но вы не поняли, почему это произошло, отчет не будет иметь смысла. Требуется описать действия, ведущие к повторению бага, до мельчайших деталей, чтобы разработчики смогли их повторить и попытаться исправить проблему.
Впрочем, все вышесказанное не значит, что тестировать игры невыносимо скучно. Это лишь сопоставление ожиданий и реальности.
Вы не будете, развалившись на диване, рубиться в бета-версию Overwatch, раз за разом вынося лузеров и купаясь в лутбоксах. Скорее всего, вам придется, сидя в офисе, час за часом перепроходить один и тот же фрагмент малоизвестной игры, пытаясь ее сломать.
Что должен уметь тестировщик игр?
Давайте поговорим о навыках.
В работе тестировщика невероятно важна внимательность к деталям. Чтобы успешно работать в этой сфере, нужно уметь замечать любые мелочи.
Гибкость мышления тоже пригодится. Придумывать все новые способы сломать игру поможет творческий подход. Главное, не давать порывам вдохновения себя отвлечь.
Значит, нужно развить в себе суперсилу: абсолютное сосредоточение. Чем ближе дедлайны, тем больше у вас работы, и продуктивность нельзя терять ни на минуту. Никогда не знаешь, сколько багов ждет впереди, а надо собрать их все: играть по настроению уже не выйдет.
Не обойтись и без навыков коммуникации. Помните: мало увидеть баг, нужно суметь рассказать разработчикам, как его воспроизвести.
Идеальный отчет об ошибке не должен быть началом долгой переписки с разработчиком. Лучше всего, если единственным ответом на него будет письмо в отдел тестирования о том, что баг исправлен. Никто не любит тратить время на уточняющие вопросы, поэтому способность сразу донести мысль играет решающую роль.
Помните также, что иногда вам придется говорить с самыми разными людьми. Не всеми ошибками занимаются только программисты. Нужно уметь найти общий язык со всеми отделами, разрабатывающими игру. Например, может оказаться, с программистами лучше говорить прямо, без обиняков, а вот в диалоге с художниками могут потребоваться более аккуратные формулировки.
Узнать подробнее о курсе «Game QA Engineer» можно здесь.
Автоматизация тестирования при создании игр
Введение
Автоматизированное тестирование во всю свою мощь используется многими компаниями. Юнит-тесты, Интеграционные тесты, UI тесты, ручное тестирование и прочие методы. Но почему-то в такой большой области, как GameDev автоматизация тестов сводится к тому, что билды передаются в QA отдел на ручное тестирование. Постараюсь рассказать как разрабатываю игры я, и как пишу для них тесты.
Конечно же, всегда есть исключения и во многих компаниях, я надеюсь, каждый билд все же проходит большинство проверок, прежде чем попасть в QA и тем-более к игрокам. К сожалению, мне не довелось поработать в таких компаниях, хоть и выборка небольшая — всего 3 компании сменил за свою карьеру. И в каждой из них тестирование проводилось только ручное (а в первой даже тестировщиков не было, обходись силами — “кто фичу сделал, тот ее и проверяет”)
Об игре
Пару слов о игре — мобильная игра Dungeon. Брождение героями по подземельям, сбор различных полезных вещей, выполнение заданий и прокачка этих самых героев. По описанию не сказать, что игра сложная и в ней много различных фич. Но внутри, как оно обычно и бывает, гораздо все сложнее.
Также о внутренностях игры — движок cocos2d-x-3.17, язык разработки — C++. Большинство тестов — Python. Из используемых сторонних инструментов — TexturePacker (сборка атласов), Spine (скелетная 2d-анимация), Tiled (редактор тайловых уровней). Сюда же стоит отнести Google Spreadsheets (большинство данных игры хранятся в таблицах). Целевые платформы — Android, iOS. Разработка ведется на OS X/Windows.
Команда небольшая — 2 человека. Художник, он же аниматор и я — программист. Геймдизайнера нет, тестировщиков нет. Их работа заменена по большей части генерацией, тестами и прочими скриптами, помогающими нам в процессе разработки. Игра все еще в разработке, уже 1,5 года. Разрабатывается в свободное время и это время ограничено. Потому и пишется много дополнительного кода, позволяющего минимизировать любой рутинный труд
Список тестов, использующих в игре
И несколько вещей, которые постоянно запускаются и помогают мне, как разработчику:
А теперь подробнее о каждом из этих пунктов
Статическая валидация ассетов (верстка, текстуры, прочее)
Учитывая, что разработка ведется на cocos2d-x, и знаком я с ним очень давно, то я не пользуюсь ни одним из их редакторов (Cocos, CocosStudio, CocosBuilder и были еще редакторы вроде как). Не пользуюсь по причине, что они постоянно меняются и их поддержка уходит на нет при обновлении движка на более свежую версию.
Вся верстка игры — xml. Все конфиги — xml. Так уж повелось. Сложно, но универсально. Поддержкой занимаюсь сам, ничего не устаревает, все что необходимо уже написано давно, а если и появляется нужда добавления нового функционала — очень быстро дописывается.
А теперь о том, что проверяется. Каждый объект на сцене описывается одной xml-нодой. Со своими дочерними объектами, свойствами и прочим. Так вот, каждое свойство можно и нужно проверить. Ссылка на текстуру, ссылка на шрифт, указание размера/позиции и прочего. Все просто проверяется, для этого написан небольшой скрипт на Python. Один раз написан, пару раз дополнялся и спасает от всех опечаток, которых хватает при ручном редактировании.
Статическая валидация локалей
С локализацией довольно просто работать, когда она вставляется в игры в конце. Но после этого многое в игре меняется, удаляется и добавляется. Локализаций в игре много, а разработка всегда ведется на одном языке. И если на этом языке можно заметить ошибки при запуске и отладке, то про другие часто забывается.
Для локалей две проверки:
Спасает от случаев: к примеру сделано новое окно с текстом — добавлен ID строки, но не сделан экспорт; изменилась строка, но билд все еще разрабатывается и на перевод отдавать рано — предупреждение при разработке, ошибка при сборке продакшн версии билда.
Статическая валидация уровней
С уровнями тоже все достаточно просто. Есть набор базовых условий из которых состоит уровень, к примеру — должны быть точки входа и выхода из уровня. Должен быть между ними путь, который возможно пройти. Должно быть определенное количество объектов, монстров. Все связи между объектами валидны, все объекты на уровне все еще присутствуют в игре.
Все проверки примитивны, но они хорошо спасают при создании, модификации и поддержки уровня. Удалился объект с уровня, а на нем завязана логика — проверка покажет. Переименовался монстр в конфигах игры, а на уровне забыли — проверка покажет.
Динамическая валидация уровней
Для того, чтобы провести достаточно корректную проверку уровня игровыми же средставами, необходим написать режим автоигры. Авторежим должен поддерживать как можно больше игровых механик (желательно все, но про 80/20 лучше не забывать). Примитивный алгоритм автоплеера — найти задачу, создать команду или список команд для ее достижения и начать выполнять их. При выполнении задачи — повторить, пока не будет завершен уровень и на нем не останется других задач. Что может входить в задачи? Самое простое — завершить уровень, но это слишком абстрактно. Для замкнутых пространств, коими и являются подземелья, это сбор предметов, убийство монстров, открытие замков, решение головоломок. Действия же в большинстве своем более просты. Дойти до точки, взаимодействовать с объектом. Большинство всех действий уже есть в игре, достаточно только дергать соответствующие методы.
Могу привести еще пример. Игра жанра Tower Defense, тоже мобильная. Около 100 уровней, по 2 режима с разными настройками, на уровень уходит в среднем 3 минуты. Проверить все уровни займет 10 часов. При ручном тестировании проверяется несколько начальных уровней, выборочно еще 1-2 в середине игры. В результате постоянно случались баги на уровнях, как значительные, так и нет. Причина проста — постоянное изменение игры, ее контента, добавление и удаление контента.
В какой-то момент был написан механизм для тестирования уровней, довольно примитивный:
Данная проверка запускается на высокой скорости игры, все уровни проходятся в среднем за час в автоматическом режиме. Используется на рабочем проекте уже более трех лет, за это время было найдено много ошибок. И как бонус — решили доработать авторежим и вставить его в игру в качестве новой механики. Игрокам понравилось, все довольны.
Оценочная проверка баланса юнитов/монетизации в Google-таблицах
Тут все проще и сводится к условному форматированию с изменением подсветки явно ошибочных ячеек с данными. Много данных для баланса и монетизации игры рассчитываются по формулам, и уже сложно опечататься. К тому же это гораздо удобнее и нагляднее.
Экспорт данных из Google-таблиц в конфиги игры (с проверками)
Для каждой таблицы есть свой export_
