17 juil. 2020
Pour notre seconde Creative Week - qui a dû être décalée de part le confinement global que nous avons connu - nous avons voulu réaliser une expérience interactive et avons opté pour un portail de jeux multijoueurs. Car durant le confinement nous aurions aimé jouer ensemble, avec simplement notre téléphone, à des jeux rapides.
Nous avons demandé au bar à jeux Les Tricheurs de nous conseiller sur un jeu que nous pourrions implémenter en une semaine, c'est à dire un jeu plutôt simple et multijoueurs. Ils ont agi en tant que "client" pour cette semaine créative.
Le premier jeu choisi pour le portail est Otrio. Un jeu semblable au Morpion (ou Tic-Tac-Toe) où les joueurs disposent de pièces de 3 tailles différentes, 3 de chaque soit 9 au total. Le but est d'aligner soit 3 pièces de même taille de sa propre couleur, soit de taille croissante ou décroissante ou encore de placer 3 pièces de tailles différentes sur une même case.
Du coté technologique, nous voulions donner une seconde chance à GraphQL dans un contexte hors cloud et sans les spécificités pouvant accompagner leurs services, contrairement à ce que nous avons essayé lors de la première Creative Week.
Pour le reste des technologies nous avons utilisé Angular et Angular Material coté écran et NestJS coté serveur ; avec la brique GraphQL client/serveur correspondant. Angular et NestJS apportant tous deux avec leurs CLIs la génération de socle et de brique de code ainsi que des couches de test déjà configurées.
Jour 1
Nous avons initialisé nos dépôts Git pour les écrans et le serveur, avec les socles initiaux des CLIs et nous sommes réparti le travail : certains maquettant les écrans et l'expérience utilisateur avec un outil collaboratif, d'autres avançant sur la logique du jeu et de GraphQL.
Dès le départ, nous avons configuré l'intégration continue de GitLab pour tester, construire et déployer l'application en tant que page GitLab et qu'application Heroku pour le serveur ; ce dernier notamment pour tester s'il y avait une quelconque spécificité technique de la plateforme pour nos développements.
Pour la logique du jeu, nous avons retenu une approche dirigée par les tests.
Par ailleurs, en vue de faire un portail avec plusieurs jeux, nous avons utilisé les module asynchrones d'Angular et configuré plusieurs endpoints GraphQL ainsi que des modules isolés.
Et pour finir la journée, nous avons aussi réfléchi au modèle commercial que pourrait avoir une telle application, tel l'achat de personnalisation graphique (référé en tant que skin ou costume dans le milieu) par les joueurs ou encore l'abonnement de professionnels pour l'habillage du site à leurs couleurs. Le pari d'argent ferait tomber l'application dans des juridictions beaucoup plus contraignantes. Bien sûr ce dernier point sur un jeu tel qu'Otrio ne s'y prête pas, mais pour un jeu de carte ou avec plus de bluff et/ou de stratégie, cela pourrait être le cas.
Jour 2
À l'aube du second jour, nous branchâmes les écrans au serveur via GraphQL, dont les souscriptions utilisent WebSocket. La documentation d'Apollo nous sembla parfois confuse, et il était difficile d'y trouver des pages telles que l'intégration pour Angular alors que celles pour React étaient directement accessibles par différents liens dès l'accueil de la documentation.
Le schéma GraphQL nous servit aussi de contrat d'interface entre le front et le back, afin de partager un point de vue commun pour faciliter l'intégration des 2 parties plus tard et qu'elles ont pu donc être développées indépendamment.
Suivirent l'implémentation des écrans et de la logique des sessions et du jeu :
- attente des joueurs ;
- mise en place du plateau de jeu ;
- démarrage de la partie ;
- glisser-poser des pièces ;
- évaluation des conditions de victoire.
La réflexion du jour tourna autour du logo de la plateforme de jeux.
Jour 3
Presque toutes les fonctionnalités principales ont été réalisées, et nous avons commencé l'authentification, qui nous permettra de garantir qu'un coup joué l'est bien par le bon joueur et non par quelqu'un d'autre jouant à sa place.
Ces fonctionnalités ont été intégrées de bout en bout (écran et serveur), et dès lors des parties purent être jouées.
Nous avons aussi fait des essais sur téléphone, et ajouté les textes réels, notamment les règles du jeu. Ces dernières sont accessibles avant et pendant le jeu.
Jour 4
Ce fut l'implémentation et l'intégration des fonctionnalités annexes telles que détecter que le jeu est bloqué ou que le joueur ne peut pas jouer, notamment à 4 joueurs.
Nous avons procédé à un phase de test d'intégration, d'où découlèrent des corrections de bugs et des améliorations de l'expérience et de quelques points de règles dont seul le cas nominal avait été implémenté.
En fin de journée, à l'ouverture des Tricheurs, nous leur avons présenté l'application et ils ont formulé des remarques positives et des points d'amélioration.
Jour 5
Ce jour marqua la conclusion de notre semaine où nous polîmes l'application et le jeu tout en préparant l'évolution potentielle de celle-ci en un véritable portail de jeux.
Pour le jeu Otrio même, nous avons ajouté la représentation de la réserve des pions des autres joueurs.
Et pour le portail, en lien avec un modèle économique évoqué, nous avons intégré le visuel des Tricheurs, qui s'affiche si la géolocalisation de l'appareil indique que l'on en est proche.
En conclusion
D'un point de vue fonctionnel, nous avons réalisé un portail de jeux qui pourra accueillir d'autres jeux.
Au sujet du jeu Otrio lui-même, nous n'avons pas finalisé le jeu à 2 joueurs, où chacun dirige 2 couleurs ; en somme comme s'il s'agissait de 4 joueurs. La dualité de l'utilisateur ici implique quelques problématiques supplémentaires que nous n'avons pas adressé par manque de temps. En dehors de ce point, nous pouvons jouer des parties selon les mêmes règles que le jeu d'origine.
D'un point de vue technique, nous aurons probablement à ajouter une couche de stockage de données autre qu'en mémoire pour persister les comptes utilisateurs et les statistiques.
Enfin ce fut notamment l'occasion d'utiliser GraphQL. Il se base de facto sur un schéma qui définit le contrat d'interface entre le client et le serveur, et apporte donc une garantie de ce point de vue. Il apporte aussi une abstraction bienvenue des WebSockets par les souscriptions. Les librairies utilisées semblent matures mais ont tout de même des défauts de documentation, qui bien que présente et à priori complète, n'est pas exhaustive et accessible.
Envie de faire une partie d'Otrio ? Appelez des amis et allez sur https://playme1.gitlab.io/portal/#/