LOCO Railroad Simulator

Нам пришлось иметь дело с довольно широким спектром областей разработки: Unity, HDRP; реализовать собственное физическое моделирование с нуля; базовый PCG; «отполировать» купленные сторонние модели Daz3D в Blender (и их текстуры в GIMP), чтобы реализовать LOD; проблемы с совместимостью, ошибки рендеринга (обесцвечивание mip-текстуры), ошибки анимации (неверно расположенные начала координат деталей модели).

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

Чем мы отличились от конкурентов:

• взяли лучшее из обоих миров: красоту и тяжелый физический вес железной дороги, удобство и свободу модельной железной дороги
• более современный рендеринг по сравнению с большинством известных симуляторов реальной железной дороги; более реалистичный стиль (т.е. меньше стилизации) по сравнению с большинством симуляторов модельной железной дороги

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

В то же время пользователь размещает чисто косметические элементы, «декорации»: здания, грузовики, пешеходные мосты, сигналы, деревья, кусты, мусор.

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

В обоих режимах пользователь может настроить время суток (включая ночь), направление солнца, туман, облачность.

своя физика

Почему нам пришлось прибегнуть к созданию собственной физики:

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

Суть функций и детали реализации:

• Каждый локомотив/вагон жестко прикреплен двумя точками к одной линии посередине железной дороги. (По сути, между видимыми рельсами проложен невидимый монорельс).
• Импульс (и дельта-импульс) является «королем» физического состояния каждого локомотива/вагона.  Все силы, скорости и ускорения преобразуются в импульс (или дельта-импульс) или выводятся из импульса (или дельта-импульса).
• Положение и поворот жестко определяются двумя точками крепления. (По сути, положение и поворот железнодорожного вагона - это среднее значение между двумя точками крепления.)
• Обнаружение столкновений, натяжение цепи, импульс и остальная физическая симуляция «происходят» на уровне кузова железнодорожного вагона.
• При каждом такте моделирования импульс передается от локомотива к противоположному концу, при этом запоминается встречный импульс. Запомненный импульс применяется в начале следующего такта.
• В конечном счете, это всё ещё метод Эйлера с цепями в качестве не совсем жесткого ограничения. Однако мы используем линейный характер поездов в свою пользу. Распространение в линейном порядке обеспечивает полную жесткость положения/поворота, управляемого «монорельсом», и реакции на столкновения. Тот факт, что только цепи являются численно нестабильными и что они также обрабатываются в линейном порядке, в сочетании с медленным движением поездов, делает невозможным дестабилизацию физики отдельного поезда.
• Столкновения с препятствиями или другими поездами - это слабая сторона наших физических расчетов.  Это можно преодолеть, но мы решили, что для бюджета проекта будет лучше это «обойти через геймдизайн» (т.е. слегка ограничить свободу пользователей, чтобы сделать «проблематичные ситуации» недоступными).

графика

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

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

Когда дело доходит до производительности рендеринга, наше собственное содержимое (как правило, поезда и здания) является основным препятствием. Мы намеренно приобрели ресурсы с высокой степенью детализации: они должны быть не менее подробными, чем модели, используемые в реальных моделях железных дорог. Как обычно, решением проблемы слишком высокого уровня детализации является снижение его для объектов, удаленных от камеры. Однако стандартный подход, заключающийся в использовании нескольких версий (для разных LOD) одной и той же модели, не был для нас экономически эффективным. Вместо этого мы разделили модели на несколько полигональных сеток, чтобы скрыть их по пороговому значению расстояния. Например, каждый локомотив/вагон имеет отдельную полигональную сетку, содержащую только заклепки, которые видны только на очень близком расстоянии от камеры. Затем, на среднем расстоянии, мы можем скрыть детали интерьера (как подвижного состава, так и зданий). И тогда – на очень большом расстоянии – на слабых ПК нам приходится жертвовать оконными стеклами, оставляя только проёмы, и даже всеми неподвижными частями корпуса.

другие трудные задачи

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

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

Другой половиной были тупиковые эксперименты. Это обратная сторона медали, когда такой подход оправдан и действительно работает: да, мы создали прототип по принципу “дешево любой ценой”; но нет, мы не стали продолжать, потому что пришли к выводу, что дальнейшая разработка того не стоит. Например, одним из таких экспериментов была процедурная генерация городов во время выполнения.