Пускай каждый непись сам следит за своими делами, например FSM
Таким образом,
sheduledTime = 0
sheduledAction = Action.None
Tick():
if CurrentTime() >= sheduledTime:
setCurrentAction(sheduledAction)
sheduledTime = CurrentTime() + sheduledAction.nextDelay
sheduledAction = sheduledAction.nextAction
В принципе можно то же самое на событиях сделать, просто записывается немного по другому.
Таким образом,
sheduledTime = 0
sheduledAction = Action.None
Tick():
if CurrentTime() >= sheduledTime:
setCurrentAction(sheduledAction)
sheduledTime = CurrentTime() + sheduledAction.nextDelay
sheduledAction = sheduledAction.nextAction
В принципе можно то же самое на событиях сделать, просто записывается немного по другому.
>Или сделать один единственный объект, который будет хранить в себе информацию обо всех расписаниях всех NPC в каждой конкретной локации?
Я бы так сделал. При это в текущей локации, где находится игрок, обновление NPC происходит в реальном времени. В других же локациях уже замедленно, раз в минуту, например. Методы, которые управляют мозгами NPC, на выход получают elapsedTime и им по сути будет пофиг, как часто ты их обновляешь, им главное знать сколько времени прошло.
Вообще, посмотри исходники Майнкрафта. Там при помощи ООП всё очень грамотно сделано. Там же много всяких NPC и целые деревни есть. И все они как-то обновляются.
Очень просто.
Если в близком-видимом радиусе от игрока, то нпс проверяет свои дела в тике к примеру 0.5-1 сек.
Если же где-то за стеной или далеко от игрока, раз в 5-10сек, в зависимости от механики, при этом у нпс отключаются все компоненты которые не требуются для видимости.
Итого ты получаешь до нескольких тысяч нпс которые грузят проц на 0.1% плюс бонусом можно даже говнокодом такое реализовать.
А что на 4й пике не нравится? Ну кроме того что циановый выглядит как говно
Ну вот там, где куча if-else, явно просится обращение к словарю ключ-значение, объявленному заранее. Я хз, что там за язык, но в JS я бы создал объект COLORS с полями White, Black и т.д. и вместо всех v-if'ов получилось бы CorrectColor = COLORS[EyeColor]. Кроме удобства, это сэкономило бы память на переиспользовании экземпляров Color(). Единственный вариант, когда так делать не правильно - если нам зачем-то нужны уникальные инстансы Color, но это редкий случай.
По-моему, вообще любое комплексное поведение должно быть event-driven, по-другому никак. У юнитов под капотом должен быть банальный eventEmitter, который шлёт и слушает события, реагируя на нужные.
Вообще для инди если работает и не лагает то трогать не нужно, всё остальное пустые выебоны. Но как мы знаем у яндере дева игра лагала как ссанина, значит явно говнокод повлиял на оптимизацию, вот тут уже стоит что-то править, так как это прямо влияет на экспирианс юзера.
Бегла глядя тут можно править две вещи.
1. Это заместо кучи ифов сделать одно обращение которое отдаёт цвет в зависимости от запрашиваемого объекта.
2. Сделать вообще конструктор или функцию которая почти весь скрин уместит в пару строк, в зависимости от данных объекта.
И как это всё должно быть по уму реализовано?
Вот у меня есть объект NPC.
Он имеет свой скин, который легко можно сменить одной командой.
Умеет из точки в точку ходить либо по заданному маршруту, либо сам ищет путь.
Умеет проигрывать кастомные анимации, команду на выполнение которых может давать ему контроллер.
Дальше более сложная штука: NPC умеет реагировать на клик игрока и стартовать нужный диалог. При этом он перестаёт идти по заданному пути, если до этого шёл, а после завершения диалога продолжает движение.
И вот что с ними делать дальше.
Сделать какую-то очередь, которую бы они "слушали", и если приходит в неё команда, то они бы по завершению одного действия эту команду дальше исполняли?
И чтобы, когда в очереди больше нет действий, NPC вставал в какое-то idle положение и транслировал контроллеру "я выполнил все действия".
Наверняка тут ещё кучу фишек придумать можно. Мне бы туториал какой, описание схемы как это всё должно выглядеть.
Изи, делаешь список или массив куда в начале дня/спавна заносятся все события и он по порядку их делает, там же реализуешь удаление или добавления события, игрок говорит-пауза выполнения скрипта.
Игрок закончил - чек списка, берём нужное чекаем условия по типу если уже день то идти на завтрак не надо, достаём следующие-чекаем.
Понятненько да?
Я в своём проекте несколько лет пробовал то-сё, пока не пришёл к оптимальной системе событий для моих задач. Лучше тебя твой код никто не знает, и конкретного решения не подскажет. Почитай статей о программировании ИИ персонажей, разберись, хули ты хотел.
Если бы геймдев был лёгким делом, тут сидел бы тот же контингент, что и на лавочке у падика, и членораздельное общение было бы невозможно.
Изи было бы, если бы NPC всегда находился в активной локации.
А если активна может быть только одна локация? Если игрок переходит из локации в локацию, а там свой набор NPC, которые что-то должны делать?
А если ещё NPC должен ходить из локации в локацию?
Так в чём проблема? Ты реализовал механику нпс, следом организовываешь архитектуру как нпс будет хранить своё состояние.
К примеру у тебя уровни - Тогда два выхода, либо нпс делать объектом который не удаляется при переходе, а лишь отключает все свои свойства кроме скритпа. Либо же пилишь менеджер который хранит всех нпс и уже он решает на основание нпс что он делает и куда идёт. Т.е ты возвращаешься в локацию менеджер смотрит так этот нпс был тут-тут и тут, теперь он тут и ставит его там.
Опять же чел, у тебя две разных задачи, первая это состояние и механики нпс на локации, а хранение и перемещение между ними это уже другое, тут уже надо либо задействовать архитектуру игры, либо же делать нпс всегда активным лишь меняющем свойство.
Так-то если ты сделаешь пустой проект и с пустышками поиграешься поймёшь что вся сложность идёт от того что ни разу это не реализовывал. Попробуй на тестов проекте это сделать, за день разберёшься, изичная задачка.
Ещё можно на языке программирования написать.
> А как вы реализуете расписание поведения своих NPC?
С помощью GOAP
> Как это вообще должно выглядеть?
Как GOAP.
> Допустим есть куча локаций, которые нужно заполнить действующими персонажами и есть внутриигровые часы и календарь.
> Дальше то что с этим делать?
Ручками берёшь и пишешь вспомогательную утилиту "менеджер календаря непися" которая формирует выходной файл, читающийся твоей игрой.
> Поставить в каждую локацию по контроллеру, который каждый апдейт будет проверять расписание сделанное для этой конкретной локации?
Можно.
> Или сделать один единственный объект, который будет хранить в себе информацию обо всех расписаниях всех NPC в каждой конкретной локации?
Можно.
> И как это должно выглядеть вообще?
Как GOAP.
> Каждый апдейт
foreach NPC in Location do NPC.CheckMyShedule();
> Это ж пиздец монструознай конструкция.
Нисколько.
> Как организовать простые и понятные легко редактируемые, как угодно настраиваемые расписания для NPC? Как вы это делаете?
Надеваю свой плащ и волшебную шляпу.
Тебе во втором посте написал - непись сам должен заниматься отслеживанием своих дел.
Это и называется уменьшать избыточные связи.
>С помощью GOAP
overkill
>Ручками берёшь и пишешь
Спасибо кэп
В общем пока наметил такой план:
Пишу файл с расписанием для каждого NPC вида:
(параметры NPC - имя, скин и т.д.)
(комната, день)
(время начала, время конца)
(действие, необходимые переменные для совершения действия)
(диалог, который должен выдать NPC в ответ на взаимодействие с игроком)
Фигачу скрипт, который читает этот файл и сохраняет в таблицу.
Делаю контроллер, который при загрузке каждой комнаты читает таблицу и выбирает из неё необходимый строки.
Если комната и день из таблицы совпадают с комнатой и днём в игре - создаю одного NPC за пределами комнаты с необходимыми параметрами и передаю ему в очередь все действия, которые он должен совершить в данной комнате.
Далее NPC будет сам разбираться с временем дня и своей очередью действий. Пока до этого не добрался.
Пишу файл с расписанием для каждого NPC вида:
(параметры NPC - имя, скин и т.д.)
(комната, день)
(время начала, время конца)
(действие, необходимые переменные для совершения действия)
(диалог, который должен выдать NPC в ответ на взаимодействие с игроком)
Фигачу скрипт, который читает этот файл и сохраняет в таблицу.
Делаю контроллер, который при загрузке каждой комнаты читает таблицу и выбирает из неё необходимый строки.
Если комната и день из таблицы совпадают с комнатой и днём в игре - создаю одного NPC за пределами комнаты с необходимыми параметрами и передаю ему в очередь все действия, которые он должен совершить в данной комнате.
Далее NPC будет сам разбираться с временем дня и своей очередью действий. Пока до этого не добрался.
Оверкиллом был бы STRIPS упрощённой версией которого является GOAP.
А ну ясно, очередной велосипедист.
А нахуй так часто проверять время НПЦ? Я тут конечно новенький в программирований, но разве не проше сделать так, чтобы при наступлений определенного часа/минуты рассылать сигнал НПС, который активирует скрипт смены поведения?
Опять же, только вкатываюсь в программирование, но по моему то, что я описал, будет нагружать процессор меньше, чем каждый НПС, который раз в секунду проверяет, который час.
По очень простой причине, так как мир вокруг нпс динамический, он же должен и реагировать на него, а если проверок не будет, он как по расписанию мимо трупа будет проходить в столовку, или игрок что нить совершает а нпс пофиг.
Как вкатишься и сделаешь хоть что-то более менее сложнее змейки или платформера, то поймёшь для чего надо делать сложнее чем кажется на первый взгляд.
И поверь один чек раз в 1сек, это пшик для игры, офк если этих непс не под штукарь и более.
Так это уже совсем другое поведение, не завязаное на времени, разве нет? Труп же не по часам находят.
В общем да, лучше самому почитать на тему ИИ в играх, так будет быстрее и проще.
Ну и тут в любом случай нужно делать иерархию поведения комплексную. Где одно событие имеет приоритет над другим. Но не все же эти события проверять каждую секунду. Так может выйти, что один нпс может по 50, если не сотни, проверок делать каждую секунду, что тоже не совсем удобно.
Ну значит делай событийную.
Под капотом событийные делают то же самое - проходят по таблице и сверяют с текущим временем, как бы они иначе это делали.
У непися есть не одновременный набор дел, у каждого дела есть время старта, каждый тик код непися чекает натсупило ли время для следующего дела и если да то запускает дело и чекает уже следующее за этим дело наступило ли оно. Если дел одновременных несколько, например ходить по маршруту и переодеваться на ходу то можно пару проверок сделать.
В коде это изи делается, каша как на пикрилах это от не знания элементарных инструментов программирования.
Как говорится если не слушаете батек которые уже сотню раз это реализовывали, то остаётся только самим через все велосипеды и подводные проходить, удачи.
Набор дел это список, чекать надо только следующее дело. Так как это список то туда может вклинится какое то новое дело или удалиться, так как код чекает только следующее дело то проблем не будет, главное чтоб дела добавлялись по порядку времени.
Например сейчас код чекает дело которое наступит через 2 часа, но тут появилось дело спать, его надо засунуть после того дела, а то непись сначала поспит а потом будет весь день ждать ту херню.
Тут пока никто не высказался из тех, кто "сотню раз уже это реализовывал"
Ну, простая машина состояний и выглядит как большой набор switch case
Допустим есть куча локаций, которые нужно заполнить действующими персонажами и есть внутриигровые часы и календарь.
Дальше то что с этим делать?
Поставить в каждую локацию по контроллеру, который каждый апдейт будет проверять расписание сделанное для этой конкретной локации?
Или сделать один единственный объект, который будет хранить в себе информацию обо всех расписаниях всех NPC в каждой конкретной локации?
И как это должно выглядеть вообще?
Каждый апдейт
switch day
switch hour
switch minute
switch second
?
Это ж пиздец монструознай конструкция. Как организовать простые и понятные легко редактируемые, как угодно настраиваемые расписания для NPC? Как вы это делаете?