RPG Maker

Where is the meaning?

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

В общем, я снова пришёл к RPG Maker, и, честное слово, я об этом не жалею. Только иногда грустно, что не смог для своей идеи подстроить огромный комбайн Юнити, но следующий проект я уже точно буду делать на RPG Maker Unite, и там получится совместить удобство с широчайшими возможностями.

Ну и примечание: так как RPG Maker MZ работает чисто на JS, модернизировать его я могу без особых проблем в связи с характером своей работы.

Я записал довольно большое видео по данному вопросу, в нём я копаюсь в мукере и изучаю его возможности:

Часть 2: Рисовака

Вторая головная (или жопная) боль - это рисование. Определился с двиглом, легко разобрался в его работе и возможностях по доработке, перешёл к созданию мира. А рисовать я, напомню, не умею.

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

И знаете, постепенно втянулся.

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

Если в самом начале я рисовал один спрайт 3-4 часа, и результат меня не устраивал от слова совсем, то к концу первого месяца я начал рисовать один спрайт (и не 48 на 48, а, скажем, 96 на 96 пикселей) уже за час. И результат меня настолько устраивает, что я даже задумываюсь о том, чтобы перерисовать первые спрайты. Потому что они разительно отличаются от новых в худшую сторону.

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

Об этом я тоже снял видос, полный рефлексии и размышлений:

Часть 3: шоу "ГЕЙМДЕВ_В_СОЛО"

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

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

Поэтому я решил сделать вот что: запустить шоу под названием "ГЕЙМДЕВ_В_СОЛО", в котором я буду делать игру буквально в прямом эфире. Регулярные выпуски-отчёты о проделанной работе, собственное сообщество в ВК (https://vk.com/era_rebirth - вступайте, кстати), которое я только что сделал, брендинг всего этого дела.

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

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

В тестовом режиме сделал первый выпуск:

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

***

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

Буду рассказывать вам о том, что мне удалось сделать в тот или иной момент времени.

Спасибо за внимание и до новых встреч.

Давайте же разберёмся, что есть в этом блоке, и зачем оно там есть.

2. Объявляем данные плагина

Тут понятно:

• Строчка 6: для какой версии RPG Maker разработан плагин,

• Строчка 7: описание плагина, полезное для других разработчиков и для тех, кто его скачает, а потом забудет, зачем качал =),

• Строчка 8: автор, то есть вы.

3. Блок помощи

Тут можно написать очень длинный текст. Я ограничился просто названием файла, потому что мне было лень, но важно то, что этот текст потом будет показываться в визуальном редакторе RMMZ в блоке описания плагина. Если вы делаете плагин на экспорт, или, тем более, хотите его продавать, этот блок придётся заполнить. Ну и для себя завтрашнего не грех постараться.

Это я сам себя уговариваю)

4. Объявляем доступные команды

На самом деле, для простых скриптов команды особо и не нужны. Имейте в виду, вам придётся описывать их действия в коде самого плагина, что для новичка может оказаться затруднительным. Я на всякий случай указал одну команду, а именно set, команды задаются тремя строчками:

• Строчка 12: объявление синтаксиса команды,

• Строчка 13: человекопонятное название команды,

• Строчка 14: подробное описание того, что делает команда.

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

5. Объявляем переменные скрипта и помещаем их в визуальный редактор RMMZ

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

Объявление переменной включает в себя:

• Строчка 16 (20): имя переменной,

• Строчка 17 (21): текстовое описание переменной (оно будет видно в админке),

• Строчка 18 (22): дефолтное значение.

Дефолтное значение - это если вы в админке ничего не выставили ещё, оно будет вот таким.

6. Код плагина

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

А вот и он:

Очень простой.

Мы создаём собственную функцию, которая будет выполняться в общем потоке при загрузке игры (но ПОСЛЕ загрузки всего ядра, что важно, так как нам нужно переопределить какую-то часть кода, а для этого она должна быть уже загружена) и будет менять два цвета в ColorManager на те, что мы указываем в визуальном редакторе RPG Maker. Что нам нужно для того, чтобы это реализовать? Переменные мы объявили, они появились в админке, но нам теперь надо получить их значения из скрипта.

За это отвечают строчки 28 и 29.

На 28 строчке мы создаём константу, содержащую название плагина (это вообще пригодится во многих случаях, так что я бы рекомендовал всегда в начале скрипта её объявлять), а на 29 по имени этой константы получаем из PluginManager параметры плагина (это как раз и есть те самые созданные нами переменные param). Как вы помните, формат у них - строка вида "0,0,0,0" - а это RGBa. Но чтобы присвоить это дело окну, его нужно немного видоизменить. На строчках 32 и 33 мы как раз помещаем значения этих параметров в обёртку, чтобы получилась строка вида "rgba(0,0,0,0)".

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

Итак, мы получили описание цвета двух параметров плагина (причём с альфа-каналом, то есть, прозрачностью), и нам осталось только закинуть их в ColorManager. За это отвечают строчки 37 и 38. Они ПОЛНОСТЬЮ дублируют аналогичные строчки из rmmz_managers, то есть, переопределяют их, подставляя вместо установленных разработчиком значений значения из плагина.

Вот, собственно, и всё. Закрываем блок кода, сохраняем и наблюдаем результат.

***

Как я уже говорил, любой JS код тут заработает, потому что запускается игра в браузере. Как мне указали в одной из моих статей, есть ещё великое многообразие WEB API, которое может обеспечить в том числе и асинхронность, и многопоточность, и прочие плюшки. Что ж, если вам хочется - используйте всю мощь жабаскрипта на полную!

А у меня на сегодня всё. Пишите свои мысли, задавайте вопросы, будем вместе искать на них ответы. Спасибо за внимание и до скорых встреч!

Рассуждения о "браузерности" RPG Maker тут: https://pikabu.ru/story/nemnogo_rassuzhdeniy_o_brauzernosti_rpg_maker_mz_10185619

Заметка на полях: когда вы что-то меняете в плагине для RMMZ, вам обязательно надо сохранить игру. Если вы тестируете через Запуск игры - движок вас в любом случае спросит, надо ли сохранить прогресс, а вот если вы, к примеру, тестируете боёвку в окне Отряды - не забывайте после всех изменений в коде сохранять проект.

Да, кстати, старый дедовский способ дебаггинга через alert() тоже работает. Как я уже говорил, браузер поддерживает все возможные функции JS, так что получите и распишитесь:

***

2. Вопросы оптимизации

Игра на RMMZ - это js код в браузере, и он болеет всеми проблемами, которые только могут быть у js кода в браузере. Однажды я по приколу делал движок на js - он был проще, чем этот, само собой, но уже тогда я понял одну вещь: оптимизировать это дело - больно и страшно. Я тогда взялся обсчитывать положение десятка объектов на каждом кадре (а их в серьёзном движке, предположим, 60 в секунду!), чтобы реализовать коллизии, и у меня задымился комплюхтер.

Если вы поместите на достаточно небольшую карту в RPG Maker MZ 20 или 30 ивентов, каждый из которых запускается параллельно и имеет свою анимацию (всего-то покадровая анимация из 4 кадров!), ваша игра с вероятностью в 99% начнёт тормозить. И каждый новый ивент будет её притормаживать всё больше и больше.

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

Хорошая новость: как и любой js в браузере, с чем знакомы многие мои коллеги, игра может быть и должна быть оптимизирована по мере возможности. Самое главное, что тут применимы все те же методы ускорения, что и в этой вашей айтишечке. Из-под капота жабаскрипт в браузере работает однопоточно, то есть весь код исполняется построчно и прямолинейно. Обратите внимание на эту мысль: КОД В JS ВЫПОЛНЯЕТСЯ ПОСТРОЧНО! А раз так - чем меньше строчек, тем лучше, как говорится. Впрочем, асинхронность в мейкере имеет место, но об этом как-нибудь потом, а то текст и так слишком длинный.

Стандартные методы оптимизации:

• Удаление неиспользуемого кода (рассуждение об этом ниже);

• Правильное написание кода - без создания по сто раз одних и тех же объектов, с своевременными прерываниями функций и циклов, если они больше не нужны, решают короткие формы записи объявления переменных, тернарные операторы и пр.;

• Естественно, минимизация кода;

• Самый объёмный пункт: и так далее.

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

К примеру, есть люди, которые делают визуальные новеллы на RPG Maker - им стопудово не нужна боевая система, значит, в помойку её. Со всей обслуживающей её инфраструктурой.

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

***

3. Игра в браузере после релиза

В связи с тем, что игра на RMMZ - это и так браузерное явление, ничего удивительного, что начиная с версии MV экспорт игр в браузер стал плёвым делом. Я даже скажу больше: как мне кажется, именно такое существование для игр на современных мейкерах предпочтительнее. Не знаю, что там будет в Unite.

Потенциально, перенос игры на сервак с возможностью подключения данных из MySQL или любой другой БД на серваке - это открытые ворота к многопользовательской игре. Ещё раз подчеркну: любой код JS будет работать. И даже сторонние плагины и фреймворки потенциально можно заставить пахать на благо вашей чудесной игры.

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

***

4. Возможность использовать альтернативные ходы

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

Помимо этого можно использовать и другие апи, надстройки и т.д., которые поддерживает JS. К примеру, кладёте в папку с игрой файл, а дальше XMLHttpRequest и поскакали. Эта апишка вполне может помочь расширить функционал вашего проекта. Потом просто по какой-то логике распихиваете полученный контент по переменным с помощью $gameVariables.setValue() - и всё, пользуйтесь.

А ещё есть достаточно бедные, но всё же заметные возможности HTML+CSS. Сама игра, как вы знаете, подгружается в canvas, но такие вещи, как иконки, параметры окна, даже курсор можно поменять в индексе! Между прочим, этим пользуются многие разработчики, которые не хотят лезть внутрь движка, а находят обходные пути.

Вот, смотрите, перед вами код де факто основного файла игры - index.html

А вы думали, как он должен называться?)

Тут сразу видно и подключение иконки, и подключение css, и подключение скрипта внизу. Нам что-то мешает, к примеру, добавить подключение ещё какого-нибудь скрипта, или даже целой библиотеки? Нет, не мешает.

Кстати, интересным развлечением будет почитать файл main.js - в нём содержится, фактически, основной класс вашей игры, этакий менеджер менеджеров. А ещё там можно почитать, в какой последовательности грузятся модули (и добавить собственный при желании), как обрабатываются ошибки и так далее. В результате его работы и работы все подключённых файлов, получается следующая html-разметка (то бишь, один единственный main.js, подключаемый в индексе, уже на клиенте подгружает ещё почти два десятка JS файлов):

Вот этот canvas - он и будет содержать собственно говоря игру.

Но посмотрите на этот впечатляющий список скриптов! Вы можете добавить в этот список что-нибудь своё и спокойно запустить.

***

В общем, вывод такой: веб-программирование никогда ещё не было так близко к геймдеву и, по всей видимости, уже никогда не будет. Пользуемся, пока движок совсем не покрылся пылью)

Спасибо за внимание и до новых встреч!

***

Предыдущая статья про RPG Maker MZ: https://pikabu.ru/story/vvedenie_v_plaginovedenie_rpg_maker_mvmz_chto_takoe_plagin_na_samom_dele_10180687 - тут про плагины.