Больше веселья с ES ...
В настоящее время у меня есть несколько систем:
- Renderer (атрибут Renderable, атрибут Transform)
- Движение (атрибут «Подвижный», атрибут «Преобразование», атрибут «Renderable» [для ограничительных рамок и т. Д.])
- Input (атрибут InputReceiver)
- и т.п.
Я добавляю обнаружение столкновений. Моей первой мыслью было добавить новую систему, которая выполняет столкновение. Это имеет смысл для меня , чтобы держать это изолировано от Motion
системы , так как не все, что движение или анимированы обязательно участвуют в обнаружении столкновения - камеры, туман и т.д. - но, кажется, Collision
и Motion
являются взаимозависимыми.
Когда Motion
перемещается объект, трансформация должна быть подтверждена с помощью Collision
, а движение либо отменено, либо скорректировано (подпрыгивание, остановка у стены и т. Д.).
Альтернативой может быть создание атрибута Collidable, который поддерживает ссылку на объект столкновения - kd-tree, octree и т. Д., Который совместно используется объектами, которые могут сталкиваться друг с другом. Затем Motion
система проверит этот атрибут и использует его для проверки или корректировки движения.
С точки зрения кода это приемлемое решение. Однако, с точки зрения архитектуры ECS, кажется, что она проталкивает логику в Motion
систему, которая не применяется ко всем объектам, которые имеют Movable
атрибут.
Я мог бы также хранить вектор движения в Movable
атрибуте, и есть Collider
система регулировки по Transform
мере необходимости, но это будет включать в себя дублирование функциональных возможностей между Motion
и Collider
, или обратного вызова от Collider
к Motion
с некоторыми данными о местоположении столкновений и поверхностных данных для отскока / отражения, и т.д. ,
Это может подпадать под заголовок «взломать особый случай», но я хотел бы получить некоторую информацию от тех, кто обрабатывал это раньше, без создания тонны краевого кода случая.
Вопрос Какой хороший способ избежать тесной связи между системами движения и столкновения, когда кажется, что они требуют знания друг друга?
Ответы:
Вы переосмысливаете это. В моем движке, который также использует систему компонентов, каждый
GameObject
может иметь указатель наModuleCollision
.Что происходит при обновлении игры:
Update
функцию для каждогоGameObject
.Update
функции каждый обновляетGameObject
только свою скорость и направление, а не свою позицию.GameObject
загружает свою текущую позицию, скорость и направление на нееModuleCollision
, если таковая имеется.ModuleCollision
основе.UpdatePost
функцию на каждомGameObject
. Если у объекта есть модуль столкновения, он выбирает обновленную позицию, скорость и направление из модуля столкновения. Положение обновляется со скоростью и направлением.GameObject
Создает конечную матрицу 3х3 из своего положения и курса.Да, есть некоторое дублирование состояния, но это нормально. Обработка столкновений на a
ModuleCollision
- лучший способ сделать это, потому что в противном случае вам придется проверять каждый из них,GameObject
чтобы увидеть, есть ли у негоModuleCollision
дескриптор.источник
Я бы сделал это так ...
Есть три системы:
Система движения применяет скорости к позициям. Система ускорения прикладывает силы к скоростям. Система столкновений обнаруживает столкновения и прикладывает силы в правильных направлениях, или, если вы хотите грубые столкновения, напрямую изменяет скорости.
Например, вы можете рассчитать угол между столкновениями, используя atan2 , а затем использовать его, чтобы применить правильные силы / скорости тел.
Если необходимо, имейте также широковещательные сообщения системы обнаружения столкновений.
источник