Je n'avais jamais vu une telle fonctionnalité auparavant, mais elle devrait offrir une opportunité de gameplay intéressante.

Alors oui, dans un environnement multijoueur / temps réel (imaginez FPS), comment pourrais-je implémenter un effet de temps au ralenti / balle?

Quelque chose comme une illusion pour le joueur qui est actuellement au ralenti. Donc tout le monde le voit "en temps réel", mais il voit tout ralentir.

Mise à jour

Une note: gardez à l'esprit qu'un jeu FPS doit être équilibré pour qu'il soit amusant. Donc oui, cette fonction de temps de balle doit être solide, donnant un petit avantage au "joueur", sans pour autant éloigner les autres joueurs.

De plus, il est possible que deux joueurs puissent activer leur balle en même temps.

En outre:

Je vais mettre en œuvre cela à l'avenir, peu importe ce qu'il faudra. Et, l'idée est de construire un tout nouveau moteur de jeu pour tout cela. Si cela donne de nouvelles options, je suis plus qu'intéressé à entendre les idées.

Pendant ce temps, ici avec mon équipe, nous y pensons aussi, lorsque notre théorie sera élaborée, je vais la partager ici.

Est-ce seulement possible? Donc, la question "est-ce encore possible" a été répondue, il est maintenant temps de trouver la meilleure solution.

Je garde la "réponse" jusqu'à ce que quelque chose d'exceptionnellement bon apparaisse, comme une théorie prototype avec quelque chose de proche du pseudo-code fonctionnel.

Ce que disent les physiciens et les philosophes:

Les liens sont pour vous, car les sujets sont fermés.

https://physics.stackexchange.com/questions/17118/time-traveling-and-time-dilation-within-a-multiplayer-videogame

https://philosophy.stackexchange.com/questions/1704/seeing-everything-in-slow-motion-but-being-real-time

Les conditions auxquelles j'ai pensé en écrivant la question sur le site de physique (copié):

1. Le joueur sous les effets du ralenti a l'avantage de faire des actions plus précises (tir, mouvement etc.), car il voit tout à un rythme beaucoup plus lent.
2. Ses actions devraient affecter les autres joueurs en temps réel.
3. Les joueurs qui regardent notre joueur affecté ne voient aucune différence, sauf qu'ils peuvent expérimenter les actions qu'il a faites (comme, le joueur se fait tirer / esquive une esquive).
4. Lorsque le joueur sort de cet effet, il continue simplement au même rythme que d'habitude. (Si ce n'est pas possible, alors je suppose qu'il devra souffrir jusqu'à ce que le temps soit synchronisé)

Références sur le temps des balles (ralenti):

Malheureusement, la plupart des implémentations sont uniquement en mode solo

http://www.gamesradar.com/a-videogame-history-of-bullet-time/

Cela a déjà été fait auparavant. :) Découvrez les spécialistes , un mod de demi-vie qui a deux bonus de temps de balle différents.

MODIFIER pour inclure les informations de zzzzbov ci-dessous

Du point de vue du gameplay, la façon dont le temps de balle fonctionnait dans "The Specialists" était que le joueur pouvait obtenir des bonus qui lui donneraient un temps de balle limité. Lorsqu'elle est utilisée, une bulle autour du joueur verrait sa physique ralentie.

Les joueurs éloignés se déplaceraient à vitesse normale, mais tout ce qui se trouve dans la bulle (balles, joueurs, explosions) ralentirait. Le joueur qui a utilisé la mise sous tension se déplacerait légèrement plus rapidement, ce qui lui permettrait de s'enfuir ou d'utiliser des cascades pour esquiver les balles.

Quiconque est pris dans la bulle "bullet-time" a toujours l'avantage de voir ce qui va se passer, mais la différence de vitesse relative entre un joueur pris et des balles reste la même, de sorte que la capacité de réaction est pratiquement inexistante.

Je ne peux penser à aucun jeu qui a un temps de balle en solo qui l'a réussi à passer en multijoueur de manière significative. Il y en a peut-être quelques-uns qui ont résolu le problème en accélérant l'utilisation du joueur, mais ce genre de chose vainc le point.

Le temps de balle existe parce que vous voulez faire en sorte que le joueur se sente comme un dur à cuire. Vous donnez au joueur un avantage apparemment injuste en simulant une perception de niveau supérieur. Le résultat final est que les joueurs peuvent viser tout en faisant des choses sympas comme sauter hors de la couverture, etc. Si vous venez d'accélérer le joueur alors qu'il a activé le temps de balle, vous lui donnez moins de temps pour réagir, ce qui est l'opposé de ce que vous voulez.

Dans un environnement multijoueur synchrone, il n'y a vraiment aucune solution pour les "ralentissements" activés par l'utilisateur qui simulent le sentiment qui vient de son utilisation dans un environnement à un seul joueur. Si le temps lui-même était ralenti, alors la perception de tout le monde augmente. Surtout dans un jeu PC où la visée de la souris est généralement instantanée, tout le monde bénéficierait de cibles se déplaçant plus lentement.

Maintenant, si vous étiez mort à ce sujet, ma suggestion serait de, au lieu d'en faire une fonctionnalité activée par le joueur, en faire une sorte "d'état" de rencontre. Pensez à un film de John Woo où c'est le bon contre le méchant et tout semble ralentir alors qu'ils se tirent dessus. Donc, quand une "rencontre" commence, activez le ralenti et vous pouvez obtenir des effets intéressants. Des gars qui sautent et des trucs qui ricochent à partir de balles manquées flottant dans les airs, et tout ça. Bien sûr, cela ne fonctionnerait vraiment que pour un jeu 1 contre 1. Vous n'obtiendrez pas l'avantage unilatéral du temps des balles comme dans une partie solo, mais cela pourrait être une expérience de jeu intéressante.

Réflexions générales

C'est un problème qui est mieux décrit en utilisant la relativité générale - prenez par exemple le fait que vous pouvez voir les effets du temps de balle en regardant simplement à travers votre télescope vers un satellite (la cause du fameux neutrino voyageant plus vite que le problème de la lumière) - équations solvables existent dans ces conditions; ce qui signifie que c'est tout à fait possible.

Votre jeu devra être en mesure de gérer des cadres de référence distincts - pour autant que je sache, l'effet net de cela serait («joueur» étant la personne avec le temps de balle actif):

• Les gens qui voient le joueur les verraient se déplacer extrêmement rapidement.
• Le joueur verrait les gens se déplacer extrêmement lentement.
• Le joueur se déplacerait dans le passé / futur en référence à tout le monde.

Heureusement pour vous, cela signifie qu'un joueur en temps de balle a un avantage sur tout le monde; ils ne peuvent pas le viser - mais ce ne serait pas convaincant car la personne moyenne s'attendrait à ne voir aucune différence perceptible lors de l'observation de la dilatation du temps.

Je vous recommande fortement de publier ceci sur la physique (indiquez qu'il s'agit d'un jeu, mais vous avez besoin de réelles connaissances théoriques) et demandez des idées sur la façon dont vous approximeriez l'effet dans une simulation simultanée.

Une solution possible que je chercherais à faire est que le monde rattrape le joueur (au fur et à mesure qu'il évolue vers l'avenir) en faisant en sorte que tout le monde connaisse une quantité progressive (bien inférieure au temps de balle réel) de temps de balle en fonction de loin derrière (dans temps) ils le sont. De cette façon, vous pourriez approximer les différences de temps sans avoir à gérer le stockage de l'état passé, etc. Vous auriez besoin d'un moyen d'expliquer cet effet, le «rebond du temps» ou quelque chose, car ce n'est pas physiquement correct.

Une autre idée consiste à abuser des équations de physique les plus élémentaires ( s = d/t), lorsqu'un joueur passe au point de balle, tout devient plus petit - si vous divisez par deux la taille de tout de son point de vue tout en conservant sa vitesse en fonction de son cadre de référence d'origine, (effectivement le doubler), l'équation sera toujours en équilibre. Les séquences d'entraînement de distorsion dans les films spatiaux utilisent cette dilatation spatiale pour représenter l'effet - les gens ont donc l'habitude de le voir.

Solution réelle

J'ai réfléchi encore plus à cela. Si vous regardez comment fonctionne le système de réseau Steamworks ( quelqu'un a-t-il un lien? ), Le serveur est constamment en avance dans le temps d'un certain montant; et chaque client connaît la trame «suivante» à laquelle il doit s'interpoler.

Disons par exemple que le serveur a 20 ms d'avance sur tous les joueurs. Lorsqu'un joueur entre dans le temps de balle, changez son intervalle de mise à jour à 40 ms (sa simulation s'exécutera à des intervalles de temps de 40 ms et le serveur mettra ses actions en file d'attente 40 ms dans le futur) - ce qui poussera essentiellement vers le futur en référence aux autres joueurs: en plus pour le faire bouger plus vite de leur référence et les faire bouger plus lentement de la sienne. Une fois qu'il quitte le temps de balle, donnez à tous les autres un avantage de 5 ms sur lui afin qu'ils puissent jouer au `` rattrapage '' (c'est votre time rebound, par coïncidence, les joueurs intelligents vont bullet time pendant ces périodes de rattrapage). Cela pourrait sembler un peu mieux si vous mappez une parabole à son pas de temps - cela ralentira, s'arrêtera et accélérera progressivement.

Avertissement: je ne suis pas physicien, mais j'ai une connaissance pratique de la relativité.

Je voulais ajouter mes 0,02 $, alors que j'implémentais un prototype de mode bullet-time qui fonctionnait dans les jeux multijoueurs pour Heroes Over Europe .

En mode solo, une pression sur un bouton au bon moment ralentirait le temps et ferait un zoom avant sur votre cible. Je ne voulais pas ralentir le temps globalement en multijoueur pour reproduire la fonctionnalité (car le jeu devait prendre en charge 16 joueurs simultanés!), J'ai donc utilisé une méthode "à bulles".

Plus précisément, lorsque le mode balle a été déclenché, une sphère a été créée autour de l'avion cible. Le taux de passage du temps a changé en fonction de la distance au centre de la sphère; le temps s'est dégradé linéairement de sa surface à une valeur minimale quelque part près du centre. Le taux a également changé en fonction de la durée de vie de la sphère et de la durée de la sphère avant de "s'évaporer".

Cela a été synchronisé entre les machines en envoyant un paquet qui a défini une heure de début future pour la bulle; cela a permis à l'effet de rester synchronisé malgré la latence. (De même, lorsque l'effet devait se terminer tôt, un paquet déclarait l'heure à laquelle il devait se terminer.)

Le taux de passage du temps a toujours été défini de manière fonctionnelle: étant donné la définition d'une sphère, l'heure actuelle et une position, il était possible de déterminer la vitesse à laquelle le temps s'écoulait.

Pour que l'effet fonctionne, plusieurs systèmes de jeu ont dû être adaptés à cette définition "fonctionnelle" du temps. Les avions, les balles, les missiles et d'autres effets ont chacun utilisé un individu dtqui a été élaboré en appelant la fonction appropriée. La plupart du travail pour faire fonctionner le prototype a été passé ici.

Le résultat a fonctionné assez bien: un joueur ciblé par le temps des balles ralentirait sensiblement et aurait une (petite) chance de se frayer un chemin hors du réticule de son agresseur et loin d'une grêle de balles au ralenti. Les joueurs à proximité pouvaient voir des avions et des balles s'esquiver au ralenti, mais n'étaient pas affectés autrement.

Notez que le joueur déclenchant a également été ralenti, mais n'était pas strictement désavantagé par cela: ils avaient une vue agrandie de leur cible et pouvaient affecter les tirs à un coup sur leur proie. Un autre joueur pourrait tenter de vous tuer (ou tuer voler!) Dans cet état, mais leur avion (et leurs balles) seraient affectés en entrant dans la bulle, vous donnant le temps de vous échapper.

Malheureusement, même si cela a fonctionné, nous n'avons jamais eu le temps de terminer et de peaufiner la fonctionnalité pour le multijoueur, elle a donc été abandonnée. (Le mode solo a conservé la fonctionnalité, comme "Ace Kill".)

Pas vraiment le temps des balles, mais ça pourrait être amusant:

Qu'en est-il de quelque chose de similaire à la façon dont Braid fait la chose qui ralentit le temps? C'est-à-dire que plus on se rapproche de la personne qui vit le temps des balles, plus les choses avancent lentement ... et si vous êtes en dehors de la sphère d'influence, le temps s'écoule normalement.

... par exemple, si le joueur A passe le temps des balles, il place une sphère graduée de "temps lent" autour de lui afin qu'il puisse viser correctement, mais pas nécessairement se déplacer plus rapidement - alors le joueur B tirant des balles sur lui devrait surestimer où la balle va frapper, car elle ralentira à mesure qu'elle se rapproche de lui.

Bien que plus j'y pense, moins je pense que cela fonctionnerait, car cela pourrait simplement faire du joueur A une cible facile (car sa tête ralentirait?) - mais il serait intéressant de le voir en 3D de toute façon.

Je sais que c'est une vieille question mais j'ai eu du mal à ne pas mentionner le problème avec la plupart des réponses traitant de la relativité

Mis en œuvre avec les effets décrits dans la question, le temps de balle en multijoueur n'est pas possible.

La raison en est le fonctionnement de la relativité; certains d'entre vous l'ont mentionné et comprennent évidemment la relativité, mais le problème est que vos modèles sont mal configurés.

Beaucoup de gens ont utilisé "la référence du joueur A contre le joueur B" dans vos réponses mais malheureusement aucune de ces choses n'existe vraiment. Oui, vous avez des joueurs, peut-être même beaucoup d'entre eux, et oui, ils peuvent contrôler et interagir avec leur monde et avoir leur propre perspective du jeu, mais la perspective n'est pas un point de référence dans le temps: c'est juste un espace XYZ projeté dans le XY avion.

Il n'y a qu'un seul point de référence temporel et c'est le serveur (ou l'hôte). Il n'y a qu'une seule vision de l'état physique du monde et donc un seul point de référence. Ce que les joueurs voient sur leur écran sont des vues graphiques différentes de la même simulation physique.

Faire en sorte qu'un joueur visualise une simulation exécutée à une vitesse et un autre visualise la même simulation à une autre vitesse sans avoir de désynchronisation n'est tout simplement pas possible. Quelque part, quelque chose doit donner.

Tout effort pour avoir plusieurs simulations ou faire fonctionner le serveur avant les clients n'a tout simplement aucun sens. L'effet tel que décrit dans le post ne peut tout simplement pas être fait sans forcer le point de référence unique ou laisser les pensées se désynchroniser et dire aux joueurs que leurs actions ne se sont pas vraiment produites après coup.

Je pense que la meilleure solution est similaire à celle déjà donnée qui est d'avoir un effet de type tresse où votre vitesse est modifiée dans une bulle autour du joueur. Cela étant dit, le joueur ne ralentira pas et la bulle sera toujours positionnée et déplacée avec lui au centre. Cela fait en sorte que le joueur se déplace à pleine vitesse tandis que ses proches se sentent ralentis. Il obtient son avantage de mise sous tension et les gens loin de cette zone ne ressentent aucun effet. Ceux qui sont proches sont ralentis, mais il est évident que quelqu'un utilise la mise sous tension (je suggérerais de mettre en évidence le joueur qui l'utilise pour que les joueurs adverses comprennent pleinement ce qui se passe et pourquoi).

Ce serait très gênant. Sans même regarder le problème de la dilatation du temps, imaginez que vous êtes le joueur qui vient de passer 4 secondes en balle, tandis que tout le monde dans le jeu a passé 2 secondes en temps réel. Étant donné que le même temps s'est écoulé pour tout le monde en réalité, il vous faudrait en quelque sorte "regagner" ces deux secondes dans le jeu. Donc, à un moment donné, vous devrez "sauter" 2 secondes de temps de jeu, ou passer un peu de temps à courir plus vite que la normale, ou autre chose qui ferait probablement du temps de balle une sorte de perte.

De plus, il y a tout le fait d'avoir à envoyer ce que vous faites à 2 secondes de votre temps dans le temps 1 seconde à tout le monde.

Lancez des mini événements temporels rapides sur le joueur pour esquiver les balles ou suivre automatiquement les cibles ennemies, tout en rendant les mouvements de votre joueur flous ou "échelonnés" aux autres joueurs (afin qu'ils ne se grattent pas la tête pour savoir pourquoi leurs balles ne sont pas ne frappe pas). Cela semble être la traduction la plus simple et la plus pratique que vous puissiez faire pour le multijoueur.

Toute autre solution implique la modification d'un élément physique du jeu pour un ou plusieurs joueurs qui ne s'applique pas en parallèle pour les autres, j'imagine.

Ralentissez tout le monde, sauf que le joueur expérimente le temps des balles. Vous pouvez le faire en diminuant simplement la sensibilité de leur souris.

Disons que nous avons le joueur A en temps réel et le joueur B en temps réel. Et ils font ce qui suit du point de vue du joueur B:

• Temps 0s - Joueur A temps de balle activé
• Temps 2s - Le joueur A tire sur le joueur B
• Temps 3s - Le joueur B tire sur le joueur A

Du point de vue du joueur A, cela prendra deux fois plus de temps - puisque le monde se déplace plus lentement pour lui:

• Temps 0s - Joueur A temps de balle activé
• Temps 4s - Le joueur A tire sur le joueur B
• Temps 6s - Le joueur B tire sur le joueur A

Enfin, le serveur contient les événements suivants:

• Temps 0s - Le joueur A active le temps de balle
• Temps 3s - Le joueur B tire sur le joueur A (B initie cette action pour qu'elle suive sa chronologie)
• Temps 4s - Le joueur A tire sur le joueur B (A lance cette action)

Nous avons donc deux problèmes initiaux. La première est que A a maintenant 3 secondes de temps de jeu derrière tout le monde. Cela pourrait être un mécanisme de jeu intéressant si vous aviez un concept qui signifiait qu'il devait rembourser cette dette. Imaginez un jeu de tir basé sur une couverture où vous pouvez activer le temps de balle pour traverser un terrain ouvert, mais une fois que vous êtes en sécurité sous couvert, vous devez rester immobile jusqu'à ce que le reste du monde vous rattrape (les trois secondes de temps que vous avez manquées sont rejouées) )

Le deuxième problème est beaucoup plus important. Le serveur doit réorganiser les événements par ordre chronologique pour chaque joueur et déterminer le résultat. Tout d'abord, B tire sur A - cela se produit trois secondes après le début du jeu et A le voit à 6 secondes - aucun problème jusqu'à présent. À 4 secondes, le joueur A tire sur B. Dans la chronologie de B, cela s'est produit il y a deux secondes. Alors, que faisons-nous avec les deux secondes de jeu qui se sont déjà écoulées pour lui, y compris son tir sur A?

Nous pourrions l'annuler - dire essentiellement "Je sais que le joueur B pense qu'il a tiré sur ce type, mais il s'avère qu'il était déjà mort alors supposons que cela ne s'est jamais produit" Ce serait une expérience merdique, très similaire au lag, mais résoudrait le problème .

Nous pourrions faire évangéliser les deux chronologies - utiliser le point de vue des serveurs comme toute la vérité et nous soucier de la chronologie de chaque personne indépendamment. À 3 secondes, B tire sur A et le tue. A 4 secondes, A tire sur B et le tue. Les deux joueurs meurent de tirs qu'ils n'ont pas vus. Cela ne semble pas bon, mais il y a peut-être un bon moyen de le faire après avoir donné à tous les joueurs un bref cours dans le monde fou de la relativité.

Nous pourrions avoir un système pseudo-temps réel - un jeu au tour par tour où vous planifiez d'abord vos mouvements, puis déclenchez un calcul simultané des événements. Une bonne solution qui résout tous les problèmes sauf qu'il ne s'agit pas du type de jeu que vous souhaitez écrire.

Pour faire court, je ne pense pas qu'il existe un bon moyen de mettre en œuvre le temps de balle en le traitant dans le sens classique de l'effet sur la personne qui l'utilise - ils se déplacent plus rapidement, ils voient le monde comme plus lent, tout le monde continue comme d'habitude. Si nous l'inversons et que tout le monde est plongé dans le point de vue du minuteur et se considère comme se déplaçant plus lentement et que ses commandes deviennent lentes, alors tout se passe en synchronisation et il n'y a aucun problème. Mais est-ce vraiment l'heure de balle? Bien que cela puisse ressembler à un observateur extérieur (et dans les rediffusions de match), aucun des participants n'obtiendrait l'effet attendu.

Non ce n'est pas possible. Imaginez qu'un joueur retourne au ralenti, que verraient les autres joueurs? Vous voudriez qu'ils voient le joueur de temps de balle se déplacer normalement mais avoir des réflexes de foudre, non? Mais malheureusement, tous ceux qui jouent au jeu joueront au jeu en même temps réel. Par conséquent, la seule façon de le faire serait de ralentir tout le jeu, en se débarrassant de tout avantage qu'il apporte car tout le monde serait en temps de balle. De plus, il serait assez ennuyeux de voir le jeu ralentir tout le temps lorsque quelqu'un appuie sur ce bouton.

Il y a des contournements qui auraient pour résultat que les joueurs ont un avantage similaire (celui de pouvoir se déplacer plus rapidement, etc.) en ralentissant par exemple tout le monde et en vous permettant de vous déplacer normalement (puis dans une relecture, vous pouvez les accélérer à la normale et vous réagir rapidement) mais je ne pense pas que ce soit vraiment ce que vous voulez.

FEAR avait un temps de balle en multijoueur, mais cela s'appliquait à toute l'équipe et cela ralentissait tout le monde de l'autre équipe.

Le temps de balle en multijoueur en temps réel sans ralentir les autres désynchroniserait les clients, le joueur au ralenti réagirait aux événements que les autres joueurs ont fait il y a longtemps alors qu'ils réagiraient aux événements actuels.

Vous devriez peut-être organiser l'équipement nécessaire pour tirer le joueur sur le PC qui a déclenché le temps de balle dans l'espace à des vitesses proches de la vitesse de la lumière.

Cela résoudrait tous vos problèmes, mais pourrait générer une ping / latence plus élevée.

Eh bien, ce ne serait pas un problème s'ils se déplacent tous plus lentement que d'habitude mais pas trop lentement et que celui qui l'active se déplace plus rapidement comme en submergeant le jeu sous l'eau ou en l'emmenant dans l'espace avec celui qui active le mouvement aussi pacifiquement que jamais.