Replay - une solution optimisée?

Coucou,

voilà pour mon projet je souhaiterais développer un systeme de replay, pour que les joueurs puissent s'échanger leurs "run" sans avoir besoin de faire une capture de l'écran.

Ca va surement paraître abusé que je vienne poster sur cette section alors que j'ai pas encore commencer à coder cette partie, je tente quand même ma chance.

En fait, voilà l'idée que je me fais du truc :

Le joueur lance sa partie, les salles sont générées aléatoirement, à la création de la room je stock dans un fichier texte toutes les informations nécessaires.

Quand le joueur souhaite revoir son replay, le jeu "lit" le fichier et execute le code à l’intérieur. Jusque là je pense que (même si il y a très certainement mieux) ça peut le faire.

Par contre, là où j'arrive pas à trouver de solution c'est dans la lecture de ce qu'il se passe pendant la partie. Enregistrer la pression des touches par le joueur à chaque step dans un fichier texte? De même pour la position des ennemis?

Ca me parrait lourd, super lent et pas très "propre". Si quelqu'un a une idée, ou a déjà réaliser ce genre de chose, je suis preneur.

Même juste une "méthode" (testée ou non) qui serait correcte.

PS : J'ai fais des recherches mais je ne trouve que des exemples sur des manières d'enregistrer réellement la partie ( comme une capture vidéo).

Bon je continue quand même à chercher.

Bah le plus simple serait d'enregistrer les positions de tous les objets dans un ds_list ou une ds_grid ; puis ensuite de 'lire' la structure. Problème, ca risque de bouffer beaucoup de mémoire, donc deux solutions qui me viennent à l'esprit :
- soit tu as peu d'objet mouvants, donc pour eux tu enregistre leurs positions, et pour les objets statiques (genre murs), tu enregistre leur position qu'un seule fois (le plus simple pour implémenter ca consisterai à faire 2 super-objets 'statique' et 'mouvant' dont chaque objet hériterai)
- autrement tu n'enregistre les positions qu'une fois tous les x steps, et tu calcule les positions intermédiaires lors du replay :
si à l'instant 0, l'objet est à la position (100;50) et à l'instant 30 à la position (200;0) à l'instant 15, sa position est (150;25). Par contre je sais pas si ca a rendre bien, iaura pas les mouvements exacts (genre la courbe des sauts sera plus linéaire) ; mais c'est un bon moyen de libérer de la mémoire (ne serait ce qu'en enregistrant les positions un step sur deux, t'économise la moitié de la mémoire et c'est presque imperceptible pour le joueur)

Comme dit, ce ne sont que de simples idées, rien ne dit que ce soit le top. Par contre, si au contraire ca marche plutôt bien, rien ne t'empêche de combiner les deux techniques
Voilà, en espérant t'avoir aidé

Si tes salles sont générées procéduralement, le plus simple est de stocker la seed du niveau. Impossible de fait plus compact :D

En général, mieux vaut éviter de ne stocker que les inputs. Dans le cas d'une légère erreur, la suite du replay donnerait n'importe quoi. Stocker toutes les informations à chaque step est en effet overkill, je pense.
Essaye de voir ton jeu (dont j'ignore le gameplay, mais c'est de là que découlera la manière de sauvegarder) comme un jeu en ligne. Il te suffit de sauvegarder ce que le serveur enverrait aux clients.
Par exemple, pour un shooter, mettre à jour les positions et vitesses de 2 à 5 fois par seconde, et laisser le "client" interpoler les mouvements lui-même. Tu peux même implémenter un système exact puisqu'ici tu as accès à la position à t+1. Tu peux omettre ce paquet quand la position du joueur ne change pas. Même système pour l'orientation éventuelle des joueurs. Ce genre de données n'a pas besoin d'être exact lors d'un replay (lors d'un partie en ligne c'est plus compliqué).
Les actions de jeu (tirs, grenades, etc) et les évènements ponctuels (marquage de point, frag, respawn...) seront sauvegardées à la frame près, avec le nécessaire pour les simuler à partir de ce paquet initial.

Une fois ton protocole établi, il ne te reste plus qu'à écrire dans un fichier à mesure que tu joues, et à lire ce fichier dans l'ordre. Je vois bien une structure comme ça :

Code:

frame 0
creer_joueur 0 x y
creer_joueur 1 x y
creer_joueur 2 x y
creer_joueur 3 x y
frame 6
pos_joueur 0 x y
pos_joueur 2 x y
.
.
.
frame 35
tir 0 x y dir fusil
frag 2 0 fusil
frame 36
tir 3 x y dir pistol
sang x1 y1
pos_joueur 0 x y
pos_joueur 1 x y
pos_joueur 3 x y
.
.
.

Il vaudra mieux bien sûr (je crois que GM sait le faire) utiliser des fichiers binaires.
La première colonne est codée par un code opératoire sur un octet (ou plus), à partir de là (via un gros switch) tu récupères les paramètres dont tu connais le nombre et le type et tu réagis en conséquence, à la manière d'un socket.

Tu peut enregistrer les input. Cela devrait marcher.

Mieux encore pour compresser le tout:
Au lieu d'enregistrer 'état de chaque step.
Tu peut enregistrer seulement le nombre de step avant un changement

tu genre:
10,2,1024,40

correspond à l'appuie entre 10 et 12 et entre 1036 et 1076
au lieu d'enregistrer plus de 1500 boolean, tu as 4 entiers.

(presque du codage run-length)

Je pense que pendant une partie, on n'appuie pas plus de 2 fois par secondes en moyenne.
soit pour une partie de 5 minutes : 600 entiers. Cela reste très petit.

Merci pour vos réponses.

Ouai en effet, j'avais absolument pas pensé à ça mais je vais surement "penser" comme si il s'agissait d'un jeu en ligne avec envois de donnés vers un serveur. (sauf que là se serait simplement vers un fichier).

C'est vrai que je vais devoir faire le fichier en binaire, et le protéger (faudrait pas qu'on puisse bidouiller dessus à la main).

Merci arthuro, je pense que je vais procéder comme ça. Chaque "éléments" qui devra être enregistré enverra la frame de début de mouvement et la frame de fin de mouvement, le jeu se chargera d’interpréter la position de l'élement entre les deux "marqueurs" de façon cohérente par rapport aux déplacements habituels de l'objet.

Par contre, j'ai encore un peu peur quant à la perte de fluidité.
Si le joueur s'amuse à bouger partout en sautant à chaque frame où cela lui est permis etc... ça fait pas mal de truc à écrire.
Je ne sais pas si ça peut mettre à mal une petite config, je ferrais des tests.

A priori l'écriture en fichier est différée, donc pas vraiment de problème de performances à craindre si tu prends un tantinet garde à ta manière de stocker (un fichier texte est par exemple une mauvaise idée pour stocker des entiers).

Petit passage juste pour dire que j'ai changé la notion d'aléatoire, pour me diriger vers ton idée de "seed", D-z.

Plus le joueur est bon, plus les niveaux seront difficiles, le jeu peu donc interpréter chaque room en fonction du score de la room précédente.

Bah il suffit de faire un random_get_seed() avant de générer ton niveau, puis de tout générer sans utiliser d'autre processus aléatoire, et dès lors que tu feras random_set_seed() avec ce nombre, régénérer le niveau te donnera le même résultat.

Ca me rappelle mon enfance purement vachemoune.