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

Hitscan


В предыдущую эпоху многие игры для рендеринга 3D-сцен в 2D-изображения использовали технику под названием raycasting («бросание лучей»). Raycasting позволяет движку определять первый объект, с которым пересечётся луч. Но потом разработчики задались вопросом: «Что, если выпустить луч из ствола оружия, чтобы имитировать пулю?» Благодаря этой идее родился hitscan («сканирование попадания»).


Пример raycasting

В большинстве реализаций оружия с hitscan при выстреле игрока физический движок выполняет следующие операции:

  • Определяет направление, в котором указывает оружие.
  • Выпускает из ствола оружия луч на заданное расстояние.
  • Использует raycasting для определения того, попал ли луч в объект.

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


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

Hitscan по своей природе прост, но для добавления другой логики можно внести множество различных модификаций:

  • Если мы продолжим луч за первый объект, в который он попал, то сможем пронзать несколько объектов на линии, как рельсовая пушка (railgun) в Quake
  • Если убрать у луча максимальную дальность, то мы получим лазер, который будет лететь вечно, пока во что-то не попадёт
  • Можно программно сделать некоторые поверхности отражающими, чтобы от них отскакивали пули


Overwatch. Способность персонажа Гэндзи deflect — пример отражающей поверхности.

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

Поэтому неудивительно, что в логике стрельбы многих игр используется hitscan. Классическими примерами являются Wolfenstein 3D и Doom, но эта технология используется и в современных играх. Такие персонажи, как Солдат 76, Маккри и Роковая вдова из Overwatch используют оружие с hitscan, а большинство оружия в Call of Duty тоже основано на hitscan.




Overwatch, Call of Duty, Wolfenstein 3D

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

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


Halo. Заметьте, что дульная вспышка и эффекты попадания по земле происходят одновременно.

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

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

Баллистика летящего предмета


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


Max Payne 3

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

Так как пули в такой системе не движутся со скоростью света, можно также реализовать и временны?е свойства:

  • «Буллет-тайм», применяемый в Max Payne, Sniper Elite и Superhot.
  • Время перемещения пуль, то есть при стрельбе на дальние расстояния (или стрельбе медленно двигающимся снарядом) критически важным становится упреждение.
  • Отложенные взрывы снарядов, например гранат

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




Superhot, Battlefield 1, Overwatch

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

Также существует множество способов выполнения вычислений, но на высоком уровне разница заключается в том, где они решают обрабатывать «такт» игры — единицу измерения времени:

  • Такт вычисляется отдельно от логики рендеринга, то есть игра будет иметь более точное воспроизведение объектов даже при пропуске кадров. Для вычисления точного времени, прошедшего с момента предыдущего рендеринга, требуется больше логики.
  • Вычисление такта в каждом кадре; привязка физики к частоте кадров. Если отключить ограничение на максимальную частоту кадров или если игра начнёт пропускать кадры, то физика мира ускорится или будет тормозить.

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

Всё это кажется сложным, поэтому многие люди думают, что это относительно новый метод; однако на самом деле он возник раньше, чем hitscan! До игр жанра FPS существовало множество шутеров с видом сверху, например Asteroids, Space Invaders или Galaxian. Это аркадные игры 70-х годов, в которых уже была реализована баллистика снарядов, хотя и довольно примитивно.


Asteroids. Снаряды довольно сложно увидеть, но они есть!

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

Гибридные системы


Большинство игровых движков способно обрабатывать оба типа симуляций пуль: hitscan и баллистику. Это позволяет реализовать огромный выбор оружия; в таких играх, как Halo, GTA и Half-Life есть оружие, которое может поддерживать оба типа физики.



Halo. В Assault Rifle используется hitscan; в Needler используется баллистика снарядов

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

Также их можно объединять для улучшения особенностей игры. Отличным примером подобного является серия Sniper Elite; после нажатия на спусковой крючок движок использует hitscan, чтобы определить, сделан ли выстрел достаточно близко к любому обнаруживаемому объекту для включения slow motion. Если да, то выстрел пулей производится с расчётом баллистики в режиме «буллет-тайм».


Sniper Elite

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

Что же дальше? Как будет развиваться эта область в дальнейшем?

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

Комментарии (51)


  1. buglife
    13.11.2019 09:52
    -2

    We value your privacy!


    1. GCU
      13.11.2019 12:00

      После первого ответа можно обновить страницу — так не нужно будет отвечать на каждую анимацию ^___^


  1. GennPen
    13.11.2019 10:05

    Это значит, что если луч попал в объект, от пули уклониться невозможно,
    Заголовок спойлера


    1. scronheim
      13.11.2019 10:36

      Интересное как такое вообще попало в продакшен))


      1. asd111
        13.11.2019 11:02

        говорят это был баг, но он был настолько смешной что решили оставить как фичу


        1. tangro
          13.11.2019 11:51

          Да чемодан с такими возможностями можно выдавать в кино следующему Джеймсу Бонду!


      1. GCU
        13.11.2019 12:06

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


    1. kowack
      13.11.2019 13:04
      +2

      Заголовок спойлера


  1. triton
    13.11.2019 10:44

    Вспоминаются тепло любимые PPC из MechWarrior 2, которыми можно было нанести повреждения почти на любом расстоянии (даже вне зоны действия радара), главное — попасть на таком расстоянии.


    1. Kwisatz
      13.11.2019 11:40

      А мне Battlefield 3, я там ракетами попадал через всю карту, по косвенным признакам.


      1. korobkov-k
        13.11.2019 14:03

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


        1. Kwisatz
          13.11.2019 16:07

          Очень здорово, когда люди этим реально пользуются.

          Судя по тому количеству банов, что я получал, не все в восторге)

          Кстати не всегда подсветка нужна, открыл для себя я такую возможность увидев на границе прорисовке облако от разгоняющихся винтов вертолета)


    1. AllexIn
      13.11.2019 11:46

      В тройке тоже самое. Бесконечно летит.


  1. DDDDImoN
    13.11.2019 11:04

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

    П.С. была интересная статья на хабре, но в году так 2013 или 2016. Там очень подробно это всё описали, но по моему на примере hitscan. Явно что-то да уже поменялось.


    1. AllexIn
      13.11.2019 11:47

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


      1. DDDDImoN
        13.11.2019 13:05

        Постреляйте в тот же CS:GO при пинге 200+ms — после скажите, что сетевая задержка не играет особой роли в шутерах.
        А если ещё и игроков под 100 будет… на примере любого survival (SCUM, DayZ, Tarkov) — сколько боли будет в глазах при пинге в 200 ms :)

        По поводу фиксированного FPS и так понятно, но ведь каждый просчёт «1 кадра» должен учитывать и задержку каждого игрока, иначе картинка будет далеко не синхронная: стреляешь в бегущего игрока, а убить не можешь (если конечно не просто hitscan, но и тут нужно учитывать задержку). А вот как такое работает при гибридной реализации, было бы интересно прочитать.


        1. AllexIn
          13.11.2019 14:54

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


          1. Nokse
            13.11.2019 23:00

            Могу не согласиться)) Доводилось играть в CS 1.6 с пингом 120+, так вот в меня никто попасть не мог, зато я попадал нормально)) возможно, это особенность движка CS 1.6, или я так приспособился тогда, но вот как-то так)


          1. IamNoExist
            14.11.2019 06:04

            С херовым пингом будешь проигрывать всё время.

            Вы мало играли с людьми умеющими пользоваться преимуществами херового пинга. У них есть огромное преимущество в раше (rush) и префайре (prefire), так как при активном движении, они могут замечать врага раньше чем он заметит их.


        1. chupasaurus
          13.11.2019 18:41

          В CS:GO эталонно отвратительный сетевой код из-за возможности полного рассинхрона клиента и сервера даже при нахождении обоих на одной машине, плохой пример.


          1. Dee3
            14.11.2019 01:37

            Есть какие нибудь подробности почитать на эту тему?


            1. chupasaurus
              14.11.2019 11:04

              Да достаточно поднять сервер c картой Fast Aim/Reflex Training Map (там боты бегут на игрока) с любым тикрейтом (хоть 256) у себя и включить sv_cheats 1; sv_showimpacts 1.
              В принципе в игре можно сорвать синхронизацию поворота камеры на 90° при любом тикрейте.


  1. kalininmr
    13.11.2019 11:12

    в Wolfenstein 3D даже не совсем hitscan.
    вернее там объекты все кубиками


    1. pewpew
      13.11.2019 17:41

      Скорее квадратиками, ибо до кубиков движок не дорос, а спрайты там плоские.


      1. kalininmr
        14.11.2019 02:27

        ну да. квадратики, конечно :)


    1. kravtsov_victor
      13.11.2019 18:42

      Все объекты кубиками (хитбоксами) — это не исключает hitscan. Просто проще рассчитать попадание луча на кубик. С этим бывают интересные баги. В Half-Life 2, пример, хитбоксы были такого размера, что для убийства противника было достаточно выстрелить из арбалета в область в районе головы. Стрела попадает левее на 10 см — противник умирает от хедшота.


  1. andrewdrone
    13.11.2019 11:28

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


    1. AllexIn
      13.11.2019 11:48

      Постэффектом по глубине.


      1. andrewdrone
        13.11.2019 16:40

        разве это потребует меньше ресурсов чем затенение шейдера в зависимости от расстояния до игрока/источника света? К тому же, как в таком случае реализовать подсветку фонариком…


        1. 16tomatotonns
          13.11.2019 19:45

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


          1. andrewdrone
            13.11.2019 20:38

            Спасибо, добрый человек, пойду курить буфер глубины и как выборочно отключать постпроцессинг в зонах подсвеченных фонариком (pp volume? / mask)


    1. PoliTeX
      13.11.2019 15:45

      LODами?


  1. LibrarianOok
    13.11.2019 12:04

    Вспомнились игрушки MDK/MDK2, там была снайперская пуля, к которой цеплялась камера.


  1. Vsevo10d
    13.11.2019 12:21

    Меня больше интересует, как hitscan компенсируется в мультиплеере, где у обоих игроков скачущие пинги и в реальности, если ты нажимаешь выстрел, он происходит через миллисекунд 100 позже (твой лаг обработки выстрела + лаг движений того парня от него до сервера и до тебя). Нельзя ведь, чтобы игроки никогда не попадали?


    1. CorvOrk
      13.11.2019 12:41

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


      1. DDDDImoN
        13.11.2019 13:10

        Вот про эти стать я и упоминал в комментарии выше, спасибо добавил в избранное.
        Но судя по статье как раз речь идёт о hitscan, а после уже с raycast в прошлом — работает ли такая схема с гибридом? когда и hitcast и одновременно создаётся объект как пуля.


        1. mayorovp
          13.11.2019 14:00

          А почему нет?


        1. marsermd
          13.11.2019 18:32
          +1

          С проджектайлами история сложнее, конечно. И в моей статье это никак не описано.


          Решений есть несколько:
          1) не делать клиентского предсказания для проджектайлов. Самый простой способ и довольно популярный года до 2010, когда проджектайлы обычно были гранатами — редко используемыми и непредсказуемыми объектами
          2) не делать клиентского предсказания для проджектайлов, но делать компенсацию лагов на задержку выстрела. Используется на некоторых оружиях в овервотче. Идея в том, что у нас есть задержка от команды до самого выстрела. Например, это время на анимацию натяжения лука. В таком случае мы из этой задержки вычитаем пинг.
          3) делать клиентское предсказание с лагокомпенсацией. Это самая жесть.
          а) на клиенте мы выпускаем пулю сразу и симулируем её передвижение с клиентским предсказанием
          б) на сервере мы делаем компенсацию лага, т.е. делаем вид что пуля уже была запущена Ping секунд назад. Т.е. эффективно нам нужно подвинуть пулю вперед на расстояние (Ping * Velocity)
          в) на вражеском клиенте мы эту пулю должны привести в то же время, что и нашего персонажа (TServer + Ping), чтобы было легче уворачиваться. Для этого нам опять же надо воспользоваться клиентским предсказанием.


          И тут проблема: с точки зрения вражеского клиента, пуля заспавнится на расстоянии 2 Ping Velocity От стрелка. Это решается исключительно визуальным сглаживанием — экспоненциально интерполируем позицию пули для рендеринга между позицией выстрела и предсказанной позицией пули.


          Этот способ также используется в овервотче (могу ошибаться насчёт экспоненциальной интерполяции снаряда)


          1. DDDDImoN
            13.11.2019 21:56

            Т.е. по пункту 3 если вдруг пуля уже выпущена, а враг двигаясь по намеченной траектории вдруг за какие то доли секунды нажимает шаг влево/вправо и т.д. (начинает «мансить» — по моему так оно называется), всё равно получит пулю «в лоб» как ни крути? Т.к. предсказать клиент не может куда шагнёт игрок (предсказания ведь явно рассчитываются по вектору в сторону движения)?
            (Ping+Velocity)+(TServer+Ping) может, да и будет явно больше чем приемлемая компенсация погрешности (общая маленькая задержка, к примеру пинг меньше 10 ms), чтобы при большом кол-ве клиентов делать такие предсказания.


            1. onlinehead
              14.11.2019 00:11

              Т.е. по пункту 3 если вдруг пуля уже выпущена, а враг двигаясь по намеченной траектории вдруг за какие то доли секунды нажимает шаг влево/вправо и т.д. (начинает «мансить» — по моему так оно называется), всё равно получит пулю «в лоб» как ни крути?

              Из опыта игры в Overwatch на далеких серверах — судя по всему да. При пинге 30-40 на европейских такого не замечал, а вот при игре на американских серверах при задержке 130-140 схлопатать хэдшот от MсCree или стрелу от Hanzo в момент этой доли секунды, когда нажимаешь влево\вправо — такое бывает. Причем на реплее от лица игрока этого движения нет, а ты успеваешь нажать кнопку и поидее должен был бы уже немного сдвинуться (и даже кажется что сдвинулся, но я это склонен списывать на предсказания собственного мозга).
              Другое дело что на американских серверах все равно, к сожалению, приятнее играть из-за контингента и подхода к процессу, но это уже к вопросам предсказания попаданий слабо относится.


              1. Darth_Malok
                14.11.2019 05:32
                +2

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

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


      1. lain8dono
        13.11.2019 18:41

        Ещё на статьи Pixonic стоит обратить внимание.


    1. voidMan
      14.11.2019 13:01

      Есть отличное видео на Battle(Non)Sense с наглядными поясненинями как это решается в современных шутерах www.youtube.com/watch?v=hiHP0N-jMx8

      На этом канале постоянно разбирается неткод, пинги современных игр и всякое такое, рекомендую, если вопрос интересен.


  1. Tsvetik
    13.11.2019 13:15

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


    1. Fenzales
      13.11.2019 13:25
      +1

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


    1. AllexIn
      13.11.2019 14:57

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


    1. OutOfMemory
      13.11.2019 21:14

      Попадания пуль вычисляются на этапе проверки коллизий. Коллизии (в общем случае) проверяются каждый такт вычислений физического движка (не путать с FPS).
      Вычисления коллизий начинаются с определения вектора скорости объекта, он откладывается от текущего положения к будущему.
      Затем по концу вектора определяется положение Bounding Box-ов (BBox, ограничивающий параллелепипед) пули и движущихся окружающих объектов. По пересечению ББоксов определяются все столкновения и попадания.
      Для упрощенных вычислений ББокс пули может отсутствовать и тогда вычисляется только пересечение вектора движения пули и ББоксов окружающих объектов.
      В частном случае (например, в старых играх) ББокс статичный и если нет дополнительных проверок, то объекты могут пролететь один сквозь другого, чем пользуются читеры и абьюзеры.
      В современных движках могут применяться разные алгоритмы определения коллизий. Чаще всего — комбинированные, для каждого типа объектов свой алгоритм. Могут определяться точки касания пересекшихся объектов для точного расчета физики. Могут применяться вытягивающиеся ББоксы, у которых чем выше скорость, тем более вытянутыми они станут.


    1. dev96
      13.11.2019 23:45

      Можете почитать про алгоритмы CCD (Continuous Collision Detection).
      Везде проблема с туннелированием решается по разному.
      Ну и проблема эта возникает не только с линейным движением, но и с вращательным.
      Havok, например, не решает в CCD проблему быстрого вращения.


    1. elmm
      14.11.2019 11:39

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

       PS: надо читать коменты, перед тем как их писать. Выше уже написали про CCD


  1. OldGrumbler
    13.11.2019 14:12

    Помнится, в старом добром DOOM при пилении розового бодуна бензопилой на нем появлялись кровавые всплески, как от шотгановской картечи)))


  1. elmm
    14.11.2019 11:43

    Помню как был 90х поражен игрой Delta Force где у пуль была скорость, баллистика. Надо было брать упреждение при стрельбе из снайперской винтовки. Зато попасть в бегущего врага с километровой дальности вызывало непередаваемые эмоции.