Почему решили использовать UniTask вместо ValueTask?
Если интересует мое мнение: мне сначала нравились UniTask, но не удобно то что они не показывают стек вызова, в эксепшене ты видишь только что вызов был из PlayerLoop и юнитаску. ValueTask честно показывает стек вызова, откуда была запущена.
Про "checked/unchecked exceptions" - наверно он имел в виду обработанные catch-ем и unhandled exceptions. Вообще мне кажется автор пару вопросов из собеса по Java случайно добавил. )
Я специально написал в вопросе в контексте Unity (C#). В C# вопрос должен звучать так - чем отличается readonly (и sealed) / finally / Finalize().
А еще лучше просто спросить, что такое readonly, sealed, как работает try/catch/finally (и хорошо если скажут когда не работает )), и что такое Finalize() (можно спросить в связке с Dispose()).
Отличная статья, спасибо! Надеюсь будет продолжение, есть желание изучить ECS, если напишите какой-то туториал для новичков скажем по Morpeh - с удовольствием бы почитал.
Мне кажется можно избавиться от рефлексии, если каждый раз при подписке передавать интерфейс в явном виде (но тогда для каждого интерфейса придется вызывать подписку и отписку).
Так же можно добавить асинхронные RaiseEvent - чтобы их можно было авейтить (внутри сделать как Task.WhenAll). Тогда можно будет делать await RaiseEvent<..> и ждать когда все подписчики выполнят свои таски.
Согласен с большинством советов, но некоторые моменты спорные:
Постарайтесь определить как можно больше в коде, а не полагаться на Unity Editor или предварительную сериализацию. Когда вам понадобится что-то рефакторить, наличие множества вещей, соединенных в единые YAML-файлы, добавит вам проблем. Используйте редактор, чтобы быстро найти хороший набор значений в рантайме, затем впишите его в код и удалите [SerializeField].
Автор предалагает хардкодить какие-то значения, которые можно задать в эдиторе? Или выность в какие-то отдельные файлы настроек? А ссылки как — через GetComponent<>? )
Избегайте 2D физики Unity даже для 2D-игр. Постройте ее с 3D, и вы получите многопотоковый Nvidia Physx вместо менее производительного Box2D.
Если проект для мобил — сдается мне, что 2D будет все таки профитнее. Хотя лучше проверить и убедиться.
Используйте редактор кода, который показывает ссылки на классы, переменные и методы. Например, Visual Studio Code — он великолепен.
Прикольно, у меня есть подобная наработка AI, только более продвинутая (NPC лазит, спрыгивает, запрыгивает, земля любой геометрии из SpriteShapes, на движущихся платформах даже почти ездит (малость доделать надо :)), лестницы вот только вертикальные обычные). Тоже есть эммоции (обычный, агрессивный, паника, ...) и есть список потребностей (жажда, голод, нужда в деньгах и тп) и точек интереса (есть, пить, в туалет, работать, ...), в зависимости от этого перс принимает решение, идет в нужное место и делает что надо. Сейчас правда тоже подзабросил. Может гифку запосчу позже.
Чем не устроил A*? Отлично подходит для такого решения, простой и эффективный, не понял почему начали свой велосипед изобретать.
Статья супер, есть даже ответ на вопрос который у меня возник в процессе чтения, раз уж используется C# 7+ (ответ в последнем примечании). Только дело не в любви, если мне не изменяет память Coroutines выполняются в Main Thread, в отличие от async/await, для закачки наверно лучше все таки задействовать другие потоки.
Я не собирался спорить с вами, просто высказал мысли о том что можно улучшить, которые появились после прочтения статьи.
5) Сортировка списка не нужна, это будет лишняя трата ресурсов, достаточно просто поиска минимума (это намного быстрее). Без неё (то что у вас сейчас) — это другой алгоритм, не A* (поиск в ширину по моему называется, точно не помню сейчас).
6) Я не имел в виду использовать юнитевский, я имел в виду написать свой NavMesh.
1) Наследование карты (Map) от препятствия (Obstacle) — лучше сделать им общего абстрактного предка. У Obstacle еще добавляется функционал и он весь будет унаследован картой.
2) С точки зрения оптимизации каждый кадр в карте пробегать и проверять препятствия — не сдвинулись ли они и не поменяли ли размер — плохое решение. У большинства препятствий 99,9% времени размер и позиция не будут меняться. Лучше чтобы они при изменении позиции или размера уведомлять карту что было изменение (ставить флаг requireRebuild в True или если не хочется чтобы Obstacle знал о Map то завести статичный флаг, скажем, dirty — и его устанавливать при изменении позиции или размера, а из карты его чекать). Будет работать намного быстрее.
3) При изменении положений или размера препятствий обычно всю карту не перестраивают, только часть.
4) «Дело в том, что в unity для указания позиции объекта в пространстве используется простой float который весьма неточен и может быть дробным или отрицательным числом, поэтому его будет сложно использовать для реализации поиска пути на карте. Координаты же выполнены в виде четкого int который всегда будет положительным и с которым работать намного проще при поиске соседних точек.» — не согласен. float-а вполне достаточно, просто чем делать карту и брать из неё точки лучше задать возможные переходы для каждой точки (и можно посчитать их стоимость — чтобы не тратить время в риалтайме), тогда все будет работать нормально, немного больше расход памяти, но работать будет быстрее. A* по большому счету без разницы — сетка это или просто графы, это алгоритм поиска по графам, а сетка лишь частный случай.
5) Реализация A* ваша немного странная — не понял как идет выборка из открытого списка. Такое ощущение что не лучшее совпадение берется, а всегда первый попавшийся. Вы всегда берете первый элемент массива openList[0] без учета эвристики. Или он у вас где-то сортируется? Не очень понял этот момент.
6) Для этого примера лучше бы подошел NavMesh — гораздо меньше узлов пришлось бы обработать, работало бы быстрее. Хотя если просто для примера — то нормально.
7) По самой Job system — инфы мало, хотя статья о нем.
PS: при изменении размеров и позиции препятствий боты глючат.
Круто, идея интересная. Только лучше поменять Windows-1251 на UTF-8 в тегах и readme, если не сложно, на маке не отображается.
Хм, возможно я не прав и что-то путаю.
Статья отличная, как и первая часть.
Почему решили использовать UniTask вместо ValueTask?
Если интересует мое мнение: мне сначала нравились UniTask, но не удобно то что они не показывают стек вызова, в эксепшене ты видишь только что вызов был из PlayerLoop и юнитаску. ValueTask честно показывает стек вызова, откуда была запущена.
Про "checked/unchecked exceptions" - наверно он имел в виду обработанные catch-ем и unhandled exceptions. Вообще мне кажется автор пару вопросов из собеса по Java случайно добавил. )
Я специально написал в вопросе в контексте Unity (C#). В C# вопрос должен звучать так - чем отличается readonly (и sealed) / finally / Finalize().
А еще лучше просто спросить, что такое readonly, sealed, как работает try/catch/finally (и хорошо если скажут когда не работает )), и что такое Finalize() (можно спросить в связке с Dispose()).
>> В чём разница между ключевыми словами final, finally, finalize?
А можно услышать ответ, в контексте Unity (C#) ? )
Отличная статья, спасибо! Надеюсь будет продолжение, есть желание изучить ECS, если напишите какой-то туториал для новичков скажем по Morpeh - с удовольствием бы почитал.
Вместо == лучше использовать ReferenceEquals(animator, null)
Отличная статья, спасибо!
Мне кажется можно избавиться от рефлексии, если каждый раз при подписке передавать интерфейс в явном виде (но тогда для каждого интерфейса придется вызывать подписку и отписку).
Так же можно добавить асинхронные RaiseEvent - чтобы их можно было авейтить (внутри сделать как Task.WhenAll). Тогда можно будет делать await RaiseEvent<..> и ждать когда все подписчики выполнят свои таски.
Автор предалагает хардкодить какие-то значения, которые можно задать в эдиторе? Или выность в какие-то отдельные файлы настроек? А ссылки как — через GetComponent<>? )
Если проект для мобил — сдается мне, что 2D будет все таки профитнее. Хотя лучше проверить и убедиться.
Попробуй Rider — он еще великолепнее. )
Лучше в Dictionary ключи не string, а тип (T). При таком подходе поиск зависимостей по проекту делать проще, чем по стрингам.
Чем не устроил A*? Отлично подходит для такого решения, простой и эффективный, не понял почему начали свой велосипед изобретать.
Из фантастики еще можно упомянуть 13 этаж. Ну и Хакеры — тоже про IT.
5) Сортировка списка не нужна, это будет лишняя трата ресурсов, достаточно просто поиска минимума (это намного быстрее). Без неё (то что у вас сейчас) — это другой алгоритм, не A* (поиск в ширину по моему называется, точно не помню сейчас).
6) Я не имел в виду использовать юнитевский, я имел в виду написать свой NavMesh.
1) Наследование карты (Map) от препятствия (Obstacle) — лучше сделать им общего абстрактного предка. У Obstacle еще добавляется функционал и он весь будет унаследован картой.
2) С точки зрения оптимизации каждый кадр в карте пробегать и проверять препятствия — не сдвинулись ли они и не поменяли ли размер — плохое решение. У большинства препятствий 99,9% времени размер и позиция не будут меняться. Лучше чтобы они при изменении позиции или размера уведомлять карту что было изменение (ставить флаг requireRebuild в True или если не хочется чтобы Obstacle знал о Map то завести статичный флаг, скажем, dirty — и его устанавливать при изменении позиции или размера, а из карты его чекать). Будет работать намного быстрее.
3) При изменении положений или размера препятствий обычно всю карту не перестраивают, только часть.
4) «Дело в том, что в unity для указания позиции объекта в пространстве используется простой float который весьма неточен и может быть дробным или отрицательным числом, поэтому его будет сложно использовать для реализации поиска пути на карте. Координаты же выполнены в виде четкого int который всегда будет положительным и с которым работать намного проще при поиске соседних точек.» — не согласен. float-а вполне достаточно, просто чем делать карту и брать из неё точки лучше задать возможные переходы для каждой точки (и можно посчитать их стоимость — чтобы не тратить время в риалтайме), тогда все будет работать нормально, немного больше расход памяти, но работать будет быстрее. A* по большому счету без разницы — сетка это или просто графы, это алгоритм поиска по графам, а сетка лишь частный случай.
5) Реализация A* ваша немного странная — не понял как идет выборка из открытого списка. Такое ощущение что не лучшее совпадение берется, а всегда первый попавшийся. Вы всегда берете первый элемент массива openList[0] без учета эвристики. Или он у вас где-то сортируется? Не очень понял этот момент.
6) Для этого примера лучше бы подошел NavMesh — гораздо меньше узлов пришлось бы обработать, работало бы быстрее. Хотя если просто для примера — то нормально.
7) По самой Job system — инфы мало, хотя статья о нем.
PS: при изменении размеров и позиции препятствий боты глючат.