Моделювання швидкості розповсюдження світла в космосі

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

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

Я не бачив цього раніше, і мені цікаво, чи є якісь найкращі практики для моделювання цього. Зараз я розмічую мітки кожної події та відмічаю її місцеположенням, розміщую її в черзі, а потім кожну галочку перевіряю, чи не знайдеться який-небудь з об’єктів у світі ігор на краю світлого конуса та додаю подію до їхньої черги датчиків. Я буду (але ще не) оптимізував це, видаляючи будь-які події, які вже були відчуті всіма об'єктами, які, можливо, це відчують, але все-таки, я думаю, що це стане громіздким досить проклятим швидко, і з'їсти багато циклів, якщо в грі сотні об'єктів зондування (що досить звичайно).

Чи є моделі даних, які краще для цього підходять, що я повинен перевірити?

Просто мозковий штурм тут ...

Цікаво, що мережеве відставання є вашим другом у цій справі. Так як у вас ХОЧЕТЕ виникнути затримки для деяких пакетів даних, принаймні, якщо мова йде про малювання. Але замість базового відставання кожен гравець, як правило, матиме для всіх пакетів даних, які впливають лише на швидкість їхньої мережі, вам потрібно застосувати певні відставання для кожної події до кожного гравця, грунтуючись на затримці світлової швидкості.

Зазвичай сервер надсилає оновлення для всіх клієнтів одночасно, але те, що вам потрібно, це для сервера обчислити "легкий лаг" для кожної події (виходячи з відстані глядача), а потім не надсилати оновлення до цього час.

Отже, для кожної події обчислюйте затримку в часі між подією та кожним гравцем, а потім чергуйте цю чергу, щоб її не надсилали для малювання до цього гравця, поки не минув час затримки.

Це не стосується впливу зміни позиції або швидкості гравця після події, але ви можете потенційно відрегулювати події, які були встановлені в чергу, залежно від змін гравця. Гравець починає рухатися ближче, переміщувати подію ближче у часі. Гравець відсувається, віддаляється вчасно.

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

Питання полягає в тому, наскільки точно вам потрібне ваше запізніле зображення, як воно насправді розігрується? Якщо ви шукаєте 100% точність, вам потрібно буде зберегти дії або стан кожного об’єкта на карті при кожному галочку і, як ви кажете, відтворювати їх із затримкою, залежно від відстані. Якщо вас не так хвилює точна точність, яка вам рідко потрібна в іграх, ви можете зберігати стан з інтервалом і екстраполювати між ними, коли затримка наступить. Ви можете оптимізувати, не зберігаючи однакові оновлення.

Крім того, ви можете векторизувати весь рух і зберегти шлях для кожного об'єкта разом із часом початку, який бачив універсальний спостерігач. Тоді ви можете просто обчислити очікувану позицію об'єкта для кожного спостерігача на основі універсального лічильника часу за місцевим часом на основі збережених вузлів шляху. Коли часова мітка вузла шляху йде за світлою шишкою всіх відповідних об'єктів, ви її відкидаєте.

Редагувати: вищевикладене передбачає, що ви збираєтесь обдурити основну відносність, маючи абсолютного спостерігача (я припускаю гравця). Це позбавить вас деяких більш цікавих аспектів розширення часу, але моделювання цих проектів було б самим проектом> _>