S K Y R I F T

Fiche signalétique

Unity | C# | Unet

Skyrift est un Runner / Fps multijoueur dans lequel ​deux équipes de 3 joueurs s’affrontent dans une course au boss mélant phase de plate-forme et shoot. La première équipe qui bat le boss en fin de course gagne la partie.

Développement

Deux équipes de 3 joueurs s’affrontent dans une course au boss mêlant phase de plate-forme et phase de shoot. La première équipe qui bat le boss en fin de course gagne la partie. Les deux équipes ne peuvent pas se tirer directement dessus. Il faut donc utiliser les capacités spéciales des personnages au mieux afin de prendre l’avantage. Sur ce projet, je me suis principalement occupé des personnages jouables, du controller, des tirs et des capacités spéciales.
Mise en place du personnage
Le jeu étant en multijoueur, il a d’abord fallu créer la hiérarchie du personnage, avec les objets visibles en local et ceux visibles par les autres joueurs. Il y a donc le modèle en vu FPS (seulement les bras), visible seulement en local, qui suit le mouvement de la caméra.

Ensuite il y’a le modèle complet du personnage, visible lui seulement par les autres joueurs, qui lui suit la rotation sur 2 axes de la caméra. Outre les scripts classiques d’un FPS (déplacement, tir, …), il a fallu aussi synchroniser toute les actions du joueurs sur le serveur (déplacement, envoi de projectiles, interaction, animations, ...).
Le character controller
Ensuite, une des grosses parties du projet a été la création du Character Controller. Le jeu se voulant très rapide et dynamique au niveau du gameplay, avec des mouvements spéciaux comme des phases de slides ou des wallruns, le controller se devait d’être très réactif. Il devait aussi pouvoir subir des contraintes comme être propulsé, ralenti, gelé,...

Le joueur se déplace toujours en fonction de la normal du sol, afin d’éviter les accoups dans les pentes. Pour les phases de wallrun et de slide, la direction du joueur est bloquée par rapport à l’objet (mur, pente) sur lequel il se trouve afin qu’il soit guidé dans la bonne direction.
Problèmes liés au multijoueur
Le composent Unity qui synchronise les animations n’envoie pas les changements de layers d’animation. Les layers d’animations servent à superposer plusieurs animations, on peut y mettre des masques. Par exemple le shoot n’affecte que le bras, ainsi on garde l’animation de course pour tous les corps sauf le bras, qui lui joue l’animation de tir. Il faut donc envoyer l'information d’activation de layer aux autres pour qu’ils nous voient jouer l’animation.

Pareil pour les informations d’IK (ici le bras qui suit la direction de la visée). Il faut l’envoyer manuellement, en fixant un rate pour ne pas surcharger le réseau et en interpolant pour garder le mouvement fluide.
Le tir
Les tirs ne se font que côté serveur, le résultat est ensuite communiqué aux joueurs concernés. Seule les flèches sont physiques et possèdent de la balistique, les autres tirs sont juste des rayons.

Le fusil à pompe envoie 32 rayons dans un cône. Cela amenait des problèmes d’actions qui se passent dans la même frame. Par exemple le cristal qui fait baisser la vie du boss quand il se fait tirer dessus et qui est détruit directement par ce tir recevait quand même les autres tirs de la salve puisque ils étaient instantanés. Il a donc fallu stocker ce qui a été touché par un tir, vérifier les doublons, additionner les dégâts, afin d’envoyer un seul message ensuite avec la bonne information.

En ce qui concerne les impacts, pour les autres armes, la position est envoyée et chaque joueur génère l’effet de son côté. Mais avec le fusil à pompe et ses 32 tirs, l’envoie est trop lourd. Finalement à chaque tir de fusil à pompe, chaque joueur calcule en local un tir dans la même direction. Même si ce n’est pas la position exacte, le joueur ne voit pas la différence.
Les capacités
Les tirs ne se font que côté serveur, le résultat est ensuite communiqué aux joueurs concernés. Seule les flèches sont physiques et possèdent de la balistique, les autres tirs sont juste des rayons.

Le fusil à pompe envoie 32 rayons dans un cône. Cela amenait des problèmes d’actions qui se passent dans la même frame. Par exemple le cristal qui fait baisser la vie du boss quand il se fait tirer dessus et qui est détruit directement par ce tir recevait quand même les autres tirs de la salve puisque ils étaient instantanés. Il a donc fallu stocker ce qui a été touché par un tir, vérifier les doublons, additionner les dégâts, afin d’envoyer un seul message ensuite avec la bonne information.

En ce qui concerne les impacts, pour les autres armes, la position est envoyée et chaque joueur génère l’effet de son côté. Mais avec le fusil à pompe et ses 32 tirs, l’envoie est trop lourd. Finalement à chaque tir de fusil à pompe, chaque joueur calcule en local un tir dans la même direction. Même si ce n’est pas la position exacte, le joueur ne voit pas la différence.