Conceptuellement, comment fonctionne le replay dans un jeu?

Starcraft et Starcraft: Brood War avaient une fonction de relecture. Une fois une correspondance terminée, vous pouvez choisir d'enregistrer la relecture pour la voir plus tard. Tout en rejouant, vous pouvez faire défiler la carte et cliquez sur les unités et les bâtiments, mais pas changer leurs comportements.

Je me souviens avoir regardé une fois une rediffusion d'un match qui avait été joué dans le jeu original, mais la rediffusion était vue dans Brood War. Pour ceux qui ne connaissent pas, Brood War contient toutes les unités et les bâtiments d'origine, ainsi que une variété de nouveaux. Dans le jeu original, le joueur avait vaincu l'ordinateur en créant des unités que l'ordinateur ne pouvait pas facilement contrer. Quand j'ai joué le replay dans Brood War, l'ordinateur avait accès à différentes unités, qu'il a créées et utilisées pour vaincre le joueur. Ainsi, le même fichier de relecture a donné lieu à un gagnant différent en fonction de la version de Starcraft qui jouait le fichier.

J'ai toujours trouvé le concept fascinant. Il semblerait que la fonction de relecture travaillé en enregistrant toutes les entrées du lecteur, et supposé que l'ordinateur répondrait à ces stimuli de la même manière à chaque fois. Lorsque les entrées du Joueur ont été introduites dans le replayer original de Starcraft, le jeu s'est joué exactement comme dans le match original. Lorsque la même entrée exacte a été introduite dans le replayer Brood War, l'ordinateur a réagi différemment, a créé des unités plus fortes et a gagné le match.

Quelque chose à garder à l'esprit si vous écrivez un moteur de relecture.

Il existe deux méthodes principales:

1. stocker des événements (tels que les actions joueur/IA) - comme vous le dites.
2. État de stockage (état complet du jeu, par exemple emplacements des objets, dans des moments consécutifs).

Cela dépend de ce que vous voulez faire. Parfois, le stockage des événements est préférable, car cela prend généralement beaucoup moins de mémoire. De l'autre côté, si vous voulez fournir des replays qui peuvent être lus à des vitesses différentes et à partir de différents points de départ, il est préférable de stocker les États. Lors du stockage des États, Vous pouvez également décider de les stocker après chaque événement ou par exemple seulement 12 ou 25 fois par seconde-cela pourrait réduire la taille de votre relecture et faciliter le rembobinage/avance rapide.

Notez que "État" ne signifie pas État graphique. Plus quelque chose comme les positions de l'unité, l'état des ressources et ainsi de suite. Des choses comme les graphiques, les systèmes de particules et ainsi de suite est généralement déterministe et peut être stocké comme "animation X, temps Y: Z".

Parfois, les replays sont utilisés comme schéma antichauffant. Ensuite stocker des événements est probablement le meilleur ici.

Techniquement, vous devriez écrire votre moteur pour être déterministe, ce n'est pas un hasard. En supposant qu'un personnage du jeu vise le bras d'un adversaire et tire une arme, alors la même quantité de dégâts doit être appliquée à l'adversaire dans tous les cas.

En supposant qu'une bombe explose à L'emplacement X, les particules produites par cette explosion devraient toujours avoir le même résultat visuel. Si vous avez besoin de caractère aléatoire, créez un ensemble de nombres aléatoires, sélectionnez une valeur de départ lorsque le jeu est joué, et enregistrez cette valeur de départ dans la relecture.

En général, avoir du hasard dans un jeu est une mauvaise idée. Même pour des choses comme le multijoueur, vous ne pouvez pas avoir la moitié de vos joueurs capables de voir autour d'une explosion tandis que les autres ne peuvent pas simplement parce qu'ils n'ont pas obtenu la bonne valeur aléatoire.

Faites tout déterministe, et vous devriez aller bien.

Étant donné l'état initial et une série d'actions avec des horodatages, passez simplement par la séquence car les actions enregistrées sont supposées avoir une relecture.

Pour que les événements aléatoires se reproduisent exactement de la même manière, utilise des nombres pseudo-aléatoires ensemencés et enregistre la graine dans le fichier de relecture.

Tant que vous utilisez le même algorithme pour générer les nombres aléatoires à partir de la graine, vous pouvez recréer tous les événements tels qu'ils se sont produits dans le live jeu sans avoir besoin d'instantanés complets de l'état du jeu.

Cela nécessitera que les replays soient regardés séquentiellement , mais c'est assez normal pour les replays de jeu (voir Starcraft 2). Si vous voulez autoriser un accès aléatoire à la chronologie, vous pouvez Prendre des instantanés d'état complet à des intervalles définis (disons chaque minute), pour sauter autour de la chronologie à une granularité définie.

NVidia PhysX (un moteur de simulation physique qui est souvent utilisé dans les jeux) est capable d'enregistrer l'état complet de la scène physique au fil du temps. Cela intègre toutes les entrées de conduite du moteur de jeu, ce qui signifie que vous n'avez pas besoin de suivre les graines de nombres aléatoires comme d'autres l'ont suggéré. Si vous prenez ce vidage de scène, vous pouvez le rejouer dans un outil extérieur (fourni par NVidia), ce qui est très pratique pour traquer les problèmes avec vos modèles physiques. Cependant, vous pouvez également utiliser le même flux physique pour conduire votre moteur graphique, ce qui vous permettrait alors d'avoir un contrôle normal de la caméra, puisque seule la physique conduisant les graphiques ont été enregistrés. Dans de nombreux jeux, Cela inclut les effets de particules (PhysX comprend des systèmes de particules très sophistiqués.) En ce qui concerne le son, je suppose que c'est enregistré verbatim (en tant que flux sonore), mais je ne suis pas sûr.

Votre idée originale est juste, et pour les effets vraiment complexes, ils ne sont pas mémorisés exclusivement. Par exemple, le système de relecture Warcraft 3 ne stocke pas l'état des animations, ni les effets de particules dans le cas d'effets aléatoires, etc. En outre, la plupart des choses peuvent être calculées à partir d'un point de départ de manière déterministe, donc pour la plupart des systèmes qui utilisent des variables aléatoires (une explosion de particules qui donne un décalage aléatoire, par exemple), tout ce dont vous auriez besoin est le temps de la effet, et la graine aléatoire. Vous pourriez alors recréer l'effet sans vraiment savoir à quoi il ressemblera.. sachant qu'il passe par un chemin de code déterministe.

En pensant purement conceptuellement, pour rejouer une chronologie des événements, tout ce dont vous avez besoin sont les actions de l'utilisateur. Le programme réagira exactement de la même manière, sauf dans le cas de variables aléatoires. Dans ce scénario, vous pouvez soit ignorer le caractère aléatoire (est - ce vraiment important si les effets ressemblent exactement au même, ou peuvent-ils être générés aléatoirement), ou stocker la valeur de la graine et simuler le caractère aléatoire.

Jette mes deux pence.

Dépend de ce que vous voulez, la relecture peut être effectuée via

1. Enregistrement vidéo tampon et rejouer plus tard,
2. capturer l'état de l'objet à chaque image et rejouer plus tard,

La plupart du temps, les gens veulent une rediffusion interactive, donc 2. est le chemin à parcourir. Ensuite en fonction de vos contraintes il existe un certain nombre de moyens pour optimiser ce processus

• assurez-vous que le système est une simulation déterministe *, telle que chaque entrée génère une sortie cohérente et attendue
• si la randomicité est requise, assurez-vous que les nombres aléatoires peuvent être reproduits exactement à une date ultérieure [regardez l'ensemencement avec des générateurs de nombres Pseudo-aléatoires PRNG, ou utilisez des ensembles aléatoires en conserve]
• divisez les éléments du jeu en éléments " mécaniques "et" esthétiques". les éléments mécaniques affectent le résultat [par exemple la colonne tombant et le chemin de blocage], les éléments esthétiques sont pour le spectacle et n'influencent aucun processus de prise de décision dans le système [par exemple effets de particules visuelles comme des étincelles].

C'est vraiment un sujet passionnant. Je me souviens qu'un titre de lancement pour Xbox originale Wreckless avait une bonne fonctionnalité de lecture. Malheureusement, à plus d'une occasion, le replay serait bousillé;)

Oh oui, comment peut-on oublier Blinx balayeuse de temps ! Super replay interactif qui a été incorporé dans mécanicien de jeu réel!

* = semble qu'il y a quelques commentaires concernant les pas de temps. j'utilise "simulation" ici pour capturer cette fonctionnalité. à la Base, votre moteur doit être capable de produire des images de temps discrètes. même si une trame de relecture prend plus ou moins de temps à traiter que l'original, le système doit percevoir que le même temps que delta est passé. cela signifie enregistrer le pas de temps de trame avec chaque entrée enregistrée, et fournir ce delta à votre horloge moteur.

Peut-être que vous pourriez simplement enregistrer une pile de commandes envoyées par chaque joueur. Donc, au lieu de sauver qu'une bombe explose à un certain moment, ou qu'une certaine voiture est détruite, vous enregistrez simplement les pressions sur les touches envoyées par chaque joueur. Ensuite, dans la relecture, vous simulez simplement le jeu comme cela se serait passé avec ces presses. J'ai l'impression que cela a le potentiel de prendre moins de Place, mais je n'ai jamais travaillé sur un système de relecture comme ça.

Question intéressante, cependant. Je serais intéressé par la façon dont il est fait dans les jeux professionnels.

Dan Bryant

De plus, l'enregistrement de graines aléatoires ne serait pas suffisant pour le rembobinage soutien, puisque la progression aléatoire n'est pas une procédure réversible sans support spécial dans toute la logique en s'appuyant sur le hasard. Il est plus flexible d'enregistrer les résultats des opérations aléatoires comme une partie du flux d'événements.

C'est exactement ce que je pensais au début quand j'essayais de comprendre comment ils faisaient pour que le jeu rejoue toujours le même chacun temps. Avec Doom, je pensais à la façon dont les pousses sont allées au hasard: D. stocker tout nombre aléatoire s'est utilisé, j'ai découvert que cela pourrait être une solution. C'était avant que je tombe sur un document pdf sur la technologie Crysis. Certaines textures de bruit là-bas et la disposition de l'herbe ou de l'arbre, semblaient utiliser la pseudorandomisation avec des graines réversibles fixes pour le rendre si vous ne voyez pas la disposition modifiée du bruit, des arbres et de l'herbe chaque fois que vous regardez!

En évitant en même temps, pour stocker des millions d'arbres et d'arbres d'herbe position. Apparemment, la séquence pseudo-aléatoire peut rejouer la même chose à tout moment, car la logique est fixée, pour simplement faire une fausse séquence statistiquement aléatoire de nombres.

Le problème d'avoir une rediffusion cohérente est le même (enfin, plus facile) comme avoir un jeu multijoueur cohérent.

Comme d'autres l'ont mentionné précédemment, les replays dans les jeux RTS sont stockés en enregistrant toutes les entrées (cela a un effet. Le défilement n'a aucun effet.) Multijoueur transmet toutes les entrées, aussi

Enregistrement de toutes les entrées non seulement une supposition-il y a une bibliothèque pour lire Warcraft3 replays avec révèle cela.

L'entrée inclut des horodatages pour cette réponse.

Je crois qu'à certains incréments, le jeu prendrait un instantané de l'état de tout (tout). Ensuite, lorsque la relecture se produit, l'utilisation simple de l'interpolation linéaire peut être utilisée pour remplir les "trous". C'est du moins la façon dont je pense que ce serait fait.

Vous avez raison de dire que l'enregistrement des entrées ne serait pas fiable/ne garantirait pas la même sortie. Le jeu doit certainement garder une trace de l'état de tous les objets (ou au moins les plus importants)