-
EvilCat
-
-
Вне сайта
-
Просветлённый
-
- Сообщений: 469
- Спасибо получено: 850
-
-
|
Это отчёт о том, как было разработано и выпущено приключение “Самый обычный день”, сделанное с помощью RPG Maker MV и вставленное в браузерную игру на Русской Лиге Покемонов.
Документ длинный, но это не значит, что 5-10 минутное приключение было делать долго и трудно: это говорит только о моей готовности болтать о собственных интересах и о моей скорости печати %)
Следует заметить, что у меня не было времени вычитать этот текст. Приношу извинения за опечатки и ошибки.
В слегка устаревшую, но отдельную от браузерки версию приключения можно поиграть здесь. Не следует обращать внимания на кривое имя покемона, в релизе всё отображается правильно.
Концепция
Мне слишком поздно перед 1 апреля пришла замечательная мысль: игры на RPG Maker MV прекрасно чувствуют себя браузере - так есть хоть какая-то причина, почему мы не вставляем их в нашу браузерную игру, сводящуюся к мечте о нормальной покеигре (суть JRPG) в браузере? Подумав так, я при поддержке остальной команды игры за неделю (учитывая, что на эту неделю также пришёлся мой квартирный переезд) смогла сделать забавное ролевое приключение длиной 5-10 минут, куда игрок попадал, отправившись в браузерке в “экспедицию” - уже существовавший у нас механизм, заключающийся в том, что игрок записывает в неё покемонов, а затем спустя 8-12 часов забирает их той или иной концовкой с наградой. Раньше между записью и наградой не было никакого геймплея, одно лишь ожидание, и вот впервые он появился.
Следовательно, передо мной стояло три задачи:
- Сделать 5-10 минут забавного и похожего на покеигры приключения на РПГ Мейкере.
- Интегрировать его с браузерной игрой Русской Лиги Покемонов (например, чтобы персонаж был соответствующего пола, и в партии был именно покемон игрока, а не какой-то посторонний).
- Успеть сделать это к 3 апреля (к завершению квартирного переезда, когда сервер начинал работать на новом месте.
Критерии успеха проекта - это его выход в 3 апреля (или с небольшим опозданием) с надлежащей интеграцией с браузерной игрой Русской Лиги Покемонов, и чтобы у большинства игроков не возникло ни технических трудностей, ни проблем с прохождением - и, желательно, возникли бы улыбки и приятное удивление.
Цели, которых я хотела добиться этим проектом: опробовать включение мейкерского приключения в браузерную покеигру и одновременно прорекламировать такую возможность как игрокам, так и товарищам по команде. Одно дело - когда говоришь “слушайте, а ведь мы можем включать куски настоящей JRPG! И делать их будет очень просто на удобном редакторе!” - а другое, когда показываешь это на деле.
Первым вопросом было: успею ли я? Или точнее: сколько запланировать сделать, чтобы успеть? Очевидно, задачи, поставленные выше, имеют подзадачи:
Ролевое приключение:
- Определиться с графическим стилем: насколько воспроизводить стиль исходных покеигр? а насколько можно использовать стандартные мейкерские ресурсы?
- Найти или адаптировать тайлсеты и чарсеты.
- То же самое насчёт музыки и звуков.
- Определиться с общим сюжетом.
- Определиться с последовательностью сцен (очевидно, при таких сжатых сроках игра должна быть линейной).
- Обеспечить дополнительный функционал и ресурсы, нужные для такой последовательности сцен.
- Собственно создать сцены.
- Резервное время на случай непредвиденных проблем.
- Тестирование и отладка.
Интеграция с браузеркой:
- Научить браузерку понятию “ролевое приключение”. У каждого ролевого приключения должен быть идентификатор, название, автор…
- Сделать связку “экспедиция”-”приключение”. Добавить выбор приключения в форму редактирования экспедиции.
- Сделать старт приключения после записи в экспедицию.
- Сделать завершение экспедиции после завершения приключения, с выбором соответствующего исхода (концовки).
- Ограничить доступ к приключению: только игроки, находящиеся в данной экспедиции, должны иметь возможность проходить его, и только пока экспедиция не завершится.
- Сделать пол и имя главного героя такими же, как на сайте.
- Отобрать 10-20 видов покемонов из самых распространённых, которые можно будет использовать в приключении.
- Сделать, чтобы за главным героем следовал его покемон из браузерки - включая имя, вид, пол и цвет (в браузерке особи одного и того же вида могут отличаться цветом).
- Показывать приключение в окне сайта, а не на чёрном фоне.
- Убедиться, что игра со всеми нужными плагинами работает в большинстве браузеров, с которых ходят на Русскую Лигу Покемонов.
- Создать в браузерке соответствующую экспедицию (с описанием, параметрами…), придумать и подготовить награду.
- Подготовить анонс. Подготовить ЧаВо (FAQ) с ответами на предполагаемые баги и непонятки.
- Резервное время на случай непредвиданных проблем.
- Тестирование и отладка.
Даже по количеству пунктов получается много работы… К счастью, тренерская игра Русской Лиги Покемонов (да и весь сайт) - не сольный проект, а командный. Значительную часть задач можно было делегировать, да и по остальным я могла рассчитывать хотя бы на обсуждения. Награду мы придумали вместе, материалы и загрузили подготовили мои товарищи по проекту. Сюжет, последовательность сцен и многое, что не было связано с программированием и работой в Мейкере, было сделано командными усилиями. Тестирование тоже проводилось коллективно.
Итого на меня оставалось всё, что касалось Мейкера - маппинг, расстановка и настройка событий, подготовка тайлсетов и чарсеров… а также изменения в движок браузерки для интеграции её с мейкерским приключением.
В итоге, однако, из планов на содержимое приключения от где-то половины пришлось отказаться, так как не укладывалась по срокам (и то игру удалось запустить лишь вечером 5 апреля, на два дня позже планируемого), но с другой стороны - я заранее знала, от чего откажусь, если сроки будут поджимать, и начала работу с того, без чего проект не мог бы существовать. Например, имитация покебоёв и “секрет” с NPC-авторами - мило, но не критично, а вот если за главным героем не ходил бы тот самый покемон, которого игрок записал в экспедицию - это бы поломало всю идею.
RPG Maker MV стандартно поддерживает тайлы 48 на 48 и такого же размера персонажей, а также разрешение 816x624. Я предполагала, что это станет проблемой: для изображения главного героя, покемонов и других тренеров я собиралась использовать спрайты из одной из официальных покеигр, и вряд ли они каким-то чудом были уже в 48 на 48. Я морально готовилась разбираться, как использовать плагин на уменьшение размеров тайлов, и жонглировать двумя версиями тайлсетов и чарсетов: “мыльным” увеличенным для редактора и итоговым для тестов.
Но Мейкер преподнёс сюрприз. Оказалось, достаточно того, чтобы обычные чарсеты делились на 12 по горизонтали (четыре персонажа по три шага) и на 8 по вертикали (два персонажа по четыре направления). “Большие” чарсеты просто должны делиться на три по горизонтали и четыре по вертикали. Разделив лист на отдельные картинки таким образом, движок правильно размещает их в тайле карты, какого размера тот бы ни был. Увеличив персонажей и покемонов ровно в два раза, я получила чарсеты примерно 56 на 56 (некоторые больше). Это позволило мне использовать и девочку-тренера с её торчащими по бокам хвостиками, и таких огромных покемонов как дракон гярадос и лохнесское чудовище лапрас, не поступаясь их сравнительным размером. Такого не удавалось добиться даже Pokemon HeartGold/SoulSilver - официальной игре! Правда, косички девочки и ласты лапраса иногда торчали сквозь стены, но это почти не портило картину - мало ли в JRPG условностей.
В качестве тайлсета я решила использовать стандартную графику Мейкера. Она достаточно красивая и детальная, и совершенно не навязла игрокам Русской Лиги Покемонов, большинство из которых мейкеристами не являются. Кроме того, те самые геометрические деревья и кустики, которые так разочаровали многих мейкеристов по сравнению с VX Ace, довольно похожи на родной стиль покемонов. Возможно, это не случайность, учитывая популярность покемонов; а также куда меньшую требовательность условных пейзажей по сравнению с красотами из FF и Chrono Trigger. Несмотря на то, что тайлсеты Мейкера имели один размер пикселей, а мои увеличенные покемоны и покетренеры - другой, вместе всё смотрелось вполне естественно.
Итого для приключения понадобилось заготовить примерно 10 чарсетов покемонов (отдельными файлами, чтобы движок браузерки мог их перекрашивать сообразно конкретной особи в наличии у игрока), 1 чарсет с тренерами (девочка и мальчик, на велосипеде и без) и 1 чарсет с тренерами-NPC и 1 чарсет с грузовиком. Также я загрузила 6 дополнительных картинок - спрайтов покемонов из браузерной игры, которые пришлось увеличить в 2 раза, так как для финальной сцены они были слишком мелкими, а родное Мейкерское увеличение давало мыло. Использовался Adobe Photoshop, хотя, конечно, подошёл бы любой редактор с прозрачностью, слоями и разметкой клеток.
На вопросы графики суммарно ушло полтора-два вечера.
Приключение в итоге состоит из следующих сцен или ситуаций (с точки зрения игрока):
- Герой и его покемон едут в грузовике среди коробок.
- Грузовик приезжает, герой выпрыгивает из него, грузовик уезжает.
- Герой идёт вперёд, вдруг слышит звук в небе и видит пролетающую лугию - легендарного покемона. Появляется мотивация: догнать и поймать лугию.
- Герою преграждает путь профессор Оук, рассказывая нашему тёртому жизнью игроку банальности типа “Люди и покемоны живут бок о бок”. После короткого диалога он погружается в задумчивость и отпускает героя.
- Герой видит велосипед, который поможет ему скорее догнать лугию. Если он садится на велосипед, то через три клетки тот ломается, и герой снова пеший.
- На лесной тропинке героя подстораживает заклятый противник. Но похоже, его больше волнует, чтобы герой восхитился его новеньким велосипедом, который тот оставил на опушке. Если герой разбивает велосипед, противник смущается и пропускает героя (это внутренний юмор покевселенной).
- Герою предстаёт поле высокой травы, где водятся дикие покемоны, и галерея тренеров, попав в поле зрения которых нельзя избежать боя. Но ему некогда, нельзя тратить время на бои. Это место можно пройти, если заметить скрытую тропинку через деревья.
- Наконец, герой подходит к статуе дракона, и озень падает лугия… Но оказывается, что это всего лишь дитто - покемон-мимик.
- Герой предлагает дитто принять форму другой легенды, и дитто демонстрирует несколько форм. Когда игрок говорит “Эта мне нравится! Пошли со мной!”, приключение заканчивается, и он получает дитто в соответствующей форме в браузерке.
Далее я разберу каждую сцену и что понадобилось для их реализации.
Это не сцена, потому что игрок её не видит: он видит только чёрный экран, который постепенно становится грузовиком (вид изнутри). Но кое-что происходит уже до этого. А именно:
- Блокируется показ меню (не успевала настроить его так, чтобы было похоже на покемонское - уровень покемона должен быть до 100, а не 99, тренер не должен показываться в команде…).
- Инициируется загрузка музыки, которая должна зазвучать после выхода из грузовика (без этого музыка звучит с заметным запозданием).
- Партия наполняется тренером соответствующего пола и покемоном, записанным в экспедицию. Применяются настройки внешности, меняется имя…
В создании этой сцены помог параметр “Партия начинает игру прозрачной”. Значит, игрок видит просто чёрный экран - а не чёрный экран, где на один кадр возникает главный герой, прежде чем событие успеет сделать его прозрачным.
Главной проблемой здесь была предварительное начало загрузки музыки. Задержка проигрывания музыки - это вообще повсеместная проблема, но поскольку мало людей пользуются выкладыванием игр в браузер (а не пакованием их в exe или apk), она не столь известна. Для её решения предлагается плагин TDDP PreloadManager, но он довольно объёмный, и мне не требовался весь его функционал. Вместо этого я подсмотрела там операторы, с помощью которого он заставляет движок начать скачивать (но не проигрывать!) музыку заблаговременно, и использовала эти же операторы в команде “Script”.
Настройка партии и персонажей осуществляется специально для той цели написанным плагином Pokeliga. Он берёт данные, поставляемые ему браузеркой в виде Яваваскриптового объекта, и нехитрыми манипуляциями корректирует персонажей и состав партии.
Внутренности грузовика - прямое заимствование из Pokemon Emerald, так что эта карта сделана не тайлами, а параллаксом. Чтобы обозначить клетки, куда игрок не должен мочь наступить, использован плагин YEP_RegionRestrictions от Янфлая. Была приятно удивлена, что для этого не потребовалось также устанавливать какой-нибудь корневой движок Янфлая! Хотя я сама использую подобный для своих плагинов, но как пользователь, конечно, не любить устанавливать плагины-зависимости.
Сложнее было сделать звуки шагов, без которых эта сцена была бы абсолютно беззвучной и смахивала бы на баг. В процессе написания этого отчёта я наткнулась на видеоурок, который делает всё то же гораздо проще с помощью плагина Янфлая, но на тот момент мне удавалось найти только сложные плагины-системы, покрывающие все нужды игры в области шагов - и разные звуки на разной поверхности, и всё на свете. Такой сложный плагин мне был ни к чему. Поэтому я решила использовать собственный плагин RegionCommonTrigger, чтобы запускать common event, когда игрок входит в заданный регион. Его логика отличается от янфлайского тем, что событие запускается не только на входе, а на протяжении всего нахождения персонажа в условленном регионе. Поэтому мне пришлось добавить также переключатель “Игрок начал двигаться”, который данный плагин включает, если игрок сошёл с клетки; событие, соответственно, выключает переключатель и таким образом отрабатывает всего раз для каждого шага.
В качеству звука шагов использовался стандартный Knock, а для звука остановки грузовика - Push. В покеиграх есть и готовые звуки для этих ситуаций, но мне не хотелось искать их и конвертировать в OGG. Не уверена, что для звуков и музыки из игр существует такой сайт как The Spriters Resource, благодаря которому я легко нашла все нужные картинки для графики.
Мне также понадобилось решить вопрос, что считать выходом из грузовика: когда игрок наступает на клетку со светом, струящимся снаружи, или когда игрок утыкается в границу этой клетки? Будут ли игроки, которые встанут на клетку со светом, не догадаются нажать стрелку вправо и подумают, что не могут выйти? Я решила, что нет, и действительно, никто не признался в том, что застрял в грузовике.
В Мейкере есть и функция прыжка, и соответствующий звук, а благодаря отсутствию ограничения на размер чарсета я без труда сделала сцену, когда игрок выпрыгивает из грузовика (пришлось проявить экран через 7 кадров после начала прыжка, иначе было бы видно, что герой прыгает с земли), а затем грузовик, ускоряясь и покачиваясь, уезжает налево. Начинается стандартный трек Field1.
Пришлось также придумать реакцию игры на случай, если игрок пойдёт влево, а не вправо, где размещает всё содержимое. Приключение не претендует на открытый мир, так что имеет право ставить невидимую стену, но я также снабдила эту стену парой забавных сообщений вроде “Вы слышите судьбы призыв из другого направления” (отсылка к телепереводу заставки “Покемонов”). Невидимую стенку внизу я не стала никак объяснять - было достаточно очевидно, что локация горизонтальна, хотя несколько кусочков мха и могли намекать на выход на юг… Ну а наверху просто плыли облака.
Когда игрок достигает, грубо говоря, горизонтальной координаты Х в первый раз, показывается катсцена с лугией в небе (вот для чего сверху плыли облака). Чтобы не делать это common event’ом, отдельным от карты, я просто заполнила столбец клеток обычными ивентами. Но так как мне не хотелось копировать громоздкий ивент со сценарием лугии восемь раз, то я воспользовалась собственным плагином ReferByTitle, чтобы все кроме одного ивенты были копией этого самого одного. В данном случае было лучше использовать упомянутый плагин RegionEvents Янфлая, так как обилие ивентов плохо сказывается на производительности, а плагин Янфлая отрабатывает всего раз за шаг и настраивается отдельно для каждой карты. Основное назначение ReferByTitle задумывалось для копирования ивента из карты-палитры или копирование незначительного числа ивентов. Так или иначе, не думаю, что это создало так уж много лагов, хотя владельцы слабых телефонов могли прочувствовать.
Во время катсцены нужно было двигать не только героя, но и его покемона. К сожалению, Мейкер из коробки не предлагает способов двигать партийцев-последователей, так что я воспользовалась плагином Simple Follower Control, который оказался не столь уж простым в освоении из-за невыразительных кодов ошибок, но полностью решил проблему.
В остальном сложностей не было. Для появления лугии использовался стандартный звук Wind1. Сама лугия была представлена крупным чарсетом и пролетела по горизонтали, а потом подпрыгнула (так как игрок видит только половины прыжка, то похоже, будто лугия взлетела). Кроме прыжка, без плагинов не было способа заставить персонажа двигаться плавно и наклонно под углом, не кратным 45 градусам.
Сначала я хотела сделать анимацию с кружащей лугией с чередованием картинок, но оказалось, что без визуальных средств заставить чередующиеся картинки двигаться по плавной траектории очень сложно.
Это, наверное, самая смешная сцена игры. Профессор Оук в официальных покеиграх рассказывает игроку основы основы мира покемонов и позволяет сгенерить персонажа (то есть выбрать пол). Объяснения, конечно, предназначены для игрока, который ничего о покемонах не знает - не то что наш матёрый тренер, умудрившийся зарегистрироваться на фансайте, раздобыть покемона в фанатской браузерке и записаться в начале апреля в экспедицию. Ему надо за лугией, а тут профессор! И он ходит вверх-вниз вместе с героем и не пропускает!
Чтобы профессор и имел собственное уникальное поведение, и мог поддержать диалог, его пришлось представить двумя событиями: второе, параллельное, называлось “Навигатор Оука” и отвечало за его поведение вне диалога. Помимо движения вверх-вниз, это были также не блокирующие игрока сообщения сверху экрана с применением плагина Янфлая YEP_GabWindow. Этот же плагин использовался, чтобы покемон игрока периодически ненавязчиво мявкал или издавал другие характерные звуки.
Выяснилось также, что некоторые команды в событии “съедают” фрейм, и профессор начинает тормозить и не поспевать за игроком. Я так и не поняла, какие это были команды, но после нескольких копирований-вставок профессора и его навигатора это исправилось. Чтобы сохранить резервную копию профессора (и не потерять сложную систему команд и поучительные фразы, если я напортачу), я копировала его событие на неиспользуемую карту.
В диалоге с профессором есть пункт, где нужно “выбрать” стартового покемона. На выбор - стандартные бульбазавр, чармандер и сквиртл, собственно вид покемона, который уже есть у тренера (у зашедших в приключение со скитти - скитти, с гярадосом - гярадос…) и робкое возражение, которое профессор пропускает мимо ушей. Чтобы в диалоге мог появиться никнейм второго партица (туда я определила название вида), я добавила в плагин Pokeliga обработку шифра \Species[#] и \species[#] в текстах, что возвращает никнейм соответствующего партийца с большой или маленькой буквы.
Когда профессор пройден, он перестаёт загораживать проход, а начинает задумчиво бродить по локации. Чтобы он не уходил слишком далеко, с помощью плагина Янфлая RegionRestrictions вокруг него были установлены невидимые барьеры, ограничивающие только ивенты.
Велосипед и поломанный велосипед - единственные понадобившиеся добавления в тайлсет. Для этого был создан файл Pokemon_D и подставлен в стандартный тайлсет Outside под соответствующей литерой, предусмотрительно оставленной создателями Мейкера пустой. Я думала о том, чтобы сделать велосипед чарсетом, но в графике покемонов нет велосипеда, едущего отдельно от наездника. Поломанный велосипед был получен из здорового методом поворота тайла против часовой стрелки.
При наличии графики посадить персонажа на велосипед было не очень сложно (я также рассматривала вариант велосипеда как транспорта, но ни на лодку, ни на корабль, ни на дирижабль по своему действию он не подходит). Для ускорения я использовала команду плагина Pokeliga Hurry_on (уже применявшуюся для того, чтобы персонаж погнался за лугией как угорелый, но затормозил у профессора). Переключать скорость с помощью Set Route было нельзя потому, что включаться должен именно бег - иначе игрок с мышкой, перемещение которой всегда подразумевает бег, обнаружит увеличение скорости персонажа до космических величин.
Сложнее было свалить персонажа спустя три клетки. Для этого я использовала ту же схему, что со звуком шагов (и, опять же, было бы удобнее использовать плагин Янфлая). Вокруг исходной позиции велосипеда был размечен регион радиусом 3 клетки, при нахождении на котором игра отсчитывала число шагов. Когда это число становилось 3 или больше, проигрывалась сценка падения с велосипеда (с использованием стандартного звука Run). Теоретически, если бы игрок мог покинуть эту область, не пройдя 3 шагов, он мог бы всю остальную игру проехать на велосипеде.
Здесь не на чём заострять внимание, кроме того, что на эту встречу пришлись основные сложности с пониманием работы плагина SimpleFollowerControl. Кроме того, здесь я впервые использовала вызов одного события другим - без плагина, просто банальным скриптом $gameMap.event(#).start(). Ведь другие точки помимо самого Гари (противника), которые должны были вызывать взаимодействие с ним, не должны были быть его копией, скорее дополнительной точкой входа, и поэтому не подходили для плагина ReferByTitle.
Именно здесь я столкнулась с проблемой, что музыка в веб-версии подгружается какое-то время и не стартует сразу. Для этой сцены это особенно важно: музыка боя должна начинаться как только герой наступит в высокую траву или попадётся на глаза тренеру. Спустя две секунды событие уже закончилось, и не важно, подгрузилась ли музыка. Да, со второго раза она стартовала как надо, но увы. Это, однако, был повод для меня разобраться с предварительной загрузкой и попросить приключение начать загрузку боевой музыки ещё во время встречи с противником.
Сбежав из высокой травы или из-под взора тренера (то, что все хотели, но не могли сделать в оригинальных играх!), игрок видит надпись “Пока вы будете сражаться, лугия улетит”. Мне пришлось поменять её на “Не время сражаться! А то лугия улетит!”, потому что первоначальный вариант все бегло читали как “...лугия улетела”.
Когда герой подходит к уголку одной кроны, то длинный ряд клеток леса постепенно исчезает. Когда герой покидает тропу, эти клетки постепенно появляются. Движение героя не блокируется, пока это происходит, так что система событий должна адекватно реагировать на героя, мечущегося между тропой и равниной как бешеный.
Для самого механизма исчезания я взяла плагин SimpleEventFade. 3 апреля уже подходило к концу, и я понимала, что придётся запускать приключение с опозданием, так что времени долго искать и выбирать плагин не было… Я не знала, как плагин отреагирует, если отдавать ему команды появиться или исчезнуть вперемешку. Но всё оказалось хорошо, плагин отрабатывал всё идеально.
Но подвела меня собственная способность составить логическую картину, как ивенты должны переключаться между режимами “видим”, “становлюсь невидимым”, “невидим”, “становлюсь видимым”. Конечные точки тропинки к тому же должны были переключать направление процесса, а не начинать процесс с начала. Ивент не может иметь двух поведений одновременно… Никакие рисуемые на листах бумаги блок-схемы не могли изменить этого. Я слишком поздно догадалась наложить на клетку два ивента, один из которых ловит присутствие игрока и щёлкает переключатель, а другой - проявляется или скрывает часть кроны. Редактор не позволяет поставить два ивента в одном месте, так что ивенту-переключателю пришлось при загрузке карты подвинуться в параллели, а потом щёлкнуть внутренний переключатель и уже сидеть смирно. Кроме того, мне пригодился очень удобный плагин CustomPageConditions от Hime, чтобы реализовать условия “или” и “переключатель выключен”, которые из коробки решаются копипастой страниц. На проявление тропы ушло около двух часов вечером 3 апреля и утром 4 апреля - понедельника. Работа уже шла туго, сказывался недосып и переживания (всегда фактор при сложных и ограниченных по времени проектах).
Можно было отказаться от постепенного проявления и скрытия тропы, но очень не хотелось расписываться в бессилии движка справиться с такой простой вещью. Ведь одна из целей проекта была продемонстрировать мощь редактора, его способность сравнительно легко воплощать идеи в рамках JRPG.
Во время тестирования выяснилось, что существование тропы слишком неочевидно, и игрок может подумать, что надо как-то миновать тренеров и высокую траву, не вступая в бой. Или понять, как вступить в бой, и выиграть его (возможность такого прохождения планировалась, но я не успела). Поэтому в качестве подсказки хилая тропинка, которая вела ещё с самого начала локации, стала ненавязчиво заворачивать к секретному проходу. Застрявшие игроки всё равно обнаружили себя, но не в таких количествах. Некоторая сложность была оправдана: в конце концов, эта загадка фактически “босс” приключения, за которым - награда.
Когда игрок приближается к последнему экрану игры (а локация представляет собой длинную горизонтальную карту где-то 80 на 17), музыка перестаёт играть, сигнализируя о монументальности происходящего. Это сделано с помощью двух полосок регионов, каждая из которых связана с событием посредством RegionCommonTrigger: при пересечении границы в одну сторону музыка затихает, а в другую - возобновляет с того же места (такая функция уже есть в Мейкере).
Я некоторое время помучалась с тем, когда именно должна появляться лугия: очевидно, когда игрок попадает очерченную на полянку, но как он это поймёт? К тому же он должен стоять в определённом месте, чтобы не пришлось рассчитывать катсцену на все варианты местонахождения героя (и его покемона!) во время старта.
В результате ключевую точку я пометила статуей дракона из стандартной графики, которая активизировалась по касанию (из четырёх ивентов, составляющих статую, только один содержал команды, а другие вызывали его скриптом, описанным выше). Не важно, почему “лугия” решает приземлиться на статую - важно, что игроку понятно, что статуя является ключевой точкой, к которой надо подойти. Кроме того, когда “лугия” приземляется на статую, экран “от удара” засветляется, и пока игрок не видит, я двигаю его персонажа и покемона на нужные мне места подле статуи.
Подвинуть персонажа игрока из произвольной точки на конкретную, однако, оказалась не так просто. Для него я нашла только относительное движение или же телепортацию на другую карту (если указать эту же, она всё равно перезапускается). Возможно, я упустила что-то очевидно, но время уже поджимала, и я просто набрала скрипт “$gamePlayer.setPosition(#, #)” и такой же - в отношении первого фолловера (покемона, следующего за героев).
Далее игрока заставляют спросить вскрывшегося дитто “А другие легенды ты можешь?”, и начинается финальный экран.
Финальный экран - это другая, абсолютно пустая и потому чёрная карта, куда игрок попадает невидимым. Двигаться он, конечно же, не может: пустые клетки считаются непроходимыми.
Всем происходящем на экране управляет автозапускаемое событие, которое показывает картинку дитто, а потом трансформирует его в случайную форму из пяти (точнее, устанавливает переменную на случайное число от 1 до 5, а вторая страница ивента уже делает всё, что необходимо для трансформации в указанную форму).
Для реализации этой сцены понадобилось два плагина: HiddenChoiceConditions от Hime, чтобы скрывать из диалога пункт про текущую форму; и ChoicePositionManager от Soulpour777, чтобы расположить окно с выбором не на средней горизонтали экрана, а внизу.
Когда игрок определяется с выбром (я рассчитывала, что наши игроки уже понимают, что они выбирают вид ивентового покемона-приза, поскольку подобные раздачи были не раз; и действительно, очень немного людей спросили “А как можно было выбрать награду?”), игра предупреждает его сообщением с моим аватаром: “Приключение закончено, хотите получить награду или переиграть?”. Когда игрок получит награду, он уже не сможет запустить приключение заново, а он мог захотеть перечитать какие-то диалоги или поискать секреты (и действительно, один секрет и ряд неочевидных сообщений в приключении есть). Если игрок отвечает, что хочет забрать награду, то плагин Pokeliga инициирует переход на другую страницу, где тренерская игра, собственно, и заканчивает экспедицию с переданной ей концовкой.
Времени добавить много опционального контента не было… Так что секрет всего один: в одном месте можно перешагнуть через кажущееся непреодолимым (по логике остальной игры) бревно и подойти к роще, где если зайти в одну нишу - то игра говорит с моим аватаром “Здесь должен был быть секрет  “. Это самое простое, что можно было сделать в РПГ Мейкере, и никакого секрета в производстве этой фишки нет %)
Эти планы были перечёркнуты из-за нехватки времени.
В секрете планировалось сделать участок леса, где за компьютерами бы трудились аватары творческой команды сайта. Кроны деревьев должны были пропадать по той же логике, что и на секретной тропе. Аватары должны были рассказывать о том, какие технологии были использованы, какие авторские ресурсы были использованы, ну, и пару внутренних шуток.
С тренерами и дикими покемонами должно было возможным можно посражаться, но переименовать сущности и настроить встроенную боевую систему Мейкера под подобие покебоёв я не успела.
Дитто игрок должен был застать поедающим розовые ягоды - которые меняют цвет покемонов на розовый, зачастую навсегда. Это бы объяснило, почему у дитто получалась нормальная белая лугия, но легенды на выбор игрока почему-то розовые.
Видов покемонов должно было быть в два раза больше. Но когда я сделала 10 видов, то оставила остальные 10 на потом на случай, если не буду успевать: иметь 20 видов в неготовой игре хуже, чем 10 - в готовой. Это решение оказалось правильным.
Русская Лига Покемонов работает на самописном фреймворке, рассчитанном под удовлетворение неожиданно возникающих нужд и идей игроделов, поэтому добавить ещё один тип сущности и связать с существующими было несложно (вот бы это услышала Кэт два года назад, когда концепция фреймворка только придумывалась именно с такими формулировками!). Стандартные средства выводили данные об игроке и записанных им в экспедицию покемонов в объект Яваскрипта, который подхватывался плагином Pokeliga, написанным для этой цели.
Чтобы встроить окно мейкерской игры в готовый сайт (а не отдельной страницей на чёрном экране), понадобилось немного разобраться. Причём вариант с фреймом (iframe) меня не устраивал: браузеры подозрительно относятся к фреймам и отказывают им во многих правах. Элемент с игрой нужно было вставлять в div, находящийся глубоко в иерархии элементов страницы (сейчас Лига работает на тяжёлом наследии табличного дизайна, но времени исправить это пока нет). В результате получился новый плагин EmbedRPG (будет выложен вскоре). Он правильно размещает элемент игры внутри сайта (но поскольку я не пробовала его на многих играх, некоторые вещи могут всё же съехать), а также решает проблему с подгрузкой шрифта, который в генерируемой Мейкером странице перечислен в стилях и должен быть известен до подключения плагинов. Плагин также позволяет запретить полноэкранный режим и добавить предупреждение перед обновлением или закрытием вкладки.
Ещё одной неожиданной проблемой обернулась совместимость с браузерами - но не Мейкерской игры или сторонних плагинов, а… моих плагинов. Я большая сторонница свежего стандарта Яваскрипта, где есть “синтаксический сахар” для объявления классов, переменные локальной области видимости и всякие удобные новые стандартные функции. Оказалась, мои представления о совместимости этого с современными браузерами не соответствовали действительности: только Хром поддерживал их достойно (сам движок Мейкера для тестов использует Хром 41, так что неподдерживаемое им я уже не использовала). Даже стоявшая у меня Лиса сразу запнулась о мои плагины, и только в конце недели вышла Лиса 45, которая перестала жаловаться. И хотя большая часть пользователей Лиги сидит, как и всюду в рунете, на Хроме, немалая часть использует Лису, Оперу, мобильные браузеры и многое, многое другое. К счастью, сообщество веб-разработчиков давно борется с проблемой зоопарка браузеров, так что я прогнала свои плагины через Babel: это сделало их слабочитаемыми, но обеспечило совместимость со старыми браузерами без переписывания. Перепишу их потом, когда не надо будет торопиться.
Когда приключение было готово, я залила его на сайт для внутреннего тестирования - до того, как я принялась за основной массив интеграции (к тому моменту достаточно было проверить саму техническую возможность интеграции). Значит, пока я делала интеграцию, команда сайта могла посмотреть приключение, его работоспособность и совместимость хотя бы с нашими браузерами. По результатам тестирования я внесла ряд изменений, отмеченных выше: переделала одну фразу на ту, которая правильно бегло читалась, подвела дорожку ближе к секретной тропинке… Кроме того, я убедилась, что многие каверзные места работают одинаково у всех: например, ни у кого Оук не отстаёт от персонажа.
Также пришлось убедиться, что при медленном интернете, действительно, игра становится неподъёмной, а также музыка начинается с задержкой. Я попыталась исправить это, вынув из подгрузки лишние ресурсы (листы с оружием и так далее), а также обеспечив предварительную загрузку музыки перед сценами, где она понадобится. Это не помогло бедняге с медленным интернетом, но, возможно, помогло тем, у кого интернет был самую капельку быстрее. Да и нагрузка на сервер должна была снизиться.
Кроме того, один из наших нашёл огрехи в паре спрайтов, и мы загрузили их улучшенные версии.
Тестирование уже интегрированной версии не выявило новых проблем. Интеграция прошло почти безупречно, разве что портреты покемонов оказалась немного обрезанными. Зато покемоны были именно того цвета, как в исходной игре!
Продолжение в следующем посте...
|
