Samuel Dubois - Tool Programmeur

Foxy Flox

la_sixème_collection
Foxy Flox est un jeu de manipulation en Réalité Virtuelle multijoueur. Dans ce jeu, les joueurs doivent manipuler des flox : pièces emboîtables tel des tétrominos. En les empilant, les joueurs forment une tour, le premier atteignant la ligne d’arrivée à gagner. Pour cela, ils disposent de différents moyens comme l’obtention de flox de métal ou l’envoie de météorite sur la tour de leur adversaire.

Le projet a été réalisé en 4 mois par une équipe de 4 étudiants en game design et de 1 étudiant en game programming sur Unity 3D.

L’intégration de l’api Steam est en cours et le jeu sera bientôt disponible.

Mon rôle :

J’ai été le seul programmeur du jeu, alors que je travaillais sur les systèmes du jeu, les game designers réalisaient des prototypes que j’intégrais ensuite au system. J’ai principalement travaillé sur trois grandes fonctionnalités : le VR contrôleur, remaniement de la physique, mise en place du réseau.

- VR contrôlleur :

Nous avons utilisé le SDK OpenXR afin de réaliser ce projet, ce dernier permet de réunir les sdk de la plupart des casques VR (Quest, HTC, Index) en un seul.

Le jeu étant un jeu de manipulation, nous avons utilisé le XR Interaction Toolkit de Unity que nous avons modifié pour convenir à notre jeu : j’ai rajouté une « tomato presence » qui permet de déplacer l’objet attrapé afin qu’il apparaisse comme étant attrapé dans la main et non pas remplaçant la main comme le propose le toolkit de base. Cela permet aussi de conserver la rotation actuelle de l’objet afin de faciliter la manipulation.

Mouse over pour animer
Nous avons également créé un system de déplacement afin de limiter la motion sickness que procure souvent une expérience VR. Le joueur se déplace ainsi autour de sa table en effectuant des mouvements semblables à un tir à la corde, et cela, aussi bien verticalement qu’horizontalement. Les mouvements réels du joueur dans son salon sont toujours pris en compte, mais il peut, grâce à notre system, se déplacer dans le jeu sans se mouvoir dans la vraie vie. Cela permet même de jouer assit si on le désire.
.gif
Mouse over pour animer

- Physique :

Le jeu étant un jeu d’empilement en réalité virtuel, il nous a fallu utiliser une physique réaliste. N’ayant pas le temps de recréer une physique, j’ai décidé de travailler sur la physique du moteur Unity. Seulement, je me suis très vite retrouvé bloqué par un problème de tremblement : si on empile plus de 3 rigidbodys (corps physiqués de Unity), et que l’on rapproche un autre de la structure, celle-ci va se mettre à bouger même s'il n’y a pas de contact. Cela est dû à l’anticipation qui permet de prédire les comportements physiques quelque frames en avance afin d’optimiser les calculs.

J’ai donc tout d’abord modifié les paramètres de physique de Unity afin de les rendre le plus optimisé possible (gestion des sleep treshold, des contacts offset, des world subdivisions, des time step, etc.) ce qui a permit de limiter le problème. Ensuite, j’ai modifié via code l’anticipation afin qu’elle soit réduite. Cela augmente les calculs, mais les gains au niveau de la manipulation et de la physique est tel que nous avons jugé cette modification acceptable.

- Réseau :

N’ayant aucune connaissance en réseau, j’ai dû me former sur le tas. J’ai utilisé l’ API Mirror (bas niveau) afin de créer mon réseau. Celui-ci fonctionne en Peer To Peer (system qui m’a semblé être le plus simple à mettre en place) pour deux joueurs. La physique du jeu est calculée en local sur les deux joueurs, le serveur ne possède que des informations de positions afin de limiter le poids des paquets. Les joueurs ne jouant pas sur la même structure, le fait que l’actualisation de la physique d’un joueur dans le monde de l’autre joueur ne soit pas instantanée ne gêne pas.

Afin d’augmenter l’interaction entre les joueurs, j’ai aussi mis en place un système de communication vocal via micro. Les paquets de sons étant assez lourds, j’ai organisé l’envoie de paquet afin qu’il n’y ait rien d’autre que des informations sonores dans leurs paquets.

Tool d'analyse:

J’ai réalisé un tool d’analyse qui permet au Game Designer d’équilibrer le jeu. Ils peuvent trouver quel flox tombe le plus souvent et à quelle position. Cela a permis de mettre en évidence des problèmes de forme sur certains flox qui tombaient bien plus que les autres.
 The tool  The tool
Informations que les Game Designers obtiennent grace au tool.

Quand un flox tombe, l’information est comparée aux autres pour ne pas faire de doublons puis est envoyée dans un tableur .CSV sur un cloud. Au lancement d’une partie ce .CSV est mis à jour en local puis converti en .Json et est encrypté. Ensuite, l’application d’analyse créée sur Python via la librairie Tkinter va décoder le .Json et en extraire des informations.

Le tout est fait de façon dynamique sans que le joueur ni le Game Designer n’est besoin de faire autre chose que de lancer le jeu ou l’application.

Compétences acquises :

- J’ai appris les enjeux des contrôleurs de réalité virtuelle et j’ai appris à utiliser le SDK Open XR afin de créer mon contrôleur compatible sur la plupart des casques de réalité virtuelle.

- J’ai amélioré mes connaissances sur la simulation physique 3D et sur ses optimisations dans des moteurs de jeu.

- J’ai appris à développer une infrastructure en Peer to Peer pour deux joueurs via l’API bas niveau Mirror.

- J’ai appris à manager et à optimiser l’envoie de paquet afin d’anticiper le lag et la perte de données.

- J'ai appris à créer une application en Python.

- J'ai appris à stocker, envoyer et recevoir des données sur un cloud.

- J'ai appris à sécuriser des fichiers .Json en les encodants.