«Вагон-вагон»: клубок технологий внутри простой текстовой игры, часть вторая

Продолжение рассказа о создании интерактивной новеллы для мобильных телефонов.

Сценарные и визуальные тесты, перевод на английский, сборка мобильного приложения, тягучее болото плагинов для Apache Cordova и страдания при заливке в AppStore.

Первую часть статьи читайте здесь.

“Вагон-Вагон” - это на первый взгляд простая текстовая игра. Разработку начинали с нуля, финальной целью поставили релиз на мобильных телефонах. Важной промежуточной точкой выбрали конкурс русскоязычной интерактивной литературы - КРИЛ-2017. К нему хотели подготовить полноценную веб-версию и узнать реакцию настоящих игроков, которые лично с нами незнакомы.

Для создания веб-версии я решил использовать:

Также выделил отдельно связующий слой игровой логики и назвал его GameLogic. Сам слой писал на Python, транслировал в JavaScript с помощью конвертера Transcrypt.

Прежде чем продолжить, нужно сказать пару слов о структуре игры. Эта структура окончательно сформировалась к КРИЛ и позже почти не менялась.

В каждой попытке изменить судьбу главных героев есть четыре развилки. В каждой развилке игроку нужно сделать выбор из трёх вариантов развития диалога. Наивный подсчёт показывает, что общее число путей прохождения игры: 3*3*3*3=81. Эти пути ведут к семи различным концовкам. Плюс есть длинная “истинная” концовка, которая открывается только тогда, когда все обычные концовки открыты. Плюс есть две первых особых попытки изменить судьбу, когда игрок только знакомится с игрой, и число вариантов выбора ограничено.

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

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

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

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

Нас выручили автоматические тесты. Но уже не юнит-, а тесты более высокого уровня, сценарные. Для них я использовал фреймворк Jasmine. Фактически я сделал урезанную html-версию игры без визуальной части (Ink + GameLogic), запустил её в браузере и стал прогонять на ней различные игровые сценарии. Jasmine предоставил для этого необходимую инфраструктуру.

Сценарии, на которые написал тесты:

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

Альтернатив Jasmine много, но я их не изучал. Решающим фактором стало то, что установить Jasmine можно через PyPI (Python Package Index). Для меня это самый быстрый и естественный способ установки, так как основная часть игры написана на Python.

Хорошо, я более-менее застраховался от ошибок в игровой логике и в истории, но как быть с ошибками в визуальной части? Что если я неправильно создал кнопку в Phaser, или текст исчез после открытия занавеса и не появился обратно (реальный случай)? Опять же, чем раньше я узнаю, что после очередного моего изменения в коде что-то в графике испортилось, тем быстрее смогу найти причину ошибки. А каждый раз запускать браузер и протыкивать все варианты скучно и долго.

Для этого есть визуальные тесты. Мы выводим в браузер ровно то, что видит игрок, и эмулируем его действия: нажатия на кнопки, прокрутку и т.д.. Проверяем, что реакция игры на эти действия соответствует ожиданиям.

Часто графическая библиотека предоставляет внешний интерфейс для обращения извне к графическому интерфейсу. Например, для обращения к окнам Windows есть механизм Windows Messages.

В Phaser, к сожалению, ничего подобного нет. Тут надо уточнить, что я использую Phaser 2, а в Phaser 3 автор движка обещал над этой проблемой поработать. Надо будет проверить, получилось у него или нет.

Так или иначе в то время, когда я готовил “Вагоны” к конкурсу, Phaser 3 ещё не вышел, и у меня была единственная альтернатива - тесты на основе распознавания образов.

Принцип таких тестов простой: делаем скриншоты объектов/кнопок, назначаем для этих объектов определённые действия игрока (нажатия, перетаскивания и т.д.), формируем из этих действий последовательность, дальше запускаем игру и пытаемся эту последовательность выполнить. Если на каком-то шаге нужного объекта на экране не нашлось, значит, тест завершается с ошибкой.

SikuliX - отличная программа для формирования и запуска таких тестов. Бесплатных альтернатив я не нашёл.

Самое впечатляющее в этих тестах это то, как они выглядят в редакторе. Наглядней некуда.

Но практической пользы от них мало. Вот почему:

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

Мой вывод: для визуальных тестов нужно иметь движок с их хорошей поддержкой. Для игры небогатой на графику и визуальные игровые механики, вроде нашей, внедрение таких тестов - лишняя трата времени.

Кстати, больше всего крови выпили у меня ошибки даже не в графике, а в звуке: зацикливание, прерывание, наложение… Интересно, можно ли их покрыть тестами? Скажем, озвучку можно тестировать через распознавание речи… Кажется, родилась идея для стартапа…

Графики у нас мало, зато много текста (~27 тыс. знаков с пробелами). При этом в Ink не встроена проверка орфографии для русского языка. Как следствие было море опечаток. Я пытался полностью копировать исходный текст Ink в условный Word, править там ошибки, а потом копировать обратно, но это было очень неэффективно.

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

Очередное небольшое исследование привело меня к LanguageTool. Программа проста, популярна, работает из командной строки, поддерживает русский и английский языки, есть бесплатная версия. Смотрел альтернативы: Grammarly, Ginger, Орфограммка - но одновременно всех этих свойств нет ни у кого.

На практике оказалось, что LanguageTool проверяет не только орфографию, но и пунктуацию, и даже согласование частей речи.

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

Получилась хорошая защита от мелких опечаток. Всем рекомендую.

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

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

Этот инструмент превращает код в более компактный, не меняя при этом его смысла: сокращает имена переменных, убирает комментарии и т.д. Например, исходники Phaser занимают 3,3 Мб. После сжатия через применения Closure Compiler они превращаются в 800 Кб. А вся наша игра весит в сумме 5,5 Мб. Почувствуйте эффект.

Почему выбрал именно Closure Compiler? Потому что он уже встроен в Transcrypt. Т.е. Для сжатия кода, который транслировался из Питона, мне достаточно было выставить нужную опцию в Transcrypt. А сжимать мне нужно было только внешний JavaScript-код, например связанный с загрузкой Ink. Странно было бы это делать другой программой-паковщиком.

Также Closure Compiler умеет преобразовывать код более позднего стандарта JavaScript к более раннему стандарту. Это важно, скажем, для поддержки Internet Explorer и браузеров на старых Андроидах.

Узнал я об этом полезном свойстве и применил его уже после конкурса. Мотивировали жалобы игроков.

Думал я и о настоящей обфускации - т.е. о защите от декомпилирования. Но тут далеко не продвинулся. После пары статей по теме понял, что игра не стоит свеч.

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

Мы поучаствовали в конкурсе КРИЛ. Выступили достойно, заняли не последнее место, получили много разных отзывов.

Среди отзывов был один особенный. Прочитав его, мы поверили, что делаем игру хорошую и что надо доводить дело до конца. То есть переводить игру на английский и делать полноценный релиз на iOS и Android. Подробнее об этом писали в отдельной статье.

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

Интересно, что наше совещание и решение идти до конца пришлось ровно на середину всего срока разработки. Прошло 11 месяцев со старта нашего приключения, а релиз случился ещё через 11 месяцев. При этом мы рассчитывали закончить месяцев за 6. С запасом... Классика.

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

Технически у меня было три варианта внедрения в игру английских текстов:

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

Самым простым и удобным казался третий. Я его и выбрал.

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

Ещё были некоторые проблемы с подстановками в языке Ink. Например, конструкция "Номер поездки: {get_repeat_count_for_player()}" означает, что в итоговом тексте вместо “{get_repeat_count_for_player()}” должно подставиться число совершённых попыток изменить судьбу. Причём число попыток рассчитывалось на уровне Ink, и в GameLogic уже приходила строка с зашитым числом: “Номер поездки: 10”. И как по такому ключу можно было отыскать что-то в словаре?..

В итоге я перенёс логику подстановки текста из Ink на уровень GameLogic. Из Ink теперь приходил текст "Номер поездки: [[repeat_count_for_player]]”, я его превращал в "Trip number: [[repeat_count_for_player]]” и уже после этого делал замену “[[repeat_count_for_player]]” на число поездок. Соответственно число поездок тоже пришлось считать и хранить на уровне GameLogic.

Как организовывать локализацию, если пользоваться текстовой подстановкой Ink на полную катушку - не знаю. Для нашей игры хватило компромиссного решения.

Мы поучаствовали в конкурсе IFComp. Выступили достойно, заняли не последнее место, получили много разных отзывов. Убедились, что идём правильный дорогой. Перевод удался, и мы смотрелись уместно среди состоявшихся англоязычных авторов. Проигрывали в тонкостях использования языка, но выглядели самобытно. Это мы тоже подробно описывали в отдельной статье.

Теперь нас ждала финальная цель - релиз.

К этому времени я уже относительно неплохо ориентировался в html5-разработке и знал, что есть стандартный способ для превращения web-страницы в мобильное приложение - фреймворк Apache Cordova.

Фреймворк устроен так: для каждой платформы (iOS, Android, Desktop) есть шаблон простого приложения, которое умеет делать одно - запускать внутри себя аналог браузера и загружать в этом браузере вашу html-страницу. Дальше Cordova подключает к странице свою JavaScript-библиотеку. Через эту библиотеку можно обращаться к нативным функциям операционной системы. Например, работать с камерой iPhone. Вся работа организована через командную строку.

Сначала Apache Cordova меня очаровала своими достоинствами:

Однако дьявол скрывался в мелочах. И на каждый плюс нашёлся свой существенный минус:

Самая показательная проблема, с которой я лично столкнулся при разработке - нельзя по-нормальному локализовать имя игры под iOS. Есть три пользовательских плагина для этого. И все не работают из-за бага ядра. Есть хак, который позволяет этот баг обойти. Но сервис сборки защищён от этого хака. Занавес.

Я потратил на эту проблему недели две. Разобрался, как можно обойти защиту сервиса, и даже написал свой супер-костыльный плагин, который гвоздями забивает английское название игры. Как же я был счастлив, когда всё заработало!

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

Немного о неучтённых мелочах.

Возьмём иконки. Для поддержки разных моделей телефонов и планшетов мне пришлось сгенерировать 24 иконки разного размера. Причём их нужно ещё правильно назвать. Ошибёшься в разрешении или в названии - в лучшем случае получишь ошибку при загрузке приложения в магазин. Так получилось с AppStore. В худшем - возьмётся иконка с неправильным разрешением. Будет размытой. Такое видел на Андроиде.

С экраном загрузки те же проблемы. Для каждой модели устройства свой размер и своё уникальное название.

Для генерации всех этих вариантов я использовал программу ImageMagick. Бесплатная, доступная, легко встраивается в систему автоматизации. Можно наловчиться и не только менять размер картинки, но и залить фон определённым цветом, добавить рамку, скруглить углы. И всё это из командной строки.

Очень удобно.

C грехом пополам мы доползли до релиз-кандидата.

Это было мучительно долго и нудно. Я собирал по друзьям и знакомым телефоны для тестирования, правил для них специфичные ошибки; потом заполнял карточку игры в AppStore и Google Play, а там тоже свои нюансы, чего только стоит политика конфиденциальности; читал юридические статьи, заводил счёт в банке и т.д. и т.п.

Но вот релиз-кандидат, наконец, готов. Осталось отправить его в магазин. C Google Play всё прошло на удивление гладко, а вот заливка в AppStore - это была целая эпопея.

PhoneGap Build позволяет удалённо собрать и даже подписать архив с игрой релизным сертификатом, но для отправки архива в магазин всё равно нужен Мак. Поиски в Интернете привели меня к трём возможным решениям проблемы:

Скорость отклика была такой, что после нажатия клавиши на клавиатуре символ появлялся на экране секунд через 5. Ох, какая же это получилась длинная ночь!..

Часа четыре ушло на установку программного обеспечения и первую попытку залить архив в магазин.

Эмоции были сродни игры в старый Prince of Persia, где нажал не вовремя кнопку прыжка, упал в пропасть - начинай всё сначала. А мне нужно было точно ткнуть мышкой в правильное окошко. Ошибся - окошко пропало, открылся какой-нибудь калькулятор, курсор мышки улетел неведомо куда - расхлёбывай потом минут пять, не меньше.

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

Ещё в последний момент отключил Google Analytics, потому что плагин с аналитикой по какой-то причине обращался к Adertising Identifier, и робот Apple по этому поводу ругался страшными словами, де, объясните, зачем вам нужен рекламный идентификатор, если самой рекламой вы не пользуетесь. Вопрос был резонным, и я с ним спорить не стал. Так аналитика у нас осталось только на Андроиде…

Но и это ещё не всё. Следующий сюрприз ждал нас в ходе ревью. Нас не пропустили в магазин с формулировкой: “Это не игра, а книга”. И ещё издевательски предложили опубликоваться в iBooks.

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

Я написал апелляцию. Уже начитавшись страшных историй из Интернета и не очень веря в успех... И нас на следующий день без вопросов пропустили.

Появилась долгожданная кнопка “Release this version”. Надо ли описывать, что мы чувствовали в тот момент?..

Ох, это было долго...

Эта статья - финальная точка в конце длинного пути разработки “Вагонов”. Разработка на незнакомых тебе технологиях сродни приключению - никогда не знаешь, что встретится за поворотом. Мне было важно описать этот опыт. Во многом для себя. Но надеюсь, что получилось достаточно связно, и этот опыт пригодится кому-то ещё.

Считаю, что он был удачным. Косвенное подтверждение тому наша следующая игра - “Серость”. Скорость её разработки существенно выше - версию для конкурса КРИЛ-2018 мы сделали с нуля за 3 месяца. Впрочем, пока она технологически полностью повторяет “Вагоны”, и мы только собираемся попробовать что-то новое. В первую очередь в области графики. Так что скоро затормозим...

Напомню, что “Вагоны” можно посмотреть в Google Play и App Store, а следить за нашими дальнейшими мытарствами можно в VK, FB, Твиттере и немного в Инстаграме.

Спасибо за внимание!

#опыт