Derniers messages
Dernier message par YannK - 18 Avril 2025 à 10:39:03
Cliquez pour afficher le message
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.
Dernier message par YannK - 18 Avril 2025 à 09:40:08
Cliquez pour afficher le message
Nous avons intégré ce sujet dans la discussion sur l'architecture des services. La discussion continuera là-bas.
Dernier message par YannK - 14 Mars 2025 à 12:20:08
Cliquez pour afficher le message
Citation de: YannK le 14 Mars 2025 à 10:52:07- avez-vous des idées de niveau d'avantage/coût/budget pour des niveaux de brique ? Il n'y a aucun urgence sur ce point, mais cela fera partie des nécessités d'équilibrage du gameplay.
Pour vous donner une idée, pour mon test, j'ai prévu de faire payer la baisse du cooldown 2 points, la hauteur améliorée 2 points aussi et le niveau de Saut 1 donne une brique qui permet d'avoir -3 sur son total (en échange de dépense d'endurance, à déterminer). Ce qui veut dire qu'à ce niveau, pas possible d'avoir la hauteur améliorée ET le cooldown amélioré, il faut choisir...
Dernier message par YannK - 14 Mars 2025 à 10:52:07
Cliquez pour afficher le message
Salut à toutes,
je commence à regarder comment implémenter un premier jet de compétences pour le prototype et je m'inspire de celui de Ryzom comme prévu.
Je bosse sur le saut comme sujet de test. L'idée est donc de fabriquer une compétence de «Saut». Celle-ci aura un niveau, en fonction duquel on aura accès à des briques constitutives de plus en plus efficaces (il faudra «acheter» ces briques, hein, comme dans Ryzom, mais ce n'est pas la question là).
Le but est d'ensuite équilibrer les briques qui donnent la capacité (hauteur et cooldown dans notre cas) avec un budget déterminé d'un trait possédé par l'utilisatrice. Ce pourrait être l'endurance dans notre cas (ce qui veut dire qu'on aurait une gestion de ce trait pour les créatures).
Je résume donc, pour le saut on pourrait avoir comme briques qui apportent un effet de compétence :
Et l'avantage octroyé par ces deux briques serait déterminé par un budget défini par une autre brique :
Dans Ryzom, l'assemblage est toujours assez délicat et l'équilibrage demande toujours des arbitrages, ce que je trouve assez sympa pour la joueuse.
Donc mes questions :
- êtes vous ok pour que je parte sur cette base ?
- avez-vous des idées de niveau d'avantage/coût/budget pour des niveaux de brique ? Il n'y a aucun urgence sur ce point, mais cela fera partie des nécessités d'équilibrage du gameplay.
je commence à regarder comment implémenter un premier jet de compétences pour le prototype et je m'inspire de celui de Ryzom comme prévu.
Je bosse sur le saut comme sujet de test. L'idée est donc de fabriquer une compétence de «Saut». Celle-ci aura un niveau, en fonction duquel on aura accès à des briques constitutives de plus en plus efficaces (il faudra «acheter» ces briques, hein, comme dans Ryzom, mais ce n'est pas la question là).
Le but est d'ensuite équilibrer les briques qui donnent la capacité (hauteur et cooldown dans notre cas) avec un budget déterminé d'un trait possédé par l'utilisatrice. Ce pourrait être l'endurance dans notre cas (ce qui veut dire qu'on aurait une gestion de ce trait pour les créatures).
Je résume donc, pour le saut on pourrait avoir comme briques qui apportent un effet de compétence :
- la hauteur qu'on peut sauter
- le cooldown après un saut
Et l'avantage octroyé par ces deux briques serait déterminé par un budget défini par une autre brique :
- l'endurance consommée par le saut
Dans Ryzom, l'assemblage est toujours assez délicat et l'équilibrage demande toujours des arbitrages, ce que je trouve assez sympa pour la joueuse.
Donc mes questions :
- êtes vous ok pour que je parte sur cette base ?
- avez-vous des idées de niveau d'avantage/coût/budget pour des niveaux de brique ? Il n'y a aucun urgence sur ce point, mais cela fera partie des nécessités d'équilibrage du gameplay.
#5
Programmation / SpacetimeDB
Cliquez pour afficher le message
Bonjour,
Comme vous le savez, faire un MMORPG capable de supporter du monde est difficile, très difficile. Récemment je suis sur un projet qui pourrait simplifier l'affaire et qui, malgré ses défauts, vaut sans doute le coup qu'on le regarde d'un peu plus prêt : SpacetimeDB.
Il s'agit d'une projet un peu spécial qui se présente comme une base de données sur-boostée spécialisée dans les MMORPG et autres applications multi-utilisatrices à haute performance, mais qu'à titre personnel je vois plus comme un serveur générique paramétrable qui intègre une base de données. Le principe est assez simple : on écrit des sortes d'extensions pour SpacetimeDB et ça en fait un serveur de jeu complet avec d'excellentes performances et qui est fait pour « scaller » de manière très simple. Il est prévu de pouvoir écrire ces extensions dans plusieurs langages, dont Python, mais à l'heure actuelle seul Rust est supporté pour le serveur.
Bien entendu, afin de communiquer avec le serveur il faut que le client soit compatible. Il y a des des bibliothèques disponibles dans différents langages. À l'heure actuelle, seuls Rust, C# et Typescript sont supportés, mais il est prévu d'ajouter Python, C++ et Lua.
Enfin, il y a un soucis avec la licence. Dans la mesure où la société derrière SpacetimeDB commercialise une offre d'hébergement en infonuagique, elle n'a pas super envie que d'autres entreprises utilisent la liberté du logiciel pour leur faire directement concurrence. De base, SpacetimeDB est donc sous une licence privatrice qui ressemble cependant à une licence libre mais ajoute 2 restrictions : la possibilité de n'avoir qu'une seule instance en production et l'interdiction de s'en servir pour faire une offre en infonuagique. Il est important de noter que la licence change automatiquement 4 ans après la release afin de devenir l'AGPL.
À titre personnel je ne suis pas fan des licences privatrices, mais je peux comprendre le mouvement ici car sur d'autres logiciels libre il y a eu des abus qui ont fait que la société fournissant tout le travail perdait des parts de marchés face à des concurrents peu scrupuleux qui revendaient leur solution moins cher et sans les financer ni contribuer en retour. Ici je trouve que la bascule automatique vers l'AGPL est très appréciable.
Pour en apprendre plus, voici un certain nombre de ressources en anglais :
Comme vous le savez, faire un MMORPG capable de supporter du monde est difficile, très difficile. Récemment je suis sur un projet qui pourrait simplifier l'affaire et qui, malgré ses défauts, vaut sans doute le coup qu'on le regarde d'un peu plus prêt : SpacetimeDB.
Il s'agit d'une projet un peu spécial qui se présente comme une base de données sur-boostée spécialisée dans les MMORPG et autres applications multi-utilisatrices à haute performance, mais qu'à titre personnel je vois plus comme un serveur générique paramétrable qui intègre une base de données. Le principe est assez simple : on écrit des sortes d'extensions pour SpacetimeDB et ça en fait un serveur de jeu complet avec d'excellentes performances et qui est fait pour « scaller » de manière très simple. Il est prévu de pouvoir écrire ces extensions dans plusieurs langages, dont Python, mais à l'heure actuelle seul Rust est supporté pour le serveur.
Bien entendu, afin de communiquer avec le serveur il faut que le client soit compatible. Il y a des des bibliothèques disponibles dans différents langages. À l'heure actuelle, seuls Rust, C# et Typescript sont supportés, mais il est prévu d'ajouter Python, C++ et Lua.
Enfin, il y a un soucis avec la licence. Dans la mesure où la société derrière SpacetimeDB commercialise une offre d'hébergement en infonuagique, elle n'a pas super envie que d'autres entreprises utilisent la liberté du logiciel pour leur faire directement concurrence. De base, SpacetimeDB est donc sous une licence privatrice qui ressemble cependant à une licence libre mais ajoute 2 restrictions : la possibilité de n'avoir qu'une seule instance en production et l'interdiction de s'en servir pour faire une offre en infonuagique. Il est important de noter que la licence change automatiquement 4 ans après la release afin de devenir l'AGPL.
À titre personnel je ne suis pas fan des licences privatrices, mais je peux comprendre le mouvement ici car sur d'autres logiciels libre il y a eu des abus qui ont fait que la société fournissant tout le travail perdait des parts de marchés face à des concurrents peu scrupuleux qui revendaient leur solution moins cher et sans les financer ni contribuer en retour. Ici je trouve que la bascule automatique vers l'AGPL est très appréciable.
Pour en apprendre plus, voici un certain nombre de ressources en anglais :
Dernier message par Zatalyz - 11 Décembre 2024 à 12:42:36
Cliquez pour afficher le message
C'est corrigé !!!! Alleluiaa !!!!
Dernier message par Zatalyz - 10 Décembre 2024 à 21:09:02
Cliquez pour afficher le message
Comme vous avez pu le constater depuis la dernière mise à jour, les numérotations des titres sur le wiki sont des plus fantaisistes. Cela n'arrive que si on est connectée. J'ai mis du temps à identifier le problème, car tout marche tant qu'on n'est pas co ; mais une fois co, une balise "div" est ajouté autour de chaque titre, ce qui amène des erreurs dans la façon dont le css est interprété. Car ces numéros sont ajoutés via le css...
J'ai cherché longuement d'où venait cette div en trop et la réponse est : c'est une modification dans le code même de dokuwiki. La réponse est ici :https://github.com/dokuwiki/dokuwiki/pull/3957.
Je ne comprends pas trop le détail du "pourquoi", par contre ça me pose souci pour le css, parce qu'il faut que je prévois la version "pas connectée" et la version "connectée". Et ce n'est vraiment pas trivial, mais le css permet des choses fabuleuses à présent. Et maintenant que je sais que cette div n'est pas un bug ou un souci quelconque, je vais trouver comment faire avec. Ou arrêter d'essayer de numéroter les titres. On va voir
J'ai cherché longuement d'où venait cette div en trop et la réponse est : c'est une modification dans le code même de dokuwiki. La réponse est ici :https://github.com/dokuwiki/dokuwiki/pull/3957.
Je ne comprends pas trop le détail du "pourquoi", par contre ça me pose souci pour le css, parce qu'il faut que je prévois la version "pas connectée" et la version "connectée". Et ce n'est vraiment pas trivial, mais le css permet des choses fabuleuses à présent. Et maintenant que je sais que cette div n'est pas un bug ou un souci quelconque, je vais trouver comment faire avec. Ou arrêter d'essayer de numéroter les titres. On va voir
Dernier message par YannK - 05 Décembre 2024 à 21:39:50
Cliquez pour afficher le message
Personnellement je serais pour:
- les infos minimum nécessaires pour mettre en place les outils (donc ce que tu as listé comme obligatoire). Si jamais le reste s'avérait utile à l'avenir, ça pourra être ajouté. Pas la peine de s'ouvrir une porte inutile et d'ajouter du taf genre RGPD en plus si ce n'est pas utile.
- pour les groupes au sein de khaganat, je verrais assez bien de décliner en fonction des accès aux outils, par exemple :
- membre du collège associatif
- membre de l'association
- contributrice simple : accès sans privilèges à tous les outils (ou les plus bas accordés à chaque fois)
- contributrice développeuse : accès avec privilèges DEV sur la forge
- contributrice mainteneuse : accès avec privilèges Maintainer sur la forge
- contributrice éditrice : accès avec privilèges avancés sur les wikis
- contributrice adminsys : accès avec privilèges avancés sur les wikis adminsys
- contributrice modératrice : accès avec privilèges avancés sur le forum
Dernier message par Zatalyz - 05 Décembre 2024 à 21:16:52
Cliquez pour afficher le message
CitationEn y réfléchissant, et après visionnage de la vidéo que tu as liée, je me demande si OAuth est vraiment adapté à ce schéma.
Tu as raison, il faut peut-être que je veille à ça. Après, Oauth, OpenID, SAML... ça se vaut (même si ça ne demande pas les mêmes choses). Et malheureusement je ne saurais quel système est "bon" qu'une fois que j'aurais testé... Je sens que je vais m'amuser.
Après, attention, y'a une différence entre le backend, où je suis pour le moment (avec très peu de choix, quand on élimine certaines techno...) et le frontend. LemonLDAP, FreeIPA, Kadnim etc c'est du frontend et à ce stade "je m'en fous", je ne suis que sur LDAP brut... Et vu les limitations de LLDAP et ce que Shepeng pointe, je vais devoir retourner à OpenLDAP. Et bon c'était pas pour partir dans une discussion de tech, je demandais juste des trucs basiques comme "vous voulez quoi comme groupes et arborescence" et autre "et mettre votre bio dans le profil ?"
CitationEst-ce que le périmètre s'applique uniquement au services web ou aussi au machines (container LXC, machines virtuelles, Hyperviseurs) ?
C'est du LDAP. Donc, ça s'interface avec ce qu'on veut, pour peu que le truc en question supporte le protocole LDAP. Et si ça ne supporte pas LDAP mais qu'on veut l'interfacer, ben on fera le lien avec une autre techno. Le gros intérêt de LDAP c'est que c'est un truc assez primaire qui sert facilement de liant à "plein de trucs". Mais je n'ai pas prévu qu'on se connecte en tant que sysadmin aux serveurs avec ça, là je préfère séparer un peu, et ssh me va très bien. Proxmox... on verra.
Maintenant concernant les besoins, ils sont déjà décrit dans le wikhan, et à mon niveau si j'arrive à avoir le forum et les wikis avec un seul coin pour les identifiants, je serais déjà contente. L'objectif c'est de mettre en place le système, puis d'y connecter petit à petit le maximum de chose. Sachant que certains services web demanderont peut-être du développement.
Dernier message par shepeng - 05 Décembre 2024 à 13:59:59
Cliquez pour afficher le message
En y réfléchissant, et après visionnage de la vidéo que tu as liée, je me demande si OAuth est vraiment adapté à ce schéma.
D'ailleurs sur la doc de lemonLDAP OAuth n'est pas cité.
Du coup : regarder plutôt SAML ou OpenID Connect.
D'ailleurs sur la doc de lemonLDAP OAuth n'est pas cité.
Du coup : regarder plutôt SAML ou OpenID Connect.
