XENO | Столкновение с проблемами производительности

Энергетические щиты вокруг кораблей являлись прекрасным решением проблемы нехватки вычислительной мощности еще во времена космической фантастики 1996-1999-х годов на Pentium MMX 230 Mhz, при десятках и сотнях объектов в космосе, кораблей и астероидов, столкновения между ними наиболее экономично для процессора вычислять по формуле отрезка между геометрическими центрами, на предмет не произошло ли пересечение радиусов сфер вокруг 3D моделей, если же щитов небыло то при любом прорыве сферы другим объктом происходило быстрое уничтожение корабля, что бы постоянно не проверять столкновения по каждому треуголнику модели с каждым треуголником других 3D моделей, т.к. это затратно по ресурсам компьютера. Это удобное решение прочно закрепилось в играх, так же как до того закрепилось решение порталов и гипер-пространства для обновления экрана (что бы в момент перехода выгрузить из области рендеринга графики группу юнитов и загрузить новую - так как мощности системы нехватало как во времена Pentium MMX так и сейчас что бы рассчитывать огромный игровой мир, кроме того, который отображается на экране и неподалеку за его пределами) из других примеров кроме космической фантастики это загрузка и выгрузка локаций через порталы в фэнтази играх или пример игры "Aqua Nox 1996" - с точки зрения программиста ее демо это по сути почти основа всей игры, куб океана где есть вода, дно, и 3D подводные юниты, и механика взаимодействия между объектами, остальное - это множесто данных которые загружаются в этот же кубов океана (сектор) имитируя путешествие в разные локации, т.е. наполнение контентом (его загрузка и выгрузка в этот куб/сцену) создав основу 3D мира остальное уже кажется менее сложным. Теперь же есть уверенное желание что бы игровой мир был цельным.

Пересчет движения, столкновений 1/3, а 2/3 времени рассчет графики - все требует ресурсов, если на сцене слишком много 3D моделей FPS стремительно падает. Если сделать огромный игровой мир - большую планету с юнитами на поверхности и космические корабли на орбите, то и космос вокруг нужен с большими расстояними до планет и звезды, если распределить по такому масштабу космической фантастики тысячи астероидов, их даже небудет заметно - космический корабль будет летать от планеты к планете по абсолютной пустоте в которой непонятно летит он или нет (незаметно ориентиров), требуется несколько десятков тысяч астероидов и обломков что бы наполнить пустое пространство (конечно есть оптимизация 3D сцены и каскады LOD (LOW poly) моделей) но всего этого недостаточно - насыщая пространство окружением падает запас мощности который нужен на флоты кораблей), если же делать процедурную генерацию условного льда в космосе, то увидев ледяную глыбу однажды, отведя камеру и вернув ее обратно, ее уже будет снова не найти на этом же месте. По этим причинам первые 3D сцены проекта были отклонены и создана вторая модель, а потом и третий вариант сцены который и было решено развивать. Что бы не создавать несуществующие генерируемые глыбы ледяных астероидов которые потом невозможно найти снова, вместо них эффект пространства можно создать мельком пролетающими тяжелыми частицами, светящимися точками летящими от звезды случайным разряженым потоком и сопоставлять их с интесивностью излучения и типом звезды.

После частичного решения проблемы с наполнением космической пустоты, много тестов требуется провести для оптимизации производительности и создания неразрывности пространства. Загрузка звезд с планетами в сцену, по мере приближения к ним, и удаление объектов которые остаются далеко от 3D камеры/экрана, по мере влета в область видимости новые объекты включаются в рендеринг, процесс вклчения/выключения 3D моделей при влете-вылете в область видимости потребляет не очень много ресурсов, но единое вычислямое пространство с непрерывной загрузкой - выгрузкой 3d моделей в сцене во время полета камеры приводит к тому что некоторый компьютерный игрок может направить флот кораблей к соседней звезде, и другой игрок может сделать то же действие и вокруг экрана игрока окажутся тысячи космических кораблей сразу, а на процессоре например в 3.5 Ггц по тестам на макетах космических кораблей в сцене, число недолжно сильно превышать 1000 кораблей в сумме (помимо планет, астероидов и т.д.), это значит что либо в игре недолжно быть больше 3х империй по 300 кораблей (что целиком не соответсвует идее о разнообразии цивилизаций), либо нужно ограничивать искуственно ситуации с направлением в одну систему сразу 2х флотов против 1, или нужно искать другие решения для обеспечения игры при 40 и больше империях. На этапе тестирования проекта возникло столкновение с проблемой нехватки вычислительной мощности компьютеров заставляющая искать различные способы ее решения.