TacLibrary открытая библиотека для разработки игр на Unity 3d (идея создания)

[neroxt]

Очень интересно, пойду сразу код смотреть

[Jijiki]

когда мы пользуемся, поиском пути в мире, надо учитывать как происходит работа с картой, поделена ли она на чанки(я назову квадранты чанками), какая модель управления используется(в идеале потоковый WorldComposition, грузим куда идём/отгружаем то откуда идём, очистка ресурсов и всё такое), система должна работать по офсетам мне видится, сами чанки генерятся тоже в потоках из картинок, получается, если вы камерой летите и видите прогрузку - начать надо с этого, далее, после того когда чанки заработали, надо пересмотреть работу с картографией-поиск пути, если у нас есть карта высот(текущая и соседи доступные, ведь бесконечный мир не может хранить всю карту в памяти), соотв надо обрабатывать тот чанк где находится точка, если маршрут будет строится в межчанки, тогда есть глобальные координаты usize, и есть локальные, и вот надо их подружить получается

вобщем композитор наподобии как в воксельной тематике, только перенесенный в полигональный стиль

для упрощения можно боксы - обьемы(и получится что мы либо делим каждый квадрант либо композируем его от картинки в мир, и если второй случай, то это около 512х512 масштаб(обьем/производительность), в теории можно будет с таким масштабом по фрустуму грузить с центра по направлению чанки), рисовать, но тут нюанс за место 1 бокса-обьема квадранта, будет реальный квадрант

и вот еще момент, там если с картинки грузим, то координаты надо преобразовывать! (картинка <-> мир)

старт и точка куда, а на момент маршрута фиксить позицию по карте высот если она выбрана

[tac]

Это как раз то, что я назвал движкописательство. Юнити предлагает так называемый NavMesh, поэтому нет ни какой необходимости изобретать велосипед.