Благодарю за интересное видео! Решение использовать несколько алгоритмов движения, но при этом получить улучшенную оптимизацию - хорошее решение)) С удовольствием пощупаю код! P/s "Спайки" на русском имеют другое значение)) Звучит лишком чужеродно...
Игорь привет. В открытом уроке Presentation Model, вы рассказывали про демо проект, который скидывали в чат. Можно его как нибудь получить? Мне интересно посмотреть как реализован менеджер ui, и работа с ui в целом
@@CodeCraftUnityEditionКлассно, я в вебе работаю, у нас тоже на NUnit тесты, хотя для своих проектов предпочитаю XUnit. А про то что в Unity есть свои какие-то инструменты для тестирования, помимо бенчмарка и отладки не знал
@@Daniel48476типо в намеше для этого мало возможностей. Суть серии видео чисто контент на Ютуб. Оптимизацией никогда нельзя заниматься до выявления проблем. Автор видео меняет рейкасты юнити на свои, физику и другое, а мог уже как месяц играть в свой прототип
Потому что граун-сетка решает много проблем: поиск пути, строительство зданий, рейкасты + можно динамически контролировать по каким клеткам каким юнитам можно ходить, а каким нет. Также иногда бывает, что NavMesh не всегда может посчитать путь и вернуть false, что дико бесит)
@@CodeCraftUnityEdition Спасибо за ответ :) Но все таки надо было об этом в видео рассказать, раз в описании написано :) На самом деле мало информации в ютубе, с каким проблемами можно столкнуться если использовать стандартный NavMesh и рассказать его минусы. Может потом поделитесь?
Спасибо за видео! У меня тут терзающий вопрос, а смогу ли я на Unity создать стратежку в которой все будет происходить в реальном времени, но юниты будут передвигаться определенное время (10-15 сек)? И у них будет ограничение по ходам, только после того как пройдет некоторое время у них так сказать восстановится "выносливость" и они смогут снова идти, как например в игре Hearts of Iron IV, только менее масштабно)
Мне сложно ответить на вопрос, так как я не знаю ваш бэкграунд. С точки движка Unity, да, возможно. Как я понял, получается RTS, просто есть пауза в виде ходов.
Не всегда. У каждого объекта есть свои размеры, и в одном случае в узкий проход мышка может пробежать, а танк нет. Поэтому поиск пути может учитывать и этот параметр. Но для однотипных юнитов, которые находятся в одной клетке, можно сэкономить
@@CodeCraftUnityEdition а, ну да, всё верно. Еще нужно будет добавлять пповерку размеров. Но на плоскости это всё понятно, а как бвть если ландшафт объемный? Есть спуски и подъёмы?
Вот с разными размерами юнитов начинается хардкор, в алгоритме это нужно учитывать проверяя можно ли пройти через вершину не касаясь других. Поэтому я пока что опустил этот момент
![Алгоритмы Поиска Пути на Python. Алгоритм А*, Дейкстры, Поиск в ширину [ Pygame ]](/img/1.gif)
Благодарю за интересное видео!
Решение использовать несколько алгоритмов движения, но при этом получить улучшенную оптимизацию - хорошее решение))
С удовольствием пощупаю код!
P/s
"Спайки" на русском имеют другое значение)) Звучит лишком чужеродно...
Обои как всегда зачёт!
Потому что они с кастомным навмешом
@@elsee8865 гениально)
Открытый репозиторий будет?
Игорь привет. В открытом уроке Presentation Model, вы рассказывали про демо проект, который скидывали в чат. Можно его как нибудь получить? Мне интересно посмотреть как реализован менеджер ui, и работа с ui в целом
Вот вроде: disk.yandex.ru/d/EA0V-fmsQ2u81Q
благодарю, но не увидел там менеджер ui. он не входил в тот файл?@@CodeCraftUnityEdition
Отличное видео, на чём Unit-тесты пишешь?
На C#. Библиотека NUnit. В движке Unity есть фреймворк для тестирования
@@CodeCraftUnityEditionКлассно, я в вебе работаю, у нас тоже на NUnit тесты, хотя для своих проектов предпочитаю XUnit.
А про то что в Unity есть свои какие-то инструменты для тестирования, помимо бенчмарка и отладки не знал
Ну и лайк само сабой
Благодарю (само собой)
Спасибо за видео. Но так и не услышал почему отказались от NavMesh или других написанных систем.
Он в самом конце немного сказал об этом! Видимо, чтобы просто контролировать полностью, настраивать так, как хочется.
@@Daniel48476типо в намеше для этого мало возможностей.
Суть серии видео чисто контент на Ютуб. Оптимизацией никогда нельзя заниматься до выявления проблем. Автор видео меняет рейкасты юнити на свои, физику и другое, а мог уже как месяц играть в свой прототип
Потому что граун-сетка решает много проблем: поиск пути, строительство зданий, рейкасты + можно динамически контролировать по каким клеткам каким юнитам можно ходить, а каким нет. Также иногда бывает, что NavMesh не всегда может посчитать путь и вернуть false, что дико бесит)
@@CodeCraftUnityEdition Спасибо за ответ :) Но все таки надо было об этом в видео рассказать, раз в описании написано :) На самом деле мало информации в ютубе, с каким проблемами можно столкнуться если использовать стандартный NavMesh и рассказать его минусы. Может потом поделитесь?
Спасибо за видео!
У меня тут терзающий вопрос, а смогу ли я на Unity создать стратежку в которой все будет происходить в реальном времени, но юниты будут передвигаться определенное время (10-15 сек)? И у них будет ограничение по ходам, только после того как пройдет некоторое время у них так сказать восстановится "выносливость" и они смогут снова идти, как например в игре Hearts of Iron IV, только менее масштабно)
Мне сложно ответить на вопрос, так как я не знаю ваш бэкграунд. С точки движка Unity, да, возможно. Как я понял, получается RTS, просто есть пауза в виде ходов.
@@CodeCraftUnityEdition Спасибо большое за ответ)
Я так думаю что можно ещё добавить что если юниты находятся рядом, то они будут идти по одому пути и не нужно каждому считать путь по отдельности
Не всегда. У каждого объекта есть свои размеры, и в одном случае в узкий проход мышка может пробежать, а танк нет. Поэтому поиск пути может учитывать и этот параметр. Но для однотипных юнитов, которые находятся в одной клетке, можно сэкономить
@@CodeCraftUnityEdition а, ну да, всё верно. Еще нужно будет добавлять пповерку размеров. Но на плоскости это всё понятно, а как бвть если ландшафт объемный? Есть спуски и подъёмы?
А что делать если юнит большой или карта изменилась во время движения? Юнит будеть проходить боками сквозь стены.
Вот с разными размерами юнитов начинается хардкор, в алгоритме это нужно учитывать проверяя можно ли пройти через вершину не касаясь других. Поэтому я пока что опустил этот момент
Ютуб не дает ставить слишком мелкие комменты, поэтому накалакаю тут чего
Мысли по поводу оптимизации - использовать ref struct + небезопасный код
Согласен, для этого в проекте у меня есть ECS. В этом демо-примере использую реализации без оптимизации
Что за программа для рисования?
Figma
69 юнитов маловато для ртс)
Пока да, но по мере развития движка, кол-во юнитов будет больше)
Тяжело слушать, так много лишних слов, да, мы как раз, фактически...