Пока упрощенный - надо еще понять, как правильно все сделать. Есть успехи:
1) Уже генерируется базовый ландшафт, состоящий из блоков с высотой 0. То есть "чистое поле". Размер произвольный, тестировал от 8Х8 до 256Х256 блоков.
2) Вроде окончательно решен вопрос с определением индекса блока ландшафта, на который указывает курсор мыши. Да и вообще любой объект, имеющий координаты.
3) Выборочно заменяются блоки ландшафта на другие.
Что нужно сделать:
1) Нужно чтобы блоки ландшафта не просто заменялись, а еще и меняли свою форму, если по соседству изменен блок, как в примере с забором. Тут будет много возни - потому что возможное число вариантов соседства будет просто неприличным. Надо что-то придумать.
2) Разобраться с отображением блоков. Вариант как с забором не подходит, потому что число блоков опять же неприличное. 64Х64 еще более-менее BGE держит, а дальше начинаются тормоза. Есть вариант - создать матрицу из блоков, копирующую координаты камеры. Индекс ячейки уже определять можно, проблем с перемещением камеры быть не должно. Провел эксперимент с заменой меша блока через .replaceMesh(). Как оно выглядит до запуска:
Более темные плейны вне поля зрения камеры. Если предполагается, что камера будет вращаться, то нужно располагать плейны в виде круга.
После запуска каждый из зеленых плейнов, их тут 576, если правильно посчитал, раз в два тика меняет свой меш - нечетный раз на синий куб, четный - на красный куб. Выглядит этот процесс так, что блевануть хочется. ФПС- 60, время прорисовки то же, что и в пустой сцене. Как оно будет с учетом необходимости доступа к данным в списке - вот еще что хотелось бы знать.
3) Добавить размещение ключевых точек и ресурсов. Или сделать карту ресурсов отдельно?
4) И написать парсер, который будет отправлять данные в файл. Не проблема, уже делал.
После создания редактора ландшафтов дошлифовать навигационные классы и вообще собрать пример поиска пути.
Еще болит голова, о размере блоков ландшафта и узлов навигационного графа - 2х2 метра вроде хорошо для точности навигации, неплохо для отображения групп юнитов (пехотинцы не так далеко друг от друга), но плохо с точки зрения скорости расчета пути и визуализации блоков ландшафта. 4х4 определенно лучше для визуализации ландшафта, неплохо при расчете пути, но мелкие юниты, размером меньше ячейки, уже слишком далеко друг от друга, плохо, что и рассчитанный путь получается слишком грубым. 1Х1 и 8Х8 даже не рассматриваю. 1Х1 - это уже шутеры и РПГ, хотя для шутера все же помельче надо.
P.S. Вроде не пил, а расписался...
1) Уже генерируется базовый ландшафт, состоящий из блоков с высотой 0. То есть "чистое поле". Размер произвольный, тестировал от 8Х8 до 256Х256 блоков.
2) Вроде окончательно решен вопрос с определением индекса блока ландшафта, на который указывает курсор мыши. Да и вообще любой объект, имеющий координаты.
3) Выборочно заменяются блоки ландшафта на другие.
Что нужно сделать:
1) Нужно чтобы блоки ландшафта не просто заменялись, а еще и меняли свою форму, если по соседству изменен блок, как в примере с забором. Тут будет много возни - потому что возможное число вариантов соседства будет просто неприличным. Надо что-то придумать.
2) Разобраться с отображением блоков. Вариант как с забором не подходит, потому что число блоков опять же неприличное. 64Х64 еще более-менее BGE держит, а дальше начинаются тормоза. Есть вариант - создать матрицу из блоков, копирующую координаты камеры. Индекс ячейки уже определять можно, проблем с перемещением камеры быть не должно. Провел эксперимент с заменой меша блока через .replaceMesh(). Как оно выглядит до запуска:
Более темные плейны вне поля зрения камеры. Если предполагается, что камера будет вращаться, то нужно располагать плейны в виде круга.
После запуска каждый из зеленых плейнов, их тут 576, если правильно посчитал, раз в два тика меняет свой меш - нечетный раз на синий куб, четный - на красный куб. Выглядит этот процесс так, что блевануть хочется. ФПС- 60, время прорисовки то же, что и в пустой сцене. Как оно будет с учетом необходимости доступа к данным в списке - вот еще что хотелось бы знать.
3) Добавить размещение ключевых точек и ресурсов. Или сделать карту ресурсов отдельно?
4) И написать парсер, который будет отправлять данные в файл. Не проблема, уже делал.
После создания редактора ландшафтов дошлифовать навигационные классы и вообще собрать пример поиска пути.
Еще болит голова, о размере блоков ландшафта и узлов навигационного графа - 2х2 метра вроде хорошо для точности навигации, неплохо для отображения групп юнитов (пехотинцы не так далеко друг от друга), но плохо с точки зрения скорости расчета пути и визуализации блоков ландшафта. 4х4 определенно лучше для визуализации ландшафта, неплохо при расчете пути, но мелкие юниты, размером меньше ячейки, уже слишком далеко друг от друга, плохо, что и рассчитанный путь получается слишком грубым. 1Х1 и 8Х8 даже не рассматриваю. 1Х1 - это уже шутеры и РПГ, хотя для шутера все же помельче надо.
P.S. Вроде не пил, а расписался...
Комментариев нет:
Отправить комментарий