Написание сервера для lineage 2 chronicle 1 на node.js

space2pacman написал(а):
Finite State Machine.

Есть состояния и переключения между ними.
Например FSM для NPC
state: "idle" (Если задача стоять то стоим. Если патрулировать то следующее состояние "move"
state: "move"
state: "move"
state: "move" (Если дошли то точки то переключаемся в idle)
state: "idle" (Если NPC ударили то атакуем)
state: "attack" (Если цель далеко то преследуем)
state: "follow"
state: "follow"
state: "follow" (Если дошли до цели и задача атаковать то следующее состояние "attack"
state: "attack"

И т.д.
Состояний может быть масса и логика переключения масштабируется.
Нажмите, чтобы раскрыть...
А когда follow чего он посылает клиенту?
 

gawric написал(а):
А когда follow чего он посылает клиенту?
Нажмите, чтобы раскрыть...
follow это внутренняя логика на стороне сервера. Когда move или follow то идет отправка пакета MoveToLocation.

Но вообще есть пакет MoveToPawn, который отправляется один раз и на стороне клиента NPC преследует всегда цель в не зависимости от положения цели. В случае MoveToLocation NPC идет только в одну точку и я его корректирую каждый 100мс.

follow вызывается каждые 100мс и каждые 100мс корректируется маршрут. На видео видно как npc следует за целью. Но в целях оптимизации на боевом сервере лучше использовать MoveToPawn.
 
А как он узнает что нужно остановиться StopMove?
 
Я когда мобиус разбирал он эти MoveToPawn посылал постоянно пачками когда моб преследует игрока....... Попробую для теста послать 1 moveToPawn посмотреть чего будет

Понятно теперь почему он пачкам их шлет. После каждой атаки он посылает moveToPawn и действительно двигается пока не достигнет цели
 
space2pacman написал(а):
Finite State Machine.

Есть состояния и переключения между ними.
Например FSM для NPC
state: "idle" (Если задача стоять то стоим. Если патрулировать то следующее состояние "move"
state: "move"
state: "move"
state: "move" (Если дошли то точки то переключаемся в idle)
state: "idle" (Если NPC ударили то атакуем)
state: "attack" (Если цель далеко то преследуем)
state: "follow"
state: "follow"
state: "follow" (Если дошли до цели и задача атаковать то следующее состояние "attack"
state: "attack"

И т.д.
Состояний может быть масса и логика переключения масштабируется.
Нажмите, чтобы раскрыть...
Это вроде ИИ (AI) для мобов. Как происходит переключение с одного состояния на другое?
 
MrThirtyOddSix написал(а):
Это вроде ИИ (AI) для мобов. Как происходит переключение с одного состояния на другое?
Нажмите, чтобы раскрыть...
Если используется птс аи то оно само решает как и что делать и дергает сервер методами а-ля:
AddUseSkillDesire/AddFleeDesire/AddMoveToTargetDesire/AddMoveToDesire/AddFollowDesire и прочее.
А в обычных эмулях с самописными АИ это уже зависит от того насколько разрабы оглядывались на то как это работает в птс - может быть и в аи переключение, а может и раскидано по всему ядру.
 
ANZO написал(а):
Если используется птс аи то оно само решает как и что делать и дергает сервер методами а-ля:
AddUseSkillDesire/AddFleeDesire/AddMoveToTargetDesire/AddMoveToDesire/AddFollowDesire и прочее.
А в обычных эмулях с самописными АИ это уже зависит от того насколько разрабы оглядвались на тот как это работает в птс - может быть и в аи переключение, а может и раскидано по всему ядру.
Нажмите, чтобы раскрыть...
Я про то что и как регулирует состояние FSM. Даже на ПТС скрипты на самом деле не регулируют состояние напрямую. Ведь те функции о которых вы говорите только регулируют систему desire (что в принципе и есть FSM построенная на значениях уменьшающихся во времени). Напрямую влияют только спаун (когда нпц появился) и смерть (когда FSM в принципе не работает). Под FSM я имею другую систему которая управляет скриптом по ивентам.
 
MrThirtyOddSix написал(а):
Я про то что и как регулирует состояние FSM. Даже на ПТС скрипты на самом деле не регулируют состояние напрямую. Ведь те функции о которых вы говорите только регулируют систему desire (что в принципе и есть FSM построенная на значениях уменьшающихся во времени). Напрямую влияют только спаун (когда нпц появился) и смерть (когда FSM в принципе не работает). Под FSM я имею другую систему которая управляет скриптом по ивентам.
Нажмите, чтобы раскрыть...
Оно влияет вообще на весь цикл жизни\смерти\боя\передвижения моба. Все что сервер делает: шлет в нужной ситуации нужны ивент:
CREATED/NO_DESIRE/SCRIPT_EVENT/ATTACKED и прочее, а АИ уже на это реагирует вызовом функций - бежать к атакущему, от него, двигаться в точку или помереть.
 
ANZO написал(а):
Оно влияет вообще на весь цикл жизни\смерти\боя\передвижения моба. Все что сервер делает: шлет в нужной ситуации нужны ивент:
CREATED/NO_DESIRE/SCRIPT_EVENT/ATTACKED и прочее, а АИ уже на это реагирует вызовом функций - бежать к атакущему, от него, двигаться в точку или помереть.
Нажмите, чтобы раскрыть...
Если все вместе взять да, это будет ИИ. Нo есть ведь разделение на функции скрипта и FSM (система desire). Да есть ивенты и сам скрипт, но это является составимыми ИИ так как без этого не будет самого поведения монстра. У меня различие между скриптом который обрабатывает данные/ивенты и самой системой которая производит эти ивенты. Я просто не обобщаю.
 
MrThirtyOddSix написал(а):
Это вроде ИИ (AI) для мобов. Как происходит переключение с одного состояния на другое?
Нажмите, чтобы раскрыть...
Да, типо ИИ. Состояния переключаются на основе данных.

Например переход от состояния атака к follow если цель далеко. Если близко то повторить атаку. И так каждый раз.

Состояние "убегать" если hp <= 30 && npc находится в состоянии атака. И т.д.

gawric написал(а):
Посмотреть вложение 86586
занимаемся примерно одним и тем же :) Только с разных сторон
Нажмите, чтобы раскрыть...
Если видео запишите - будет круто
 
Последнее редактирование модератором:
Войдите или зарегистрируйтесь для ответа.
Назад
Сверху