Messages

- 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...

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 :

• 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.

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 ?