Modélisation de la vitesse de propagation de l'information lumineuse dans un simulateur de combat spatial

Je travaille sur une simulation de combat spatial qui se déroule sur des zones relativement vastes (un cube d'espace ~ 20 minutes-lumière de côté) et utilise (principalement) une physique réaliste. L'un des éléments clés que je veux modéliser est la vitesse de propagation des informations à travers l'espace de bataille - c'est-à-dire que si le joueur A engage son entraînement principal d'un côté de l'espace de bataille, il y a un délai de 20 minutes avant que le joueur B ne le voit et peut y réagir

Même pour des espaces de combat relativement petits, c'est un facteur important étant donné les vitesses impliquées. Un navire de 500 m de long faisant 30 kps va se déplacer de toute sa longueur en 1 / 60e de seconde, donc même cibler un adversaire à seulement quelques dixièmes de seconde lumineuse sera affecté par un léger décalage.

Je n'ai jamais vu cela se faire auparavant, et je me demande s'il existe des meilleures pratiques pour modéliser cela. En ce moment, j'horodate chaque événement et le marque avec un emplacement, le place dans une file d'attente, puis chaque coche vérifie si des objets dans le monde du jeu sont nouvellement au bord du cône de lumière et ajoute l'événement à leur file d'attente des capteurs. Je vais (mais pas encore) l'optimiser en supprimant tous les événements qui ont déjà été détectés par tous les objets qui peuvent éventuellement le détecter, mais je pense que cela va devenir fastidieux et fastidieux et manger beaucoup de cycles s'il y a des centaines d'objets sensibles en jeu (ce qui est assez routinier).

Existe-t-il des modèles de données qui seraient mieux adaptés à cela que je devrais vérifier?

Juste un brainstorming ici ...

Chose intéressante, le décalage réseau est votre ami dans ce cas. Comme pour vous, vous VOULEZ un délai pour certains paquets de données, du moins s'il s'agit de dessiner. Mais au lieu d'un décalage de base que chaque joueur aurait normalement pour tous les paquets de données impactés uniquement par leur vitesse réseau, vous devez appliquer un retard spécifique pour chaque événement à chaque joueur en fonction du délai de vitesse de la lumière.

En règle générale, le serveur enverrait des mises à jour à tous les clients en même temps, mais ce dont vous avez besoin est que le serveur calcule le "léger décalage" pour chaque événement (en fonction de la distance de la visionneuse), puis n'envoie pas de mise à jour jusqu'à ce que temps.

Donc, pour chaque événement, calculez le délai entre l'événement et chaque joueur, puis mettez cet événement en file d'attente pour qu'il ne soit pas envoyé à ce joueur jusqu'à ce que le délai soit écoulé.

Cela ne résout pas l'effet du changement de position ou de vitesse du joueur après l'événement, mais vous pouvez potentiellement ajuster les événements qui ont été mis en file d'attente en fonction des changements du joueur. Un joueur commence à se rapprocher, à rapprocher l'événement dans le temps. Le joueur s'éloigne, s'éloigne dans le temps.

Le décalage Doppler serait une chose intéressante à jeter dans le mix, basé sur le delta de mouvement entre le spectateur et l'événement.

La question est: dans quelle mesure avez-vous besoin de votre image retardée pour savoir comment elle s'est réellement déroulée? Si vous recherchez une précision de 100%, vous devrez enregistrer les actions ou l'état de chaque objet sur la carte à chaque tick et, comme vous le dites, les rejouer avec un retard basé sur la distance. Si vous ne vous souciez pas tant de la précision, dont vous avez rarement besoin dans les jeux, vous pouvez enregistrer l'état à intervalles et extrapoler entre eux lorsque le retard se rattrape. Vous pouvez optimiser en ne sauvegardant pas les mises à jour identiques.

Alternativement, vous pouvez vectoriser tous les mouvements et enregistrer un chemin pour chaque objet avec une heure de début vue par un observateur universel. Ensuite, vous pouvez simplement calculer la position attendue d'un objet pour chaque observateur en fonction du compteur de temps universel de l'heure locale en fonction des nœuds de chemin qu'il a enregistrés. Lorsque l'horodatage d'un nœud de chemin passe derrière le cône de lumière de tous les objets pertinents, vous le jetez.

Edit: Ce qui précède suppose que vous allez tricher sur la relativité de base en ayant un observateur absolu (je suppose que le joueur). Cela vous priverait de certains des aspects les plus intéressants de la dilatation du temps, mais les modéliser serait un projet en soi> _>