Пост

В процессе разработки: апрель

Эксцентричная аномалия при средней аномалии

После того, как я улучшил интерфейс полетов для v0.7.6 и переработал систему управления ракетами в v0.7.8, я мог наконец-то начать работу над межпланетными полетами. И первое, что мне нужно было сделать — это переписать математическую симуляцию.

Я реализовал ее в те дни, когда думал, что в игре будет очень упрощенная физика ракет. Если коротко, то во время ускорения космического корабля учитывалась только полная тяга всех двигателей, а аэродинамика отсутствовала вовсе. Когда же двигатели были выключены, положение ракеты рассчитывалось по ее орбите. Поэтому, когда я добавил в игру полноценную физическую симуляцию, я решил использовать математическую симуляцию в тех случаях, когда двигатели ракеты выключены, и она не летит в атмосфере. Мат. симуляция рассчитывала позиции ракет очень быстро (нужно было просто подставить значение текущего времени в пачку формул), что позволяло ускорять время более чем в десять раз.

Но с течением времени обе системы стали все больше и больше расходиться в наборе поддерживаемых функций. Например, у математической симуляции не было доступа к деталям ракет, их параметрам и физической форме. Из-за этого она не могла правильно рассчитать тензор инерции и повернуть ракету под правильным углом. Как следствие, неверно рассчитывалось и энергопотребление. Поэтому мне приходилось переключаться на физическую симуляцию каждый раз, когда к ракете прилагался любой момент силы. В результате, ракета не могла продолжать бесконечно вращаться в космосе, когда автоматическая стабилизация была выключена.

Последнее, чего очень не хватало в математической симуляции — это доступа к остальному миру игры, помимо доступа к гравитации и радиусу всех планет, который у нее был. Это значит, что я не мог проверить, не провалилась ли ракета под поверхность планеты, используя карты высоты или шум. Это не проблема для планет с атмосферой, потому что около поверхности ракета всегда будет рассчитываться с помощью физической симуляции (был правда забавный баг, когда ракета в последний момент перед столкновением переключалась на математическую симуляцию и начинала лететь к ядру планеты). Но в Солнечной системе нет атмосферы на Меркурии, Луне и на многих других спутниках, поэтому эту проблему мне тоже нужно было решить.

В итоге я переписал математическую симуляцию, чтобы исправить все описанные проблемы, а затем запустил игру, чтобы насладиться идеальным, стабильным результатом. Но вот первое, что я увидел, когда ракета достигла космоса:

-.-)

На самом деле, это было ожидаемо. Каждый раз, когда вы вносите такие большие изменения, в любом проекте сразу возникнет множество ошибок и регрессий. Но если приложить дополнительные усилия и разобраться с возникшими проблемами, игровые системы становятся более стабильными и расширяемыми в будущем.

^_^

Я закончил разработку математической симуляции и решил навестить родителей, которые живут в другой части страны. И как только я к ним приехал, в России произошла вспышка COVID-19, и я застрял там в карантине, вдали от своего рабочего компьютера. Но хотя бы у меня был ноутбук. У него нет видеокарты, и Rocket Science выдает на нем 15 FPS, а Unity открывается по десять минут. Но я придумал, как с этим справиться.

Следующей задачей был планировщик маневров. Он слабо связан с остальной игрой, потому что единственная информация, которая ему нужна — это орбиты, небесные тела и изменения в скорости космического корабля.

Поэтому я переместил весь нужный исходный код в новый проект и начал разрабатывать фундамент планировщика. Это позволило быстро вносить изменения, запускать проект, тестировать его и повторять этот процесс. И первым я добавил поддержку параболических и гиперболических орбит:

Параболическая орбита

Гиперболическая орбита

После этого я изменил способ расчета, генерации и обновления орбит. Раньше игра могла поддерживать одновременно отрисовку и обновление около пятидесяти орбит без значительного влияния на FPS. После внесенных изменений я протестировал 100 орбит:

250 орбит:

1000 орбит:

Это, конечно, синтетические тесты, однако я уверен, что игра будет поддерживать большое количество объектов на орбите, и я смогу затронуть такие проблемы в игре, как, космический мусор. Также у планировщика маневров будет более высокий предел прогноза траекторий.

Следующая проблема, с которой мне нужно было разобраться — это рейкаст орбиты, который позволит выбрать точку, где должен начаться маневр. Я не мог использовать физику Unity, так как на таких масштабах точность вычислений будет сильно страдать. Также достаточно дорого пересоздавать новые коллайдеры для орбит космических кораблей, так как при ускорении они будет изменяться в каждом кадре. На самом деле, эта задача оказалась сложнее, чем я думал. По сути, нужно обойти каждую видимую орбиту, вычислить ближайшую точку к рейкасту, спроецировать ее обратно на экран и сравнить полученную позицию с позицией мыши. Однако новая архитектура орбит справилась с этим восхитительно:

Фундамент для планировщика маневров был готов. Три дня назад я собрал новый компьютер, чтобы продолжать работать над игрой в том же темпе, который был дома (потому что я не знаю, когда закончится карантин и я смогу вернуться). Я заменил в игре старую систему орбит на новую и проверил, что все работает как надо:

Далее нужно реализовать прогноз траекторий, энкаунтеры, системы добавления узлов маневров не только к текущей орбите космического корабля, но и к прогнозируемым. И все это умножается на требования к масштабу Солнечной системы и проблемы с точностью. Звучит непросто, но практически каждая задача кажется тяжелой до тех пор, пока вы не начнете ее решать.

Еще я начал работать с Артуром (композитором саундтрека Rocket Science) над дополнительными треками для сборочного цеха, полета на орбите, в межпланетном пространстве и для планет с атмосферой и без нее. Они будут включены в игру и в ОСТ на Стиме со следующим обновлением.

Пока это все, до встречи в следующем дневнике разработки.

Авторский пост защищен лицензией CC BY 4.0 .

© unbeGames. Некоторые права защищены.

Популярные теги