La fonctionnalité est très demandée des joueurs de ManiaDrive, donc il me semblait nécessaire de l’ajouter pour ManiaDrive 2 : les replays. En clair, la capacité de pouvoir sauvegarder une partie pour la rejouer plus tard.

Deux solutions basiques pour réaliser une telle tâche : jouer sur le déterminisme ou tout enregistrer. La première option part du principe que si on reconstruit la scène exactement comme lors de l’enregistrement et que l’on injecte les entrées (clavier, souris, joy, …) du joueur au même moment, tout va se passer de la même manière que lors de l’enregistrement. Cette méthode à l’avantage d’être très simple à implémenter et de générer des enregistrements de taille très modeste (état initial de la scène + entrées utilisateur).

En revanche, avec cette méthode, il est nécessaire d’être très attentif puisque la moindre erreur, même infime, va complètement décaler la relecture dès les secondes suivantes. Et ces erreurs peuvent êtres engendrées pour des raisons parfois tordues (arrondi d’un nombre flottant, paramétrage différent du FPU de la machine à cause d’une autre application [DirectX est une cause courante de ce problème], léger décalage ponctuel dans la lecture replay, …). Autre problème : les nombres aléatoires. Ils sont très souvent utilisés dans les jeux, et il est nécessaire que la série aléatoire soit la même lors de l’enregistrement que lors de sa relecture. Il faut donc être sur qu’aucune autre partie de l’application ne se serve du même générateur de nombres aléatoires pendant l’enregistrement et la lecture. Autre point noir : les entrées peuvent être complexes. Par exemple, l’enregistrement des entrées clavier ne pose aucun problème en général. Mais la souris et les joysticks/joypads/volants génèrent beaucoup plus d’évènements, ce qui va alourdir beaucoup le fichier final … mais le pire reste le problème du réseau. Lors d’une partie multi, gérer les actions des autres joueurs va demander un travail énorme.

Raydium est multiplateforme (OS et CPU peuvent êtres différents), supporte les parties en réseau, et utilise ODE, un moteur physique connu pour être difficile à rendre déterministe. Inutile de perdre du temps à tenter d’implémenter ce genre de replays.

L’autre solution est toute simple : tout enregistrer. En permanence. Chaque création d’objet, chaque destruction, chaque déplacement. Le résultat est bien sûr un fichier beaucoup plus conséquence en taille, on arrive vite à plusieurs Mo par minute sur des scènes complexes. Les avantages en revanche sont très nombreux :
– La répétabilité est excellente : quelle que soit la plateforme, quel que soit l’OS et la version de l’application et de son moteur physique, peut importe ce que l’application fait d’autre que jouer le replay : le résultat sera le même.
– Possibilité de jouer sur la précision du replay. J’enregistre par défaut à 30 Hz, mais il est possible de générer des replays moins précis mais plus petits (10 Hz par exemple).
– Possibilité de jouer le replay en accéléré, mais surtout en arrière ! (très utile pour retrouver une action particulière dans un replay). Les sauts dans le replays sont aussi très peu couteux, quel que soit la taille du saut et son sens.
– Possibilité de jouer un replay pendant une autre partie … et d’enregistrer en même temps !
– …

Bref, j’ai cherché a implémenter cette méthode, et avec succès. L’écriture a été assez complexe, je dois l’avouer (on tombe par exemple sur quelques paradoxes temporels lors des lectures en sens inverse), et surtout, elle n’est pas encore complète. Par exemple, les vitesses de lecture inférieures à 1.0 sont encore mal supportées (je n’interpole pas encore entre les samples), et seuls les évènements principaux sont enregistrés. Les sons, les particules, explosions et autres ne font pas encore partie du replay.

Petite vidéo très vite faite de l’application de lecture des replays.

J’ai ici enregistré une partie solo, relancé l’application, joué le replay que je venais de créer tout en jouant « par dessus », tout en enregistrant le tout. Le résultat « ressemble » à une partie multi à deux joueurs. Le fichier pèse 900 Ko pour 61 secondes.

Bref, le sujet s’avère assez complexe, et demande encore quelques évolutions dans Raydium. Mais nous disposons maintenant d’une solution très souple et très générique au problème des replays. A suivre.

Autre sujet, sans grand rapport : les wiimotes. A la suite d’une soirée « Les lapins encore plus crétins » chez un ami en manque de wiimotes, j’ai dû me procurer une wiimote au Auchan du coin. Mais je ne possède pas de Wii. Que faire alors de ce machin tout blanc ? Jouer avec bien sûr !
Grâce à la libcwiimote, il est extrêmement simple d’écrire des applications utilisant la wiimote. Une heure après la découverte de la lib, j’avais une démo qui tournait. Alors certes, il ne se passe pas grand chose, mais l’écriture de cette démo était très intéressante :

A coder une telle appli, on découvre plein de choses sur le fonctionnement interne de la wiimote. Je recommande l’exercice à tous les curieux. Je n’ai pas l’intention d’inclure le support de la wiimote directement dans Raydium (en tout cas pour l’instant), en particulier pour des raisons de portabilité. Mais je compte bien continuer mes tests sur ce nouveau jouet.

Et tant qu’a parler de périphériques d’entrée, j’ai découvert récemment l’effet FTIR. Frustrated Total Internal Reflection pour la version longue. L’utilisation de cet effet permet de créer des écrans tactiles de toutes tailles à moindre frais, et supportant plusieurs pressions en simultané. Et j’avoue être très très tenté par la réalisation d’une telle chose. Je n’ai trouvé aucune vraie ressource en français, mais on trouve beaucoup de réalisations « homemade » à droite et à gauche en anglais.

L’idée de base des écran multitouch FTIR consiste a utiliser une plaque en acrylique (transparente donc) assez épaisse (de l’ordre du centimètre), au bord de laquelle on place des « guirlandes » de LED infrarouges. Ces rampes de LED sont souvent orientées à 45° même si ça ne semble pas strictement nécessaire. La lumière émise par ces LED va rebondir sur la surface de la plaque, ce qui fait que si on filme la plaque à l’aide d’une caméra infrarouge, on ne voit presque pas le rayonnement des LED (qui est « enfermé » dans la plaque). En revanche, il suffit de placer un doigt sur la plaque pour complètement modifier le rebond de la lumière … et générer un « point » d’émission IR très distinctif.

A l’aide d’une webcam un poil bricolée (on enlève le filtre IR qu’on y trouve systématiquement), on peut filmer la plaque par l’arrière et détecter la présence et la position des contacts des doigts (à l’aide d’un algo qui est ni plus ni moins que celui que j’utilise pour les impacts laser).

Si l’on projette (à l’aide d’un vidéoproj donc) un image sur un papier fin accolé à la plaque d’acrylique (le « diffuser » du premier schéma), on obtient bien un écran tactile !

Pas si encombrant que ça 🙂

Et avec beaucoup de boulot coté logiciel, on arrive à des trucs du genre de ce que Perceptive Pixel arrive à faire :

Je vais continuer de chercher des infos là dessus, mais j’avoue être très tenté par l’expérience (la partie hard me fait beaucoup plus peur que la partie soft).

PS : Rien à voir, mais je recommande très vivement l’épisode 6 de la saison 10 de Top Gear diffusé dimanche dernier, on y trouve une course de Camping-cars absolument mémorable. Probablement l’un des meilleurs moments de cette saison pourtant déjà bien chargée (cf la traversée de la manche ou la Peel P50 par exemple).