• Игролог
• Игры
• Об авторе

Mushroomer. Взгляд изнутри, игровая физика

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

Последний раз я работал над игрой аж 22 ноября прошлого года. Поскольку времени уже прошло много и я успел подзабыть, что и как работает, то работу я начал с рефакторинга кода. Ковыряясь в коде, я вспомнил о том, что я обещал по подробнее рассказать о том, как устроен Грибник внутри.

Скриншот игры с отладочной прорисовкой

�?гра Грибник, как уже известно — это усложненный платформер, с некоторой разновидностью динамических объектов, на основе которых строятся разнообразные головоломки на игровых уровнях. При этом в игре не используется сторонних физических библиотек. �?з-за специфичности геймплея мне пришлось писать свою игровую физику. Физическая модель игрового мира Грибника очень простая и не соответствует реальным физическим законам. Вся сложность была не столько в реализации самой физики, сколько именно в настройке игровых объектов и их возможного взаимодействия друг с другом. Поэтому при разработке игры я сразу предусмотрел отладочную отрисовку физических объектов, подобную тому, как это реализовано, например, в Box2D. �? признаться, сам того не подозревая, я избежал просто огромную кучу возможных проблем при настройке и отладке игрового мира.

В физическом мире Грибника существует только один вид проверки столкновений — это квадратные/прямоугольные формы. Все динамические объекты имеют одинаковый вес, а так же на них постоянно действует гравитация и некоторые из них даже умеют засыпать, прямо как в Box2D :) Как раз за счет засыпания камни имеют игровую фичу зависания в воздухе, на основе которой строится большинство задачек.

У каждого игрового объекта есть основное физическое тело, с которым могут сталкиваться другие тела и реагировать на него. А так же у каждого тела может быть любое количество «датчиков», используя которые, игровой объект, персонаж или монстр может менять свое поведение и реагировать на объекты, находящиеся рядом. Все датчики имеют так же квадратную форму, и за счет этого проверка столкновений для всех игровых объектов и их датчиков осуществляется одним методом и является стандартной. На мой взгляд, использование подобного рода датчиков очень удобно, поскольку это самый простой и наиболее точный способ определить наличие нужного объекта в строго заданной области.

С точки зрения кода, тела и датчики представляет собой один простой класс CollisionBox, в котором все параметры хранятся в самых обычных числовых значениях, а не в мувиклипах, и столкновения проверяются в ручную. То есть создание бокса для проверки столкновений производится в ручную в момент инициализации игрового объекта практически так же, как это реализовано в Box2D. Только вот физика и реакция объектов друг на друга — это неотъемлемая часть самой игры, и все необходимые расчеты производятся в коде самих игровых объектов.

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

 

• Зеленый — статические непроходимые объекты;
• Оранжевый — динамические непроходимые объекты;
• Розовый — датчики реакции/проверки;
• Синий — статические датчики.

 

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

 

1. Это уши убегающего гриба, ими он нащупывает приближающегося игрока и делает ноги.
2. У моста тоже есть ухо, когда с ним пересекается какой-либо из динамических объектов, мост прогибается, как-будто от веса этого самого объекта.
3. Это датчик персонажа, он нужен чтобы проверить наличие объекта, по которому можно ударить кувалдой, а так же он проверяет тип объекта. Например если это камень, то в момент удара будут произведены необходимые действия.
4. Этот датчик проверяет не помешает ли что-нибудь удару по месту под номером 3. А так же он проверяет наличие в этом месте монстра, чтобы в момент удара его замочить.
5. Этот датчик предназначен для проверки и удара по маленьким камням сбоку.

 

 

1. Датчик зрения гоблина для поиска приближающегося игрока. Не работает со спины, но зато со спины работает датчик под номером 3 — если игрок касается этой зоны, то гоблин разворачивается и пытается его ударить (симметричный датчик).
2. Зона удара гоблина, все объекты, которые попадают в эту зону, могут подвергаться удару (симметричный датчик).
3. Датчик, определяющий землю под ногами при движении, он не позволяет падать гоблину в ямы (симметричный датчик).
4. Этот датчик-пипка, нужен для определения активной зоны магического источника, когда он попадает в активную зону источника, камень поднимается вверх. А еще у маленьких камней есть снизу и в центре какие-то датчики, если честно я уже не помню зачем они нужны, но помню, что как раз с этими камнями было больше всего возни и без вспомогательных датчиков не получалось реализовать правильное поведение.
5. У больших камней все проще, но они так же не обделены датчиками-пипками, которые работают в паре. Только при условии, что оба этих датчика попадают в активное поле источника, камень начинает всплывать.

 

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

 

1. У злого гриба меньше датчиков, чем у гоблина, потому что по задумке это более тупое создание :) У него от гоблина осталось только зрение.
2. Эти оранжевые датчики есть у игрока, грибов и у гоблина с драконом. В отличии от физического тела, они помогают живности определять, с какой стороны препятствие и как выравнивать эту саму живность относительно препятствия, а так же помогают разворачиваться монстрам в правильном направлении.
3. Это та самая магическая сила источника, которая действует на датчики камней и персонажа.

 

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

А вообще, знаете, у меня сейчас даже какое-то неловкое ощущение. Наверное все потому, что это практически вся та голая правда, на которой держится и работает эта забавная игрушка. Вроде все настолько очевидно и просто, и вместе с тем настолько интимно...