Моделирование скорости распространения световой информации в космическом боевом симе

Я работаю над симулятором космического боя, который разворачивается на относительно больших территориях (куб пространства ~ 20 световых минут в сторону) и использует (в основном) реалистичную физику. Один из ключевых элементов, которые я хочу смоделировать, - это скорость распространения информации по всему пространству битвы, то есть, если игрок А задействует свой основной диск на одной стороне поля битвы, то до того, как его увидит игрок Б, будет 20 минут может реагировать на это

Даже для относительно небольших боевых пространств это важный фактор, учитывая скорость. Корабль длиной 500 м, совершающий 30 к / с, собирается сместиться на полную длину в 1/60 секунды, поэтому даже при нацеливании на противника, находящегося всего в нескольких десятых доли секунды, будет слабое отставание.

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

Есть ли модели данных, которые лучше подходят для этого, которые я должен проверить?

Просто мозговой штурм здесь ...

Интересно, что сетевое отставание - ваш друг в этом случае. Как и у вас, ХОТИТЕ задержка для некоторых пакетов данных, по крайней мере, если речь идет о рисовании. Но вместо базовой задержки, которую каждый игрок обычно имеет для всех пакетов данных, на которые влияет только их скорость сети, вам нужно применить определенную задержку для каждого события для каждого игрока на основе задержки на скорости света.

Обычно сервер отправляет обновления всем клиентам одновременно, но вам нужно, чтобы сервер вычислял «небольшую задержку» для каждого события (на основе расстояния до зрителя), а затем не отправлял обновления до тех пор, пока время.

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

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

Доплеровское смещение было бы интересно добавить в микс, основываясь на дельте движения между зрителем и событием.

Вопрос в том, насколько точно ваше задержанное изображение должно быть таким, каким оно было на самом деле? Если вы ищете 100% точность, вам нужно будет сохранять действия или состояние каждого объекта на карте на каждом тике и, как вы говорите, воспроизводить их с задержкой на основе расстояния. Если вас не очень заботит точная точность, которая вам редко требуется в играх, вы можете сохранять состояние с интервалами и экстраполировать их, когда задержка догоняет вас. Вы можете оптимизировать, не сохраняя идентичные обновления.

Кроме того, вы можете векторизовать все движения и сохранить путь для каждого объекта вместе со временем начала, видимым универсальным наблюдателем. Затем вы можете просто рассчитать ожидаемую позицию объекта для каждого наблюдателя на основе универсального счетчика времени по местному времени на основе сохраненных узлов пути. Когда временная метка узла пути идет позади светового конуса всех соответствующих объектов, вы отбрасываете его.

Изменить: выше предполагает, что вы собираетесь обмануть основную относительность, имея абсолютного наблюдателя (я полагаю, игрок). Это лишило бы вас некоторых более интересных аспектов замедления времени, но их моделирование было бы проектом само по себе> _>