Something i realized a while back about enemies in games: They are enforcers. They force the player to comply to the rules of the game. If the player does not comply, he not only cannot proceed, but he will be punished (with time). Maybe that's a part of why people like games so much? Exercising the part of you that is able to learn how to comply to the rules of the world seems pretty useful And that's why people (usually) don't like it when enemies are too strong/make no sense/have no feedback/etc.. They say 'its not fair' (I'm doing things right, why can't i keep playing). There's even a whole genre for that Yes this is all just tangentially related to the video, but unfortunately i think about things in a metaphysical a lot. I always have one eye in a telescope (and another in a microscope)
Amazing video, expected a code overview and got a design presentation TED talk. And yeah, I think it's really important to know what goals your design for your enemies have before you actually program it.
Как всегда классное видео, ещё и куча ресурсов чтоб в свободное время прочекать! Но я вот что спросить ещё хотел, если ты не против. Как бы ты реализовывал систему эвентов? Скажем, если я планирую добавлять объекты, которые должны получать некоторые эвенты и как то на это реагировать, например какой-нибудь тотем, который что-то делает, когда рядом умирает враг, пассивное свойство, которое активируется, если враг далеко от игрока получил урон, противник, который кастует на соседних противников щит, если игрок кастует заклинание, т.д. Пока что лучшей идеей, которая у меня появлялась по этому поводу - это сделать нод, который будет хранить в себе словарь из названий эвентов и списков слушающих нодов, что то типа этого: ("смерть" : "тотем1, тотем2"; "урон" : "перк1Игрока1"; "каст" : "противникМаг1") и всё что может затригерить действие вызывает функцию у соответствующих объектов. Однако из минусов этого метода: 1) Мне нужно вручную прописывать код, ответственный за добавление нужных объектов в списки словаря / подписку на эвенты 2) Как будто нет возможности изменить логику триггера эвентов, например, что если в последним случае я хочу чтобы только 1 противник маг кастовал щит, если таких противников больше 1? (Хотя полагаю это можно решить костылём, что противник сам чекает список, если находит там других противников магов, то кастует щит только если он первый, кто получил эвент...) В общем как будто это достаточно часто встречающаяся проблема, что должно быть какое то элегантное её решение, некая быстро расширяемая и изменяемая система эвентов, но я пока его не нашёл
1) Спасибо! От это вопросец, конечно, на него меньше, чем за неделю и несколько исписанных белых досок не ответить нормально). Но я попытаюсь, так, на уровне оракула. Первое, что бросается на ум: нам не увернуться от огромного количества тегов, а в Godot это группы, но нужно будет найти еще нормальный способ работы с ними, система тегов - это гораздо больше, чем накидывание стринга на объект. Второе: как всегда, у тебя будет выбор между одним глобальным менеджером и рядом распределенных функционалов без слоя-менеджера вообще. Основной проблемой слоя-менеджера будет поддержка изменений с какого-то момента, потому что он гигантский, и "де-масштабирование" его. Легко сделать один класс, который обслуживает ивенты всей Доты, скажем, на 120+ героев. Сложно сделать, чтобы 90% этого класса не работали в каждом матче, потому что в игре героев всего 10. Основной проблемой распределенных агентов будет отладка сложных случаев, нужно будет подзаебаться с dev-layer тулзами, а также унификация. Допустим, я сделал один единственный класс, который в ответе за смерть юнита. Я его нацепил на своего юнита в эдиторе руками, найс, работает. Но что, если у меня 150 видов юнитов? Мне 150 раз эту ноду перетащить? Короче, проблемы у распределенки всегда всплывают в default-реализациях и дупликации кода.
2) Я всегда софт-хейтил гигантские менеджер-слои, так что я предвзят, обрати на это, пожалуйста, внимание. Я же поразмышляю дальше над распределенкой. Godot конкретно имеет много минусов, например, отсутствие понятия интерфейса, которое нам бы очень помогло с данной проблемой. Зато Godot о-очень нативно поддерживает, я бы сказал, прям байтит на аспектное проектирование. Вот что бы я сделал, напихал бы своим сущностям нод-аспектов. Представим на секунду, что мы разобрались внутри сущности, что сущность, например, внутри себя знает, когда она умерла, когда скастовала заклинание, и тд. Теперь создадим ей возможность делиться этим замечательными знаниями. Отметим, что для большинства ивентов нам нужны две половинки, как бы рукопожатие, значит, мы создаем аспекты парами, кричащий аспект и слушающий аспект. Это нам нужно для распределения кода, потому что зачастую один триггер используется разными пассивными способностями по-разному, кричащему "я помер" аспекту не должно быть дела до того, что мы потом делаем с этой информацией. К дизайну: вот у меня есть умирающий юнит. Навешиваю на нее ноду DyingUnitAspect, с кодом примерно следующего содержания: все аспекты группы "слушающие смерть", слушайте, я умер, вот моя ивент-дата (пакет с точным временем, местом и прочей фигней о юните). Теперь если я хочу сделать себе какого-то некроманта, радующегося этому событию, я должен на нем создать аспект NecromancerDeathSeekingAspect (да, я пишу на Java, а как вы узнали?). Этот аспект будет иметь у себя классненькие экспортные поля с радиусом и всем, что ему понадобится для работы, и кодом, реагирующим на клич умирающего аспекта-напарника: в радиусе ли я, как я реагирую и тд. Заметим, что этот дизайн носит гибкость с собой встроенно, никто не запрещает мне иметь 100 видов некромантов, радующихся смерти ближнего по-разному, это просто будут разные аспекты. Также отметим, что реализация системы тегов идет здесь же. *В группе находится не сущность, которая умирает, в группе "умирающее" находится аспект-нода, висящая на этой сущности*. Это позволит практически свести к нулю секс с учетом групп, все группы поставляются вместе с использующими их аспектами, заранее в статичном дизайне, с проектирования. Ну а теперь, отстрел проблем. Первая: дефолты. Я не хочу на каждого своего умирающего юнита навешивать 150 раз "умирающее". Я потом еще изобрету "воскрешаемое", и буду его опять 150 раз навешивать?? Ну, да, строго говоря. Но на помощь нам придут сцены. Количество аспектов в такой системе будет расти как на дрожжах, на одном юните скоро будет висеть с десяток. Но не в виде отдельных нод, а в виде сцены "пакет наземного юнита", "пакет здания", "пакет героя", "пакет нежити". Тут-то мы осознаем всю мощь теговой системы. Теги скалируются и выстраиваются в иерархии. Например, пакет-сцена аспектов "лесное животное" будет носить тег "лесное животное" на этой сцене. Но внутри этой сцены будут сложены аспекты (им же все равно, куда быть прицепленными, главное быть в дереве на сущности где-то), там будет аспект "легко пугающееся", "приручаемое друидом" и "съедобное", каждый из которых будет своим аспектом и своим тегом. Вот тебе и дефолты, собери дефолт-пакет один раз, и уж да, повесь его всем юнитам один раз, зато потом менять нужно одну сцену. Вторая: динамика. Глобальный слой-менеджер довольно легко с ней расправляется, но распределенка гораздо хуже обрабатывает рантайм-изменения. А они могут быть, допустим, герой купил предмет, который реагирует на смерти вокруг. Раньше в мире симуляции не было никого, кто слушал смерти, а сейчас появился - этот предмет. Ну, ничего, на самом деле, поебешься с дебагом, но Godot спокойно изменяет дерево в рантайме, просто носи аспект слушающий смерть вместе с предметом и навешивай на героя после покупки. Отмечу, что ты приводил пример с одноразовым триггером. Это просто будет отдельный вид аспекта. Очень похожий, но отдельный. Допустим, у нас есть юнит, на нем есть аспект "умирающее", и рядом аспект "умирающее 1 раз". Первый орет на весь мир всем, кто слушает, а второй при триггере собирает всех слушающих в коллекцию (они же тоже в группах), сортирует ее как-то (по дистанции, например), и говорит только первому "слушай, я умер, но только для тебя, по-братски". Фуууух. Отличный вопрос, жаль, на русском, несчастные будут мучаться в переводчики это пихать, о чем таком интересном дискуссия.
@@PointDown Супер, спасибо большое, прочекаю что есть по теме, мне ещё нравится что это решение может хорошо сочетаться с ECS архитектурой, где поведение объекта описывается его компонентами
@@Limofeus Ну-у, да-а-а, сочетается. Но для нормального ECS нужна низкоуровневость, исполнение на уровне движка. ECS хорош в юнити не потому, что он там [есть], он хорош, потому что там отдельный компилятор позволяет работать в несколько десятков(!) раз быстрее. Было бы очень круто иметь это в Godot, но последний раз, когда я проверял, какой-то ECS фраймворчик на нем был чисто на нодах, то есть над движком, по факту, меняющий только архитектуру проекта, но не добавляющий основного преимущества ECS в Да производительности.
Something i realized a while back about enemies in games: They are enforcers. They force the player to comply to the rules of the game. If the player does not comply, he not only cannot proceed, but he will be punished (with time).
Maybe that's a part of why people like games so much? Exercising the part of you that is able to learn how to comply to the rules of the world seems pretty useful
And that's why people (usually) don't like it when enemies are too strong/make no sense/have no feedback/etc.. They say 'its not fair' (I'm doing things right, why can't i keep playing). There's even a whole genre for that
Yes this is all just tangentially related to the video, but unfortunately i think about things in a metaphysical a lot. I always have one eye in a telescope (and another in a microscope)
Love to see you are keep going and growing!
Amazing video, expected a code overview and got a design presentation TED talk. And yeah, I think it's really important to know what goals your design for your enemies have before you actually program it.
Yup, I tend to dump theory in earlier videos for a subject. Next episodes will be more Godot centric.
23:40 К этому треку не хватает ещё и моделей из Деревни Дураков. Добавить бы бабу со сковородой, например...
continue ai series, maybe u become godot ai guy) Children of the Omnissiah goes hard
Как всегда классное видео, ещё и куча ресурсов чтоб в свободное время прочекать!
Но я вот что спросить ещё хотел, если ты не против. Как бы ты реализовывал систему эвентов? Скажем, если я планирую добавлять объекты, которые должны получать некоторые эвенты и как то на это реагировать, например какой-нибудь тотем, который что-то делает, когда рядом умирает враг, пассивное свойство, которое активируется, если враг далеко от игрока получил урон, противник, который кастует на соседних противников щит, если игрок кастует заклинание, т.д. Пока что лучшей идеей, которая у меня появлялась по этому поводу - это сделать нод, который будет хранить в себе словарь из названий эвентов и списков слушающих нодов, что то типа этого: ("смерть" : "тотем1, тотем2"; "урон" : "перк1Игрока1"; "каст" : "противникМаг1") и всё что может затригерить действие вызывает функцию у соответствующих объектов. Однако из минусов этого метода: 1) Мне нужно вручную прописывать код, ответственный за добавление нужных объектов в списки словаря / подписку на эвенты 2) Как будто нет возможности изменить логику триггера эвентов, например, что если в последним случае я хочу чтобы только 1 противник маг кастовал щит, если таких противников больше 1? (Хотя полагаю это можно решить костылём, что противник сам чекает список, если находит там других противников магов, то кастует щит только если он первый, кто получил эвент...)
В общем как будто это достаточно часто встречающаяся проблема, что должно быть какое то элегантное её решение, некая быстро расширяемая и изменяемая система эвентов, но я пока его не нашёл
1)
Спасибо!
От это вопросец, конечно, на него меньше, чем за неделю и несколько исписанных белых досок не ответить нормально). Но я попытаюсь, так, на уровне оракула. Первое, что бросается на ум: нам не увернуться от огромного количества тегов, а в Godot это группы, но нужно будет найти еще нормальный способ работы с ними, система тегов - это гораздо больше, чем накидывание стринга на объект. Второе: как всегда, у тебя будет выбор между одним глобальным менеджером и рядом распределенных функционалов без слоя-менеджера вообще. Основной проблемой слоя-менеджера будет поддержка изменений с какого-то момента, потому что он гигантский, и "де-масштабирование" его. Легко сделать один класс, который обслуживает ивенты всей Доты, скажем, на 120+ героев. Сложно сделать, чтобы 90% этого класса не работали в каждом матче, потому что в игре героев всего 10. Основной проблемой распределенных агентов будет отладка сложных случаев, нужно будет подзаебаться с dev-layer тулзами, а также унификация. Допустим, я сделал один единственный класс, который в ответе за смерть юнита. Я его нацепил на своего юнита в эдиторе руками, найс, работает. Но что, если у меня 150 видов юнитов? Мне 150 раз эту ноду перетащить? Короче, проблемы у распределенки всегда всплывают в default-реализациях и дупликации кода.
2)
Я всегда софт-хейтил гигантские менеджер-слои, так что я предвзят, обрати на это, пожалуйста, внимание. Я же поразмышляю дальше над распределенкой. Godot конкретно имеет много минусов, например, отсутствие понятия интерфейса, которое нам бы очень помогло с данной проблемой. Зато Godot о-очень нативно поддерживает, я бы сказал, прям байтит на аспектное проектирование. Вот что бы я сделал, напихал бы своим сущностям нод-аспектов. Представим на секунду, что мы разобрались внутри сущности, что сущность, например, внутри себя знает, когда она умерла, когда скастовала заклинание, и тд. Теперь создадим ей возможность делиться этим замечательными знаниями. Отметим, что для большинства ивентов нам нужны две половинки, как бы рукопожатие, значит, мы создаем аспекты парами, кричащий аспект и слушающий аспект. Это нам нужно для распределения кода, потому что зачастую один триггер используется разными пассивными способностями по-разному, кричащему "я помер" аспекту не должно быть дела до того, что мы потом делаем с этой информацией. К дизайну: вот у меня есть умирающий юнит. Навешиваю на нее ноду DyingUnitAspect, с кодом примерно следующего содержания: все аспекты группы "слушающие смерть", слушайте, я умер, вот моя ивент-дата (пакет с точным временем, местом и прочей фигней о юните). Теперь если я хочу сделать себе какого-то некроманта, радующегося этому событию, я должен на нем создать аспект NecromancerDeathSeekingAspect (да, я пишу на Java, а как вы узнали?). Этот аспект будет иметь у себя классненькие экспортные поля с радиусом и всем, что ему понадобится для работы, и кодом, реагирующим на клич умирающего аспекта-напарника: в радиусе ли я, как я реагирую и тд. Заметим, что этот дизайн носит гибкость с собой встроенно, никто не запрещает мне иметь 100 видов некромантов, радующихся смерти ближнего по-разному, это просто будут разные аспекты. Также отметим, что реализация системы тегов идет здесь же. *В группе находится не сущность, которая умирает, в группе "умирающее" находится аспект-нода, висящая на этой сущности*. Это позволит практически свести к нулю секс с учетом групп, все группы поставляются вместе с использующими их аспектами, заранее в статичном дизайне, с проектирования.
Ну а теперь, отстрел проблем. Первая: дефолты. Я не хочу на каждого своего умирающего юнита навешивать 150 раз "умирающее". Я потом еще изобрету "воскрешаемое", и буду его опять 150 раз навешивать?? Ну, да, строго говоря. Но на помощь нам придут сцены. Количество аспектов в такой системе будет расти как на дрожжах, на одном юните скоро будет висеть с десяток. Но не в виде отдельных нод, а в виде сцены "пакет наземного юнита", "пакет здания", "пакет героя", "пакет нежити". Тут-то мы осознаем всю мощь теговой системы. Теги скалируются и выстраиваются в иерархии. Например, пакет-сцена аспектов "лесное животное" будет носить тег "лесное животное" на этой сцене. Но внутри этой сцены будут сложены аспекты (им же все равно, куда быть прицепленными, главное быть в дереве на сущности где-то), там будет аспект "легко пугающееся", "приручаемое друидом" и "съедобное", каждый из которых будет своим аспектом и своим тегом. Вот тебе и дефолты, собери дефолт-пакет один раз, и уж да, повесь его всем юнитам один раз, зато потом менять нужно одну сцену.
Вторая: динамика. Глобальный слой-менеджер довольно легко с ней расправляется, но распределенка гораздо хуже обрабатывает рантайм-изменения. А они могут быть, допустим, герой купил предмет, который реагирует на смерти вокруг. Раньше в мире симуляции не было никого, кто слушал смерти, а сейчас появился - этот предмет. Ну, ничего, на самом деле, поебешься с дебагом, но Godot спокойно изменяет дерево в рантайме, просто носи аспект слушающий смерть вместе с предметом и навешивай на героя после покупки.
Отмечу, что ты приводил пример с одноразовым триггером. Это просто будет отдельный вид аспекта. Очень похожий, но отдельный. Допустим, у нас есть юнит, на нем есть аспект "умирающее", и рядом аспект "умирающее 1 раз". Первый орет на весь мир всем, кто слушает, а второй при триггере собирает всех слушающих в коллекцию (они же тоже в группах), сортирует ее как-то (по дистанции, например), и говорит только первому "слушай, я умер, но только для тебя, по-братски".
Фуууух.
Отличный вопрос, жаль, на русском, несчастные будут мучаться в переводчики это пихать, о чем таком интересном дискуссия.
3) *Что гуглить?* Гугли тему брокера сообщений (message broker или event broker). Также гугли аспектно ориентированное программирование.
Сори, ютуб не отправляет простыни, разбиваю так.
@@PointDown Супер, спасибо большое, прочекаю что есть по теме, мне ещё нравится что это решение может хорошо сочетаться с ECS архитектурой, где поведение объекта описывается его компонентами
@@Limofeus Ну-у, да-а-а, сочетается. Но для нормального ECS нужна низкоуровневость, исполнение на уровне движка. ECS хорош в юнити не потому, что он там [есть], он хорош, потому что там отдельный компилятор позволяет работать в несколько десятков(!) раз быстрее. Было бы очень круто иметь это в Godot, но последний раз, когда я проверял, какой-то ECS фраймворчик на нем был чисто на нодах, то есть над движком, по факту, меняющий только архитектуру проекта, но не добавляющий основного преимущества ECS в Да производительности.
first lol
the lord of godot documentation has returned to us