SEPT. / OCTOBRE 2017

INTRODUCTION ET DIRECTION DE PROJET - Lauriane

      Ces deux derniers mois ont été une période chargée pour le studio.

Le travail sur Dionysos, l’une des arènes de dWARf, s’est intensifié, notamment à l’approche de la deadline de mi-octobre. De nombreux débats apparaissent au fur et à mesure de la production. Plus l’arène avançait vers sa finition, plus nous avons constaté des détails problématiques auxquels nous devions trouver des solutions.

     Dionysos a été un bon moyen de mettre à l’épreuve l’organisation mise en place à la suite des erreurs faites avec Héphaïstos. Une petite équipe nous permet de faire des ajustements constants et de communiquer rapidement sur des changements d’organisation ou de méthode. Dionysos nous a permis de voir que les décisions prises à la suite de la production de Héphaïstos fonctionnaient bien et avaient accéléré la façon de travailler et amélioré la communication au sein de l’équipe. Cependant, un système peut toujours être amélioré, et j’ai passé une grande partie du mois d’octobre à réajuster les processus de production, mettant en place un document le plus exhaustif possible (mais toujours modifiable à la lumière de nouvelles expériences).

 

     A ce travail s’est ajouté la pression supplémentaire de l’organisation d’un playtest.

Un playtest a pour objectif de recueillir en direct les retours de joueurs d’un panel représentatif. Pour qu’un playtest soit le plus intéressant possible, la build (la version du jeu) que les joueurs sont amenés à tester doit être la plus complète possible afin que les remarques des testeurs ne soient pas au sujet d’éléments déjà analysés et traités de notre côté.

Par exemple, si le son apporte un retour sur le gameplay (une petite cloche sonne quand un personnage finit une action), il faut que le son soit présent dans la build testée, sinon nous prendrions le risque qu’un joueur se plaigne d’un manque de retour (qu’on appelle « feedback sonore ») sur son action alors que ce retour est prévu. Il serait donc dommage que le joueur se soit concentré sur un manque qui en réalité n’existe que parce que la build est incomplète.

Le mois d’octobre a donc aussi été une période de challenge quant à l’organisation de ce playtest et à la détermination de pré-requis à la build présentée.

 

     Le playtest est aussi un moyen de tester notre communication sur le jeu notamment sur les tutoriels, les vidéos de gameplay et les présentations des arènes.

Toujours dans l’axe de la communication, ces deux derniers mois nous avons travaillé sur le premier ► teaser du jeu que vous avez découvert sur YouTube et sur Twitch lors de la Paris Games Week. Offrir une histoire à dWARf était une envie très personnelle, je souhaitais réellement permettre au jeu de s’inscrire de manière cohérente dans un univers propre dans lequel les joueurs pourraient se projeter et apprécier.

 

     En parallèle de tout cela, nous avons fait une nouvelle « réunion pâte à modeler » pour l’arène suivante, Poséidon (quand je vous disais que ces deux mois avaient été chargés), et nous avons commencé à travailler selon la nouvelle méthode créée, plus précise et plus adaptée au fonctionnement de notre équipe.

 

     J’ai aussi travaillé sur plein d’autres petites surprises que vous découvrirez au fur et à mesure des mois à venir !

GRAPHISMES 2D - Audrey

Réflexion sur les processus

    La création 3D de la prochaine arène, Poséidon, n’était prévue qu’en Novembre. Or, nous préférons attendre quelques semaines avant cette étape pour réaliser le concept art. On s’est rendu compte que les arènes était soumises à des évolutions de game design influant les éléments visuels jusqu’à tard. Si je me lançais trop tôt dessus, je prenais le risque de refaire beaucoup d’éléments, voire de reprendre le tout pour gagner en cohérence… et donc de perdre un temps que j’aurais pu passer à faire autre chose (voyez l’angoisse m’sieurs-dames). C’est ça aussi d’être une petite équipe ! 

Pour l’exemple, cet aperçu de planche concernant un ornithorynque qui ne sera finalement pas intégré.

    Il me restait donc près de 2 mois pour réaliser des missions annexes: des éléments complémentaires (peaufiner les pédalos, designer des canetons) ou plus éloignés (esquisser divers icons d’UI, poursuivre la Community Road Map…). D’où notre volonté d’en profiter pour réaliser un teaser, introduction à l’univers du jeu ! L’écriture était donc commencée.

 

     Nous sommes 2-3 à garder un oeil sur ce projet bonus ; la réalisation du jeu étant prioritaire. Mais une répartition un peu floue de nos rôles nous a mené à quelques erreurs de production.

     Après coup nous est venu d’autres idées de format (3 x 1min par exemple). On se lance parfois un peu vite dans une direction avec la volonté de ne pas perdre trop de temps en amont. Or, c’est important de se laisser le temps au début de tout projet. Car ne pas assez mettre ses idées à l’épreuve (du temps, des autres) peut se révéler assez contraignant après coup. Quand on approche de la fin, il est difficile de faire marche arrière (et souvent inenvisageable de repartir de zéro sans carrément abandonner). C’est un réflexe qu’on tend à avoir vis à vis de la création des arènes, mais qui nous a malheureusement quelques peu échappé ici.

Étapes et choix

     Pour les néophytes, voici les étapes de création d’une vidéo animée, rapportées à notre contexte bien sur – quand on ne veut pas de mauvaises surprises 😉

CONCEPTION

  –  Réécriture de l’histoire pour en faire un scénario = imaginer les étapes clés de l’histoire

PRE-PROD

  – Ecriture de la voix off = en lien avec le scénario et le storyboard pour éviter des redondances

  – Recherches graphiques = références pour le style (visuel & animation), palettes de couleurs, essais

Quelques recherches dans une direction graphique que nous avions validée qui ne me semblait finalement pas adaptée au sujet. Des recherches de style (parfois d’après des références graphiques), de couleur, de composition. Des pistes souvent trop proches de choses plus modernes, trop détachées de ce qu’est communément la forme d’un teaser.

– (Storyboard d’après scénario = plan fixes pour visualiser l’animation à venir et les enchainements)

– Enregistrement voix off = définir son ton, son ambiance, son rythme

– Animatique = Poser les bases des animations, durées des plans, transitions – un storyboard dans le temps

PRODUCTION

– Animation = Finalisation des illustrations, intervalles des animations 2D, motion design

– Finalisation = Sound design, mixage, effets visuels, harmonisation des couleurs, export…

 

    Concernant l’animation, je me dirige vers des illustrations animées; pas de l’animation traditionnelle pure (24 dessins par secondes pour des mouvements fluides), pas de motion design pur (animation d’éléments graphiques avec un logiciel), mais plutôt un mélange des deux. 

    Sur cette scène, j’utilise 3 images (frames) pour évoquer un mouvement brut: le brasier jaillissant du volcan. Mais j’utilise aussi des interpolations pour faire tomber les cendres de façon plus légère et délicate et ajoute une option 3D (pour les vrilles) et un peu de flou pour donner un sentiment de profondeur.

GRAPHISMES 3D - Liam

     L’objectif de mi-octobre est de terminer globalement l’arène Dionysos. Il nous faut donc texturer à la chaîne tous les éléments de décor modélisés dans l’été. Cette organisation un peu fastidieuse nous permet néanmoins de garder une meilleure cohérence graphique entre tous les éléments. Nous intégrons donc au fur et à mesure les différentes textures dans la scène, qui prend vie peu à peu. Il est ainsi plus facile d’équilibrer et corriger la colorimétrie et le contraste des éléments.

   Pour la texture du solSarah a eu une idée brillante avant son départ: utiliser une « splat map ».

En effet, la surface du sol est assez importante, et en conséquence, il faudrait utiliser au minimum une map de texture de résolution 4096px pour la couvrir. Du coup, dans un souci d’optimisation de map, et de temps de travail nous optons pour le texture splatting. C’est une technique qui permet de combiner différentes textures à l’aide d’une splat map qui fera office de masque, et déterminera les zones où les textures devront apparaître.

 

     Nous créons donc 3 maps différentes : une d’herbe, une de terre, et une de dalles rocheuses. Ce sont des tiling textures : c’est à dire qu’elles se répètent. Elles seront donc plus petites, car elles apparaîtront plusieurs fois à l’écran de manière répétée, au lieu de couvrir d’un bloc l’intégralité de la surface. On peut donc se permettre de se limiter à une résolution 512 pour ces 3 maps.

    Il ne reste alors plus que la splat map, qui nous permet de combiner nos 3 textures. Cette map sera une image RVB, qui couvrira toute la surface du sol, et où chaque couleur représentera une des trois textures. On prendra le rouge (R) pour les dalles, bleu (B) pour la terre et vert (V) pour l’herbe

    L’ambiance colorée de notre arène est désormais posée. Il nous faut maintenant ajouter un peu de vie et de mouvement dans la scène. Il est donc temps de s’atteler aux FX, c’est ce que nous verrons le mois prochain !

GAMEPLAY DEVELOPPEMENT - Solune

    Ces deux mois ayant surtout été de l’intégration, de la finition et du débug en préparation des playtest de début novembre, et tout ça n’étant pas très intéressant, on va plutôt parler de choses qui datent un peu mais qui sont toujours très utiles et bonnes a savoir.
Les scripts de l’éditeur (utilitaires) dans Unity

    Dans Unity, il est possible d’ajouter des sortes “d’extensions” à l’éditeur lui-même, ces scriptsutilisent le même langage que les scripts gameplay, mais ne servent qu’à rendre la vie plus facileà ceux travaillant sur le projet Unity et ne seront pas dans le jeu lui même.

   Le projet commençant à se fournir en assets, scripts, prefabs et autres, les utilitaires deviennent indispensables pour gérer, manipuler, utiliser et maintenir tout ça. Par exemple, un des premiers scripts utilitaires que j’ai fait sert à créer une miniature pour l’éditeur de personnage à partir d’un prefab d’un élément de personnalisation.

Beaucoup moins long que faire tout à la main, et permet de voir exactement où l’élément va

    Un autre utilitaire qui s’est vite montré indispensable est la recherche d’un script dans les prefabs du projet, ce qui permet, couplé à la fonctionnalité “find references in scene”, de trouver facilement où et pourquoi est utilisé chaque script.

Les quelques lignes qui épargnent des heures de recherche dans les centaines de prefabs

    D’autres utilitaires, plus discrets, servent par exemple à régler automatiquement les paramètres d’import de certain type d’assets, ce qui rend l’intégration bien plus agréable et rapide. Globalement, tous ces scripts sont un gain de temps non négligeable pour toutes les membres de l’équipe utilisant Unity, et permettent de s’affranchir des tâches répétitives et laborieuses qui donnent envie de rester chez soi !

Au niveau d’Unity

    Je ne sais pas si ça a déjà été mentionné, mais la programmation gameplay dans dWARf ne se limite pas à coder le client du jeu (le programme que les joueurs utilisent pour interagir avec le serveur) mais également le serveur de jeu !

C’est bel est bien Alexandre qui s’est occupé de la partie communication client-serveur, mais une grosse partie du gameplay est gérée par le serveur, et ça, c’est à moi de le faire.

 

    Le serveur étant dit “autoritaire” tout ce qu’il se passe en jeu est d’abord “validé” par le serveur. Par exemple la position des joueurs, leur collision, etc… est gérée par le serveur, ce qui veut dire que la physique d’Unity doit fonctionner sur celui-ci.

Ce fait pose un problème plutôt important : il y a un serveur de jeu qui doit être démarré par partie en cours. Il est donc indispensable que le plus possible de programmes “serveur de jeu” puisse être exécutés simultanément sur un seul serveur physique (les machines sur lesquelles sont hébergés les serveurs de jeu) et donc qu’un serveur de jeu utilise le moins de ressources possible, pour une raison évidente de coût, mais aussi de stabilité.

 

    L’optimisation de la physique d’Unity, sans non plus recoder tout le moteur, se fait surtout dans la gestion des collisions : la complexité des calculs des collisions dépend énormément de la forme des colliders. Du coup, il est évident qu’on ne peut pas raisonnablement utiliser la même scène que pour le client avec des “mesh collider” (qui calcule des collisions correspondantes exactement au visuel de l’objet) pour tous les objets modélisés par l’équipe 3D.

 

    Du coup, il faut représenter les objets qui doivent avoir un collider (et pas les autres) le plus fidèlement possible avec uniquement des formes primitives, mais là encore, toutes les formes primitives ne se valent pas.

Par exemple, contrairement à ce qu’on pourrait croire, le cube est peu performant car il demande une série de calculs complexe pour établir le point du cube le plus proche de l’autre objet potentiellement en collision et déterminer s’ils se traversent. Les sphères au contraire, peuvent sembler complexe car un objet 3D sphérique est composé d’une multitude de petites faces, mais au niveau des colliders, détecter une collision entre deux sphère revient simplement à calculer la distance entre celles-ci !

 

    L’objectif est donc de reproduire le plus fidèlement possible les formes du jeu avec en priorité: des sphères, des capsules (dont le calcul revient à chercher la distance du point le plus proche d’une droite) et des cubes (parce que des fois, pas le choix).

En haut ce que le client voit, en bas, les colliders côté serveur. Si si, c’est la même map !

    Comme on peut le voir, la plupart des objets peuvent être formés d’un composé de sphère et de capsule, le collider des personnages étant une capsule, les calculs physiques sont simplifiés au possible ! Les seuls cubes étant les colliders au sol, qui ont besoin d’être plats dans deux dimensions.

 

    Pas grand chose d’excitant en ce moment, mais le prototype prend bonne forme et on s’amuse toujours autant lors de nos tests internes !

DEVELOPPEMENT MULTI - Alexandre

    Refonte de l’API dWARf, refonte de l’API de matchmaking, préparation du déploiement de la boutique, mise en place des premières “pipelines” de collecte de données serveursystème de mises à jour de dWARf, c’est ce qui vous attend dans cette partie dev multi du blog!

Problème de l’API dWARf

    Concernant l’API dWARf et merci à une discussion avec Solune, il s’est avéré que j’avais très mal compris une partie du cahier des charges : la gestion de la couleur sur l’équipement des joueurs.

Une refonte quasi-complète de la gestion de personnage de l’API a donc été nécessaire, ce qui a consommé une bonne partie du mois de septembre. Les librairies permettant au client Unity de communiquer avec ladite API ont aussi eu droit à leur mise à jour respective.

Cela m’a aussi permis de revoir une grosse partie de l’optimisation des requêtes SQL, qui utilisaient essentiellement des jointures pour permettre une récupération de données rapide via des clés extérieures (foreign keys). J’ai préféré utiliser des données brutes directement mises à jour dans les tables, histoire de ne pas avoir à chercher dans différentes tables lors des requêtes SQL.

Ce qui a donné une très belle amélioration de performances du côté de la récupération d’équipements comme on peut le voir sur les graphiques ci-dessous.. 

Refonte de l’architecture du Matchmaking

    Dans un premier temps, vu qu’on n’avait besoin que d’une simple file d’attente pour le matchmaking, j’ai pensé à l’implanter directement dans l’API de matchmaking, de manière à ce que ce soit l’API qui décide, lorsqu’un nombre d’utilisateurs assez élevé pour faire un groupe était inscris à la liste, de créer un groupe de joueurs et lancer une partie en envoyant un ordre au service de gestion de parties comme sur le schéma suivant :

      Cette architecture comportait pas mal de problèmes: ralentissement des requêtes HTTP (et donc, moins bon temps de réponse de l’API), une désynchronisation possible de l’état du joueur et une difficulté pour agrandir (scalel’architecture et éviter les points faibles (weak points) qui, au lieu de ralentir un worker, ralentiraient un service entier.

Du coup, au lieu de laisser l’API Matchmaking faire tout le travail, ce qui en plus, me limitait au niveau de la gestion des matchmaking spécialisés (utilisant des algorithmes plus consommateurs en temps d’exécution), j’ai décidé d’utiliser des workers, qui changent d’algorithme en fonction des besoins et sont programmables à souhait!

La création d’un matchmaking ressemble donc à ceci :

    Du coup, en cas d’un trop gros nombre de joueurs en file d’attente, il nous suffit d’augmenter le nombre de workers pour permettre une fluidité du service!

De plus, on peut faire en sorte que certains workers soient uniquement dédiés à une file d’attente en particulier, ce qui évite encore plus les bouchons 🙂

La boutique

    Noël arrive de plus en plus vite et nous avions prévu de déployer la boutique avant Noël. Ainsi, j’ai mis en place les nouveaux systèmes de paiements manquants et amélioré le système de gestion de paiement qui sont gérés par l’API de gestion de comptes.

Le backend est prêt à être déployé, il n’attend que le frontend qui est encore en développement, mais tout ceci arrivera vite 😉

“Pipelines” de collecte et monitoring des données

    Il est très important pour nous d’avoir toujours en vue les données actuelles, ainsi que leur utilisation. Il faut donc les monitorer de manière à pouvoir les surveiller, mettre en place des alertes en cas de soucis, etc.

   Dans ce contexte, nous utilisons Prometheus pour le monitoring de nos données, j’ai donc créé des pipelines de données nous permettant de récupérer les données de monitoring directement sur tous nos services. Le but, c’est de trouver rapidement quel endpoint est lent sur une API, pour pouvoir le fixer le plus rapidement possible.

Si un endpoint est lent, il risque de mettre en file d’attente les autres utilisateurs qui veulent y accéder et ce n’est pas ce que nous souhaitons pour garantir un temps de réponse optimal de l’API, il est donc important de le monitorer.

D’autres ressources ont été monitorées aussi, comme l’utilisation générale des serveurs, ou encore le nombre de joueurs en ligne 😉

Le système de mises à jour

    Enfin, j’ai passé quelques semaines à travailler sur le système permettant de maintenir à jour dWARf, tout simplement.

Ce système est un simple service d’updater, permettant de générer des “package” de données pour générer une mise à jour, qui peut être directement exportée en production, ainsi que le système côté client permettant de télécharger les différentes données.

Pour cela, 2 systèmes ont été développés en parallèle: le système “packager”, permettant de créer les packages de mises à jour et le système “updater”, permettant de mettre à jour le jeu côté client.

Du côté du packer, il permet de générer un fichier contenant toutes les informations importantespour récupérer les mises à jour et contient même une option permettant de compresser les fichiers de manière à pouvoir permettre aux joueurs de passer moins de temps en téléchargement.

Du côté de l’updater, on est sur du classique: télécharger le fichier de versions, comparer les versions de fichier, mettre à jour si besoin, décompresser si besoin.

Une version MacOS et Linux sont aussi en cours de développement.
Conclusion

    C’est une période bien remplie du côté du multijoueur. Beaucoup d’optimisations ont eu lieu, pas mal de nouvelles fonctionnalités ont été ajoutées, un système de mise à jour est fonctionnel, il ne reste plus qu’à attendre l’arrivée du sysadmin pour commencer à mettre tous les process de mise en place en production!