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

29

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

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

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

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

Джон Биснекер
источник
7
Не знаю, ответ, но я скажу, что за аккуратный вопрос!
Тим Холт
Вау! Игры в основном о визуализации. Мне нужно знать, как вы планируете визуализировать противников, когда пиксели слишком велики? Простые индикаторы HUD? Текстовый режим приключенческая игра? Пожалуйста, просветите меня!
Йонас Быстрем
1
Вы говорите, что ваша модель физически точна. Это ньютоновский или релятивистский? Это может иметь большое значение в таких масштабах.
MSalters
1
Не то чтобы это отвечало на вопрос, но, возможно, взгляд на «Медленную скорость света» даст вам некоторые идеи.
Михаил Панков
@ JonasByström - вид на большие расстояния довольно сложный, и я пытаюсь его очистить. По сути, я надеюсь, что это будет вероятностное представление о том, где будет находиться цель в будущем, основываясь на небольшом отставании и оценках вашего корабля компьютера относительно максимального значения дельта-v цели. Прямо сейчас, это гораздо менее круто, чем это, хотя :)
Джон Биснекер

Ответы:

9

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

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

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

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

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

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

Тим Холт
источник
Я уже как бы моделирую изменение положения и скорости. Несмотря на масштаб, объекты в игре обычно не достигают заметной доли скорости света, поэтому события обгоняют их относительно легко, но на каждом тике проверяется, находится ли получатель в той сфере, которая могла видеть событие, поэтому, если вы двигаетесь в направлении хорошего клипа или от него, это может повлиять на это несколькими тиками. Впрочем, допплер действительно был бы интересен! Что-то, чтобы посмотреть. :-)
Джон Биснекер
2
Что следует знать, если вы используете этот метод, никто, сканирующий пакеты, не сможет получить информацию раньше, чем должен. Eve Online делает нечто похожее с невидимыми кораблями. Когда какой-либо корабль движется в области, все клиенты уведомляются, но когда скрытый корабль движется, клиентам ничего не говорят. В противном случае, хотя клиент не показывает корабль, пакеты будут.
Рэй Бриттон
5

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

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

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

Jono
источник