Fin juin, l’équipe s’est retrouvée pour une nouvelle session de R&D (AKA “journée Inno’ ” chez nous) et voici les sujets qui ont été traités : Application tvOS, Découverte de Deno et Board Game API. Bonne découverte !
L’objectif de notre journée innovation était de réaliser une application de type liste/détail pour tvOS en utilisant SwiftUI. Nous souhaitions voir qu’elles étaient les interactions possibles, ainsi que les points communs et les différences entre tvOS et iOS.
À la fin de la journée, nous avions une application listant les plus grands succès du Box-office mondial et affichant le détail de ses films (Titre, affiche, résumé et bande-annonce en arrière-plan).
Nous avons remarqué des problèmes avec SwiftUI et tvOS tel que la navigation, qui ne permet pas d’afficher une seconde fois le détail d’un film. Ce problème pouvant être réglé en utilisant le développement des vues avec le storyboard.
De plus, nous avons aussi des problèmes d’interaction avec le résumé du film, celui-ci n’étant pas scrollable.
Cette journée nous a démontré la puissance et la facilité de développement d’interfaces graphique avec SwiftUI.
Deno est le nouveau runtime JS/TS fait par le créateur de NodeJS: https://deno.land/
La version 1.0.0 étant sortie le 13 mai, Nous avons souhaitez tester la réalisation d’un premier POC d’API sur le sujet.
Ayant de l’expérience sur NodeJS, c’est sereinement que nous avons attaqué le sujet Deno, bien que la communauté ne semble pas être encore vaste et les articles bien rares.
Notre idée était de proposer une API gérant des utilisateurs via un CRUD basique, l’objectif étant avant tout d’appréhender Deno.
Notre environnement de travail se constitue donc :
Concentrons nous désormais sur le coeur de notre journée, l’API.
En nous appuyant sur Oak, nous avons mis en place l’ensemble de l’architecture comprenant modèle, contrôleur, services et routes. Le framework est simple et efficace. Nous avons très vite trouvé les éléments dont nous avions besoin et mis en place la partie serveur http de l’API:
Les deux seuls problématiques que nous avons rencontrées lors de notre journées sont liés à la couche de persistance :
Conclusion de notre journée, Deno est prometteur:
Il est donc évident que cela semble trop tôt pour partir en production avec Deno, mais qu’il faudra suivre de près ses futures évolutions avant d’envisager la bascule Node — Deno.
Après deux mois à travailler à distance, les “moments d’équipe” nous manquent, notamment les parties de jeux de société du midi. Plutôt que d’utiliser les services en ligne existants, pourquoi ne pas développer notre propre outil interactif et évolutif, dans lequel nous pourrons venir intégrer petit à petit les différents jeux que nous aimons ?
L’objectif technique est de réaliser une plateforme de développement de jeux de plateau. Générique et évolutive, elle permettra de jouer aux cartes, aux dés, aux dames, à n’importe quel type de jeu. Chaque jeu prend la forme d’un module qui apporte son matériel spécifique (cartes, dés, pions) ainsi que ses règles. La plateforme est agnostique.
Pour le backend, nous avons besoin de synchroniser la partie avec chaque joueur. Nous utilisons donc les WebSockets, et leur intégration dans NestJS.
Pour le plateau de jeu, nous avons choisi d’utiliser le framework Phaser qui permet de réaliser des jeux utilisant les Canvas et WebGL.
Sur la base d’un exemple Phaser affichant un paquet de cartes, nous avons créé un plateau de jeu présentant une pioche.
Chaque joueur a la possibilité de piocher une carte, que ce soit son tour ou non (comme dans la “vraie vie” ^^), et de la déplacer sur le plateau. Les déplacements de cartes sont synchronisés entre chaque joueur mais chacun peut placer sa pioche où il le souhaite.
Nous avons également ajouté sur les cartes une indication de couleur permettant à tous de savoir qui a pioché chaque carte.
NestJS simplifie beaucoup la mise en place de l’API.
L’arrivée dans Phaser est un peu délicate du fait d’un manque de visibilité de la documentation (documentation officielle, documentation officieuse, documentation de plugins, documentation v2/v3). Néanmoins, une fois le “tri” fait, le framework est simple d’utilisation. De plus, la quantité d’exemples de code et de cas d’usages permet de démarrer rapidement.
Étant donné le peu de temps à notre disposition, nous avons développé cette application en mode rush, sans prendre le temps de penser l’architecture. Le POC est concluant et le projet va désormais nécessiter une phase de réflexion :