Comments 11
Очень интересно, пойду сразу код смотреть
когда мы пользуемся, поиском пути в мире, надо учитывать как происходит работа с картой, поделена ли она на чанки(я назову квадранты чанками), какая модель управления используется(в идеале потоковый WorldComposition, грузим куда идём/отгружаем то откуда идём, очистка ресурсов и всё такое), система должна работать по офсетам мне видится, сами чанки генерятся тоже в потоках из картинок, получается, если вы камерой летите и видите прогрузку - начать надо с этого, далее, после того когда чанки заработали, надо пересмотреть работу с картографией-поиск пути, если у нас есть карта высот(текущая и соседи доступные, ведь бесконечный мир не может хранить всю карту в памяти), соотв надо обрабатывать тот чанк где находится точка, если маршрут будет строится в межчанки, тогда есть глобальные координаты usize, и есть локальные, и вот надо их подружить получается
вобщем композитор наподобии как в воксельной тематике, только перенесенный в полигональный стиль
для упрощения можно боксы - обьемы(и получится что мы либо делим каждый квадрант либо композируем его от картинки в мир, и если второй случай, то это около 512х512 масштаб(обьем/производительность), в теории можно будет с таким масштабом по фрустуму грузить с центра по направлению чанки), рисовать, но тут нюанс за место 1 бокса-обьема квадранта, будет реальный квадрант
и вот еще момент, там если с картинки грузим, то координаты надо преобразовывать! (картинка <-> мир)
старт и точка куда, а на момент маршрута фиксить позицию по карте высот если она выбрана
Из проблемы работы с поиском пути вылезла проблема сделать какую то библиотеку. Причем я так ничего и не понял что там будет и чем поможет. Это ли не движкописательство?
Хотя по идее достаточно было заиспользовать AStar Project и разобраться в основах того, что такое поиск пути и оценках сложности этого алгоритма.
Проблема с поиском пути это лишь пример "проблем" и задач возникающих в юнити, в которых полезна библиотека более высокоуровневых игровых понятий. Использование специализированных аж целых библиотек аля AStar Project (хотя вы так и не дали ссылки и понять что это такое не возможно) с большой вероятностью, есть вторая обозначенная крайность - использование непропорционально больших ассетов для решения простой задачи.
А не поняли чем поможет, потому что в статье это и не описано, а код в репозитории вам посмотреть лень. Было бы нормально, если хоте ли бы разобраться попросить объяснить, но вы решили зайти с претензий ..
https://arongranberg.com/astar/front вполне широко используется в коммерческих проектах. Даже написав неправильно и загуглив получил ссылку в первой выдаче.
По мне, когда пишут статью, поднимая какую то проблему, то уводить куда то из статьи, чтобы понять о чем она написана стоит только для дополнительной информации о том, почему автор пришел к какому то выводу в статье и это должно быть опционально. Ну т.е. я ожидаю от статьи такого.
Что касается описания ссылок на доку и репозитории. Ок, я почитал. У меня только один вопрос - вам приходилось оптимизировать игру? Потому что предлагаемое решение, на мой взгляд, в мирах, где очень много сущностей, быстро начнет тормозить.
Возможно, но совсем не факт. Но вначале, хотелось бы выслушать ваши аргументы, почему начнет тормозить? Только тогда можно будет понять, что мы обсуждаем. Но в любом случае, это не повод использовать платный ассет с кривым решением.
Вот ECS вы оценили как костыль, A* Pathfinding как ассет с кривым решением. Почему? У меня совсем другой опыт. ECS дает великолепный Performance Boost, при этом тоже отлично разделяет логику и данные. A* тоже отлично работает, гибкий и быстрый.
Тормозить начнет потому что идея основана на вынесении логики. Это намного менее производительно, чем конвейерная пакетная обработка.
идея основана на вынесении логики
Можете это подробнее описать. Это типа любовь к ECS и вера, что нарушая ООП появляется производительность. Или что-то другое?
P.S. Про остальное я могу ответить, но это длинный разговор, а по ссылкам вы не хотите проходить ... впрочем одну дам, чтобы снять начальные вопросы про ECS, при желании там есть еще объяснения, что уродство кода ECS - подходом не дает ни производительности, ни какого либо удобства.
Что касается, A* Pathfinding - юнити тоже реализует этот же алгоритм. Делать аналогичное решение, как сделали разрабтчики A* Pathfinding Project - это классическое движкописательство, на сколько я понял из описания их библиотеки, они перереализовали практически тот же подход через NavMesh, детально нужно разбираться, но в этом нет смысла, когда это не поддерживает Юнити. Как и написал в статье, это устареет. Поэтому даже если их решение в чем то интересное, его возьмут и засунут в коробку, а само по себе она не нужно.
Попробуйте найти среди тоны кода решения от A* Pathfinding Project вот такой кусочек
// PathTypesDemo.cs
IEnumerator DemoMultiTargetPath () {
MultiTargetPath mp = MultiTargetPath.Construct(multipoints.ToArray(), end.position, null, null);
mp.pathsForAll = !onlyShortestPath;
lastPath = mp;
AstarPath.StartPath(mp);
yield return StartCoroutine(mp.WaitForPath());
...
}а потом сравните, что в том же месте в моем наивном, но нативном решении. И затем просто подумайте, откуда тут появится лучшая производительность? И зачем в свой проект тянуть несколько сотен классов, логику которых вам совсем не хочется знать, вместо того, как сделано в моей библиотеке решение на базе Юнити, стоящее двух методов с прозрачным решением. Я бы о нем написал и подробнее, но у меня ограничение на количество статей на хабре.
Такое ощущение что я слышу убеждения, когда сам аргументы привожу из собственного опыта. Может у вас тоже свой опыт. Тогда, видимо, мы по-разному готовим.
Вы не справедливы. Я привожу вам код и подробные объяснения, а в ответ слышу только короткие замечания. Опыта в этом не заметно, не то что его нет, может он и есть. Но вы не читаете, не слушаете и не смотрите код, а свой не показываете. Поэтому странно сравнивать убеждения. И да, все программисты по разному готовят, собственно это то самое место, где мы обсуждаем как мы это делаем.
Давайте вернемся к началу
> Хотя по идее достаточно было заиспользовать AStar Project и разобраться в основах того, что такое поиск пути и оценках сложности этого алгоритма.
Итог разговора. Это не просто достаточно - это с переизбытком и не нужно. Это как раз иллюстрирует слова из статьи: "Не каждое функциональное решение разработчик хочет тянуть «к себе в проект». И этому есть куча причин."
В идеале, я вообще не должен знать что-такое AStar не говоря о каких то там оценках сложности. Это не тот уровень абстракции. В статье поэтому и говорится о "Юнити предоставляет достаточно низко уровневые понятия и логику построения игрового пространства. Нет ни каких высокоуровневых концепций "
Позвольте себе думать более высокими категориями.
TacLibrary открытая библиотека для разработки игр на Unity 3d (идея создания)