Как сделать бег ue4
Создаем 2D платформер при помощи Unreal Engine 4. Часть 1 — Игровой персонаж, движение
Давайте подготовим раскадровки для 2х состояний: покой и бег, для этого необходимо удалить красный фон (нам ведь не надо, что бы персонаж перемещался всегда на фоне красного прямоугольника) и вырезать требующиеся части изображения, на выходе получая что-то вроде этого:
Из фоновых изображений пока вырезаем только пол:
Структурируем папки проекта и импортируем соответствующие изображения:
Далее необходимо из текстур извлечь, собственно, спрайты. Сделать это можно двумя способами: автоматически и вручную, замечу, что с автоматичемским извлечением может быть один нюанс: спрайты будут пронумерованы по возрастанию, но совсем не обязательно, что нумерация будет соответсвовать их положению в исходной текстуре, так что после извлечения рекомендую все тщательно проверить, что бы впоследствии не было артефактов анимаций. Поскольку у нас все же урок, сделаем все вручную.
Первым делом создаем еще пару папочек, на этот раз в “Sprites” → “Alucard”, внутри которой будут папки “Idle” и “Walking” с соответствующими спрайтами. Итак, создаем пустой спрайт, называем его “Idle_1” и открываем. Сразу же переходим в “Edit source region”, а в качестве текстуры-источника указываем текстуру «Alucard_Idle».
Один спрайт должен содержать один кадр анимации персонажа, так что скорректируем значения “Source UV” и “Source dimension”, что бы получить один кадр, либо просто дважды кликаем на нужно изображение, что бы автоматически определить его границы:
Проделываем то же самое с оставшимися кадрами покоя и ходьбы:
Из текстуры платфомы так же создаем спрайт, но, поскольку там всего одно изображение можно сделать просто через контекстное меню.
Самое время придать немного жизни нашим спрайтам! Для этого создаем “Animation flipbook”, даем ему имя и открываем. Добавляем соответствующие кадры по порядку и выставляем количество кадров в секунду по вкусу, мне нравится 6:
Повторяем для ходьбы и на выходе имеем 2 flipbook’а:
Теперь добавим на сцену нашу платформу, важно что в ее положении по компонента Y была равна 0. Далее добавим управление (в заготовке оно уже включено, но переназначим, как нам будет удобно): Edit → Project Setting → Input.
Переходим непосредственно к созданию персонажа. В папке “Blueprints” создаем новый BP, нас спросят, какой класс принта, выбираем “Character”, даем имя, открываем и направляемся в раздел “Components”. Добавляет к капсуле Flipbook, в качестве источника выбираем заготовленную Idle анимацию, так же добавляем SpringArm и к ней цепляем камеру, в принципе можно обойтись и без руки, но лучше с ней. Настраиваем размеры спрайтов и капсулы по вкусу, но капсулу лучше делать немного поменьше, что бы спрайт не парил над землей. У камеры убираем зависимость от контроллера и выставляем ортографический тип, глубину — по вкусу.
Компилируем, сохраняем. В настройках мира можно создать свой GameMode, либо поменять в уже существующем “Default Pawn Class” на только что созданного нами персонажа.
Теперь можно запустить и убедиться, что мы все сделали правильно и что наш персонаж нетерпеливо ожидает приказов.
Пора научить его передвигаться, для этого вновь открываем BP персонажа и переходим в раздел графа. Стоит отметить, что Blueprints – очень мощный инструмент, с его помощью можно обойтись в проекте без классического написания кода, но на деле это то же самое программирование, просто, собственно, писать надо будет разве что несколько имен, да значений. Итак, прежде всего надо добавить движение по вектору при событии MoveRight:
Тут происходит следующее: при воздействии на ось (у нас может быть два воздействия ± 1) происходит передвижение объекта по оси X на заданное воздействие. В принципе этого достаточно для передвижения, можно пробовать — компилируем, сохраняем, тестируем. Персонаж смещается вдоль оси, но без анимации, ведь мы не предусмотрели ее переключение.
Для переключения между анимациями нам необходимо заменить, собственно анимацию в flipbook нашего персонажа. Сделать это можно несколькими способами, но я предпочитаю наиболее универсальный и, как мне кажется, изящный. Создадим на графе Свое событие, назовем соответственно цели – “Update animation”.
Логика работы тут следующая: при вызове события во flipbook цели помещается заданная анимация. Сама анимация выбирается в зависимости от того, какая скорость у нашего объекта, если больше нуля — анимация ходьбы, иначе — покоя. Обновим и граф движения:
Появилось новое событие — “Event Tick”, оно происходит каждый кадр, соответственно каждый кадр у нас теперь происходит проверка необходимости смены анимации. Если сейчас запустить игру, то персонаж будет двигаться с анимацией бега, но всегда будет смотреть в одну сторону, исправим это:
Таким образом сегодня мы создали анимированного 2D персонажа, способного перемещаться по платформе. В дальнейшем добавим способность прыгать, сражаться и уничтожать врагов. Пожелания, комментарии и критика приветствуются.
UPD 1. По совету пользователя Torvald3d убрал билинейную интерполяцию на текстурах-исходниках персонажа. Просто заходим в импортированную текстуру и меняем фильтр на «ближайший».
Создаем 2D платформер при помощи Unreal Engine 4. Часть 1,5 — Прыжки
В прошлой статье мы подготовили персонажа и простую сцену, научились перемещаться горизонтально, пришла пора научиться, если и не летать, то, как минимум, прыгать!
Первым делом нам потребуется подготовить анимации. Как это делать, описано в части 1, для удобства я предпочитаю разделить прыжок на 2 условные части — прыжок и падение. До верхней точки в воздухе проигрываем первую анимацию, после, соответственно, вторую. Анимацию падения так же можно использовать при, собственно, падении с края обрыва или прочих препятствий. Подготавливаем Flipboocks, следует отметить, что скорость проигрывания и длительность показа отдельных кадров подбирается индивидуально.
Далее переходим, собственно, к отработке прыжков. Идем в Blueprint нашего персонажа, добавляем обработчик события прыжка — InputActionJump. Это простой обработчик нажатия клавиши, имеет два состояния — нажат и отпущен. В принципе, можно напрямую добавить функцию прыжка к нажатию клавиши, работать будет, но мы ведь стараемся делать хорошо, верно? В прошлый раз мы начали делать систему смены анимаций, она легко расширяется и может быть весьма гибкой, поэтому воспользуемся ею.
Что бы переключить анимацию, нам надо знать, что была нажата клавиша, так что добавляем на ввод булевую переменную и переводим в состояние истинности. Таким образом, отследим нажатие клавиши, после идет прыжок и обнуление (false) нашей переменной, с задержкой — анимация ведь занимает какое-то время.
На освобождение клавиши добавим другую булевую переменную — она нам потребуется позже. В итоге получаем простой алгоритм:
Расширяем нашу систему анимаций. У нас пояпилась новая возможность, так что добавим ветвление к выбору анимаций: проверим, может ли персонаж прыгать (встроенная функция, спасибо ребятам из Epic Games), если прыгать может — мы за земле, идем в уже существующую ветвь, если нет — мы в воздухе и анимации нужны другие.
Логика тут простая: если мы прыгать не можем, то надо определить по какой причине — мы либо прыгаем, либо падаем. В первом случае последовательно проигрываем прыжок/падение, во втором только падение.
Русские Блоги
Принцип движения игрового персонажа «Исследование в UE4» (часть 1)
Предыдущая статья В основном для популяризации науки о том, как движутся «персонажи» в игре. Сегодняшняя статья даст вам очень подробный анализ того, как Unreal Engine обрабатывает движение персонажа. Однако содержание статьи может быть относительно глубоким, и читатели должны иметь определенный опыт разработки игр, поэтому рекомендуется понимать его вместе с исходным кодом движка.
Поскольку статья очень длинная, я разделю ее на две, которые можно собирать и читать не торопясь.
Знайте оригинальную ссылку: https://zhuanlan.zhihu.com/p/34257208
Один. Глубоко понимать значение мобильных компонентов
Платформа GamePlay, предоставляемая UE4, предоставляет разработчикам идеальное мобильное решение. Поскольку UE принимает идею компонентного дизайна (то есть разделение и инкапсуляция различных функций в конкретный компонент), все основные функции этого мобильного решения передаются для выполнения мобильному компоненту. Логика движения будет обрабатываться по-разному в зависимости от сложности игры.Если это простая игра типа RTS с видом сверху, она может обеспечивать только базовое координатное движение; в ролевой игре от первого лица игрок может лететь в небо. Для дайвинга требуется более сложное движение. Но независимо от того, какой именно, UE в основном помог нам реализовать это, чему также способствовал его ранний опыт разработки игр FPS.
Базовое движение, обеспечиваемое двигателем, не обязательно достигает нашей цели, и мы не должны ограничивать нашу конструкцию. Например, карнизы и стена из света работают, супергравитация волшебного космического корабля, пружинные башмаки и управление полетом реактивного ранца. Эти эффекты требуют от нас дальнейшей обработки логики движения самостоятельно. Мы можем изменить ее на основе или настроить наш собственный режим движения. В любом случае эти операции требуют кропотливой настройки мобильных компонентов, поэтому мы должны глубоко понимать принципы реализации мобильных компонентов.
Кроме того, в онлайн-игре наша обработка движения будет более сложной. Как позволить игрокам на разных клиентах нормально работать на мобильных устройствах? Как сделать так, чтобы персонаж не «телепортировался» из-за небольшой задержки? Подход UE к этому аспекту заслуживает нашего размышления и изучения.
два. Основные принципы мобильной реализации
2.1 Мобильные компоненты и персонажи игроков
Движение персонажа, по сути, предназначено для разумного изменения координатного положения, а суть движения персонажа в UE заключается в изменении координатного положения определенного корневого компонента. На рисунке 2-1 показан наш общий компонентный состав для персонажа.Можно увидеть, что мы обычно используем CapsuleComponent в качестве корневого компонента, а координаты персонажа по сути являются координатами его корневого компонента, сетки сетки и других компонентов. Будет следовать за телом капсулы и двигаться. Когда мобильный компонент инициализируется, тело капсулы устанавливается как UpdateComponent мобильного базового компонента, и все последующие операции вычисляют положение UpdateComponent.
Рисунок 2-1 Компонентный состав символа по умолчанию
Конечно, нам не нужно устанавливать для тела капсулы значение UpdateComponent.Для DefaultPawn (наблюдатель) его SphereComponent используется как UpdateComponent, а для объекта транспортного средства AWheeledVehicle его компонент сетки Mesh по умолчанию используется как UpdateComponent. Вы можете определить свой UpdateComponent самостоятельно, но ваш пользовательский компонент должен наследовать USceneComponent (другими словами, компонент должен иметь информацию о мировых координатах), чтобы он мог нормально реализовать свою логику движения.
2.2 Дерево наследования мобильных компонентов
Рисунок 2-2 Схема классов отношений наследования мобильных компонентов
Следующим компонентом является UNavMovementComponent, который в большей степени обеспечивает поиск пути ИИ и включает в себя базовый статус движения, например, может ли он плавать, может ли он летать и т. Д.
Фактически, существует более часто используемый мобильный компонент, UProjectileMovementComponent, который обычно используется для имитации движения лука, стрел, пуль и других снарядов. Однако в этой статье мы не будем останавливаться на этом.
2.3 Краткий анализ родственных отношений классов мобильных компонентов
Предыдущий анализ в основном сосредоточился на самом мобильном компоненте, вот более полный обзор всей структуры мобильных устройств. (См. Рисунок 2-3)
Рисунок 2-3 Схема связанных классов мобильной платформы
В обычном трехмерном пространстве самым простым движением является прямое изменение координат персонажа. Поэтому, пока у нашего персонажа есть компонент, содержащий информацию о координатах, он может перемещаться по основным мобильным компонентам. Однако по мере того, как сложность игрового мира стала глубже, мы добавили площадку для прогулок и океан, которые можно исследовать в игре. Мы обнаружили, что движение становится более сложным. Игрок может ходить по земле под ногами, поэтому нам необходимо постоянно обнаруживать информацию о столкновении с землей (FFindFloorResult, FBasedMovementInfo); если игрок хочет плавать в воде, нам нужно определить объем воды (GetPhysicsVolume ( ), Событие Overlap, также требует физики); скорость и эффект в воде сильно отличаются от таковых на суше, поэтому запишите два состояния отдельно (PhysSwimming, PhysWalking); при движении анимационные действия совпадают, а затем обновляются Когда вы находитесь в позиции, обновите анимацию (TickCharacterPose); что делать, когда вы сталкиваетесь с препятствиями при движении, и как справляться с толканием других игроков (в MoveAlongFloor есть соответствующая обработка); игрового контента слишком мало, я хочу добавить некоторых NPC, которые могут найти свой путь, Необходимо настроить сетку навигации (с участием FNavAgentProperties); если игрок слишком скучен, пусть все вместе играют онлайн (имитация мобильной синхронизации FRepMovement, клиентская мобильная коррекция ClientUpdatePositionAfterServerUpdate).
С этой точки зрения сделать отличный мобильный компонент действительно непросто. Но несмотря ни на что, UE в основном делает это за вас. Благодаря приведенному выше описанию у вас теперь есть общее представление об обращении с мобильными компонентами во всех аспектах, но вы не сможете начать, когда столкнетесь с конкретными проблемами, поэтому давайте продолжим анализ.
три. Детальная обработка каждого состояния движения
Рисунок 3-1 Поток мобильной обработки в автономном режиме
3.1 Walking
Давайте сначала проанализируем процесс FindFloor.FindFloor, по сути, находит землю под ногами через обнаружение капсулы Sweep, поэтому земля должна иметь физические данные, а тип канала должен быть установлен для ответа на пешку игрока с блоком. Здесь есть некоторые мелкие детали. Например, когда мы ищем землю, мы учитываем только местоположение около ступней и игнорируем объекты около талии; Sweep использует капсулу вместо рентгенологического обнаружения, что удобно для обработки движения наклонной плоскости и расчета стояния Радиус и т. Д. (См. Рисунок 3-3, Нормальный и Ударный Нормальный в HitResult не обязательно одинаковы в случае обнаружения капсулы с помощью развертки). Кроме того, текущее движение Персонажа основано на капсуле, поэтому Актер без компонента капсулы не может нормально использовать UCharacterMovementComponent.
Предыдущая подготовительная работа завершена, и теперь официально вводится расчет смещения при ходьбе.Этот фрагмент кода рассчитывается в PhysWalking. Чтобы работать плавно, UE4 делит движение Tick на N сегментов (время каждого сегмента не может превышать MaxSimulationTimeStep). При обработке каждого сегмента сначала запишите информацию о текущем местоположении и наземную информацию. В TickComponent текущее ускорение рассчитывается в соответствии с длительностью ключа игрока. Затем CalcVelocity () вычисляет скорость на основе ускорения, а также учитывает трение о землю, находится ли оно в воде и т. Д.
Теперь кажется, что мы можем идеально смоделировать мобильный процесс, но если задуматься, есть еще одна ситуация, которая не рассматривалась. Вот как бороться с препятствиями? Согласно нашему обычному игровому опыту, при столкновении с препятствием необходимо не двигаться, и оно может немного скользить по стене. Это действительно так в UE. В процессе движения персонажа (SafeMoveUpdatedComponent) будет происходить процесс обнаружения столкновений. Поскольку компонент UPrimitiveComponent имеет физические данные, эта операция обрабатывается в функции UPrimitiveComponent :: MoveComponentImpl. Следующий код определит, встречаются ли препятствия во время движения, и вернет HitResult, если встретятся препятствия.
После получения HitResult, возвращенного SafeMoveUpdatedComponent (), препятствие столкновения будет обработано в следующем коде.
Если Hit.Normal имеет значение в направлении Z и все еще может ходить, это означает, что это наклонная плоскость, которую можно перемещать вверх, а затем игроку разрешено двигаться по наклонной плоскости.
Определите, можно ли наступить на текущий коллайдер, и, если возможно, попробуйте наступить на него.Если на него не наступили во время процесса, также будет вызвана функция SlideAlongSurface () для скольжения по столкновению.
Основная обработка движения завершена.После движения будет определено, вошел ли игрок в воду или в состояние Падения, и если это так, он немедленно переключится в новое состояние. Чтобы
Поскольку игрок может постоянно переключаться из состояний «Ходьба», «Плавание», «Падение» и других состояний в кадре, перед каждым движением будет выполняться итерация для записи количества ходов в текущем кадре. Если предел превышен, имитация движения будет отменена. поведение.
3.2 Falling
Состояние падения также является наиболее распространенным состоянием, кроме ходьбы. Пока игрок находится в воздухе (прыгает или падает), он будет находиться в состоянии падения. Подобно ходьбе, для плавного выполнения расчет падения также делит движение тика на N сегментов (время каждого сегмента не может превышать MaxSimulationTimeStep). При обработке каждого абзаца сначала вычислите горизонтальную скорость игрока, управляемую вводом, потому что игрок также может зависеть от управления игроком в воздухе. Затем получите скорость вычисления силы тяжести. Получение силы тяжести немного интересно, вы обнаружите, что она приобретается через Volume,
Volume возьмет GlobalGravityZ из WorldSetting. Напоминаем, что мы можем изменить код для достижения разной гравитации для разных объемов и достижения индивидуального игрового процесса. Обратите внимание, что даже если мы не находимся в каком-либо томе, он привяжет DefaultVolume по умолчанию к нашему UpdateComponent. Тогда почему там DefaultVolume? Потому что при большой логической обработке вам нужно получить DefaultVolume и связанные данные внутри. Например, DefaultVolume имеет TerminalLimit, который не может превышать установленную скорость при вычислении скорости спуска под действием силы тяжести.Мы можем изменить ограничение скорости, изменив это значение. По умолчанию многие свойства в DefaultVolume инициализируются с помощью конфигурации, связанной с физикой, в ProjectSetting. См. Рисунок 3-4,
После того, как мы вычислили скорость и передвинули игрока, нам также необходимо рассмотреть проблему столкновения при движении.
Первый случайЭто обычная посадка. Если игрок обнаруживает, что он сталкивается с местностью, которая может стоять после расчета, то напрямую вызовите ProcessLanded для выполнения операции приземления (это решение в основном основано на высоте точки столкновения, и стена может быть отфильтрована).
Второй случайОн должен встретить платформу во время прыжка, а затем проверить, находятся ли координаты игрока и текущая точка столкновения в допустимом диапазоне (IsWithinEdgeTolerance), если да, выполнить FindFloor, чтобы повторно проверить землю, и, если она обнаружена, выполнить процесс приземления.
Третий случайЭто стена и другие предметы, на которые нельзя наступать.Если во время процесса падения встретится препятствие, сначала будет выполнено HandleImpact, чтобы придать силу затронутому объекту. Затем вызовите ComputeSlideVector для расчета смещения скольжения.Так как скорость игрока изменится после столкновения с препятствием, пересчитайте скорость в это время и снова отрегулируйте положение и направление игрока. Если в это время игрок имеет горизонтальное смещение, LimitAirControl также будет использоваться для ограничения скорости игрока.В конце концов, игрок не может свободно управлять персонажем в воздухе. Чтобы расширить третью ситуацию, может быть регулировка столкновения и встреча с другой стеной.Процесс Падения здесь позволяет игроку найти подходящее положение на двух стенах. Но он все еще не может решить ситуацию, когда игрок застрял на двух склонах, но не может приземлиться (или постоянно переключается между Waling и Falling). Если у нас есть время, мы можем попытаться решить эту проблему позже. Решение может быть из функции ComputeFloorDist в FindFloor. Цель состоит в том, чтобы позволить игроку найти удобную площадку для ходьбы в этой ситуации.
Рисунок 3-5 Захват в зазоре вызывает постоянное переключение
Когда дело доходит до падения, я должен упомянуть базовую операцию прыжка. Следующее примерно описывает основной поток реакции на скачок.
1. Привязка события отклика триггера
2. Установите для bPressedJump значение true, как только кнопка ответит. Цикл кадра TickComponent вызывает ACharacter :: CheckJumpInput, чтобы немедленно определить, выполняется ли операция перехода.
Выполните функцию CanJump (), чтобы обработать соответствующую логику ограничений в схеме. Если функция не переписана в схеме, ACharacter :: CanJumpInternal _ Implementation () будет выполняться по умолчанию. Это основа для управления тем, может ли игрок прыгать, например приседать и не прыгать, а также плавать. Кроме того, существует JumpMaxHoldTime, что означает, что игрок не будет запускать прыжок после нажатия клавиши над этим значением. JumpMaxCount представляет количество сегментов, на которые игрок может выполнить прыжки. (Например, двойной прыжок)
Выполните функцию CharacterMovement-> DoJump (bClientUpdating), выполните операцию перехода, войдите в Falling и установите скорость перехода JumpZVelocity.Это значение не может быть меньше 0.
Определите, истинно ли const bool bDidJump = canJump && CharacterMovement && DoJump; Выполните другие связанные операции.
Счетчик прыжков и распределение связанных событий
3. После завершения PerformMovement будет выполнен ClearJumpInput, а для bPressedJump будет установлено значение false. Но JumpCurrentCount не будет очищен, чтобы вы могли продолжить обработку нескольких переходов.
4. Когда игрок отпускает кнопку p, для bPressedJump будет установлено значение false, очищая связанное состояние. Если игрок все еще находится в воздухе, JumpCurrentCount не будет очищен. Если bPressedJump имеет значение false, операции перехода не будут выполняться.
5. Если игрок нажимает кнопку прыжка в воздухе, он также вводит ACharacter :: CheckJumpInput.Если JumpCurrentCount меньше, чем JumpMaxCount, игрок может продолжить выполнение операции прыжка.
3.3 Swiming
В каждом состоянии есть три существенных отличия:
Разница в скорости
Компонент CharacterMovement имеет конфигурацию плавучести Buoyancy, и окончательная плавучесть может быть рассчитана в соответствии со степенью погружения игрока в воду (ImmersionDepth возвращает 0-1). После этого нам нужно рассчитать скорость.В это время нам нужно получить силу трения в Volume, а затем передать ее в CalcVelocity, которая отражает эффект более медленного движения игрока в воде. Затем вычислите плавучесть в направлении Z, чтобы рассчитать скорость в этом направлении. По мере того, как игрок ныряет, вы обнаружите, что скорость игрока в направлении Z становится все меньше и меньше. Когда все тело погружается в воду, скорость гравитации в направлении оси Z Будет полностью проигнорировано.
Рисунок 3-7 Персонаж, плавающий в водном объеме.
После того, как скорость рассчитана, игрок может двигаться. Здесь UE написал отдельный интерфейс Swim для выполнения операции движения.В то же время он посчитал, что если игрок покидает водный объем после перемещения и слишком сильно выходит за поверхность воды, у него есть возможность заставить игрока приспособиться к положению на водной поверхности, и производительность будет лучше.
Что еще дальше? Как вы уже догадались, это обнаружение столкновений с препятствиями во время движения. В основном логика аналогична предыдущей. Если вы можете наступить на него (StepUp ()), отрегулируйте положение игрока и наступите на него. Если вы не можете наступить на него, приложите к препятствию силу, а затем сдвиньте расстояние по поверхности препятствия (HandleImpact, SlideAlongSurface).
3.4 Flying
Наконец, поговорили о последнем состоянии движения. Если вы хотите отладить это состояние, вы можете изменить DefaultLandMovementMode на Flying в компоненте движения персонажа. Чтобы
Полет аналогичен процедурам других состояний и относительно проще: сначала вычислите ускорение на основе предыдущего ввода, а затем начните вычислять текущую скорость на основе трения. После расчета скорости вызывается SafeMoveUpdatedComponent для перемещения. Если вы столкнулись с препятствием, сначала посмотрите, сможете ли вы на него наступить, если нет, справитесь со столкновением и скользите по поверхности препятствия.
Есть феномен, связанный с состоянием полета, к которому у вас могут возникнуть вопросы. Когда я устанавливаю метод движения по умолчанию на «Полет», игрок может скользить на определенное расстояние (с инерцией) после отпускания клавиатуры. Но почему при использовании команды GM она такая же, как состояние «Ходьба», она останавливается сразу после отпускания кнопки? Чтобы
Его код в реальном времени специально обрабатывает чит Flying: после того, как игрок отпускает кнопку, ускорение становится равным 0. В это время скорость игрока принудительно устанавливается на 0. Таким образом, эффективность использования GM отличается от реальной производительности.
3.5 Отложенное обновление FScopedMovementUpdate
Зачем помещать движущийся код в эту скобку и что такое FScopedMovementUpdate? Внимательно вспомните нашу предыдущую конкретную логику обработки движения. В кадре мы можем многократно сбрасывать или изменять наше движение из-за незаконного движения и препятствий. Если вы просто измените положение корпуса капсулы, на самом деле это ничего, но на самом деле нам также нужно одновременно изменить положение подкомпонентов, обновить физический объем, обновить физическое положение и т. Д., И данные движения в процессе расчета фактически бесполезны. Требуются только последние мобильные данные.
Следовательно, использование FScopedMovementUpdate может сначала заблокировать, чтобы не обновлять движение объектов, таких как физика, в пределах своей области, а затем обновить после того, как движение действительно завершено. (Подождите, пока FScopedMovementUpdate не будет уничтожен перед обработкой) Существует много мест, где используется FScopedMovementUpdate, и в основном там будет логика, связанная с откатом мобильных устройств.
Продолжение следует
Ответьте на «gamebook», чтобы получить книги по разработке игр.
Ответьте на «C ++ Interview», чтобы получить опыт собеседования по C ++ / игре.
Ответьте на «Введение в разработку игр», чтобы получить статью о введении в разработку игр.
Ответьте на «операционная система» и получите книги по операционной системе