Velocità di modellazione della propagazione delle informazioni sulla luce nella simulazione di combattimento spaziale

Sto lavorando a una simulazione di combattimento spaziale che si svolge su aree relativamente vaste (un cubo di spazio ~ 20 minuti luce di lato) e usa (principalmente) fisica realistica. Uno degli elementi chiave che voglio modellare è la velocità di propagazione delle informazioni attraverso lo spazio di battaglia - cioè, se il Giocatore A si impegna nella sua unità principale su un lato dello spazio di battaglia, c'è un ritardo di 20 minuti prima che il Giocatore B lo veda e può reagire ad esso

Anche per spazi di battaglia relativamente piccoli questo è un fattore importante date le velocità coinvolte. Una nave lunga 500 m che fa 30kps si sposterà per tutta la sua lunghezza in 1/60 di secondo, quindi anche colpire un avversario a pochi decimi di secondo di distanza subirà un leggero ritardo.

Non l'ho mai visto prima e mi chiedo se ci sono alcune migliori pratiche per modellarlo. In questo momento sto timestamp di ogni evento e contrassegnandolo con una posizione, inserendolo in una coda, quindi ogni segno di spunta verifica se uno qualsiasi degli oggetti nel mondo di gioco è di nuovo sul bordo del cono di luce e aggiungo l'evento alla loro coda del sensore. Lo (ma non l'ho ancora) ottimizzato rimuovendo tutti gli eventi che sono già stati rilevati da tutti gli oggetti che possono eventualmente rilevarlo, ma comunque, penso che questo diventerà ingombrante e dannatamente veloce, e mangerò molto di cicli se ci sono centinaia di oggetti sensibili in gioco (il che è piuttosto normale).

Esistono modelli di dati che potrebbero essere più adatti a ciò che dovrei verificare?

Sto solo facendo un brainstorming qui ...

È interessante notare che il ritardo di rete è tuo amico in questo caso. Come in VOGLIA che si verifichi un ritardo per alcuni pacchetti di dati, almeno se si tratta di disegnare. Ma invece di un ritardo di base che ogni giocatore avrebbe normalmente per tutti i pacchetti di dati influenzati solo dalla loro velocità di rete, è necessario applicare un ritardo specifico per ciascun evento a ciascun giocatore in base al ritardo della velocità della luce.

In genere il server invierebbe aggiornamenti a tutti i client contemporaneamente, ma ciò di cui hai bisogno è che il server calcoli il "ritardo di luce" per ciascun evento (in base alla distanza del visualizzatore) e quindi non invii un aggiornamento fino a quello tempo.

Quindi, per ogni evento, calcola il ritardo tra l'evento e ciascun giocatore, quindi fai la coda di quell'evento per non essere inviato per il sorteggio a quel giocatore fino allo scadere del tempo di ritardo.

Questo non affronta l'effetto del cambio di posizione o velocità del giocatore dopo che si è verificato l'evento, ma potresti potenzialmente regolare gli eventi che erano stati messi in coda in base alle modifiche del giocatore. Un giocatore inizia ad avvicinarsi, avvicina l'evento nel tempo. Il giocatore si allontana, si allontana nel tempo.

Lo spostamento Doppler sarebbe una cosa interessante da aggiungere al mix, in base al delta di movimento tra spettatore ed evento.

La domanda è: quanto è necessaria la tua immagine ritardata rispetto a come è stata effettivamente riprodotta? Se stai cercando una precisione del 100% dovrai salvare le azioni o lo stato di ogni oggetto sulla mappa ad ogni segno di spunta e, come dici tu, riprodurli in un ritardo in base alla distanza. Se non ti interessa molto della precisione millimetrica, che raramente ti serve nei giochi, puoi salvare lo stato a intervalli ed estrapolare tra loro quando il ritardo raggiunge. È possibile ottimizzare non salvando aggiornamenti identici.

In alternativa, puoi vettorializzare tutti i movimenti e salvare un percorso per ciascun oggetto insieme a un orario di inizio visto da un osservatore universale. Quindi puoi semplicemente calcolare la posizione prevista di un oggetto per ciascun osservatore in base al contatore del tempo universale e all'ora locale in base ai nodi del percorso che ha salvato. Quando il timestamp di un nodo percorso passa dietro il raggio di luce di tutti gli oggetti rilevanti, lo scarti.

Modifica: quanto sopra presuppone che stai per imbrogliare la relatività di base avendo un osservatore assoluto (suppongo che il giocatore). Questo ti deruberebbe di alcuni degli aspetti più interessanti della dilatazione del tempo, ma modellarli sarebbe un progetto in sé> _>