Nous avons eu une réunion hier soir afin d'avancer sur ces sujets.
Nous avons discuté de ce sujet, mais aussi de la mise en place des dépôts, qui est donc fusionné avec celui-ci.
tl;dr de la réunion :
Un schéma réalisé sous draw.io a permis d'avoir une vision d'ensemble de ce que nous avions envisagé au fil des années en ce qui concerne les exécutables nécessaires et les données ou bibliothèques à partager. Le but était d'avoir un élément de discussion pour voir le consensus qui en sortirait. Il a été créé en envisageant que chaque dépôt contiendrait un projet Godot, sans que cela soit indicateur de ce que le collectif allait décider.
Le fichier éditable est dans le Kloud : https://kloud.khaganat.net/index.php/f/719742
La partie la plus simple concernait les clients, que ce soit le client de jeu 3D, le client d'administration Polcie ou l'éditeur de jeu Khan. Seule question pour ce dernier : part-on sur un addon de grande ampleur qui permette l'édition avec Godot ou réalise-t-on un exécutable basé sur Godot. Un mode expert permettrait de faciliter la contribution en cachant les options complexes pour les personnes débutant dans ce genre de travail. Tout cela demeure à étudier plus finement.
La majeure partie des échanges a concerné la structure des éléments serveur.
Il a été rappelé que la gestion de tous les accès à l'écosystème serait basé à terme sur du LDAP, donc que le client devrait aller interroger cette base pour savoir quelle serait l'accréditation d'une joueuse lorsqu'elle tenterait de connecter un client.
Toute cette partie de Portail de connexion/ annuaire d'authentification sera développée en Rust pour des raisons de sécurité et de fiabilité, étant donné qu'il s'agit des éléments les plus exposés. L'usage de biscuitsec a été évoquée.
Le schéma proposait ensuite que les échanges passent par un Accès frontal, il a été retenu de le penser plutôt comme un bus de brokers (également en Rust, pour des raisons d'efficacité) qui permettrait d'adresser ensuite les échanges avec les différents micro-services (la dernière ligne des systèmes serveurs dans le schéma).
Cette dernière ligne propose un ensemble d'exécutables qui pourront chacun être placés sur une machine différente en cas de montée en charge. Les penser comme des projets distincts au sein de la Forge permettra de s'assurer un découplage optimal, même si certaines bibliothèques/modules devront être partagés pour partager les protocoles de discussion et d'accès aux données. En outre, même si il sera très certainement nécessaire de les développer en Rust, le fait de les penser dans des dépôts séparés permettra le cas échéant de les prototyper dans Godot, afin de faciliter la contribution. Il pourrait être nécessaire d'intégrer un module intermédiaire en Rust pour accéder au broker de façon sécurisée, mais cela reste à définir plus précisément.
Le service EGS pourrait être ne se voir affecté qu'une partie d'un monde, plusieurs services EGS devant alors échanger pour se synchroniser. C'est valable pour d'autres services comme AIS ou GPS, donc à garder en tête lors du développement.
Cette ligne concernant un monde accessible pour les joueuses, il faut également penser que l'accès à l'un ou l'autre devra être géré, ainsi que les accréditations relatives à chacun de ces mondes, lors de l'adressage vers les brokers.
Les échanges sont pensés avec protobuf afin de permettre la présentation d'une API simple et documentée qui permette l'enrichissement de l'écosystème de façon souple et modulaire.
Il a été évoqué le recours ou non à un super service du type Administrator qui superviserait tous les services au sein d'un monde, sans que son périmètre d'usage ou sa réelle nécessité n'aient été envisagés.
En ce qui concerne les backups, certains éléments nécessiteront une sauvegarde quasiment en temps réel (la création de compte par exemple) tandis que d'autres pourraient être moins critiques, en fonction du temps de jeu que l'on estimerait acceptable de perdre en cas d'incident. Le transfert vers ces espaces de backup doit se faire de la façon la plus simple possible, du genre fichier texte plat.
Par ailleurs, penser aux éléments relevant du RGPD dès le début du développement, en suivant la proposition de Marien Fressinaud a été retenue : https://marienfressinaud.fr/gdpr-txt.html
Enfin, la dernière ligne de ces micro services permettant de gérer un monde devrait trouver un nom pour en faciliter la désignation. Nous sommes quasiment sur le même périmètre que ce que désignait un « shard » dans l'écosystème Ryzom. Proposition : appeler cet ensemble un « khanat »
Il serait également intéressant d'avoir, à terme, la possibilité pour les joueuses d'instancier un mini-khanat, appelé « rêve ». Ce serait un monde réduit, où la joueuse aurait créé le leveldesign de façon similaire au Ring de Ryzom. Il demeure à voir où cette instance serait hébergée, comment elle serait créée, quels seraient les possibilités d'échanges entre un Khanat et ces mondes etc.
Nous avons discuté de ce sujet, mais aussi de la mise en place des dépôts, qui est donc fusionné avec celui-ci.
tl;dr de la réunion :
Un schéma réalisé sous draw.io a permis d'avoir une vision d'ensemble de ce que nous avions envisagé au fil des années en ce qui concerne les exécutables nécessaires et les données ou bibliothèques à partager. Le but était d'avoir un élément de discussion pour voir le consensus qui en sortirait. Il a été créé en envisageant que chaque dépôt contiendrait un projet Godot, sans que cela soit indicateur de ce que le collectif allait décider.
Le fichier éditable est dans le Kloud : https://kloud.khaganat.net/index.php/f/719742
La partie la plus simple concernait les clients, que ce soit le client de jeu 3D, le client d'administration Polcie ou l'éditeur de jeu Khan. Seule question pour ce dernier : part-on sur un addon de grande ampleur qui permette l'édition avec Godot ou réalise-t-on un exécutable basé sur Godot. Un mode expert permettrait de faciliter la contribution en cachant les options complexes pour les personnes débutant dans ce genre de travail. Tout cela demeure à étudier plus finement.
La majeure partie des échanges a concerné la structure des éléments serveur.
Il a été rappelé que la gestion de tous les accès à l'écosystème serait basé à terme sur du LDAP, donc que le client devrait aller interroger cette base pour savoir quelle serait l'accréditation d'une joueuse lorsqu'elle tenterait de connecter un client.
Toute cette partie de Portail de connexion/ annuaire d'authentification sera développée en Rust pour des raisons de sécurité et de fiabilité, étant donné qu'il s'agit des éléments les plus exposés. L'usage de biscuitsec a été évoquée.
Le schéma proposait ensuite que les échanges passent par un Accès frontal, il a été retenu de le penser plutôt comme un bus de brokers (également en Rust, pour des raisons d'efficacité) qui permettrait d'adresser ensuite les échanges avec les différents micro-services (la dernière ligne des systèmes serveurs dans le schéma).
Cette dernière ligne propose un ensemble d'exécutables qui pourront chacun être placés sur une machine différente en cas de montée en charge. Les penser comme des projets distincts au sein de la Forge permettra de s'assurer un découplage optimal, même si certaines bibliothèques/modules devront être partagés pour partager les protocoles de discussion et d'accès aux données. En outre, même si il sera très certainement nécessaire de les développer en Rust, le fait de les penser dans des dépôts séparés permettra le cas échéant de les prototyper dans Godot, afin de faciliter la contribution. Il pourrait être nécessaire d'intégrer un module intermédiaire en Rust pour accéder au broker de façon sécurisée, mais cela reste à définir plus précisément.
Le service EGS pourrait être ne se voir affecté qu'une partie d'un monde, plusieurs services EGS devant alors échanger pour se synchroniser. C'est valable pour d'autres services comme AIS ou GPS, donc à garder en tête lors du développement.
Cette ligne concernant un monde accessible pour les joueuses, il faut également penser que l'accès à l'un ou l'autre devra être géré, ainsi que les accréditations relatives à chacun de ces mondes, lors de l'adressage vers les brokers.
Les échanges sont pensés avec protobuf afin de permettre la présentation d'une API simple et documentée qui permette l'enrichissement de l'écosystème de façon souple et modulaire.
Il a été évoqué le recours ou non à un super service du type Administrator qui superviserait tous les services au sein d'un monde, sans que son périmètre d'usage ou sa réelle nécessité n'aient été envisagés.
En ce qui concerne les backups, certains éléments nécessiteront une sauvegarde quasiment en temps réel (la création de compte par exemple) tandis que d'autres pourraient être moins critiques, en fonction du temps de jeu que l'on estimerait acceptable de perdre en cas d'incident. Le transfert vers ces espaces de backup doit se faire de la façon la plus simple possible, du genre fichier texte plat.
Par ailleurs, penser aux éléments relevant du RGPD dès le début du développement, en suivant la proposition de Marien Fressinaud a été retenue : https://marienfressinaud.fr/gdpr-txt.html
Enfin, la dernière ligne de ces micro services permettant de gérer un monde devrait trouver un nom pour en faciliter la désignation. Nous sommes quasiment sur le même périmètre que ce que désignait un « shard » dans l'écosystème Ryzom. Proposition : appeler cet ensemble un « khanat »
Il serait également intéressant d'avoir, à terme, la possibilité pour les joueuses d'instancier un mini-khanat, appelé « rêve ». Ce serait un monde réduit, où la joueuse aurait créé le leveldesign de façon similaire au Ring de Ryzom. Il demeure à voir où cette instance serait hébergée, comment elle serait créée, quels seraient les possibilités d'échanges entre un Khanat et ces mondes etc.
)
). On n'est pas au tick comme sur le déplacement, mais il y a là encore une décision stratégique à prendre. Y prévoir de la souplesse de paramétrage (sur plusieurs variables : délai, façon de streamer les données, distance aux objets InGame qui détermine la densité des infos à récupérer etc.) depuis le backend serveur afin de se garder de quoi faire des stress tests serait pertinent je pense. Il faudra d'ailleurs y inclure l'envoi des données de « Gestion de position » à la déconnexion de la joueuse et, de façon plus globale, des logs sur les différents services, afin qu'on ait de quoi monitorer/modérer depuis le backend.
