Messages

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
  
  

J'ai certainement raté des outils/niveaux d'accès, mais vous voyez l'idée : créer une hiérarchie par outil et créer un rôle distinct pour chacun de ces rôles au sein de Khaganat. Ça va demander qu'on liste les outils et les différents niveaux, mais l'alternative serait qu'il y ait juste des échelons globaux et que le fait de grimper en responsabilité sur un outil donne accès à un autre où n'est pas forcément intéressées/compétente, et ça me semble bancal comme solution.

Vous avez demandé la légion ? Ne quittez pas ... https://asso.framasoft.org/pic/gallery#yb2YLw1S/myleL8Zi.png,eQulfhNE/78DxipdY.png,0jHMq7Kg/ulzhWFZR.png,usYal77o/xJ7hLZtu.png,haKUpEOb/0X7FoKZI.png,fyj8WyWo/6BALPTKr.png,AVlvrzjE/3lFcS2jO.png,IRByS4QB/LZue4NSi.png,vnQpaKnJ/3JL4ceKA.png,TOP89Rje/GssgFX5E.png,3nhIr4H0/a9j51NIQ.png,LnQWf6ps/3tzZxbtI.png

Quetzara en approche ? https://asso.framasoft.org/pic/kPubScGX/ia3cNpUg.png

Et hop, une petite visite au jardin des plantes ? : https://asso.framasoft.org/pic/gallery#FWItGLyA/tStahn4l.png,xEZgPI3c/tTACSWEL.png,ZXILuH7s/Hg6ftemg.png,xjmedmWa/cFw3Wfh6.png,4hVTzMCk/aXgziE17.png,7TzMzJsK/qCtQsVq8.png,ejXrjgBQ/L7qvtK7K.png,3y0f45un/q6uXvNB0.png,ekRIYP5a/oRtJISSI.png,WcWQ3evY/lIj7pMHG.png,b6X9IAZm/8hLsznR6.png,IR9HqtUn/nYLhCMUS.png,Qdop7C01/acsSamgO.png,5U5DCbsA/gxsBGr4D.png,LcjeMZhm/AxoZLO1V.png,NvkMZznu/c8ii5Pjm.png,lcJQMK6K/GK7jt1ei.png

Je pense qu'on peut penser en terme de cohérence pour les organisations : une organisation « MMORPG Khanat », une autre pour ce qui touche au web « Khaganat web », en gros créer une organisation pour chacun des sous-groupes de Khaganat sur le Gitlab :https://git.khaganat.net/khaganat

Bon, on va s'y (re)mettre, qu'en dites-vous ? Mais il faut trouver un nom pour le dépôt avant tout, et je commence à sécher après en avoir recréé plusieurs à la suite. Je vais archiver Khanat client et je me disais qu'on devrait lui donner un nom comprenant « 3D »  pour spécifier que ce sera celui du client 3D. Ça ferait « Client 3D Khanat ». Mais je trouve ça un peu... plat.

Ça vous irait ? Vous avez d'autres idées/suggestions ?

Vous avez trois voix chacune, merci d'indiquer vos trois directions possibles préférées.

[Waterways]

Waterways

Système de génération de cours d'eau basé sur des courbes de bézier.

Dépôt : https://github.com/Arnklit/Waterways

Présentation vidéo : https://www.youtube.com/watch?v=cQX50j8fCa8

[Proton Scatter]

Proton Scatter

Dépôt : Système d'automatisation pour le placement procédural d'une grande quantité d'assets. Compatible avec Terrain 3D.

Dépôt : https://github.com/HungryProton/scatter

Présentation vidéo (par Game From Scratch) : https://www.youtube.com/watch?v=MB3Vz6JFAOA

[Terrain 3D]

Terrain 3D

Système de terrain 3D en C++

Dépôt : https://github.com/outobugi/Terrain3D

Présentation vidéo : https://www.youtube.com/watch?v=Aj9vWIEaFXg

Je propose qu'on se note ici les plugins qui pourraient être intéressants à utiliser pour Godot. Selon leur maturité et adéquation au projet lorsque le besoin s'en fera sentir, on verra à les ajouter. Entre-temps, que les testeuses n'hésitent pas à faire des retours.

Super boulot, Alea, merci beaucoup d'avoir entrepris de mettre tout ça au clair. Je suis trop nul en UML pour avoir osé m'y lancer.

J'adhère globalement à ta proposition, qui est similaire à ce que Nevrax avait fait pour OpenNeL et la résilience de ce modèle n'est plus à prouver je pense.

Est-ce que tu pourrais détailler ce que tu mets dans « Donnée actions » ? Je ne suis pas certain d'en voir les contours : on est ok que c'est le serveur qui valide une action et donc ses répercussions sur le monde/les autres joueuses, mais est-ce que tu y mets plus que ça ? Je ne vois pas la raison qui te pousse à y mettre de la persistance, même si elle n'est pas aussi longue que pour les « Données décor ». Du log me semble intéressant, pour monitorer, est-ce que c'est ça que tu ferais persistant ?

Je sépare la question API de celle des bots :

• avoir une API claire me semble intéressant pour permettre des clients différents de celui 3D que nous proposerons par défaut. Il faudrait y intégrer une validation quelconque (token individuel par modèle de client ?) pour permettre d'échanger avec le serveur en toute sécurité. Ce serait valable pour notre client, afin de se garantir contre des modifs dans le code qui permettrait des exploits. Et on pourrait en effet se servir de ça pour faire des tests lors du développement (simulation d'actions en masse, etc.), je trouve ça vraiment super comme idée.
• Sur les bots, Zatalyz a proposé déjà pas mal de chose sur le wikhan : https://khaganat.net/wikhan/fr:reroll et on peut en parler plus longuement sur le sujet qu'elle a initié là : Multicompte, bot et compagnie (oui oui, ce sujet a plus de dix ans )

À partir de tout ça, il y a pour moi quelques questions stratégiques à définir avant qu'on puisse effectivement se mettre au boulot :

• est-ce qu'on fait un proxy  de connexion avec agrégation (c'est le choix d'OpenNeL) ?, ce qui implique une plus grande latence, comme tu dis, ainsi qu'une sérialisation des données afin d'optimiser les échanges. Donc plus de complexité de transfert des infos. J'avoue que je préfère cette approche (y compris par rapport à du multicast) car on réduit la surface d'attaque des serveurs, ce qui semble devenir un souci de plus en plus grand avec le temps.
• la question de la persistance des données longues, qui seront streamées depuis et vers le disque dur, qui sera un goulot d'étranglement selon le volume qu'on décide de valider régulièrement (oui, Star Citizen je pense à toi ). 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.
• la partie « Discussion » devra être pensée de façon plus fine, mais ce n'est pas urgent. on a dit qu'on allait se baser sur XMPP, mais il s'y greffe la question de la modération, de l'accès aux messages privés et de l'archivage, qui sont des questions délicates. Il faut donc y intégrer un point de persistance.
• Enfin, comme on est en France, il serait bon de se mettre quelque part les questions RGPD afin qu'on ne galère pas par la suite. Je me disais qu'on pourrait l'aborder de la même façon que Marien, de Framasoft, qui propose une solution qui pourrait s'implémenter au fur et à mesure : https://marienfressinaud.fr/gdpr-txt.html

Je pense qu'on pourra compléter au fur et à mesure la détermination des différents points mais on a là une belle base pour entamer le boulot serveur, merci beaucoup Alea

AH oui, c'est vrai qu'on a weblate aussi. Il faudrait que je regarde quelles serait la solution la plus simple pour nous pour en récupérer les traductions et y ajouter les nouveaux termes. Tu as regardé un peu comment ça marche en interne ?

Je propose qu'on échange ici sur la façon dont on met les choses en place sur la forge.

Nous allons travailler sur le client 3D Godot depuis le groupe MMORPG Khanat comme précédemment. Après un peu de ménage et d'archivage, on trouve en son sein :

• Khanat Guide de Développement qui définit les bonnes pratiques et qui doit servir, à terme, à alimenter des pages du wikhan, peut-être à générer un pdf, un epub etc. afin d'en faciliter la consultation par les contributrices.

Un ensemble de dépôt qui ne seront alimentés que via des Merge Request afin d'avoir des Changelogs propres et des commits apportant un lot de fonctionnalités répondant à un Ticket :

• Khanat client qui est le dépôt principal pour le client
• Khanat client 3D assets, qui pourrait aussi recevoir du contenu via un pipeline automatique depuis Khanat Client 3d Assets Sourcefiles
• Khanat client 3D textures library

Le dépôt suivant pourrait aussi n'être rempli que via des Merge Request, si un pipeline alimente automatiquement ensuite le dépôt Khanat client 3D assets. Il pourrait aussi être alimenté via un plugin Blender dédié (du type Khanat tools, en cours de conception) afin de garantir un contrôle qualité :

• Khanat Client 3d Assets Sourcefiles

Enfin, ces deux dépôts servent à rendre accessibles des éléments pouvant alimenter les différents travaux, sans qu'un fonctionnement précis pour chacun ait été décidé :

• Illustrations and concepts
• Khanat alphabets

Et il reste encore :

• Khanat server docker que je me propose d'archiver car plus en rapport avec le développement actuel.

Enfin, il y a le milestone 0.1 que je me propose d'effacer et d'en réorganiser les tickets pour correspondre à ce qu'on peut faire avec Godot 4 en l'état.

Qu'en pensez-vous ?

Une fois qu'on sera un peu fixées, je reprendrai la page Contribuer : les dépôts du projet Khaganat du Wikhan.

[Programmation :]

Bonjour à toutes, je propose qu'on se serve de ce fil pour organiser le travail en asynchrone pour le client Khanat développé sous Godot.

Le lien vers le document de Game Design (non achevé) : https://khaganat.net/wikhan/fr:gamedesign:khanat:start

Quelques liens vers des sujets toujours valides en 2023 (a priori).


Programmation :

• Organisation des dépôts au sein du groupe MMORPG Khanat
• Architecture des services
• Exécutables et partages structurels
• Godot et réseau

Gameplay

• Khompétences, Khapacités et KhasesSignifier le HRP
• Plateforme ou non
• Intégrer le vol en jeu ?
• XMPP en jeu et au-delà ?
• (télé)(konta?)pathie, silence et rêve dans la communication ra

Pipelines

• Pipeline pour les animations

Graphisme

• Style architectural pour la zone Hors les Brumes
• Cmuzda du Dispensaire
• Cékoidon ce matériau ?

Pour l'instant, nous avons sur le Gitlab un sous-groupe de Khaganat qui est dédié à tout ce qui a trait au jeu à venir : MMORPG Khanat.

Je pense qu'il serait bon qu'on y crée encore un sous-groupe, tu type « Godot Khanat » où nous mettrions tous les projets qui généreront les exécutables tels que proposés dans Exécutables et partages structurels. Cela permettra d'avoir des paramètres de groupe pour les CI, des accès globaux pour les développeuses etc.



Je propose de le mettre en place avec un dépôt pour tester les fonctionnalités de base nécessaires dans la CI pour la gestion des changelog tel que je l'ai envisagé sur le dépôt Bareto. Cela fera partie des fonctionnalités de base pour nos dépôts. Une fois cela fait, j'effacerai mes tests et je mettrai en place le premier dépôt, pour le client 3D, faisant encore une fois référence au schéma proposé. Si c'est possible pour notre Gitlab, je créerai un template de dépôt. Dans le cas contraire, je ferai un dépôt exemple pour se simplifier la tâche à l'avenir. On verra également avec les développeuses si nous commençons le dépôt « Khanat Core » dès maintenant ou pas.

Je verrai aussi comment avoir une gestion pratique des tickets et une fois tout cela testé et validé, je compléterai le guide de développement pour indiquer la marche à suivre pour contribuer.

Sans veto dans la semaine qui vient, je m'attaquerai à ces tâches.

pour les dimensions il n'existe que "--ar 3:2" et "--ar: 2:3" pour le moment