Запутанный дневник по созданию My Confused Pony

Давно хотел проявлять какую-либо деятельность на этом форуме, но до данного сайта я не сидел на форумах - так что не судите строго, ведь с оформлением постов на данной площадке у меня возникает некоторый конфуз.
"Все когда-то бывает в первый раз"
Разработка проекта My Confused Pony ведётся с 3 ноября 2017 года, в программе RPG Maker VX Ace. Персонажи данного проекта будут пони, но от этого крови в игре будет не меньше. В игре почти реализованы возможности расчленения тел персонажей, с последующим выпусканием на пол множественных кровавых следов.
Игра планируется в жанре Bit'em up, где игроку даются возможности:

• Выполнять подкаты, для уворота от пуль, или некоторых ударов(кнопки: LCTRL + WASD)

Выполнять воздушные рывки, которые позволяют быстро добраться до врага и эффективно оглушить его. Также с помощью этого рывка можно спровоцировать цепочку комбо, которая реализована пока на уровне концептов. (кнопки: LSHIFT + WASD)

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

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

• хп
• хитбоксы различных частей тела

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

Модель поведения

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

За ~5 лет разработки было сделано много всяких механик и в игре на данный момент присутствует 43 листа со скриптами. Представленный выше список реализованных возможностей и инструментов это лишь небольшой срез 6-7 листов. Все остальные листы либо технические упрощения, либо вкрапления для маппинга, либо графические улучшения, либо же устаревшие, не использующиеся механики, до удаления которых руки пока не дошли. Работу этих листов я хочу продемонстрировать в видео, или в последующих постах этой темы, посвященных багфиксу, стараясь не углубляться в технические термины. Времени на разработку мало, но по первой возможности я буду стараться делится прогрессом.

P.S. Надеюсь из-за обилия крови в игре, меня не забанят на данном сайте)

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



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

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

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

Прости, это банальный и неприятный вопрос, но почему ты делаешь Bit'em up именно на Мейкере, который для этого не предназначен? Что в нём для игр этого жанра работает лучше, чем у других движков?

Хороший вопрос. Вообще игру я хотел сначала делать на Game Maker Studio - но денег на него нету. Другие движки учить надо. Я знал язык скриптов RGSS3 и в целом в Мэйкере ориентировался - так что выбор долго себя не ждал. Да и на создание проекта меня вдохновила история про создание мода The Binding of Isaac: Antibirth. Хочу нечто подобное провернуть и Мэйкером. Запарится, но перевернуть движок вверх дном. Челенж своеобразный. Глупо, авантюрно, не перспективно - но зато опыта в программировании можно подкачать неплохо.)

А спиратить game maker? Всеравно ж мейкером пираченым пользуешься

На тот момент не мог найти годную раздачу именно Game Maker Studio. Находил только Lite версии, у которых функционал, как мне тогда показалось, +- как у Мэйкера. В любом случае, если даже и найдётся тот самый заветный торрент файл, то уже слишком поздно переписывать весь текущий код игры на Гамак. Да и уже самому интересно то, что же все-таки из этой задумки получится в конечном итоге.

Зачем пиратить Game Maker если можно потопать на ныне развивающийся Godot. Программирование на нем легко изучается после RGSS3 (Я тому пример) ¯\_(ツ)_/¯

Ну, может после релиза данного проекта и присмотрюсь к Godot. Пока всё-же хочу в Мэйкере покопаться.

Впилил в систему комбо таймер, а также расставил по анимациям атак динамичное изменение скорости. Теперь с каждым обновлением передвижения, в пределах анимации, у игрока повышается скорость на 1.3. Благодаря этому динамичному изменению скорости анимации выглядят менее топорно и более реалистично(?).


Далее по плану добавить снятие хп во время ударов.

P.S. 1277 is complete

Окей. Что я могу сказать. Снятие хп сделано и комбо в игре, особенно с переходом в режим казни(Режим, где ты цепочкой ударов добиваешь врага), выглядят довольно-таки динамично. Мне во всяком случае нравится данная механика и на релиз её точно оставлю. Также для демонстрации сей механики я записал 35 секунд демонстрации из движка. Внимание, если вы не любите расчлененку, кровь и жестокость, то я не рекомендую разворачивать спойлер ниже и смотреть данное демо. Я вас предупредил.


Какие недостатки из данной демки можно заметить:

• Во время ударов, бойцы способны клипаться через стены
• Труп проигравшего оппонента таинственным образом телепортируется в исходную точку
• По окончанию комбо, враг должен был упасть замертво, а не дышать и кричать
• Текстура главного героя не сразу меняется на исходную, из-за чего он ходит борясь с воздухом
• Труп проигравшего оппонента таинственным образом телепортируется в исходную точку
• В первом ударе, при заходе в режим казни, игрок бьёт врага... на расстоянии?!
• Труп проигравшего оппонента таинственным образом телепортируется в исходную точку
• Во время ударов горе драчуны уползают за экран. Это неприятно.
• Окошко с демонстрацией комбо в боковой проекции, главный герой куда-то исчезает

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

P.S. Стоит также подметить, что кровь я собираюсь реализовать в виде партиклов, поэтому её так мало на демо. По истечению таймера ничего не происходит потому, что нужно сделать анимации контратак для врагов.

Не мог ведь я остановится на одной лишь демки и функции нанесения урона, верно? Так что я сейчас готов поделиться дальнейшей проделанной работой.

Клип через стенки

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





Уезд персонажей за экран во время атак

Окей, с этой недоработкой уже не так все однозначно. Начнём с того, что экран сейчас уже следует за главным героем во время атак и делает это, более менее, плавно. Но появилась ещё одна проблема, скорость персонажей во время прокрутки бустится до невероятных высот и они за 2-3 удара оказываются у края карты. Если бы не стена, то эти 2 хвостатых монахов Шаолиня обошли бы весь мир в процессе битвы! Есть предположения о том, откуда мог появится этот баг, но структурировано и понятно изложить его здесь - я, увы, пока не в состоянии.

В спойлере присутствует кровяка. Аккуратно!



Телепорт трупа в исходное место

Результат данного багфикса можно было наблюдать в скриншотах выше. Дак в чём же оказалась проблема? Дело все в том, что в RPG Maker VX Ace персонажи имеют у себя 2 вида координат: координаты положения текстуры на экране и логические координаты, которые определяют то, на каком тайле карты сейчас стоит персонаж. Дак вот, проигрыватель анимаций написан таким образом, что вместо того, чтобы динамично изменять логическую координату вместе с положением на экране - он больше предпочитает синхронизировать её с положением на экране в конце анимации. Я просто понатыкал эту синхронизацию в концы анимаций и все.

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

Так. Ну что я могу сказать по сегодняшнему дню? Сегодняшний день я посвятил фиксу связанным со скроллингом экрана и бустом скорости у персонажей во время анимации. Не могу сказать, что все прошло успешно и баг пофикшен. Но и не могу сказать, что все убито в ноль и нужно все переписывать. Работа над фиксом продвигается, но пока всё безрезультатно. Я попытался сделать вычисление коэфициента сдвига экрана за кадр и с помощью него отодвинуть координаты драчунов назад. Но по итогу получилось следующее.



Как завещал нам дядя Ильич: "Учиться! Учиться! Учиться!" - так что буду работать над этим и не опускать руки. Пока ищу альтернативные пути решения этой проблемы.

Все же я, похоже, добил этот баг. Проблема, как оказалось, все же крылась, в любимой многими(я не исключение) привычкой всё усложнять. А я просто этим коэффициентом, описанным постом раннее, решил подвигать viewport с персонажами... Кринж.
Но благо хоть баг пофикшен и наши мастера боевых искусств больше не прыгают на 9-10 тайлов вперёд-назад. На сегодня думаю можно уже и закончить. В спойлере лежит кровяка. Открывать на свой страх и риск.



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

Всем вновь драсть. Вот и проходит сегодня с 9:00 мой обещанный "мини кранч" по устранению багов. Пока из исправленного могу отметить следующее:

Снова скроллинг!

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




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



Приближение экрана

Во время включения режима казни, активируется скрипт, создающий приближение экрана(Зум). Скрипт этот довольно-таки прост по структуре. Просто игра создаёт отдельный спрайт, который по содержанию является просто стоп кадром экрана(своеобразным скриншотом) и с помощью метода zoom_x и zoom_y приближает его. Казалось бы: что может пойти не так? Ну чтож.. VX Ace, как оказалось, плохо управляется с большим разрешением текстур.
Давайте немного посчитаем. Увеличение экрана, во время казни, происходит, примерно в 2-3 раза. Умножаем на это число разрешение экрана(640х480) - и получаем красивое число 1920х1440. Учитывая, что игра всё равно на экране будет демонстрировать только 640х480, то логичным действием будет обрезать нужный участок этой самой текстуры и растянуть его, для приближения, под 640х480. Таким образом кадр экрана, во время зума, теперь обновляется чаще, а зум происходит теперь быстрее.

Осторожно! Кровь в спойлере!



Наложение исполнения анимаций друг на друга

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

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

На этом багфикс не кончается. Так что, ожидайте дальнейшие посты по этой теме!

Драсть всем снова! Как я и обещал - ещё один пост. Последний за сегодня.
В этот раз я решил немного отойти от комбо и поисправлять немного механику Бустеров. Что такое бустеры? Бустеры - белые точки на карте, при налёте на которые игра позволяет совершить от неё дополнительный дэш в нужное направление. Данные бустеры можно будет располагать в целые ветки, которые можно впилить уже в маппинг для некоторых миссий или просто с помощью их усложнить немного получение какого-либо секретика или коллекционной погремушки.



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

• Исправление бага, который Исполнял ближний удар во время полёта
• Внедрение заморозки экрана на определенное число кадров, при "подборе" бустера
• Изменение структуры внепланового исполнения деша

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

В воскресенье я планирую заняться сторонними проектами.
В понедельник или вторник я хочу вновь взяться за My Confused Pony.
А на сегодня, пожалуй, данный мини кранч можно объявлять закрытым.
Ожидайте.

P.S. В коем-то веке пост без крови и расчленёнки)

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

Баг с исчезновением текстуры персонажа в окошке боковой проекции комбо

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

Изображение бага:



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

Исправленный вариант:



Исполнение ударов во время полёта по бустерам

Изображение бага:



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

Исправленный вариант:



В особенности и детали исправления данной ошибки вникать не буду. Долгий пост будет. Просто всё объясню в общей манере. Вкратце, теперь при налетё на бустер, игра присваивает определенной переменной значение true. Данная переменная отвечает за "заморозку" кнопок управления. При остановке персонажа, данная переменная отключается и значение её снова становится false, возвращая игроку управление. Спросите: "А как тогда игрок управляет полётом при налёте на последующие бустеры?" - Что же.. ответ прост. Для данной механики был сделан отдельный метод, по принципу действия который схож с исполнением обычного дэша, но написанный в более упрощенном варианте, не подразумевающий в себе задержку между воспроизведением или выбора между подкатом или дэша.

Не восстанавливающиеся бустеры.

Игрок прыгает по бустерам >> Бустеры исчезают >> Игрок проваливает буст паркур >> Игрок спавнится на последнем чекпоинте, перед бустерами >> Бустеров нету >> Игрок не может пройти игру.

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

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



К сожалению, от работающей версии данного скрипта остался лишь этот скриншот с демонстрацией бага. Причиной не дееспособности скрипта является базирование на старой версии проигрывателя анимаций, который, с того времени, в корне изменился. Процесс реставрации этого скрипта будет не самой лёгкой задачей. Реставрировать придётся 1020 строчек кода. Задача, как я думаю, будет не из лёгких. Учитывая, что попутно нужно будет её оптимизировать и исправлять различные ошибки - то я думаю, что на недельки 2-3, если не месяц, я на нём застряну.



Следующий пост, о прогрессе над реставрацией, думаю стоит ожидать в среду, или в четверг.
Ожидайте.

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





Из особенностей:

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

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

Завтра я вновь попытаюсь продолжить работу над этой механикой.
Ожидайте!

Ужас. Последний пост в данной теме был 2 недели назад.. Ну-у.. скажем так, что на это были свои причины и данный пост призван быть не ознаменованием конца, а скорее явлением комбэка в данный дневник. Дерьма произошло за эти 2 недели достаточно. Работа на производстве, сложные моменты в разработке MCP и другого, стороннего, проекта - довольно-таки сильно душили. Контент для поста был, но времени на его написание - нет. Поэтому я и решил оставить этот весь контент для лучших времен и, как по мне, эти времена настали.
Последний пост демонстрировал начало работ над Супер бустерами. С того времени прогресс в этом процессе неплохо шагнул вперед и кусочек от результата проделанной работы я хочу показать вам в гифке.





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



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

Касательно системы тэгов.
В самой конструкции мини-игры тоже была внедрена эта система.



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

На данный момент готовится введение в эту мини игру эвентов встречающихся по пути(повороты, где нужно будет налететь на центральный супер бустер, дабы поменять направление полёта. Или просто встречающиеся препятствия).
Ожидайте!