У проекта появилась чёткая архитектура управления сущностями. Теперь NPC, игроки, питомцы и другие объекты взаимодействуют в мире через систему менеджеров — рассказываю, как это работает.
В игровом мире есть разные типы сущностей: NPC, игроки (Player), питомцы (Pet) и другие. Каждая из них имеет свои состояния (движение, атака, бездействие) и требует управления.
Основные сущности и их поведение • NPC – управляет собой (перемещение, атака, idle). • Player – управляется игроком (те же состояния: ходьба, атака и т. д.). • Pet – похож на NPC, но принадлежит игроку.
Менеджеры и их задачи 1. NpcManager – создаёт NPC, реагирует в случае смерти NPC. 2. PlayersManager – отвечает за вход игроков в мир. 3. PetsManager – управляет питомцами (аналогично NPC, но с привязкой к игроку). 4. EntitiesManager – главный координатор: o Управляет NpcManager и PlayersManager. o Обрабатывает взаимодействия (например, если игрок подошёл к NPC, оба получают информацию друг о друге). 5. VisibilityManager – отвечает за видимость объектов: o Определяет, кто кого видит. o Периодически обновляет списки видимости для оптимизации. 6. MovingManager – обновляет позиции всех подвижных объектов в мире.
Зачем это нужно? Такая система позволяет: • Эффективно управлять сотнями сущностей. • Оптимизировать обновление состояний (движение, видимость, атака). • Гибко добавлять новые типы объектов (монстры, питомцы, NPC-торговцы).
Помните как мы бегали по горам и не придавали значение тому как быстро спускались или поднимались на них?
Как мы знаем в реальной жизни перемещаясь на плоскости горизонтальная скорость у нас постоянная. Как только мы начинаем преодолевать горы и другие неровности то горизонтальная скорость у нас будет меньше. Но не в мире Lineage 2 где горизонтальная скорость всегда постоянная и нее зависит от неровностей. Связанно это с тем чтобы было проще синхронизировать персонажа на сервере и клиенте. Ведь на сервере нет точной модели мира, а лишь примерное очертание называемое geodata. А из-за того, что geodata приблизительно повторяет ландшафт клиента то было бы невозможно синхронизировать персонажа по Z оси. Поэтому синхронизация идет только по X и Y оси.
Видео:
1) Горизонтальная скорость на плоскости постоянная.
2) Как было бы в жизни. Взбираясь на гору горизонтальная скорость падает.
3) Как сделано в игре. Горизонтальная скорость постоянная.
4) Демонстрация из игры. Бежит словно нет никаких гор.
Тестирую синхронизацию объектов на перемещение и атаку между NPC и игроком и немного намусорил. Дроп, который падает, показывает текущее местоположение объекта на стороне сервера. Каждый n-ный тик происходит синхронизация.
Я разрабатываю эмулятор сервера для Lineage 2 Chronicle 1: Harbingers of war на Node.js.
Столкнулся с проблемой синхронизации скорости персонажа на сервере с клиентом. Когда в игре вы нажимаете мышкой в то место, куда хотите перейти то происходит плавный переход с анимацией движения. На сервере в этот момент тоже происходит движение по таймеру, но не такое плавное.
C(client) – двигается плавно из одной точки в другую. S(server) – делает прирост координат по таймеру.
Для примера я взял сборку написанную на java l2j-lisvus Сборок много. Но все они являются fork’ами проекта l2jserver https://l2jserver.com/И многое наследуется. В том числе и передвижение персонажа.
В l2j-lisvus, как и во всех сборках l2jserver перемещение персонажа на сервере идет при помощи таймера с приростом одинаковых значений.
Проблема проявляется, когда нам надо сделать какое-то действие после того, как персонаж добежал до пункта назначения. Например, нанести удар по NPC.
На коротких расстояниях проблема незаметна. Нога наступает точно в монету.
На длинных расстояниях действие атака начинается раньше, чем персонаж добегает до цели.
А если выкрутить скорость на максимум (900) то проблема расхождения очевидна. Это связанно с тем, что помимо скорости бега есть скорость ходьбы.
Как работает передвижение персонажа на сервере.
За основу взяты базовые характеристики персонажа. Скорость бега 126.
126 — это количество внутренних unit’ов за секунду.
На данной схеме идет прирост координат персонажа каждые 1000мс на 126 unit’ов. Исходя из схемы выше пример кода для действий персонажем после достижения пункта назначения:
// Прироста координат нет. Просто считаем когда персонаж дойдет до конечных координат. const distance = 1500; const playerSpeed = 126; const ticks = distance / playerSpeed; // 11.90 const time = ticks * 1000; // 11900mc
setTimeout(() => { // действие персонажа после бега }, time);
На коротких расстояниях.
На длинных расстояниях.
Расхождения на коротких расстояниях.
Расхождения на длинных расстояниях.
Зеленой зоной показана точка куда должна ступить нога персонажа если бы не было расхождений.
Рост скорости при развитии персонажа.
126 — это базовая скорость. И по мере развития персонажа будет расти и скорость передвижения. А значит расхождение будет больше. Но перед тем, как создать формулу надо подтвердить теорию, что скорость ходьбы влияет на расхождение.
Данные о характеристиках персонажа передаются от сервера к клиенту.
Выставляю значения walkSpeed: 126. Если скорость ходьбы будет равна скорости бега, то расхождения должны пропасть.
Нога персонажа достигает правильной конечной точки.
Персонаж синхронизирован и начинает атаку вовремя. Теперь надо понять, как скорость ходьбы влияет на расхождения между клиентом и сервером.
Сколько же персонаж успевает пройти перед тем, как начинает бежать?
Надо поймать момент когда ходьба переходит в бег. Для этого передадим в клиент данные, где скорость ходьбы будет больше скорости бега. Из-за этой разницы будет виден переход и можно будет рассчитать пройденное расстояние при ходьбе.
runSpeed: 10
walkSpeed: 600
Ходьба быстрее бега.
При скорости шага в 600 персонаж успевает пройти 250, прежде чем начинает бежать.
600 / 250 = 2.4
700 / 291 = 2.4
800 / 333 = 2.4
Из этого вывод, что персонаж перед тем, как начать бежать успевает пройти расстояние в 2.4 раза меньше, чем его скорость ходьбы.
Значит при скорости ходьбы 88 персонаж пройдет 36 unit’ов.
88 / 2.4 = 36
Первое деление — это начало движения (ходьба) а следующие деления — это бег.
