Sujets

J'ai ouvert un ticket pour savoir ce qu'on allait mettre dans les crédits du jeu : https://port.numenaute.org/Khaganat-games/Khanat/issues/9

Godot fournit déjà une liste de toutes les contributrices à son code, les systèmes tierces et leurs licences, ainsi qu'une liste des donatrices. Tout ça est bien ordonné par catégorie etc. J'ai mis les liens vers la documentation dans le ticket.

La question est donc de savoir comment on procède. Personnellement j'ai beaucoup aimé la longue liste de crédits de Tiny glade qui recense aussi bien les bibliothèques tierces que les outils, les personnes etc. (et c'est très long son défilement dans le jeu, ce qui peut donner lieu à un Easter egg à la fin )

Des avis sur la question avant que je n'en fasse quà ma tête ? 

Je ne me souviens pas qu'on en ait particulièrement parlé, sauf à dire qu'il n'était pas forcément dans no moyens techniques d'alors de proposer les deux vues comme Ryzom. Mais ayant vu quelques jeux où on est à la première personne, je trouve que l'immersion est meilleure. Et que ça pourrait donc bien convenir aux joueuses, vu que Khanat est un jeu d'ambiance. Cela permettrait aussi de mieux voir les personnages des autres joueuses vu que la caméra serait plus proche d'elles.

D'un autre côté, la troisième personne permet de contempler son eprsonnage en permanence

Je suis parti sur l'idée qu'on serait à la troisième personne pour IRIS et ça semblait faire consensus, mais je préfère qu'on le valide formellement avant d'attaquer les scènes 3D.

Toujours dans le cadre de khanatiser les choses, on aurait besoin de noms pour les différents services proposés par le système serveur:

• Le gestionnaire de comptes (qui permet de se connecter) - Account sur ab_extra
• Le gestionnaire d'un monde - World sur ab_extra
• Le gestionnaire de joueuses - Player sur ab_extra
• Le gestionnaire de position - Galileo sur ab_extra
• Le gestionnaire de communication - Talk sur ab_extra
• Le gestionnaire de vue des logs pour les admins - View sur ab_extra

Je laisserai Alea détailler les fonctions s'il y a des questions.

Salut,
testant pas mal de jeux multijoueurs (de type MMO) où on peut construire des éléments dans l'espace commun, je me demandais comment nous allions gérer ces éléments. Je ne parle pas des endroits qui pourront être instanciés, simples à envisager d'un point de vue gameplay, mais des espaces aménagés/créés par des joueuses dans les zones non instanciées. Comment va-t-on gérer cette emprise sur le long terme ?

Certains jeux proposent de devoir "entretenir" le lieu par un apport régulier de matériaux quelconques à un point dédié, dont la quantité et la qualité augmentent avec l'importance de l'emprise et des moyens mis en œuvre par le groupe. Ça pourrait bien marcher pour le kagnivo, qui doit rendre compte de son exploitation, tout en obligeant à une certaine "productivité" qui pourrait être délicate à équilibrer si on veut un jeu non extractiviste.

Et, au-delà, si on envisage par exemple des nomades avec tentes, comment ça pourrait se régler ? Avec un système similaire ? Pourrait-on envisager qu'une joueuse nomade sans organisation doive se connecter tous les XXX pour "réalimenter son feu de camp" pour ne pas voir son camp disparaître ? N'est-ce pas trop contraignant pour les casuals ? On pourrait imaginer que les éléments déployés qui devraient être enlevés du monde pour cause de non-connexion seraient rendus sous une forme ou l'autre à la joueuse pour ne pas trop pénaliser. Par ailleurs, les modératrices pourraient bien sûr déplacer/détruire des aménagements gênants (en redonnant - ou pas - les matériaux/éléments dépoppés à la joueuse incriminée)

L'idée est bien sûr d'éviter que tout l'espace soit encombré, ou de bons emplacements trop facilement squattés tout en offrant aux joueuse l'occasion de modifier le monde... J'atermoie pas mal dans ma tête entre les solutions qui m'apparaissent, sans jamais être convaincu totalement par l'une ou l'autre. Avez-vous des idées, des envies, sur cette question ?

Sur la forge, dans le groupe Khanat, on va créer un dépôt où tout sera regroupé : code serveur, client, utilitaires etc.
Il faudrait lui donner un nom, ça pourrait être « Khanat » mais je me suis dit qu'il pourrait y avoir d'autres idées. Donc à vos plumes, si vous avez des idées plus percutantes 

Le dépôt sera sur la forge dans l'organisation « Khanat » : https://port.numenaute.org/Khanat

https://mesh2motion.org/ est une alternative à https://www.mixamo.com que l'ont pourrait héberger pour permettre aux joueuses et développeuses de voir aisément la correspondance entre une désignation et une animation. Cela aiderait par exemple les joueuses à retrouver les emotes ou les animatrices 3D à voir quelles animations manquent pour certaines créatures...

(message modifié, merci François)

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.

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.

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.

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 -> sujet clos car changement de forge depuis Gitlab -> Forgejo
• Architecture des services
• Exécutables et partages structurels -> fusionné avec le sujet précédent
• 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.

Je n'ai pas encore vraiment d'idée pour la coiffure du premier personnage, mais j'ai plein de propositions d'inspirations. 



Faites votre choix

Après une bataille homérique contre les générateurs d'images, j'ai enfin trouvé un moteur avec lequel j'arrive à quelque chose de correct, et qui me laisse mettre le produit de mes prompts sous la licence que je souhaite. J'ai donc cherché à avoir des idées pour le cmuzda du Dispensaire.

J'ai tenté de mixer Art déco, Art Nouveau et Franck Lloyd Wright avec un zeste de solarpunk, le tout sous terre. J'ai récupéré énormément d'images, avec beaucoup d'hallucinations (des erreurs visuelles plus ou moins flagrantes pour nous humains), mais je pense que j'ai ainsi une direction visuelle assez claire de ce vers quoi je souhaite aller.

Je vous partage donc une capture d'écran de mon tableau d'inspiration. Il est réalisé avec le logiciel gratuit, mais pas libre, PureRef. Je peux mettre le fichier sur le Kloud, je ne l'ai pas fait par défaut car il est très gros (plusieurs dizaines de Mo).



Comme pour le be'ibi, mon idée est de travailler essentiellement avec les images principales (en haut du panneau) comme base que je combinerai au mieux, en intégrant les détails dessous pour certains éléments et/ou détails.

Sans veto sous une semaine, j'avancerai à partir de ça pour les éléments 3D de départ. n'hésitez pas si vous avez des remarques/précisions/questions

Cela fait longtemps qu'on n'en a pas parlé, mais on a prévu un petit robot d'assistance pour les ra qui fonctionne selon l'effet Tsupa'a Galton - Cfiden Mojig : le be'i bi (car c'est la 8e déclinaison de ce type de robot qui transporte les objets).

J'ai enfin des visuels à vous proposer pour valider leur aspect. Ils sont en forme de cylindre étiré et bombé, avec des ouvertures latérales qui s'écartent et d'éventuelles trappes ailleurs sur le corps. Ils peuvent apporter de l'éclairage, porter des sacs grâce à des crochets escamotables...

La plus grosse image est celle qui est la plus proche en ce qui concerne l'aspect général et les autres sont des déclinaisons pour y puiser des idées pour les détails et zones arrières, voire des variantes pour certaines zones. Je pense qu'on pourra le customiser un peu, ne serait-ce qu'au niveau de la couleur.



Sans veto formel d'ici une semaine, je considérerai ce concept comme valide et je passerai à la phase suivante d'ajout sur l'UM1 puis de modélisation. Si vous avez des idées/remarques/questions, les avis sont les bienvenus

En discutant avec Zatalyz de l'architecture des données dans le jeu, on a repensé au système de compétences, qui doit être unifié afin de permettre d'être utilisé pour toutes les entités en jeu, car toutes ont la capacité de devenir ra. Techniquement parlant, le but est de n'avoir qu'un système qui gère les capacités des différentes entités (via des fichiers XML avec une notion d'héritage comme dans OpenNeL).

Le système se base donc sur des Khompétences par exemple la danse. Dans celles-ci, on acquiert des Khapacités composées de Khases. Dans notre exemple de danse, les Khapacités seraient le type de danse  : solo, en groupe, à deux. Les Khases seraient la Durée, l'Intensité, le Type de pas (par ex. les pas de la spadzura). On combine les Khases en fonction de la Khapacité qu'on veut réaliser. Par exemple : Faire une Spadzura à deux de façon Intense et d'une faible Durée. Il y aura des notions de bonus/malus avec les Khases pour équilibrer la création de la Khapacité.

Pour l'acquisition de ces Khompétences, chaque Khase a un coût en Point d'Unité Mémorielle (P.U.M), en sachant que chaque ra est dotée d'un maximum de PUM (à déterminer). Ainsi certaines Khases peuvent coûter 0 PUM (permettant de les attribuer de façon invisible, genre pouvoir bouger), et certaines valoir très cher (Ajouter des effets de particule quand on danse : le K'Deed effect). Le total des PUM dépensés dans une Khompétence permettra d'estimer le profil de la ra.

Le fait d'acquérir une Khase sera proposée à la ra selon plusieurs modalités (en observant, en s'entraînant...). Il pourrait y avoir une préférence de la joueuse qui accepte toutes les nouvelles Khases tant qu'elle n'a pas atteint son budget (ou pas), mais dès lors qu'un arbitrage devra être fait, la joueuse validera ou non l'acquisition de la Khase.

Le Monde des Rêves pourrait être un endroit où acquérir ou perdre des Khases de façon... onirique. Et les Brumes seraient l'endroit où l'Oubli pourrait s'imposer violemment avec la perte de Khases aléatoires. D'où l'expression ratique « Celle-là, depuis qu'elle est passé par les Brumes, il lui manque des Khases. »


PS : La terminologie en Kh est une touche personnelle du chef.

Bonjour à toutes,
en travaillant sur les modèles architecturaux pour le Khanat, je me suis rendu compte que je manquais de concepts pour penser certains espaces de transition.  Sur terre, nous avons le dedans et le dehors, avec des zones intermédiaires qui permettent de se sentir dans l'un ou l'autre. Mais dans le Khanat, nous ne sommes pas dans un système binaire : il y a du dedans et du dehors dans culno (qu'on pourrait désigner comme le Dehors) et il y en a aussi possiblement dans ratmidju (qui serait donc le pendant du Dehors, le Dedans), et ce ne sont pas les mêmes. Il faudrait qu'on pense un peu ces concepts, qu'on les nomme (avec des termes courts de préférence car ils sont certainement usuels) pour que je tente de les traduire en propositions architecturales.

Vous avez des idées, des remarques, des propositions, des critiques ?

Faisant suite à l'idée de Zatalyz que les ra aient une technologie basée sur le mycélium (voir ce sujet), je me suis dit que ça pourrait être la base de leur plasturgie, basée sur les champignons et pas les dérivés pétroliers comme nous. En outre, cela permettrait d'avoir un matériau très zbasu qui ne soit pas minéral sans être du bois (je pense en particulier au mobilier). Et comme j'aime bien la bakélite, je réfléchis à en faire un truc qui pourrait s'en inspirer (cela pourrait servir des formes rétro-futuristes).

Et donc, avant de faire une fiche dans l'UM1, je me disais qu'il faudrait lui trouver un nom à ce truc, plus sympa que plastic ou bakélite (qui est une marque, en plus).

j'ai trouvé ces termes, mais ils ne m'inspirent pas trop :

- slasi: plastique
- mledi: champignon/moisissure

Donc avez-vous des idées ?

Je viens de me rendre compte en allant sur l'UM1 qu'il n'y avait pas les termes en langue sacrée pour le code de l'honneur. Ce serait bien qu'on ait au moins les piliers qui soit définis vu que ce sont des termes qui pourraient être visibles à pas mal d'endroits.

Il nous faudrait donc définir :

• Entente
• Égalité
• Responsabilité
• Respect

Des idées, propositions ?