В игре понадобилось ввести очередного рядового врага, и он уже по счёту 43-ий. Это - паук / тарантул, который фигурировал в недавнем видео про глючное появление в оригинале.
Кстати, висящий на фоне паук ни разу не респавнится с левой части экрана.
В ролике показано и рассказано о его характеристиках в оригинале, а также о нововведениях, сделанных для него в фанатском продолжении.
Было решено попробовать реализовать коллизии новым методом, прописав весь код столкновения с платформами в событии Step, что требует лучшего понимания программирования в Game Maker. Но зато это одновременно предполагает и позволяет сделать механизм более точным.
С технической стороны наиболее интересное наблюдение относительно реализации падения паука с фона, если игрок находится рядом.
В видео подробности не рассказаны, а лишь показан конечный результат. Идея такова: упомянутое выше падение не должно было происходить в случае, если между игроком и пауком по вертикали находится горизонтальная платформа. Т.е., если бы паук упал, то он не долетел бы до ниндзя, поскольку его задержала бы платформа пола, которая находится выше ниндзя.
Проверять наличие объекта посредством функции collision_line() на первый взгляд - идеальное решение: от врага вертикально вниз "чертится" линия до края экрана. И если эта линия не встречает на пути платформу пола, то это значит, что между игроком и и пауком этой платформы нет.
Но проблемы возникают, если с этой линией пересекутся сразу несколько платформ пола. Например, первая между пауком и игроком, а вторая - под игроком (игрок ведь обычно находится на полу)).
В таких случаях collision_line() может вместо платформы между игроком и пауком "увидеть" другую, под игроком.
Дело в том, что collision_line() при пересечении сразу нескольких платформ возвращает платформу с наименьшим порядковым id, а не обязательно ту, которая ближе.
Проблему решил оператор while, который позволял проверять посредством collision_line() не сразу весь отрезок от паука до низа экрана, а постепенно "увеличивая" его. Таким образом, при первом "столкновении" посредством collision_line() оставалось прекратить удлинение отрезка, тем самым определив ближайшую платформу пола.
Похожий способ реализации коллизий мне однажды показывали на одном из тематических форумов по GM, когда я только начал изучение программирования и столкнулся с первой серьёзной проблемой реагирования игрока с платформами.
Но этот метод не был использован в TNU4, поскольку моих знаний тогда не хватало для его понимания.
Включать в игру того, что работает, но разработчик совсем не знает каким образом - не лучшая идея. Ибо потенциальные проблемы в будущем из-за незнания механизмов (причём, весьма важных) могут застопорить дальнейшую работу.
В TNU4 физика различных объектов реализована разными методами. Чем позже - тем более продвинуто. У Ункенде она не раз переписывалась и совершенствовалась, но объективно, она наиболее "деревянна", нежели, чем, например, у Роберта.
Но это всё по большому счёту уже неважно. Физика всех объектов - на должном уровне и постоянно тестируется. Периодически что-либо подправляется по мере надобности или же делаются "заплатки" и дополнения. Подобное было совсем недавно, как раз для Ункенде, при реализации падающих платформ на уровне 07-2C.
Получился довольно большой пост, начавшийся с новости о новом рядовом враге и окончившийся рассуждениями о программировании TNU4. В принципе, спустя года подтверждается важнейший принцип программирования (как минимум для человека, который ничего в этом не понимал): главное - не торопиться, смотреть примеры и учится на них, и проверять уже реализованное. Тащить код откуда попало не надо. Вы сами его напишите, когда придёт время.
