хитбокс что это в играх

Выбор редакции

Топ-25 лучших аниме про вампиров.

Новинки аниме зимы 2021-2022.

Топ-1000 лучших зарубежных.

Что такое хитбоксы и как они работают?

Спросите любого разработчика о том, что такое хитбоксы и увидите букет из разных реакций. Кто-то будет с болью вспоминать об их создании, а кто-то скажет, что до сих пор находится в размышлениях об их природе. По своей сути хитбоксы [hitbox] – это невидимая геометрия, отвечающая за столкновения объектов.

Но хотя хитбоксы важны для большинства игр, они также странные и сложные. Они окутаны математическими формулами для того, чтобы в игре все было «справедливо». Hitbox – это попытка заставить игру вести себя так, как думают игроки, и это делает их серьезной задачей дизайна, которая включает в себя обман и пристальное внимание к деталям. Короче говоря, создать хороший хитбокс сложно, и разработчикам игр приходится решать эту проблему снова и снова. На РС Gamer разбирают, что такое хитбоксы и как они работают.

Что такое хитбокс?

Хитбоксы работают в обоих направлениях. Вам нужен хитбокс для того, кто наносит удары и еще один для того, по кому бьют [для вторых часто используют термин «хардбокс»]. В конце концов, для столкновения нужны двое. Но независимо от типа хитбокса правила их работы не универсальны. В разных играх используются разные подходы к их формам, размерам и поведению.

Например, хитбокс вашего персонажа в Dark Souls в значительной степени соответствует видимой модели. Так, чтобы избежать атаки, вам достаточно просто умело менять стойку.

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

Для таких 3D-игр от третьего лица, как эта, имеет смысл сопоставить хитбокс с вашим телом. Эта визуальная последовательность помогает вам понять, что происходит, и, следовательно, научиться играть.

Игры жанра shoot ’em up придерживаются другого подхода. Их хитбоксы обычно намного меньше, чем тело персонажа игрока [или корабля], чтобы помочь вам уклониться от пуль, которыми заполнен экран. Сделать хитбокс в полный размер корабля будет проигрышным вариантом для игрока. Инди shoot ’em up Blue Revolver в принципе выделяет хитбокс корабля. Он такой крошечный, что его трудно заметить, но он там есть.

Абстрактная игра Endlight также основана на этом классическом подходе. В Endlight у вашего корабля есть три хитбокса, в зависимости от ситуации. Тот, который сталкивается со стенами, он намного меньше своего реального размера, чтобы у вас было пространство для маневра. Второй, который сталкивается с объектом, когда вы собираетесь его подобрать, он немного больше, что помогает вам почувствовать себя умелым. И третий, в три раза больше вашего корабля, издает свистящий звук, когда вы проходите мимо стен и препятствий. Как мы видим, не все хитбоксы предназначены для боя.

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

Создание хитбоксов

Disc Room использует хитбоксы для создания эффектов, которые подчеркивают силу лезвий в игре. Это потрясает игрока, когда он действительно близко к нему. Вы слышите свист лезвий, а время немного замедляется.

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

Хитбоксы Disc Room существуют не только в пространстве, но и во времени. На самом деле игроку разрешено находиться внутри хитбокса до 50 миллисекунд прежде чем он умрет. Этого времени недостаточно, чтобы среагировать, но также может быть полезно.

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

«Мы еще не дошли до сути и, вероятно, продолжим учиться и открывать до самого конца проекта».

Какой вид имеют хитбоксы?

Несмотря на название, хитбоксы не всегда являются «коробками» как таковыми. Хитбоксы Dark Souls, Monster Hunter World и Apex Legends более или менее повторяют форму персонажей. В других жанрах, от платформеров до файтингов, они принимают разные формы: сферы, прямоугольники и капсулы.

В файтингах по-прежнему часто используются квадратные хитбоксы, установленные Street Fighter 2, с некоторыми исключениями, такими как Marvel vs. Capcom, в которых используются круги. В Mighty Fight Federation они обычно являются сферами и редко кубами.

В платформерах это обычно круги. Они помогают таким играм как N ++ чувствовать себя более естественным: ниндзя обычно огибает острые углы, а не задевает их.

«Если вы присмотритесь, в круге много пустого места, и покадрово вы увидите, что вас действительно не поражают вещи, которых касается модель», – говорит Райган Бернс, разработчик игры – «Но люди на самом деле не замечают».

Хитбоксы и математика

Хотя дизайн хитбоксов довольно хорошо изучен, их технические детали все еще остаются сложной наукой.

«Я был одержим их изучением 20 лет. Это открытая проблема. Никто ее не решил. Я чувствую, что наконец понимаю, что делает ее сложной, но не знаю, смогу ли я ее объяснить» – говорит Бернс.

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

Подумайте о Doom Eternal как о простом примере: каждый кадр должен проверять хитбокс игрока относительно земли и каждой стены на уровне, а также каждого демона и объекта.

Для Endlight, в котором на экране одновременно отображается множество объектов, разработчику Джиму МакГинли пришлось оптимизировать игру, сократив количество проверок неподвижных объектов и игнорируя объекты, находящиеся далеко от игрока. Поскольку игра находится в стадии разработки, МакГинли знает, что каждый объект дойдет до игрока через 20 секунд после появления, так что хитбокс выдается только на 18-той секунде.

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

Источник

Создаём файтинг в Unity: реализация Hitbox и Hurtbox

Объяснение

Что же такое hitbox и hurtbox? Разве это не одно и то же?

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

Hitbox — это невидимый прямоугольник (или сфера), определяющий, куда попадает атака.

Hurtbox — это тоже невидимый прямоугольник (или сфера), но определяющий место, в которое игрок или объект может ударить с помощью Hitbox.

На этом изображении из Street Fighter IV красный прямоугольник — это hitbox, а зелёный — hurtbox

Стоит заметить, что размер и позиция hitbox-ов и hurtbox-ов зависит от воспроизводимого кадра анимации:

В примере из Killer Instinct мы также видим ещё один тип прямоугольников, а именно Pushbox (жёлтый прямоугольник; Hurtbox — это пустые зелёные прямоугольники). Pushbox — это область, обозначающая пространство, физически занимаемое персонажем, не позволяющее им накладываться друг на друга.

В большинстве игр жанра fighting и beat ’em up существует ещё два типа областей, которые мы для простоты не будем рассматривать:

Grab или throw box определяет область, за которую персонажа можно схватить или бросить, а block box определяет область, в которой атакуемый игрок, нажимающий кнопку «назад», начинает блокировать атаку вместо движения назад.

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

Хорошее объяснение этого на примере Street Fighter представлено в видео.

Итак, разобравшись с терминологией, давайте приступать к работе.

Чего мы хотим

Давайте рассмотрим каждый тип области, с которым мы хотим работать, и скажем, чего мы от них хотим:

Pushbox: нам нужно, чтобы два pushbox-а соприкасались, но не накладывались друг на друга (именно поэтому они называются «областями отталкивания» (pushbox) — они толкают другого персонажа). Pushbox-ы должны взаимодействовать только с другими pushbox-ами.

Hitbox: мы должны иметь возможность проверки наложения его на Hurtbox в произвольных кадрах. Он должен взаимодействовать только с Hurtbox-ами.

Использование стандартных компонентов Unity

В первую очередь мы можем попробовать привязать разные типы областей к стандартным компонентам Unity. Очевидным выбором будет какой-нибудь Collider.

Pushbox можно непосредственно реализовать как Collider плюс Rigidbody. Он будет вести себя точно так, как нам нужно — реагировать на коллизии с объектами и не накладываться на другие Pushbox-ы.

Единственное, о чём нам нужно беспокоиться (кроме правильной настройки Rigidbody) — о реализации свойства «может иметь коллизии только с другими Pushbox-ами«. Если вы знакомы с системой физики Unity, то уже знаете, что решение заключается в использовании слоёв и матрицы коллизий слоёв. Для понятности мы можем создать слой с названием Pushbox, назначить его нашему объекту и настроить матрицу коллизий таким образом, чтобы Pushbox выполнял коллизии только с Pushbox.

Для Hurtbox-ов мы можем взять Collider, использующий isTrigger. Так мы гарантируем, что он не будет выполнять коллизии в физическом смысле и будет только регистрировать другие коллайдеры, попадающие в его область. Для самой регистрации удара нам нужно добавить в тот же объект скрипт, реализующий событие OnTriggerEnter, возможно, с проверкой тэга входящего коллайдера, чтобы убедиться, что вызвавший событие коллайдер является нужным нам, а затем выполнить вычисления урона и здоровья, необходимые игре. Вероятно, вам знаком такой подход.

Также нам понадобится создать слои Hurtbox и Hitbox, и мы снова воспользуемся Layer Collision Matrix, чтобы Hurtbox выполнял коллизии только с Hitbox, и наоборот.

Для нанесения урона Hurtbox-у нам нужно добавить скрипт в тот же объект, чтобы наш Hurtbox мог использовать GetComponent и получал его, чтобы узнать, сколько урона нужно нанести. Мы можем сделать это также другим способом: вызываемым для обоих Collider-ов OnTriggerEnter. Также нам нужно найти способ делать наш Hitbox активным только тогда, когда мы хотим, а не в каждом кадре и не тогда, когда персонаж не атакует. Для этого мы просто может отключать скрипт, поскольку в соответствии с документацией события Trigger передаются отключенным MonoBehaviours, чтобы позволить включать Behaviours в ответ на коллизии.

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

Проблемы

Создаём всё сами

Как вы наверно поняли из сказанного выше, Pushbox-ы и Hurtbox-ы достаточно удобно реализуются стандартными компонентами Unity.

У Hurtbox-ов всё ещё есть вышеупомянутые проблемы, и мы решим некоторые из них, но основной сущностью, требующей собственного абстрагирования, является Hitbox.

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

Мы не хотим создавать отдельный объект Hitbox для каждой из атак, и здесь мы можем использовать одни и те же, меняя их размер!

Hitbox-ы

Нам нужно, чтобы новый компонент решал следующие задачи:

Поведение

Во-первых, как нам проверить, что какая-то область накладывается на Collider? Ответ заключается в использовании UnityEngine.Physics.

В Physics есть множество методов, способных выполнить эту задачу. Мы можем указать нужную нам форму (Box, Sphere, Capsule), а также при желании получить Collider-ы, которые мы ударяем (если они есть) в виде массива или передать массив, чтобы заполнить его этими Collider-ами. Пока мы не будем об этом думать, но в первом случае выделяется новый массив, а во втором мы просто заполняем уже существующий.

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

Нам нужно задать размеры проверяемого прямоугольника. Для этого нам требуется центр прямоугольника, его половинная величина, поворот и слои, которые он должен ударять. Половинная величина — это половины размеров в каждом из направлений, например, если у нас есть прямоугольник с размером (2, 6, 8) то его половинная величина будет равна (1, 3, 4).

В качестве центра мы можем использовать transform position GameObject-а, а для поворота — transform rotation GameObject-а, или добавить общие переменные для задания конкретных значений.

Половинная величина — это просто Vector3, поэтому мы сделаем его общим и будем использовать.

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

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

Визуальное представление

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

Так как же нам отрисовать прямоугольник в окне Scene, но не в самой игре? С помощью OnDrawGizmos.

Как сказано в документации, Gizmos предназначены для визуальной отладки или вспомогательных построений в окне scene. Именно то, что нам нужно!

Мы дадим нашему Gizmo цвет и матрицу преобразований. То есть мы просто создаём матрицу с позицией, поворотом и масштабом transform-а.

При желании можно использовать OnDrawGizmosSelected, чтобы отрисовывать прямоугольник только при выборе объекта.

Настраиваемость и гибкость

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

В нашем случае мы позволим вносить быстрые изменения в форму и цвет хитбокса. Если вы используете Anima2D или какую-то скелетную анимацию, то вам возможно потребуется. чтобы Hitbox масштабировался в соответствии с масштабом костей.

Для изменения формы достаточно всего лишь добавить булево свойство и менять OverlapBox на любую другую форму, например на OverlapSphere. Для настройки сферы необходимо будет добавить публичное свойство радиуса. Не забывайте, что для отрисовки новой формы нужно будет изменить событие OnDrawGizmos (в нашем примере это будет DrawSphere).

Следует учесть, что мы не добавляем новый компонент и ничего не удаляем, а просто создали булево значение, которое будет выбирать накладываемую форму при проверке коллизий. Оно позволяет нам изменять форму хитбокса в зависимости от атаки (или даже для одной и той же атаки).

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

Мы создадим enum для состояния и три цвета, которые добавим как свойства нашего Hitbox-а.

Ваш класс может выглядеть примерно так:

Теперь мы можем обновлять gizmos, заменив строку Gizmos.color = Color.red; на вызов нового метода:

Так где же мы будем изменять состояние? Нам нужны три элемента:

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

Независимость от Unity Events API

Как вы возможно знаете, для проверки чего-то в каждом кадре мы можем использовать Update (ради упрощения я не добавляю проверку на изменение размера):

Как вы видите, мы выполняем возврат, только если текущее состояние имеет значение «Closed». Это значит, что мы по-прежнему проверяем коллизии, если Hitbox с чем-то сталкивается, что позволяет Hitbox-у ударять несколько объектов одновременно, а не только первый ударенный. В своей игре вы можете выполнять обработку иначе.

Мы используем Update, но не хотим зависеть от Unity Events API! Решение может заключаться в создании собственного публичного метода обновления, который можно назвать hitboxUpdate (содержимое его будет таким же, как и у метода Update), и вызывать только в Hitbox-ах, используемых в текущей атаке.

Очевидно, что нам понадобится вызывать Update() в каких-то объектах выше по иерархии, но нам точно не нужно использовать их в каждом Hitbox-е постоянно просто потому, что они есть.

Использование Hitbox-а скриптом в другом объекте

Помните — проблема использования Collider заключалась в том, что для реализации OnTriggerEnter нам нужен был скрипт в том же GameObject? Так как мы используем собственный скрипт и можем добавлять его к чему угодно, решение достаточно очевидно.

Мы добавим объект в качестве свойства, чтобы можно было вызывать для него какой-то метод при коллизии Hitbox-а.

Для решения этой задачи можно использовать разные подходы:

Давайте создадим и применим интерфейс:

Добавим его как свойство в наш Hitbox…

Также при желании можно использовать вместо одного респондента массив.

Давайте используем респондента:

Если вам незнаком оператор «?», то прочитайте это.

Hitbox-ы должны быть применимыми к нескольким разным атакам, а не привязаны к одной

В этом разделе я объясню, почему не важно то, что мы не можем задать HitboxResponders с помощью редактора.

Сначала давайте поговорим об этих «респондентах». В выбранном нами для реализации Hitbox-ов подходе респондентом является любой класс, который должен что-то делать, когда Hitbox находится в коллизии с Collider-ом, то есть реализует IHitboxResponder. Для примера можно взять скрипт атаки: мы хотим, чтобы он наносил урон тому, что мы ударим.

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

Усовершенствование Hurtbox-ов

В идеале для Hurtbox-ов мы хотим реализовать более-менее те же пункты, что и для Hitbox-ов. Это должно быть проще, потому что у Collider-а есть необходимый нам функционал. Также нам нужно использовать Collider, иначе Physics.Overlap… не будет сообщать об ударе.

Заметьте, что благодаря тому, как мы структурировали код, нам не нужно ни для чего использовать OnTriggerEnter, мы получаем скрипт с помощью GetComponent.

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

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

Ещё одним подходом будет добавление и удаление компонентов через код, но такое решение прибавит кучу ненужного мусора и вероятно будет не таким точным.

Было бы идеально, чтобы Hurtbox наследовал от Collider-а, а вся его логика форм была внутренней и мы могли бы отрисовывать только ту форму, которую сейчас используем, но мне не удалось заставить эту систему работать так, как хотелось.

Что дальше?

Если вы повторяли внимательно следили и повторяли за операциями в посте, то теперь у вас есть реализованные в Unity hitbox-ы, hurtbox-ы и pushbox-ы. Но что более важно, теперь мы знаем эти абстракции, и это сильно упростит работу, если вы будете надстраивать что-то поверх них.

Вероятно, сейчас инспектор скриптов у вас выглядит ужасно, но не волнуйтесь, это мы рассмотрим в следующем посте:

Источник

На чем играть в файтинги? Геймпад vs Стик vs Hitbox vs… Клавиатура!?

На чем играть? Пожалуй, этот вопрос задает себе любой новичок в мире файтингов. Конечно, первый девайс мы получаем по умолчанию вместе с игровой системой, однако потом все становится не так просто. И наш любимый жанр в этом плане особенный: по сравнению с шутерами или стратегиями, для файтингов изобрели просто неприлично много устройств, с помощью которых можно мешить ДП 🙂 Далее я разберу основные преимущества и недостатки представителей этого электронного питомника.

Надо заметить, что SF4 стал первым файтингом, в который я играл серьезно. Триалки на 100%, онлайн-матчи, бесконечное изучение матчапов и фрейм даты за всех персонажей игры. По началу все было хорошо. Но шли месяцы и удивлению моему не было предела. Почему-то верный геймпад оказался просто не приспособлен для выполнения части игровых задач!

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

+ Удобный. Легко носить с собой и просто использовать;

+ Доступный. В магазинах и в интернете можно найти множество моделей по сходной цене;

— Совершенно не приспособлен для некоторых приемов. Так что выбирайте своего персонажа соответственно;

— Мало приспособлен для некоторых игровых техник (плинкинг, пиано инпут и др.). Так что выбирайте свою игру соответственно;

— Перед покупкой нового пада на ПК желательно прочитать кучу отзывов на всевозможных форумах. Под маской «фирменных» девайсов часто продается барахло из КНР, на котором играть тоже можно, но сложно.

К такому расположению ударов я уже привык, играя на клаве, так что осваивать пришлось только саму палку у моей «палки». Для нее нужно иметь подвижное запястье, а не ловкие пальцы. 360-я и переходом «вниз-вверх».

А еще он тяжелый. И это уже не шутка. Как-то мне просто пришлось про # @% ть важный турнир, потому что в другом городе я ехал вместе с семьей и сумками по 20 кг. Приподняв перед отъездом всю ношу, я просто плюнул и выложил стик. Неделю не тренировался и играл на чужой палке.

восемь палок из десяти.

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

Настройки клавиатуры тоже позволяют так выпендриться (см. выше), и привыкнуть к «вверх под большим пальцем» довольно просто и даже весело. Вот только пробел на клаве — не самая отзывчивая кнопка, так что данная схема управления не пользуется большой популярностью среди ПеКарей. У ХБ таких проблем нет. Более того, ХБшный вверх расположен так, что его удобно нажимать и левой и правой рукой, что открывает интересные возможности.

Источник