Что такое коллизия в играх

Что такое коллизия в играх

Коллизия — это упрощенная геометрия, которая повторяет общую форму модели с меньшим количеством полигонов и создает возможность столкновений игрока с 3D объектами в игре. На нее требуется минимальное количество полигонов, отсутствие мелких деталей, определяется все это по принципу достаточности в каждом конкретном случае. Ее можно создать автоматически с помощью инструментов игрового движка, либо вручную. В некоторых случаях более подходящим вариантом будет создание вручную. В Unreal Engine 4 есть базовая утилита создания геометрии коллизии в Static Mesh Editor.

Самостоятельно коллизию можно создать двумя способами. С помощью примитивов в самом движке в разделе Static Mesh Editor — Collision, либо в 3D редакторе. При ручном создании, коллизия должна совпадать по имени с мешем для которого была сделана, обычно она имеет какие-либо дополнительные префиксы к основному неймингу, например, UCX_SM_Wood_Chair_A . Документация Unreal Engine приводит в пример следующие виды префиксов:

1. UBX_имя объекта – при наличии коллизии в виде бокса без изменений.
2. UCP_имя объекта – капсульная коллизия, представляющая собой цилиндрический объект с вершинами в виде полушарий. В ней не должно быть большого количества сегментов.
3. USP_имя объекта – коллизия в виде сферы с небольшим количеством сегментов.
4. UCX_имя объекта – сложная форма меша, не имеющая в себе разрывов, отверстий и внутренних углов.

Лучшим решением при создании коллизии является ее разбиение на простые примитивы, которым не желательно пересекаться между собой. Если коллизий несколько для одного объекта, они должны иметь уточнения в нейминге. Коллизия экспортируется вместе с основным мешем в один FBX файл (она может быть скрыта или видимой, это не имеет значения в технической работе коллизии при экспорте), расположение пивота у коллизии и меша должно совпадать и находиться в центре координат.

В выпадающем списке раздела Collision есть различные способы добавления коллизии. Первые три: Add Sphere/Capsule/Box Simplified Collision являются примитивами, которые можно редактировать с помощью пивота при нажатии на появившуюся сетку, кроме того, ее можно дублировать через Ctrl+D (Хоткей актуален для UE5, для UE4 — Ctrl + W). Следующие варианты идут с добавлением K-DOP. Это простые генераторы коллизии, где K – число плоскостей, проецируемых по выбранной оси (X, Y, Z).

• 10 – бокс с 4 забевеленными эджами (гранями) по одной из осей.
• 18 – бокс со всеми забевеленными эджами.
• 26 – бокс со всеми забевеленными эджамии и углами.

Еще одним вариантом создания автоматической коллизии является Auto Convex Collision. Появляется панель Convex Decomposition, в которой находится три параметра:

• Hull Count – общее количество примитивов.
• Max Hull Vertex – общее количество вершин, которое будет иметь коллизия.
• Hull Precision – коэффициент точности проекции коллизии.

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

Добавленную коллизию можно удалить через Remove Collision в выпадающем меню при нажатии раздела Collision.

Collision Pressets (коллизионные прессеты)

• Default – используются параметры выставленные в Static Mesh Editor.
• Custom – задаются пользовательские параметры для инстанса.
• NoCollision – нет коллизии.
• BlockAll – статический объект блокирует по умолчанию все Actor.
• OverlapAll – статический объект при пересечении задает overlap событие по умолчанию все Actor.
• BlockAllDynamic – динамический объект блокирует по умолчанию все Actor.
• OverlapAllDynamic – динамический объект при пересечении задает overlap событие по умолчанию все Actor.
• IgnoreOnlyPawn – игнорируется только объект типа Pawn (например, персонаж игрока).
• OverlapOnlyPawn – задает при пересечении overlap событие только объектом типа Pawn.
• Pawn – сам объект типа Pawn, который может использовать капсульную коллизию.
• Spectator – объект типа Pawn, который игнорирует все статические Actor.
• CharacterMesh – объект типа Pawn, который используется для персонажа.
• PhysicsActor – Actor с симуляцией.
• Destructible – разрушаемый Actor.
• InvisibleWall – статический невидимый объект.
• InvisibleWallDynamic – динамический видимый объект.
• Trigger – динамический объект, используемый как триггер.
• Ragdoll – SkeletalMeshComponent с симуляцией.
• Vehicle – блокирует другой транспорт, статические и динамические объекты.
• UI – статический объект, который перекрывает все Actor.

• Project Default – задаются параметры по настройкам проекта.
• Simple and Complex – в зависимости от запросов в сцене может быть использована простая и сложная коллизия.
• Use Simple Collision as Complex – используется только простая коллизия.
• Use Complex Collision as Simple – используется только сложная коллизия.

• NoCollision – тело коллизии не будет видно и как-либо использовано в пространстве или симуляции. Является лучшим вариантом для оптимизации.
• Query Only – используется для пространственных запросов. Подходит для движения персонажей и объектов, которые не нуждаются в физической симуляции.
• Physics Only – подходит для физической симуляции (скелетная анимация и ограничения). Полезно в работе с вторичной анимацией, где не нужно обнаружение костей.
• Collision Enabled –может быть использовано как для пространственных запросов, так и при физической симуляции.

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

• WorldStatic – используется для неподвижных объектов. Параметр хорошо подходит для объектов с одноименным типом (например: пак коробок или бочек).
• WorldDynamic – используется для Actor, которые могут быть подвижны под влиянием анимации или кода (например: лифт, двери).
• Pawn – объекты, контролируемые игроком (например: персонаж).
• PhysicsBody – объект перемещаемый благодаря физической симуляции.
• Vehicle – транспорту задается параметр по умолчанию.
• Destructible – разрушаемому объекту задается параметр по умолчанию.

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

Проработка окружения в геймдеве: собираем первую игровую сцену

Финальная статья из цикла «Арт» для начинающих разработчиков — наполняем деталями локации и полируем сцены.

Автор: Александр Новиков. По образованию программист, но в геймдев попал как концепт-художник. Потом переучился на 3D-художника и пришел в Pixonic. Работал над War Robots и другими проектами компании. Стал техлидом, и сейчас занимается прототипами игр.

В предыдущей статье о 3D-моделировании мы учились создавать уникальные внутриигровые объекты. Разобравшись с принципами создания арта, можно заменять им «серые кубики» из прототипа, чтобы потихоньку готовиться к первому релизу. Следующий этап — объединить объекты в одну сцену.

В конце статьи — последнее в этом цикле домашнее задание для конкурса работ. Выполните его, чтобы выиграть лимитированное издание Kingdom Hearts III PS4 Pro Bundle и прокачать скилл геймдизайнера.

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

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

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

Rise of the Tomb Raider

Пройдитесь по сцене — нет ли там слишком длинных и однообразных маршрутов, не кажется ли сцена слишком «пустой» местами?

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

Можно было бы поставить вместо решеток обычные стены, а источник света повесить под потолок. Или просто убрать все трубы и решетки. Окружающее пространство стало бы свободнее и лучше освещалось. Но страшно бы не было.

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

Акценты. Ещё одна задача при разработке игры — расставить акценты. Ключевые элементы геймплея должны быть выделены, а фон не должен отвлекать внимание от процесса.

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

Может показаться, что все элементы и объекты на скриншоте выше расставлены незамысловато. Но присмотритесь — маркер цели отлично читается на общем фоне, хотя это просто элемент UI. Общий фон не забирает на себя много внимания — он приглушен туманом и имеет минимальную контрастность. Ближний фон, наоборот, весьма контрастный. А ёлки, камни и платформа показывают понятный игроку путь до цели.

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

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

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

Обратите внимание на все интерактивные объекты на сцене — они должны быть отличимы от остальных. Стоит также прикинуть, что будет, если игрок не заметит их и просто пройдёт мимо.

Лаконичность. Не менее сложным бывает вовремя остановиться и не перегружать игровую сцену деталями. Когда объектов слишком много, игрок быстро устает от картинки.

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

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

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

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

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

Тестировать сцены и левел-дизайн так же важно, как идеи, механики и визуал. Для независимых разработчиков варианты собрать фидбек остаются теми же, что и в прошлых статьях: дать поиграть билд друзьям; завести свой YouTube-канал или странички в соцсетях, чтобы делиться ходом разработки и собирать комментарии; создать Discord-канал (или поискать чужие — там сидит много энтузиастов). Много фидбека можно собрать на Reddit, если не пугает английский, или на DTF.

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

Также стоит проверить коллизии на всех объектах, чтобы игрок не смог попасть за пределы сцены. Коллизия — это упрощённая геометрия объекта, которая позволяет взаимодействовать с другими объектами: столкновения, выстрелы, навигация ИИ (противники должны обходить объекты с коллизией) и прочее. Например, если отключить коллизию в 3D-шутере, игрок просто провалится под землю — персонаж и поверхность не будут взаимодействовать, то есть сталкиваться.

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

Чтобы настроить лайтмэпы в Unity, раскройте вкладку Lightmaps в инспекторе объекта и нажмите на текстуре Open Preview. Откроется окно с общим лайтмэпом сцены, где жёлтым будет обозначен ваш пропс. Сразу видно, сколько места он занимает относительно других объектов.

Если встречаются артефакты в освещении или тенях, обязательно проверьте, что у объектов достаточно разрешения в лайтмэп-текстуре. В Unity за это отвечает параметр Scale In Lightmap. Дефолтное значение 1, а для малозаметных объектов можно поставить значение 0.5. Иногда, наоборот, приходится увеличивать это значение, когда свет запекается некорректно.

Здесь, подняв значение Scale In Lightmap c 1 до 1,6, мне удалось избавиться от «чёрного» камня после перепекания лайтмэпа.

После оптимизации ассетов, обратите внимание, чтобы не осталось белых засветов и полностью черных теней — это первые признаки несбалансированной картинки. В большинстве случаев объекты должны «читаться» даже в тени. Если какое-то пространство просто «залито» чёрным цветом, глаз воспринимает это как «провал» в окружении, как на примере с камнем выше.

Конечно, бывают исключения, особенно в 2D и инди-проектах. Всё зависит от вашего замысла.

Unepic. Темно, но тут своя атмосфера

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

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

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

Настраивать билды для мобильных платформ внутри движка лучше в начале или середине разработки, чтобы ошибки с компрессией текстур всплывали на ранних тестах. Но в процессе разработки не всегда получается настроить всё вовремя, поэтому перед финальным релизом необходимо пробежаться по контенту и всё проверить. Будет плохо, если где-то заваляется текстура маленького кристалла в разрешении 2k, а размер билда при этом вырастет на 5–10 Мбайт.

Итак, финальное задание на этот цикл, а приз — лимитированное издание Kingdom Hearts III PS4 Pro Bundle. Если вы уже выполнили задания из предыдущих статей, то будет совсем просто. Нужно вспомнить всё, что мы уже проходили, и собрать выполненные задания в одном письме:

1. Опишите визуальную стилистику своего проекта и перечислите ваших ближайших «конкурентов». Сделайте мудборд. Здесь поможет первая статья цикла.
2. Добавьте к письму уникальный концепт-арт или простой скетч любого объекта, персонажа или локации из игры. К концепту приложите ТЗ, по которому он рисовался. Это тема второй статьи.
3. Покажите законченный 2D или 3D-объект, сделанный по концепту (можно скриншотами или роликом на YouTube). Говорили об этом в третьей статье.
4. Дополнительный балл за собранную игровую сцену со своими оригинальными объектами. Тоже можно записать видеоролик.

Приём работ закроется 7 апреля в 23:00 по МСК — присылайте их на [email protected] . В середине апреля выпустим материал с итогами, подарим консоль и пойдём дальше — впереди цикл про маркетинг для инди-разработчиков. Будет интересно.

Для хитбоксов нет универсального решения — как устроена система регистрации столкновений в играх Статьи редакции

Журналист издания PC Gamer Алекс Уилтшир поговорил с несколькими разработчиками и узнал, как в играх реализуется система регистрации столкновений. Оказалось, что для каждого жанра подходит свой тип хитбоксов, который лучше всего соответствует геймплею и правилам. Мы выбрали из текста главное.

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

В разных играх работают разные правила, поэтому те решения, которые подходят для одной игры, могут всё испортить в другой. Тем не менее хитбоксы применяются в огромном количестве тайтлов: удары в Mortal Kombat, прыжок над пилами в Super Meat Boy, хедшот в Rainbow Six: Siege. Во всех этих случаях хитбоксы влияют на то, справился ли игрок с испытанием или нет.

Хитбоксы работают в обе стороны — всё же в столкновении принимают участие два объекта. Для этого существует понятие «хёртбокса» (hurtbox) — у кулака, бьющего противника, и пилы также существует невидимая геометрия, которая регистрирует попадание.

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

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

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

В играх жанра shoot ’em up используется другой подход. Там хитбоксы обычно намного меньше, чем сама модель или спрайт игрока. Это помогает уворачиваться от огромного количества пуль, которые зачастую заполоняют весь экран. Если бы хитбоксы полностью соответствовали аватару, то такие игры были бы намного более трудными и менее приятными для прохождения.

Абстрактный музыкальный экшен Endlight использует традиционные для shoot ’em up хитбоксы. В Endlight у корабля есть три хитбокса, каждый из которых выявляет определённый тип коллизий. Хитбокс, который регистрирует столкновения со стенами, намного меньше корабля — это даёт большую свободу маневрирования. Хитбокс, анализирующий столкновения с ценными объектами, значительно больше аватара. Из-за этого игрок ощущает собственное мастерство.

Третий хитбокс издаёт свистящий звук, когда игрок пролетает мимо стен и препятствий. При этом у него есть два размера: один больше корабля в три раза, а другой — в десять. Первый предназначен для небольших объектов, а второй — для крупных. В результате маленькие препятствия свистят только тогда, когда они находятся рядом, а большие — когда находятся далеко.

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

Это говорит вам о том, что опасность рядом. Так игра даёт больше времени, чтобы отреагировать.

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

При этом хитбоксы в Disc Room используют ещё и временные показатели.

Игрок может находиться внутри хитбокса до 50 миллисекунд, прежде чем умрёт. Это примерно три кадра. На самом деле этого недостаточно, чтобы успеть отреагировать, но у такого решения есть куча положительных эффектов.

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

Разработчики из Metanet потратил целых десять лет на настройку и полировку хитбоксов для своей серии платформеров N. Например, работа над хитбоксами продолжалась даже в последние недели создания N++. Именно тогда увеличились хитбоксы предметов, которые нужно собирать, и уменьшились хитбоксы опасных объектов.

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

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

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

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

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

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

Например, в Doom Eternal каждый кадр игра проверяет хитбокс игрока по отношению к земле, стенам и остальным объектам. У всех демонов есть хитбоксы, из-за которых они по-разному реагируют на снаряды. Каждая пуля, попадающая в окружение, должна оставлять след в правильном месте. Каждую секунду происходят тысячи проверок коллизий.

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

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

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

Ммм, лучшая сторона DTFа,)

Мы же не на подсайте о порно

Статья пустая, надо было писать то как хитбоксы соотносится с видимой моделью в сетевых баталиях. Примеры left 4 dead 2, cs, overwatch и прочее. В этих играх, же победа у того кто лучше видит хитбоксы, а не реальную модель.

Пример того, анализ чего я хотел увидеть в статье

Хитбоксы обсуждаете, а мемы не мемите

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

Оригинальная ещё на flash была 🙂

Не, ну это откровенно тупо

В целом статья хороша

Или еще пример — решил на днях посмотреть что за зверь такой этот TES Morrowind, о котором часто слышу много хорошего.
И в первой же стычке с врагом. не попадаю по нему мечом, при том что стою в упор и махаю без перерыва. Вернее попадаю но проходит одна атака из 5 примерно. Сижу в ступоре и не понимаю куда нужно бить и когда чтоб атака засчитывалась, но, судя по всему в морровинде используется система с шансом попаданий и шанс попадания равен навыку владения оружием. То есть если у тебя навык владения 10, то 9 из 10 атак уйдут в молоко, даже если по модельке ты попал. И вот не понятно — толи ты попал по врагу, но игра засчитала "промах" то ли не попал по модельке — сиди гадай — приятного в этом мало

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

Просто все хорошие разработчики игр знают кучу приемов, для хорошей реализации.

Хах, в 2018 году на чемпионате Quake Champions во время дуэли ракета пролетела буквально между ног у модельки персонажа и ход боя поменялся в корне — все участники сразу стали требовать у разработчиков вернуть классические "капсульные" хитбоксы вместо тех, которые точно повторяют видимые модели.

Реплай для всех:
Я не доволен тем, как построено предложение. Хитбоксы нужны для регистрации попаданий, а не для удовлетворения игрока. Нет хитбокса — нет регистрации. Тут скорее "почему хитбоксы не всегда соответствует моделе" или что-то вроде этого

А разве нет? Спорил тут с парнем по поводу хитбоксов в Mortal shell — он привел в пример момент, когда визуально гг не попал по врагу из-за того что враг попал в капкан и был в соответствующей анимации "обездвиживания"
Было бы честно если бы удар по обездвиженному врагу, которого ты заманил в капкан не прошел из за анимации высвобождения из этого самого капкана? По моему нет — игрок все просчитал и сделал верно, а наказание за то что враг пошатывался в анимации обездвиживания вызвало бы крайнюю степень фрустрации и ощущение рандома и несправедливости

И ни слова о SF5 с обложки, где много хохм с хитбоксами.

Хах. Знакомая ситуация с пилой.
В моей игре есть такой "противник" и после релиза, некоторые игроки жаловались на ее хитбокс. Хотя конечно же хитбокс пилы был почти 1 в 1 по ее спрайту (даже чуть меньше).
В итоге я сделал ее хитбокс еще меньше.

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

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

Например, в этой же игре была механика разрушения "пилы" другим объектом.
И тут уже уменьшенный хитбокс пилы, играл злую шутку. Так как, хоть и получить от нее повреждение стало сложнее, но также и уничтожить "пилу" стало сложнее. Что конечно же, не вызвало бы радости у игроков.

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

GameMaker Studio 2. Урок 2. События отрисовки. Коллизия. Как работают скрипты. Как подключить русский шрифт. Переходы между комнатами ⁠ ⁠

Как было сказано в прошлом посте, игра, которая будет сделана в ходе данных гайдов, будет относиться к жанру стратегий, а в качестве источников для «вдохновения» у нас — «Oxygen Not Included» и «Rimworld«. Теперь же конкретно поговорим с вами о том, что в игре должно быть реализовано, по пунктам.

—) Персонаж — игровой «объект», способный перемещаться по игровому миру и взаимодействовать с ним. Делятся на подконтрольных и неподконтрольных игроку. Игрок НЕ имеет прямого управления над своими подопечными, кроме специального «боевого» режима.

—) Каждый персонаж должен иметь или уметь следующее:

—) Взаимодействовать с предметами, расположенными на карте: подбирать их в свой инвентарь или выкладывать; взаимодействовать с рабочими станциями; сражаться (наносить, получать урон).

—) Каждый персонаж смертен. Каждый персонаж должен иметь ряд характеристик, которые он будет пытаться «поддерживать» на должном уровне, чтобы не умереть и продолжать быть эффективным. Эти характеристики:

—) Каждый персонаж уникален и должен отличаться от других. Черты, навыки с различными уровнями прокачки. Этот пункт может игнорироваться в случае, если это не подходит под конкретного персонажа.

—) Объекты, с которыми можно взаимодействовать через интерфейс игры и с которыми могут взаимодействовать персонажи или иные игровые сущности с какой-то целью.

—) Пример: верстак для создания вещей; исследовательский стол для открытия новых вещей и пр.

-) Интерфейс.
—) Простой, понятный. Желательно, на русском языке.
—) Хотя бы минимально настраиваемый.

Скажу сразу, что персонажей мы делать будем позже. Начнём мы с интерактивных объектов и размещения их в мире. Но, это будет потом.

Сейчас — продолжаем изучать матчасть.

События отрисовки.