ModularBase - Plugin de communication pour modules

Introduction

Lors de la réalisation du premier démonstrateur, le projet devient monolithique et mélange les différentes features qui doivent communiquer par une même websocket.

Afin de pouvoir isoler les features du projet Unreal et le rendre ainsi plus modulaire, on réalise un plugin qui permet de gérer les communications avec l’environnement extérieur. A partir des classes génériques qu'il fournit, on implémente des versions correspondants aux différentes features nécessitant une communication (HTTP ou WebSocket).

Deux types de feature se présentent :

• Celles qui requièrent une connexion websocket indépendante pour des éléments (ex. Streaming)
• Celles qui requièrent une connexion websocket centrale (ex. Dessins)

Le plugin de communication les satisfaits différemment.

Dans cette section, je décris les classes qui sont proposées par ce plugin, leur raison d'être et leur utilisation. Je finis aussi par lister les quelques routes qui sont attendues d'une API externe qu'on souhaite connecter à ces éléments.

📄️ Connexions indépendantes

Dans le premier cas, on est actuellement obligé d’implémenter un acteur de zéro ou héritant de la classe contenant la logique non communicante. Pour standardiser ça, on crée un Actor Component qui embarquera toute la logique de communication.

📄️ Connexion centrale

Dans le second cas, on gère actuellement ça avec une unique game instance (GI) personnalisée, qui réagit à tous les messages utiles toutes mécaniques confondues. Pour modulariser cette solution, on implémente :

📄️ Sérialisation des acteurs

Enfin, quel que soit la méthode de communication, pour décrire les éléments de l’environnement 3D à d’autres services, il faut pouvoir les sérialiser en FString. Le plugin de communication inclut donc aussi UModuleDescComponent, une interface pour ActorComponent qui est voué à être hérité et ajouté à chaque élément qu’on souhaite sérialiser.

📄️ Spécification API

Ces composants nécessitent une API avec laquelle communiquer. Les URLs qu’ils utilisent sont composés de plusieurs éléments : des éléments statiques (que doit satisfaire l’API), des éléments variables configurés au démarrage (ex. http vs https) ou fixés lors de l’héritage (ex. ModuleType) et des éléments variables modifiés au runtime (ex. ModToken).