Modelowanie prędkości rozprzestrzeniania się informacji świetlnej w kosmicznym symulatorze bojowym

Pracuję nad symulacją walki kosmicznej, która rozgrywa się na stosunkowo dużych obszarach (sześcian przestrzeni ~ 20 minut świetlnych w bok) i wykorzystuje (głównie) realistyczną fizykę. Jednym z kluczowych elementów, który chcę wymodelować, jest prędkość rozprzestrzeniania się informacji w przestrzeni bitwy - to znaczy, jeśli gracz A włączy swój główny napęd po jednej stronie przestrzeni bitwy, gracz B zobaczy 20 minut opóźnienia i może na to zareagować

Nawet w przypadku stosunkowo niewielkich przestrzeni bojowych jest to ważny czynnik, biorąc pod uwagę zaangażowane prędkości. Statek o długości 500 m, pracujący z prędkością 30 kps, przemieści się na całej swojej długości w 1/60 sekundy, więc nawet celowanie w przeciwnika w odległości zaledwie kilku dziesiątych sekundy świetlnej będzie miało wpływ na opóźnienie.

Nie widziałem tego wcześniej i zastanawiam się, czy istnieją najlepsze praktyki modelowania tego. W tej chwili oznaczam czasowo każde zdarzenie i zaznaczam je lokalizacją, umieszczam w kolejce, a następnie sprawdzam, czy którykolwiek z obiektów w świecie gry znajduje się na krawędzi lekkiego stożka i dodaje wydarzenie do kolejki czujników. Zoptymalizuję go (ale jeszcze tego nie zrobiłem), usuwając wszelkie zdarzenia, które zostały już wykryte przez wszystkie obiekty, które mogą to wyczuć, ale myślę, że to szybko stanie się niewygodne i zje dużo cykli, jeśli w grze są setki obiektów wykrywających (co jest dość rutynowe).

Czy istnieją modele danych, które lepiej by do tego pasowały, które powinienem sprawdzić?

Burza mózgów tutaj ...

Co ciekawe, opóźnienie sieciowe jest twoim przyjacielem w tym przypadku. Tak jak Ty CHCESZ wystąpić opóźnienie dla niektórych pakietów danych, przynajmniej jeśli chodzi o rysowanie. Ale zamiast podstawowego opóźnienia każdy gracz normalnie miałby dla wszystkich pakietów danych, których dotyczy tylko jego prędkość sieci, musisz zastosować określone opóźnienie dla każdego zdarzenia dla każdego gracza w oparciu o opóźnienie prędkości światła.

Zazwyczaj serwer wysyła aktualizacje do wszystkich klientów w tym samym czasie, ale potrzebujesz, aby serwer obliczył „lekkie opóźnienie” dla każdego zdarzenia (na podstawie odległości widza), a następnie nie wyśle ​​aktualizacji, dopóki czas.

Tak więc dla każdego wydarzenia, oblicz opóźnienie między wydarzeniem a każdym graczem, a następnie ustaw w kolejce to wydarzenie, aby nie było wysyłane do losowania do tego gracza, dopóki nie upłynie czas opóźnienia.

Nie dotyczy to wpływu zmiany pozycji lub prędkości gracza po wystąpieniu zdarzenia, ale można potencjalnie dostosować zdarzenia, które zostały ustawione w kolejce na podstawie zmian gracza. Gracz zaczyna się zbliżać, zbliżać wydarzenie w czasie. Gracz się odsuwa, odsuwa się w czasie.

Przesunięcie dopplerowskie byłoby ciekawą rzeczą do włączenia w miks, w oparciu o deltę ruchu między widzem a wydarzeniem.

Pytanie brzmi: jak dokładnie potrzebujesz opóźnionego obrazu, aby faktycznie został odtworzony? Jeśli szukasz 100% dokładności, będziesz musiał zapisać działania lub stan każdego obiektu na mapie przy każdym tiku i, jak mówisz, odtwarzać je z opóźnieniem w zależności od odległości. Jeśli nie przejmujesz się tak bardzo dokładną dokładnością, której rzadko potrzebujesz w grach, możesz zapisywać stan w odstępach czasu i ekstrapolować między nimi, gdy nadejdzie opóźnienie. Możesz zoptymalizować, nie zapisując identycznych aktualizacji.

Alternatywnie możesz wektoryzować cały ruch i zapisać ścieżkę dla każdego obiektu wraz z czasem rozpoczęcia widzianym przez uniwersalnego obserwatora. Następnie możesz po prostu obliczyć oczekiwaną pozycję obiektu dla każdego obserwatora na podstawie licznika czasu uniwersalnego czasu lokalnego na podstawie zapisanych węzłów ścieżki. Kiedy znacznik czasu węzła ścieżki znajduje się za stożkiem świetlnym wszystkich odpowiednich obiektów, odrzucasz go.

Edycja: Powyższe zakłada, że ​​będziesz oszukiwał podstawową teorię względności, mając absolutnego obserwatora (zakładam, że gracz). Okradłoby cię to z niektórych interesujących aspektów dylatacji czasu, ale ich modelowanie byłoby projektem samym w sobie> _>