Aller au menu du forum Aller au contenu du forum Aller à la recherche dans le forum
Logo Khaganat
Menu principal
Menu

Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.

Voir les contributions Menu

Sujets - Zatalyz

Cliquez pour afficher le message
Salut à toutes !

Ça a commencé en blague sur le Kom sauf qu'en fait ça m'a fait réfléchir...
Citation de: ZatalyzHa un spam qui réveille mon instinct troll... Je vous partage, ça vaut son pesant de cacahuète. "J'ai récemment découvert avec enthousiasme khaganat.net et j'ai été impressionné par la valeur ajoutée que votre contenu offre aux passionnés de voyages, une perspective que j'apprécie particulièrement."
Voyager dans le Khanat, c'est vrai, c'est cool.
La personne est donc représentante d'un truc de... consignes à bagages. Et donc elle a envie qu'on "créer un article adapté et raffiné pour votre blog".
je peux lui demander surtout s'ils ont prévu d'installer des consignes à bagages à Natca ? parce que ça ne sert à rien de parler d'un service qu'on ne peux pas utiliser :D
On a une gare toute adaptée, on loue l'emplacement pas cher :-°
* Zatalyz va se faire financer un jeu par une boite de consigne à bagage, tiens ^^
Je ne pousse pas plus parce que le pire c'est que bien mené, ça pourrait marcher... mais pas sûr qu'on veuille des marques en jeu (des vraies).
Citation de: K'DeedIl y a Tepsne pour ça :p

C'est vrai. Y'a Tepsne.

Pour celles qui n'ont pas suivi, on prévoit dans l'idéal trois serveurs de jeu : Khanat, le "vrai" monde ; Panka, le mode "hyper safe" avec modo h24 et pas de contenu douteux pour que les enfants puissent jouer, et Tepsne, le "cauchemar", où tester tout et n'importe quoi et balancer les trolls. Nos efforts sont surtout sur Khanat, l'objectif étant d'avoir le serveur sur lequel on a envie de se ballader.

Tepsne a toujours été l'endroit où on pourrait se permettre des options à la con ; accessoirement c'est aussi un serveur pour tester des fonctionnalités avant de les inclure dans le monde. Du pay-to-win là ? Ouais. De la modération au bazooka mais que quand ça nous chante ? ouais aussi. À l'inverse, le serveur de Khanat est prévu pour être un espace "propre" : pas trop de bug, un financement uniquement basé sur la motivation, une vraie éthique dans le gamedesign pour éviter des comportements délétères. 

J'en viens à la question du financement de façon plus large...

Comme vous le savez j'ai quelques plans pour à un moment avoir des sous pour payer du monde à développer et créer concrètement notre jeu. Sans salariés, on n'arrive pas à fournir assez de temps de travail pour avoir au moins notre client/serveur de base. Le modèle économique initial de Khaganat dépend d'un serveur fonctionnel ; avant cette étape il faut trouver d'autres plans. J'ai donc prévu d'aller chercher des financements le jour où je libère un peu de temps et d'énergie (ou accompagner quiconque a envie de le faire). Pas tout de suite : un jour.

J'ai abordé ça ailleurs, je ne vais pas y revenir (pas ici en tout cas !) mais la "blague" citée plus haut m'a fait réfléchir à un mode de financement que j'avais totalement exclu jusque là. Mettre de la pub en jeu.

Attendez, ne fuyez pas si vite ! Non, ne me lancez pas de cailloux !!!  :bow:

Il n'y a qu'un seul endroit où cette solution serait acceptable, et c'est évidement Tepsne. Non, pas de pub pour des marques réelles sur Khanat ou même Panka, ça c'est certain. Mais ces boites sans aucune éthique qui balancent de l'argent à tout va dans le marketing le plus foireux, si on leur vend un espace de pub dans un "MMORPG révolutionnaire basé sur la blockchain et tirant partie des dernières nouveautés de l'IA", et ben... elles pourraient nous lâcher du pognon alors même qu'à la base elles ne sont pas dans le secteur du jeu vidéo, et alors même que le jeu n'est pas fait. Je ne sais pas si cette voie mérite d'être creusée, et y'a un côté un peu triche de vendre de l'espace publicitaire sur un endroit où on ne va pas vraiment aller (et s'il faut des bots pour cliquer et leur faire croire que ça marche, ça me va), mais j'avoue que je n'ai pas d'éthique avec les trucs sans éthique et le temps qu'ils se rendent compte que ça n'a aucun impact... s'ils s'en rendent compte... on aura notre jeu.

À ce stade la question est donc vraiment sur l'éthique, qu'est-ce qu'on peut accepter, quelle limite ? Avez-vous d'autres idées douteuses dans ce genre ?  :))
Cliquez pour afficher le message
On brûle Gitlab, c'est décidé ! En espérant que Forgejo ne m'inspirera pas les mêmes sentiments, mais le projet étant réellement communautaire, j'ai plus d'espoir.

On a beaucoup, beaucoup de dépôts. Et ça va être l'occasion de faire du ménage. C'est obligé, d'ailleurs, parce que la méthode actuelle qu'on a trouvé demande de transférer chaque dépôt un par un.

Votre mission si vous l'acceptez :
- lister les dépôts à transférer tel quel (avec issues et tout). D'ailleurs si y'a plus que les issues et le dépôt (genre CI ou je ne sais quoi) faut le noter.
- lister les dépôts qui peuvent disparaître dans les Brumes.

Une fois ça fait, si tout le monde est d'accord :
- On détruira les dépôts des Brumes (il y a une raison que j'explique ensuite)
- On transfère les dépôts qui doivent l'être, et ensuite, on détruit la version sur Gitlab (j'ai dit : tout brûler !

Et là... On verra ce qui reste comme projets, sur lesquels on fera potentiellement une seconde passe. C'est pour ça que je veux détruire au fur et à mesure, cela permettra de faire du vide et voir où on en est.

J'espère très fortement que tout cela mènera à un moment à ce qu'on aie plus qu'une dizaine de projets "persos", et donc très peu de gens à contacter pour leur dire "décide ce que tu fais de ton dépot, transfert ou autre, mais nous on doit fermer Gitlab". Là c'est compliqué de savoir.

Les utilisatrices devront se recréer un compte sur Forgejo, parce que flemme de chercher le détails de comment transférer.
12 Septembre 2023 à 09:54:59
Cliquez pour afficher le message
J'ai un questionnement concernant le renouvellement des noms de domaine (Khaganat comme Numenaute)... C'est semi-technique, parce qu'il s'agit avant tout de gestion et de sous.

Donc : actuellement nos noms de domaines sont chez Gandi, qui a été racheté par des gens qui veulent faire des sous sans en dépenser. Donc augmentation des prix, dégradation du service.

Nos dates de renouvellement approchent. L'hébergement de nos mails ne sera pas un souci mais y'a la question de "où on met les noms de domaine". Or, on a fini par trouver comment faire pour qu'il y ait un proprio du nom de domaine (l'asso pour Khaganat, moi sur Numenaute) mais que tous les sysadmins concernés puissent, depuis leur propre compte, gérer les détails. Dont la modification des zones DNS, ce qu'on fait souvent. C'est assez propre, comme façon de faire ; dans le cas de Khaganat, le collège garde la gestion du nom de domaine, et on peut mettre à jour qui a les accès sans filer les codes pour ce compte principal.

J'avais envisagé de juste passer à un autre gestionnaire de nom de domaine, sauf que cette logique (déléguer des pouvoirs à des comptes secondaires) ne semble pas présente chez tout le monde. Bon, en même temps, j'ai mis quelques années à la trouver chez Gandi. Mais, de ce que je vois, il n'y a rien de tel sur OVH ou Bookmyname. Ce qui me semble un peu fou...

Il y a donc deux questions.

La première destinée aux personnes ayant un profil "tech", qui gèrent des noms de domaine ici et là : connaissez-vous d'autres fournisseurs où on peut donner accès à plusieurs comptes pour la gestion des DNS d'un nom de domaine ?

La seconde destinée aux choix à faire donc toute personne dans l'asso et en particulier le Collège : est-ce qu'on préfère payer très cher mais déléguer la gestion DNS par comptes, ou est-ce qu'on revient à un truc plus basique où les identifiants du compte de gestion sont partagés par tous les sysadmins ?

Pour info :
- khaganat.net a régulièrement augmenté :
  - 14,40€ à la création,
  - 18€ en 2017
  - 22,44€ en 2023
  - 29,99€ prévu pour 2024 (j'espère TTC) en 2024, et à ce prix, il n'y aura plus le mail.
- numenaute.org :
  - 19,46 € en 2022 (et un euro de moins l'année précédente)
  - 23,99 € prévu en 2024 (idem sans mail).

Et ça ne va pas s'améliorer. À bas prix (chez bookmyname par exemple), les .net et .org sont à 12€ (enfin quelques centimes en dessous)...

J'ai besoin de votre avis pour savoir "quoi" faire, et j'en ai besoin un peu rapidement à cause de Numenaute ;)
09 Septembre 2023 à 20:32:15
Cliquez pour afficher le message
Bonjour à toutes et tous,

Je me questionne un peu sur "où" est-ce le mieux de mettre la documentation technique concernant des aspects de sysadmin. Les questions du genre comment installer Nextcloud, une ferme de Dokuwiki, paramétrer Apache et Nginx, etc.

Actuellement une grosse partie est sur le Wikhan, et ça me semble bien parce que le Wikhan est un wiki très généraliste, destiné à une documentation couteau suisse pour "tout" ce qui est de près ou de loin en rapport avec les objectifs de l'asso. C'est à dire "soutenir la création d'univers fictifs libres", ce qui passe par le besoin d'héberger et maintenir les outils utiles à cette création et à l'animation de communauté.

Nous avons cependant déporté notre activité "sysadmin" sur Numenaute. Ce qui est très bien aussi dans le sens où on se sent plus libre de jouer avec des services qui n'ont pas grand rapport avec Khaganat. Pour ce qui est de mutualiser avec d'autres structures c'est pas encore au point mais ça viendra peut-être. Bref, Numenaute a aussi un site, sous forme de wiki-parce-Zat, et forcément y'a un peu de tentation d'y mettre aussi de la doc. MAIS il me semble que disperser tout ça n'est pas une très bonne idée. Ceci dit, avant de faire mon autokratès, je laisse un peu de place aux échanges, car de bonnes idées peuvent émerger, ainsi que des arguments que je n'ai pas.

J'aurais tendance à garder sur le wikhan et en public ce genre de fiche :
- Documentation concernant l'installation, le paramétrage et la maintenance d'un service (logiciel)
- Documentation concernant l'usage par les utilisateurs de base, sur un service non personnalisé

Ce genre de fiche, par contre, me semble nécessaire sur chaque "instance" (Numenaute, Khaganat, etc)
- Condition d'utilisation des services, spécificité propre à une instance, RGPD associé

Enfin, ce qui reste en doc "privée" (accessible uniquement aux personnes ayant les droits pour bidouiller) :
- Documentation sur l'architecture, les paramétrages privés. Et encore dans ce dernier cas, vu qu'aucun mot de passe ne doit être en clair... mais parfois cacher au grand public le nom d'une base de donnée et le laisser dans la doc privé réduit un peu les surfaces d'attaques tout en simplifiant le travail des sysadmin.
- Doc sur les processus de sauvegardes précis (du genre, X sauvegarde Y de tel façon avec tels paramètres).

Bref, du général au particulier ; et tenter au maximum de documenter sur le wikhan avec au besoin renvoi vers les fiches génériques depuis des fiches particulières (comme par exemple sur la partie sysadmin de la fiche "pad" de Numenaute).
Cliquez pour afficher le message
Bonjour,
Petite proposition d'ajout pour notre client de base : la possibilité de se "téléporter" sur les divers points de la map, afin de rapidement contrôler tel et tel point (par exemple, les trucs liés à l'eau).

Ce que je propose, une fenêtre avec les options suivantes :
- pouvoir afficher ses coordonnées sur la carte
- pouvoir poser un POI qui sera enregistré en local (pour quand on fait des tests soi-même) ET qu'on peut pousser sur le serveur (pour inviter les autres à regarder le même test)
- liste des POI partagés et locaux ; cliquer sur l'un permet de s'y téléporter (après une fenêtre de confirmation).
- se téléporter sur des coordonnées (pour dire à quelqu'un "va à X-Y-Z" tant qu'on n'a pas de serveur).

L'idée est posée "comme ça", ça méritera sans doute que je développe avec une proposition sur l'interface... Mais c'est noté !

Par la suite, ce sera intéressant de laisser la fonctionnalité mais uniquement accessible en ayant certains droits. Sur le serveur, se téléporter sera réservé aux devs, certains modérateurs...
20 Avril 2023 à 14:55:15
Cliquez pour afficher le message
On a joué avec diverses IA, et il se trouve que l'une d'entre elle donne de sacrés bons résultats côtés concept art, tout en étant accessible. Seul souci, c'est via un serveur discord...

https://www.bluewillow.ai/

Ils autorisent à inviter le bot sur une de ses instances discord, ce qui permet de ne pas subir le flood des autres, donc j'ai créé un canal pour ça... si si... si vous voulez voir ce que ça donne et participer, demandez une invitation.

Créer un bon prompt est compliqué, et la doc n'est pas très précise sur les options possibles. Je vous propose de partager les mots-clés qui semblent intéressants.

- "--ar 3:2" : pour forcer un format différent (ici plus large que haut)
- "--no qqch". Pour éviter/limiter la génération de certains trucs. Par exemple, sur les personnages, ajoutez "--no armor, weapon" pour ne pas avoir que des guerriers.
- "Vibrant colors" pour avoir des couleurs sympas.
- "3d, unreal engine, digital art masterpiece, highly detailed" => permet un rendu apte à être modélisé, un peu dessiné.
Cliquez pour afficher le message
Bonjour à toutes et tous !

J'ai bossé un peu sur les wikis ce matin, ce qui amène quelques changements, dans l'espoir que cela facilite la contribution des nouvelles (et des plus anciennes : je sais que ça n'est pas fluide pour tout le monde). J'aurais besoin de vos retours pour savoir si c'est bien, si vous voyez plus à faire, etc

En premier, un truc tout simple : pouvoir s'inscrire par les 4 portes d'entrées "wiki" (wikhan, mediateki, um1, taf). Et oui ce n'était pas bien paramétré et quiconque essayait par ailleurs que le wikhan allait avoir des soucis... À côté j'ai désactivé les inscriptions sur les autres wikis. Oui, bon, ça ne change pas grand chose : si vous êtes inscrit, alors vous pouvez écrire dans le blog, pas besoin d'y créer un compte  ;)

Ensuite, j'ai revu la page de l'um1 Comment participer et enrichir l'encyclopédie du Khanat. Hier en accompagnant Darck_pixel dans sa première création d'article, j'ai pu me rendre compte à quel point c'était compliqué pour quelqu'un qui découvre un wiki... Pour celles d'entre vous qui font des ateliers et accompagnent les gens à la création, ça m'intéresse de voir si ça améliore un peu les choses ? Mais à mon avis il faudra plus que ça.

Notez tout de même la trèèèès grande amélioration : un formulaire pour créer une nouvelle page, avec même la possibilité de sélectionner un modèle. Cela est permis par deux nouveaux plugins, Addnewpage et Newpagetemplate, qui apportent là une sacrée fonctionnalité. Il est possible d'ajouter des modèles assez facilement, il suffit en fait de créer une page de wiki et de dire qu'elle va servir comme modèle en la listant dans le formulaire. Bref, ça c'est les détails sous le capot, mais de façon concrète :
- On peut ajouter un formulaire pour créer une nouvelle page n'importe où
- On peut forcer à ce que ça soit créé au bon endroit de façon assez invisible
- On peut proposer un modèle de page associée.

J'ai aussi revu le texte quand on édite/crée une page, afin de faire des liens vers la doc. J'espère que ça aidera aussi... Vous avez un doute sur la syntaxe avancée, celle qui n'est pas avec les petits boutons de l'éditeur ? Ça tombe bien, il y a le lien vers la syntaxe expliquée en détail ;)
Cliquez pour afficher le message
Salut à toutes et tous !

Comme chaque année, il va falloir faire une AG, pour valider la paperasserie.

Je crois que je préférerais faire ça encore en ligne. C'est plus simple à organiser. De toute façon on gère tout en amont. Et puis vraiment, je n'ai aucun amour des longues heures à parler de trucs administratifs...

Nous avons 12 membres aptes à voter et se présenter au collège cette année. Il n'est pas trop tard pour vous inscrire, si jamais ça vous intéresse.

Côté travail à faire pour l'AG :
- Faire le bilan moral
- Faire le bilan financier (sauf erreur, Lyne a déjà géré toute la partie comptable)
- Fixer une date

Lors de l'AG, il s'agit de valider ces deux bilans et élire le collège. On peut inscrire d'autres questions au besoin, si quelqu'un en a.

Voilà, un peu de taf à faire, mais ça peut aller assez vite. Maintenant que les trucs pénibles sont vu...

Envisageons-nous un peu d'AFK ?

De mon côté, la partie sanitaire continue d'être un frein, mais j'aime aussi vous voir. Alors, oui, je veux des AFK, et même des AFK pur Khaganat, mais avec des conditions : en été (pour aérer) et en petit comité. Si je finis ces fichus travaux dans ma maison un jour, je vous inviterais pour des week-end studieux : travailler sur les guides de la contribution, le guide du khanat, se faire un sprint godot, enregistrer des podcasts Khaganat, etc. Sauf que je ne sais pas trop quand ma maison sera apte à accueillir du monde ; mais hey, je ne suis pas obligée d'être l'organisatrice. Donc, si l'une de vous a envie d'organiser des AFK chez elle, allez-y ! Partagez vos envies, vos contraintes, vos demandes, et on voit ce qu'on peut faire.

Cliquez pour afficher le message
Il y a eu un rapport en 2022 sur la question du civisme dans les jeux vidéos, avec comme objectif d'identifier les mécanismes menant à des comportements toxiques dans ce genre de communauté en ligne. Le résumé et le téléchargement sont ici :  https://www.modernisation.gouv.fr/publications/civisme-et-jeux-video-leclairage-des-sciences-comportementales. Ça se lit facilement, le corollaire c'est que ça ne va pas très loin, mais cela pointe vers diverses études et ressources intéressantes et puis ça résume les points importants.

À Khaganat, cette problématique est fondatrice, dès le début nous avons pensé le jeu et ses mécanismes comme favorisant l'émergence de comportements positifs, tout en essayant de trouver un équilibre pour offrir du défi et du potentiel narratif. Aussi le rapport n'amène pas de grandes révélations qui vont nous faire revoir notre feuille de route, mais il me semble intéressant de revenir sur quelques points du rapport. Je prends ça dans l'ordre...

Déjà, rappeler que tout le monde peut se retrouver victime/témoin/auteur de comportements toxiques, suivant les jours et les moments ; ce n'est pas une caractérisation d'une personne d'être "une victime" ou "un harceleur", et donc l'un des points important est que chacun prenne conscience de ses actes, et des moyens mis à sa disposition pour sortir d'une situation toxique.

Le rapport pointe l'importance de la diversité sociale parmi les équipes de création ; là dessus nous ne sommes pas trop mal. De même que sur l'attention portée aux stéréotypes, on crée les nôtres mais il est évident qu'on va éviter certains pièges faciles (du genre les filles à gros seins). Concernant la gestion de communauté, l'accent est mis sur le fait qu'il doit y en avoir, portée avec des discours qui donnent l'exemple (quels comportements on veut avoir ? alors il faut le montrer). Idem, on fait ce qu'on peut mais je pense que ce n'est pas trop mal :)

Et on rentre dans le vif du sujet, avec la différence entre univers en lignes et monde physique. Là, c'est le point du rapport où nous prenons la tangente, le point aussi où je pense qu'il y a de quoi discuter. Le rapport pointe le fait que l'anonymat dans lequel le joueur pense être amène à des phénomènes de désinhibition en ligne et de désengagement moral. C'est le cliché de base : un petit gars tout fluet peut se comporter comme un gros salaud en ligne parce qu'il sait que personne ne viendra lui casser la gueule, mais aussi parce que son avatar n'est pas "vraiment lui" de même qu'il n'envisage pas les autres avatars comme des êtres humains mais comme des sortes de pnj qui ne peuvent avoir de ressenti une fois l'écran refermé. Cette déresponsabilisation liée à la distance au jeu existe réellement, il n'est pas dans mon intention de le nier. Cependant cet anonymat et cette désinhibition peuvent aussi avoir des effets positifs, en permettant d'expérimenter des choses qu'on n'ose ou ne peux faire "IRL". Notre petit gars pourrait aussi expérimenter ce que ça fait d'être une femme (et c'est d'ailleurs ce que font beaucoup de joueurs... qui découvrent alors parfois brutalement le harcèlement sexiste), ou des sentiments queers ; ou à l'inverse, pouvoir jouer sans être harcelé pour certains aspects de son identité.

Là dessus, en tant que membre de diverses minorités, je dois dire que le jeu vidéo en ligne et son anonymat m'ont fait du bien. Justement parce que je n'étais pas réduite à ces étiquettes, que je pouvais être vu comme une personne avant tout, et que si je me retrouvais dans un groupe où ma personna posait souci, alors je pouvais disparaître sans craindre un harcèlement au delà de l'écran. Le risque est évidemment d'amplifier des mécanismes toxiques quand on a sa cape d'invisibilité (pour se couvrir, par soumission au groupe, pour voir ce que ça fait d'être de l'autre côté, etc) ; si toutes les joueuses jouent des mâles, ça n'aide pas à voir la représentativité des femmes dans le jeu vidéo, par exemple.

Là dessus, le rapport préconise uniquement de relier l'humain à ses avatars de façon forte :
- en liant leur identité réelle à leur compte (double authentification, vérification de l'identité)
- en poussant à ce que l'avatar ressemble à l'humain.

Cela explique certaines incitations sur certaines plate-forme à donner son numéro de téléphone, sa carte bleue, et à ne pas nous laisser être "nous-même". Parce que l'identité physique est celle qui nous est imposée par la société ; certes, très marqué par la contrainte sociale, mais généralement au désavantage des minorités. Mais Internet nous offre au contraire la possibilité d'explorer d'autres versions de nous-même, les pires... comme les meilleures !

Néanmoins, il reste un point valable dans ce qui est pointé : plus il y a d'implication, d'intrication, entre le compte et le joueur, plus le risque de pertes est coûteux, et plus il y a des chances que la personne se conforme aux attentes du groupe. Si se faire bannir n'a aucune conséquence, alors on trolle, et on revient sous un autre nom après avoir été viré, et on recommence. Mais si le compte est lié à un personnage qui a beaucoup de matos, un crédit social important, voir plusieurs perso (par exemple), alors perdre ce compte commence à être trop coûteux. Ma théorie est que récompenser les gens pour leur investissement dans le groupe au fil du temps réduit justement ce risque de déresponsabilisation. C'est d'ailleurs l'enjeu dans notre modèle économique (qui ne concerne pas que les sous) : quelqu'un d'investi dans la communauté gagne un accès exclusif au jeu en période de tension. De même, faire qu'un seul compte aie accès à plusieurs personnages (y compris partagés) facilite l'engagement sur un seul et unique compte qui va devenir "précieux".

Nous verront au fil du temps si nos diverses tactiques arrivent à créer une communauté sympa, mais je sais que je préférerais éviter de me mêler de la vie privée des gens, de les fliquer à demander leur vraie identité ; ce genre de pratique ouvre la porte à trop de dérives, trop de risques pour les gens aussi.

Je passe rapidement sur tout l'aspect "compétitivité" ; notre objectif est justement de la limiter, ou de la faire dans un cadre hautement consensuel, respectueux et fairplay (code de l'honneur, fenra). Le seul aspect où une compétitivité réelle peut advenir est dans la lutte d'influence pour les kagnivos ; c'est évidement un endroit où il faudra être vigilant, mais d'un autre côté le caractère très politique de la chose devrait plutôt attirer des joueurs qui aiment se poser et réfléchir (pas le profil à rager brutalement). Ce qui ne veux pas dire qu'ils ne peuvent pas être dans des comportements toxiques... D'un autre côté, la lutte des kagnivos est aussi une volonté politique (en jeu et hors jeu) d'attirer là les profils potentiellement problématiques, de les avoir à l'œil plus facilement et, s'ils dépassent certaines limites, de se prendre un retour de bâton monumental de la part du Khan. Le Code de l'Honneur s'y applique aussi...

Le rapport pointe aussi divers dark patterns conçus pour exploiter le joueur (grinding, pay to win, pay to, "payer pour passer", système de parrainage offrant des avantages disproportionnés), et pointe quelque chose de vraiment intéressant, qui à mon avis dépasse le dark pattern : les joueurs qui ont investi beaucoup de temps, d'argent et de capital social dans un jeu (ici en raison des dark patterns) sont plus susceptibles d'éprouver des réponses émotionnelles négatives (voir "Dark patterns in the design of games", J. Zagal, Staffan Björk, Chris Lewis ; je pense que c'est ça la vraie référence). Avec les dark patterns, c'est sûr, le joueur a forcément le vague sentiment de s'être fait exploité et en veut pour ce qu'il a investi ; mais je pense qu'on ne dois pas sous-estimer ça aussi même sans dark pattern. C'est le corollaire de l'engagement : si on a beaucoup donné, on a souvent des attentes plus élevées derrière. Il est donc extrêmement important, à mon avis, de prendre soin des contributrices les plus investis, mais aussi d'être plus vigilantes et de bien marquer les limites face à ce qui tiendra du "caprice" (il faut construire pour tous et non pour satisfaire une petite élite).

Autre point utile : identifier et aplanir les points de friction. Par exemple, désactiver le tir ami évite qu'on s'enguirlande avec ses coéquipiers maladroits. Là dessus, Khaganat expérimente, et donc : on verra suivant ce qu'on veut tester, mais il faudra se montrer vigilant et demander aux premiers testeurs de l'être. Si un élément du gameplay est désagréable (même si ce n'est que pour une minorité de personnes) ET s'il est difficile à éviter, alors il faudra travailler dessus pour qu'il donne du fun à tous. Cela peut parfois passer par l'activation d'options ; c'est par exemple le choix qu'on fait sur le pvp, où on incite à prendre le risque d'être attaqué, mais, si c'est pénible, on peut devenir intouchable (en passant en dépho), car nous savons très bien que le pvp est source de frictions et qu'il faut pouvoir les diminuer au besoin.

Il y a aussi un retour intéressant sur les systèmes d'incitation au fair-play. Certains gros éditeurs ont mis ça en place, dans des jeux qui en plus sont plutôt à favoriser l'agressivité (MOBA), et le retour d'expérience est éclairant : cela marche si la récompense est à la hauteur. Je pense qu'il faut que ce soit au minimum aussi récompensant que ce qu'on peut avoir dans d'autres actions. Gagner un titre parce qu'on a été gentil, quand à côté on peut avoir la meilleure armure du jeu en payant ou en farmant comme un porc, forcément, ça rend grognon. Mais je pense que nos mécanismes éviteront cet écueil. Notons quand même la proposition de récompenses exclusives liés au comportement, et des avantages significatifs en jeu pour celles qui sont fairplay.

Sur la partie animation de communauté, peu de chose à dire, en dehors du fait qu'il me semble réellement très important de bien penser le système de signalement et de modération. Il y a quelques éléments qui me semblent particulièrement bien vu :
- profiter des signalements pour faire réviser le code de conduite, en demandant au joueur à catégoriser son ticket suivant l'infraction ; dans le même temps il relit que harcèlement et insultes ne sont pas acceptables.
- rappeler les règles de diverses façons. Avoir des affiches dans le dispensaire en mode "pub contre tel type de comportement toxique ou pour valoriser un comportement positif", ça pourrait se faire et se changer à la volée suivant les soucis du moment sur le serveur. Lorsqu'un ticket est traité, pointer aussi au joueur où est le problème.
- responsabiliser chacun face à la modération. Ceci afin de diminuer le phénomène de "diffusion de la responsabilité" (penser qu'un modo va agir, ou un autre que soit)

Sur ce dernier point, LoL avait mis au point quelque chose d'intéressant, baptisé le Tribunal. Les joueurs étaient invités à se prononcer sur des infractions en jeu, en échange de la monnaie en jeu. Ils ont fini par remplacer ça par... un système automatique. Je refuse que l'automatisme se mêle de l'humain... les conflits ont besoin de compassion pour se résoudre bien. De même, je crains un peu l'effet lynchage public avec un tribunal (les gens sont prompts à punir quand ils ne sont pas concernés ni formés). Mais, je pense que cela pourrait donner lieu à un mécanisme vertueux. Lorsque quelqu'un crée un ticket, il doit dire si 1) il autorise à ce que le ticket soit utilisé pour la formation public et 2) à ce que le ticket soit potentiellement soumis au jugement public. Qu'est-ce que cela veut dire ? Déjà, si on veut que ça reste 100% privé entre un modo et soi, c'est possible. Ensuite, dans le cas 1, si la modératrice juge le cas pertinent, elle peut le mettre sur la pile "instructif" après l'avoir traité. Attention,dans ce genre de cas, c'est traité directement en interne, rapidement. Mais, après quelques temps (semaines, mois ?) et une anonymisation du ticket, ce dernier ainsi que sa résolution est placé dans la partie du forum "modération - étude de cas", accessible à tout le monde. Cela permet à la communauté de voir comment la modération opère, de commenter potentiellement les façons de faire, de se familiariser avec ce qui est attendu. Le problème a été résolu et il est important qu'il soit présenté publiquement avec délai, afin que le lien avec le drame du matin ne se fasse pas trop vite et ne réveille le conflit. Le cas 2, lui, concerne les cas "limites", et c'est plus chaud. Si la modératrice juge que c'est vraiment compliqué et s'il y a cet accord, donc, alors elle peut transmettre dans la foulée ce ticket (anonymisé aussi) sur le forum "modération - cas pratique", permettant à toute la communauté (ou au moins les joueuses identifiées comme fiables) de participer à trouver une résolution. Évidement cela ce fera en rappelant qu'on ne doit citer personne, que si on a des éléments à ajouter au cas (genre screen des insultes) il faut les passer par ticket, etc. Cela pourrait d'un côté aider la modération à gérer les cas limites, qui sont toujours difficiles à trancher, de l'autre faire participer la communauté et aider à placer collectivement les lignes sur ce qui est accepté ou non. 

Voilà pour les points qui m'intéressaient le plus dans ce rapport. Si vous avez d'autres choses à dire sur le sujet, ça me passionne toujours autant ;)
Cliquez pour afficher le message
Je ne sais pas si vous avez lu l'article De la bureau-cratie à la tout-doux-cratie : refonder la gouvernance associative.

C'est pour moi l'occasion de réinterroger notre modèle.

Je fais le constat que malgré nos tentatives de proposer un type de gouvernance incitatif, nous avons vraiment très peu de bénévoles, encore moins sur les questions de gestion de l'asso.

Il me semble qu'il y a des facteurs externes menant à épuisement systémique face à un monde qui sursollicite : covid, boulot, contraintes d'un "quotidien" d'une complexité toujours plus grande, sans parler de la famille qui prends aussi du temps. Le tout menant à un repli sur un cercle de plus en plus resserré : soi, ses priorités personnelles les plus vitales (suivant les gens, ça va être des loisirs, la famille, le boulot, les amis, mais rarement tout en même temps, rarement énormément de temps aussi). On pourrait dire que cela favorise l'individualisme ; je pense de mon côté qu'il s'agit aussi d'un mode de survie (si j'analyse ce que je vis), la nécessité de se concentrer sur les priorités afin d'avoir assez d'énergie pour faire face à la violence des institutions. Et je conçoit très bien que le monde associatif voir militant ne soit pas forcément dans les priorités de survie de base, bien que ces espaces soient justement ceux où on peut réellement combattre cet écrasement ; qu'il s'agisse d'essayer de changer le monde (militantisme) ou de se faire une bulle de répit (nombre d'assos de loisirs). Et pour moi, Khaganat est un peu entre les deux, à la fois bulle de répit car "c'est un jeu, ce n'est pas sérieux" mais aussi militantisme car à travers la création du monde et nos relations dans ce projet, nous expérimentons et rêvons à d'autre fonctionnements ; concrètement, nous fabriquons d'autres façons de percevoir notre environnement.

Mais au delà des facteurs externes qui peuvent expliquer la désaffection des bénévoles, il y a peut-être aussi, dans notre cas, des facteurs internes à interrogere.

En ce sens, l'article de Picasoft offre des pistes de réflexion. Peut-être que nous pourrions améliorer la façon dont chacun de vous peut agir au sein du projet. Voyez-vous des aspects à discuter, des choses qui pourraient vous permettre de participer plus facilement ? Qui rendraient l'action au sein de Khaganat non pas énergivore mais au contraire source de remotivation et de plaisir ?
Cliquez pour afficher le message
Alors, j'hésite un peu... mais l'idée m'est venue et donc je partage, on verra si ça donne quelque chose.

En relisant un log, je tombe sur un moment où un personnage, d'habitude impliqué dans le rp, a eu à faire dans une zone où les histoires se racontent. Mais, ce soir là, il avait peu de temps pour jouer, il venait juste faire quelques missions, bref : il n'avait pas envie de RP, ni d'être intégré à l'histoire en cours, et connaissant les zigotos locaux, il a donc précisé cela avant qu'on aie le temps de le saluer d'un laconique "(je suis HRP)".

Cela me rappelle ces moments en jeu de rôle grandeur nature (GN) où, pour les besoins de la narration, on peut "suspendre le temps" en tant qu'orga/PNJ. On crie "Time", et tous les joueurs s'arrêtent en plein mouvement et ferment les yeux, jusqu'au "time" suivant qui signifie que le temps reprend son cours (avec généralement l'apparition d'une horde de monstres). Là aussi un moment HRP (le temps d'amener les mobs !) a été mis en place, par convention. Plus sobre, la technique "je lève le poing" pour dire qu'on doit faire comme si la personne n'existait pas (déplacement des orgas, pnj, ou des persos morts et qui se rendent au QG pour la suite). Ces deux techniques sont abondamment utilisées en GN, avec quelques autres, mais on retrouve cette idée de signifier quelque chose qui ne doit pas être intégrée au RP.

Du coup, je me dis que ça pourrait être intéressant d'avoir un marqueur visuel indiquant qu'à un instant donné, on ne souhaite pas d'interaction et en particulier d'interaction RP. Il y a parfois des moments sur un jeu où on veut juste se connecter vite fait, faire des missions ou farmer dans son coin, en fuyant un peu les interactions. Et oui, ok, ça serait plus logique de faire un jeu solo à ce moment, mais bon, voilà.

On pourrait même s'amuser à aller plus loin, à un stade au delà du dépho : devenir invisible aux autres ra, comme eux deviennent invisibles à nous (il faut que cela soit réciproque). Ainsi la possibilité de jouer solo dans le monde serait là, pour les jours où ce n'est vraiment pas le jour. Dans cette dernière option, le seul risque d'exploit que je vois est de pouvoir "poper" au milieu de là où on ne devrait pas être, lorsque qu'on sort de ce mode. Une façon d'éviter cela serait que l'entrée et la sortie de ce mode soit lié à deux artefacts. Pour l'entrée, il faut pouvoir le choisir avant de se connecter, afin d'éviter de se faire alpaguer par tout le monde dès son arrivée ; mais pour la sortie, il serait obligatoire de toucher une "pierre de rêve" disposées un peu partout dans le Khanat, à proximité des points de resni. Ainsi la réapparition sera conditionnée au fait d'être au "bon" endroit. Évidement, être tout seul signifie plus de risque de mourir dans certains cas, mais ici je ne pense pas que ce soit un vrai souci. Lors du revif, on sera forcément proche de pierres de rêves permettant de sortir du mode. La deco/reco ne sort pas du mode. Ce mode peut ainsi même, si on en a envie, avoir un sens rp : la personne se perd un instant dans le Monde du Rêve, dans une version finalement assez balisée, où une partie des ra sont absents (les joueurs mais pas les PNJ sinon pas de missions !), mais la faune et la flore sont identiques et les règles du monde aussi.

Quoi qu'il en soit un "tag" HRP me semble utile quand même, ne serait-ce que pour indiquer aux autres qu'on ne veut pas être inclus dans les trucs en court ni que nos actions soient intégrées dans les histoires. Je n'aurais pas envie de le mettre trop en avant afin d'encourager les gens à oser le rp, probable d'ailleurs qu'il ne soit possible de l'activer qu'en étant en dépho (état qui va avec quelques avantages mais aussi pas mal de désavantages) mais cela voudrait dire que le pvp peut toujours être inclus en rp.

Bref, c'est peut-être une idée stupide, ou pas. C'est tout frais, je ne sais pas encore trop quoi en penser et si c'est à garder, quels sont les risques, etc...
17 Août 2022 à 09:29:58
Cliquez pour afficher le message
Il y a déjà deux ans, nous avions pris conscience que le forum actuel, dans son ergonomie, ne favorisait pas les échanges. Cette marche d'entrée rebutait suffisamment pour expliquer qu'il aie été si peu utilisé après le passage à SMF. Je sais que les usages évoluent aussi, pourtant je reste persuadée qu'un forum peu être vivant à condition d'être un lieu agréable.

Pour corriger ça, je me lance enfin dans sa réfection. Et je vais aussi avoir besoin de vos retours, afin d'améliorer au mieux les choses.

La première chose qui m'aiderait, c'est que vous me pointiez des forums où vous êtes actifs. Rien que de pouvoir voir leur ergonomie sera déjà utile. Si, en plus, vous pouvez analyser vos usages, voir ce qui fait que votre participation est fluide, ce qui vous plait, c'est encore mieux. À ce stade, c'est pour moi le plus important.

La seconde chose, c'est de bosser sur la liste des choses à changer par rapport au thème de base de SMF. Pas celui du forum, déjà un peu bidouillé, mais ce qu'on peut voir ici : https://www.simplemachines.org/community/index.php

Le reste de ce message concerne mes premières notes, qu'il est possible de discuter bien sûr.

À noter que le nouveau thème de SMF est responsive par défaut ; je vais tenter de ne pas casser ça. Et il semble plus accessible aussi, mais il faudra vérifier dans les coins. Quoi qu'il arrive, à terme le thème pour Khaganat sera responsive et accessible (autant que possible), cela fait partie des points importants.

Points génériques à modifier
- Traduction française : plein de choix de termes qui sont foireux ("soumettre" plutôt que "poster", "réponse" au lieu de "répondre"...)

Concernant les sujets :
- Enlever la réponse rapide. Nous ne sommes pas sur un chat, le but est justement d'être moins dans l'immédiateté.
- Smiley : va nécessiter un plugin... pas possible dans l'admin d'assigner des raccourcis à des smileys, de configurer leur titre et alt. Bon point : les alt sont renseignés. Question : sont-ils lisibles ? Par ailleurs, je préfèrerais un bouton pour déplier la liste de smiley, pouvoir les organiser en catégorie, en ajouter, etc... Oui le smiley est vital sur forum !

Menu et global :
- Lien vers les messages non lus. Configurer pour que lors de la création du compte, tous les messages soient lus (oui c'est bête mais...). 
- Ajouter aussi un bouton "messages des dernières 24h" ? Probable que ce soit redondant et moins utile, pourtant je m'en sers plus que les non-lus sur le forum de ryzom.
- Lien vers flux RSS facile à trouver. À noter qu'il existe un plugin pour s'abonner spécifiquement à un/des sous-forum via RSS : cela vous semblerais utile ou de toute façon ce sera du "tout suivi" ?
- Améliorer la visibilité de l'option "s'abonner au forum" (=> notification de tout nouveau message par mail).  Ajouter l'option pour le faire sur l'ensemble du forum, sans cliquer dans chaque sous-forum...
- "Rechercher" est redondant (deux boutons). Champ en haut => rapide mais n'affiche pas les options. Bouton plus bas => lien vers les options. Garder celui-ci, je crois...

Liste des sujets :
- Séparer les colonnes "réponse" et "vues". Je ne sais pourquoi, mais ça passe mieux. Cependant, le nombre de vue me semble une donnée vraiment inutile sauf pour l'ego...
- "Démarré par" : Alléger un max, "Par" suffit amplement, voir juste le pseudo.
- L'en-tête des colonnes doit être clairement séparé de la liste des messages (fond de couleur par exemple)
- Si il y a du nouveau : peut-être juste mettre le titre en gras ; l'icone "nouveau" a un coté assez lourd.

Forum et sous-forum
- Séparer la colonne "messages" et "sujets". "Sujets" doit être en premier
- En-tête des colonnes avec "Sujets, message, dernière réponse" ; ces infos n'ont rien à faire sur les lignes (c'est hyper redondant).
- Dernier message : $titre par $répondant, (retour ligne) $date $heure. Uniquement le titre cliquable. Mieux, toute la zone est un lien cliquable vers la réponse.

Détail de configuration (côté admin pour le truc par défaut) :
- Par défaut, abonnement et notification mail à toute réponse à un sujet où on a participé. Chacun peut aussi régler ça chez soi ensuite.

Bugs à vérifier :
- Les icones de "nouveau messages" restent-elles allumées après qu'on aie vue le message ? Ça hélas on va le découvrir après migration, j'ai du mal à reproduire le bug.
05 Juillet 2022 à 21:31:12
Cliquez pour afficher le message
Citation de: YannK
J'ai découvert un gars qui a fait une vidéo très intéressante sur l'histoire du MMO : https://www.youtube.com/watch?v=IHQE0ILci4o (2h45) suivi de « How to save the MMO genre once and for all » : https://www.youtube.com
/watch?v=WOqTjL4x7FA - (1h05)
Dans cette seconde partie, il semble analyser les problèmes du genre qui expliqueraient sa relative désaffection actuelle
Je trouve ça plutôt intéressant, incontestablement pour la partie documentaire, avec moins d'enthousiasme pour sa façon de s'exprimer que je trouve un peu... pompeuse par moment. je n'ai pas le mot juste, mais des fois je trouve qu'il est un peu trop dans la mise en scène de soi on dirait, sans que cela ne porte préjudice à sa présentation de la chronologie néanmoins
Je me disais que ce pourrait être intéressant qu'on en discute si d'autres ici le regarde (surtout la seconde partie qui doit être plus analytique je supopose)
Il a fait un très gros travail de collation et de recoupements digne d'étude en tout cas, même si je ne suis pas sensible à son style narratif :)

Attention, c'est en anglais. Cela restreint le nombre de gens pouvant voir le truc. Heureusement certains ont partagé ce qu'ils en ont vu, ce qui fait une base de discussion.


Citation de: Nomys
Je repasse pour résumer la vidéo :
Le vidéaste identifie 4 problèmes :
1_ L'attrait social
2_ La balance de l'end game
3_ L'argent
4_ Le feedback des joueurs

1_ Les mmorpg ont perdu leur aspect social à cause de quelques aspects en particulier :
- L'automatisation d'action qui requeraient avant d'interagir
- La disparition progressive des serveurs ou plutôt l'apparition des recherches inter-serveurs
- La fait de penser le jeu pour qu'il soit jouable seul plutôt qu'il oblige à jouer à plusieurs.

2_ Les joueurs consomment le contenu trop vite, notamment la phase de leveling, ce qui conduit à démarrer le "vrai" jeu dans l'endgame. Pour réduire ça il identifie 3 mécanismes :
- Rendre le jeu plus dur
- Créer du "grind", c'est-à_dire forcer les joueurs à passer du temps à faire des trucs chiants
- Créer des limites de temps (chose accessible 1 seule fois par jour et qu'il faut faire 300 fois pour avoir un objet par exemple)

3_ C'est le problème du financement.
- L'abonnement limite le nombre de joueur total (et donc limite les gains d'un shop ingame)
- Les F2p avec des paywalls partout sont un cancer
- Pourtant il faut financer un jeu pour qu'il y ait du contenu régulier

4_ Le feedback des joueurs est trop souvent centrer sur eux-même :
- Ils s'intéressent souvent à leur unique manière de jouer ou à leur propres objectifs en jeu
- Ils ne sont donc pas neutre vis-à-vis des méchaniques du jeu et bien souvent ne savent pas ce qui amène de l'amusement dans un jeu.

Citation de: Alcyone
Le point 2, je me demande s'il n'y a pas aussi un mouvement de fond avec cette sorte de "boulimie" de jeux vidéo, une quantité impressionnante de jeux qui sortent régulièrement, des prix tirés vers le bas, une grosse consommation de jeu assez peu de temps (ou beaucoup en peu de temps) sans prendre le temps de s'y plonger dans la durée, une mécanique de zapping vu l'offre pléthorique, etc.
Je me demande si ça s'est pas aussi traduit dans le MMO d'une certaine façon.

Citation de: Nomys
La question de l'investissement que demande un mmorpg pour le joueur est un peu en filigrane tout le long.
pour avoir du social, il faut s'investir, pour profiter du contenu, il faut s'investir, pour faire vivre financièrement le jeu il faut s'investir et pour donner un "bon" feedback il faut s'investir aussi.
Aller c'est parti pour les solutions que propose le vidéaste.

1_ Le problème social :
- Il faut impliquer les joueurs socialement dans le jeu et son univers. Redonner du sens à jouer dans la communauté.
- Il propose : de créer de faux serveurs (!?)
- de se focaliser sur le pvp et donc avoir des communautés qui s'affrontent (gw2 par exemple)
- d'avoir du housing et/ou une économie suffisamment bien faites pour que les joueurs soient incité à construire des choses ensemble (starwars galaxy ou eve online)
- Enfin il conseil que les choix de gameplay/design soient aussi pensés en terme de bénéfices/coûts sur les aspects sociaux
- J'ajoute que la solution que je propose personnellement est que les joueurs aient un lien de parenté entre eux et avec des PNJ afin de créer des communautés

2_L'endgame
Les solutions qu'il propose :
- Arrêter de faire que le contenu de base soit si facile. Il faut le calibré pour les joueurs moyens et non pour les joueurs les plus mauvais/casual/etc.
- Même si le jeu est dur, le contenu doit être fun. Et pour savoir si quelque chose est fun, il faut observer : si les joueurs font des choses facultatives, c'est qu'elles sont fun.
- Il parle ensuite d'un système que je n'arrive pas à identifier ("Alt" ??? pour "Altar" ???).    Ça ressemble à un truc que tu fais évoluer
- Enfin arrêter de reset du contenu ou des stats lors de nouvelles expansions pour garder un sens à l'évolution dans le temps
- Le pvp doit se faire en petites factions et avec un système de ranking avec un token visible par tous sur le pseudo (faisant gagner de la renommé au personnage vis-à-vis des autres joueurs). Comme dans LOTR online
- Avoir du contenu qui reste dans le jeu quand celui-ci évolu dans le temps (par exemple garder les donjons/raids d'extension en extension et non pas les enlever au fur et à mesure)
- Et si les joueurs terminent le contenu disponible à un moment, c'est une réussite ! Car il n'est pas réaliste de vouloir garder les joueurs à l'infini. Il faut donc réfléchir à comment faire revenir les joueurs, plutôt que de créer des mécaniques pour les garder.

3_ L'argent
Il propose :
- Rejeter le p2w
- établir précisément ce qu'est un "bon" shop et un "mauvais" shop
- Enfin ne pas être un developeur radin et ne pas avoir des joueurs radins

4_ Le feedback
On ne peut pas plaire à tout le monde, donc faites des mmorpg qui plaisent à certains.
N'écoutez pas les retours des joueurs, car ils ne sont pas au fait de ce qui fait un bon jeu.

J'ai éludé des trucs, notamment les paradoxes des mmorpg sur lesquels il se base.

CitationNomys "J'ai éludé des trucs, notamment les paradoxes des mmorpg sur lesquels il se base."
K'Deed "Nomys: alt , ça doit être reroll"
Nomys "ah oui bien vu !"
Nomys "Du coup ça fait sens, il parle de certains mmo qui permettent de monter toutes les compétences sur un seul perso, mais de ne pouvoir se servir que d'un set spécifique à la fois"

Quelques notes sur le vocabulaire pour celles qui ne sont pas familières :
- F2P : Free to play, un jeu auquel on peut jouer de façon "gratuite". Le terme est apparu en opposition aux jeux où il faut payer un abonnement pour simplement pouvoir se connecter. Dans les faits, ce n'est jamais si gratuit, car il faut financer le jeu. L'une des solutions les plus répandus est le "Pay to Win" (P2W) : si jouer gratuitement est "possible", tout est fait pour inciter à acheter via une boutique en jeu, et sans cela, le jeu est quasiment injouable.
- Alt, Reroll : second personnage qui est généralement fait pour assister le premier. Jouer plusieurs perso en même temps est une pratique courante pour certains joueurs. Certains vont jusqu'à automatiser ces comptes secondaires (ce qui est toujours assez mal vu). La pratique est courante, mais souvent mal perçue par les joueurs eux-mêmes, associée à divers comportements négatifs. Voir https://khaganat.net/wikhan/fr:reroll pour plus de détails.


11 Mai 2022 à 08:59:26
Cliquez pour afficher le message
Je lance le sujet ici pour garder des traces, on va aussi en parler sur le canal Khanat (j'espère). Visuellement, à quoi ressemble la Crypte d'après vous ? Quels sont les inspirations ?

Si vous trouvez des images pour montrer certaines idées, c'est chouette ; des descriptions aussi précises que possibles sont bien aussi :)
24 Avril 2022 à 16:21:32
Cliquez pour afficher le message
Godot 4 voit arriver la gestion du réseau. Parallèlement à ça, une chaine vidéo développe la mise en place d'un réseau pour MMORPG basé sur Godot : https://www.youtube.com/playlist?list=PLZ-54sd-DMAKU8Neo5KsVmq8KtoDkfi4s.

Cette après-midi, ce qui existe a été discuté, je laisse le log ici pour les recherches et archives.

Spoiler for Hiden:
<YannK> J'ai découvert une super série d'un gars sur YT qui fait une suite de vidéos sur les techniques pour créer un MMORPG avec Godot, avec toutes els problématiques serveur (gateway, échnages sécurisés, déplacement de certains services sur le serveur pour éviter els exploits etc. etc.) : https://www.youtube.com/playlist?list=PLZ-54sd-DMAKU8Neo5KsVmq8KtoDkfi4s 
<YannK> C'est à la fois très précis niveau implémentation, mais il explique aussi les questions de façon un peu théorique pour qu'on comprenne les raisons de ses choix. 
<YannK> Je n'ai pas fini de regarder, mais jusque là j'ai trouvé ça de très très bonne qualité :) 
<YannK> Et du coup, j'y ai appris qu'un serveur seul sous Godot ne peut pas gérer plus de 4095 connections en même temps ^^ 
<YannK> Et il parle donc des méthodes pour ne pas avoir son architecture limitée par cette contrainte 
<Link Mauve> C'est dû à quoi ? 
<YannK> La contrainte des 4095 ? 
<‎Link Mauve>: Oui. 
<YannK> Hard codé dans Godot, mais je ne sais pas pourquoi 
<YannK> Mais de toute façon, on arrive à des goulots bien avant à d'autres niveaux :) 
<YannK> Tycho, si jamais tu as un jour l'envie de regarder cette série, j'aimerais bien ton avis sur son approche de la sécurité car il semble prendre ça très au sérieux :) 
<Tycho> oh god, il y a tellement de contenu... 
<YannK> Ah mais carrément, je trouve que c'est une des meilleurs chaines Godot que j'ai trouvées, avec GDQuest 
<Tycho> bon, je commence à regarder vite fait 
<Tycho> je pense faire mes remarques au fur et à mesure 
<Tycho> déjà je ne regarde pas tout, juste els vidéo qui causent de sécu 
<Tycho> donc je commance avec « Godot Multiplayer - Player Authentication | Godot Dedicated Server #3 » 
<Tycho> à 4:40, il parle de filtrage d'IP afin de ne pas totalement exposer le serveur d'auth : c'est OK, mais perso je pousserai plus loin en regroupant tous les serveurs dans un réseau privé et donc le serveur d'auth ne serait que dans ce réseau local, pas du tout sur internet 
<Tycho> et je précise que disposer d'un filtrage par IP alors que l'on est dans le réseau privé peut rester une bonne idée suivant la sensibilité des données 
<Tycho> ça ne coûte pas plus cher et ça augmente la sécurité, alors go 
<Tycho> à 5:14, il parle d'un token : alors ça se fait et c'est un choix respectable 
<Tycho> après, il y a également d'autres méthodes qui sont également cool 
<Tycho> le choix de la solution va surtout dépendre ses caractéristiques et des contraintes que l'on a 
<Tycho> je ne sais pas si c'est adapté à un MMORPG, mais un biscuit ( https://www.biscuitsec.org/ ) c'est super cool 
<Tycho> genre c'est adapté dans le sens où ça aide énormément à scale la solution, après le seul point qui m'inquiète c'est la taille du biscuit qui devra être transmis sur le réseau 
<YannK> Super, merci Tycho de ces retours. pourrais-tu juste mettre un tag genre #godotmultiplayerGDCtutorial comme ça je pourrais ensuite compiler tout ça à la fin ? 
<Tycho> punaise, j'ai vraiment l'impression qu'il stock le mot de passe en clair 
<Tycho> NE JAMAIS FAIRE ÇA 
<Tycho> j'ai pas mal attendu afin de voir si c'était temporaire et qu'il allait corriger 
<Tycho> ça n'a pas l'air d'être le cas 
<Tycho> et bien entendu, la comparaison du mot de passe est faite avec ==, ce qui est totalement sensible à une timing attack 
<Tycho> pareil pour le check de l'existence du client, ce qui est fun car il explique pourquoi il ne faut pas laisser savoir si c'est le login ou le mot de passe qui est mauvais 
<Tycho> mais bon, c'est moins grave 
<Tycho> allez, je passe direct à « Network Token Verification | Godot Dedicated Server #6 » 
<Tycho> bon, sa génération de token est pourave 
<Tycho> 32 bits d'entropie c'est pas assez 
<Tycho> bon, vu qu'il y a un timestamp ça passe, mais du peu que j'ai vu du code ça a l'air potentiellement foireux 
<Tycho> sérieusement mec, faut 128 bits d'entropie pour un truc unique et fiable 
<Tycho> puis le SHA-256 sert à quedal là 
<YannK> Sur le stockage du mot de passe en clair, il explique que c'est mal et pourquoi et ensuite il a une vidéo sur le hash et le salt 
<Tycho> ha ok, faudra que je regarde ça alors 
<Tycho> punaise, le timestamp qui à l'air sujet au bug de 2038 https://en.wikipedia.org/wiki/Year_2038_problem 
<YannK> Ses titres sont assez explicites, du coup tu vois comment il développe peu à peu les concepts 
<Tycho> rectification : ça semble dépendre d el'implem de l'OS, donc ça doti passer 
<Tycho> franchement, la génération du token c'est mauvais 
<Tycho> il prend 32 bits, qu'il hash afin d'ateindre une longueur de 256 bits (mais qui ne dispose toujours que de 32 bits d'entropie) qu'il va représenter sur 64 caractères donc 512 bits 
<Tycho> bref, prendre 128 bits d'aléat et les représenter en hexa divise la longueur de la première partie du token par 2 et en améliore considérablement la sécurité 
<Tycho> à noter que ça ne sert à rien de prendre plus de 128 bits d'entropie 
<Tycho> c'est juste de la perte de ressources 
<Tycho> fun fact : sa fonction de purge des tokens expirés pourrait etre plus performante 
<Tycho> supprimer 1 par 1 chaque token est pourri car sa liste est de base ordonnée (et s'il veut il peut s'en assurer de manière plus fiable), donc il suffit qu'il repère le token valide le plus vieux et qu'il supprime tous ceux qui sont situés avant dans la liste 
<Tycho> et du coup regarder la liste par le début ou par la fin se calcule en fonction des usage, faut monitorer et faire des stats afin de savoir lequel des 2 modes est le plus efficient (pareil pour la fréquence de purge d'ailleurs) 
<‎pep.>: TIL biscuit 
<Tycho> ouais, un biscuit (ainsi que d'autres technos telles qu'un HMAC, JWT, etc) permettrait d'éviter la boucle qu'il fait pour attendre l'éventuel retard de réception du token par le serveur de jeu 
<Tycho> OMFG 
<Tycho> la jolie faille :p 
<Tycho> je reprend la vidéo après avoir mangé et soudainement, en regardant sa boucle, ça me saute aux yeux 
<Tycho> while OS.get_unix_time() - int(token.right(64)) <= 30 
<Tycho> vous l'avez ? :) 
<Tycho> token.right(64) ← il utilise une donnée non-authentifiée provenant de l'utilisateur dans un calcul 
<Tycho> un token forgé dans lequel on met tout au max et sa boucle ne s'arretera jamais 
<Tycho> enfin théoriquement si, mais vu la durée le serveur sera fermé/reboot/whatever bien avant que ça ne s'arrete 
<Tycho> lui qui est parano au sujet des DOS causés par des connexions trop longues, il a oublié cet aspect là ^^ 
<Tycho> au passage, je me demande ce qu'il se passe si le token est plus court que prévu et que du coup il n'y a pas la longueur nécessaire pour juste le timestamp 
<YannK> Je crois qu'il fait un tru ensuite contre cet exploit justement, Tycho 
<Tycho> sinon, vu que le token est détruit, je confirme que ça peut totalement être remplacé par un mécanisme de HMAC qui est moins sujet à ce genre de problèmes, faut juste prévoir une rotation des clés une fois de temps en temps (par exemple, sur EvE online il y a 1 reboot chaque jour, c'est le moment idéal pour changer la clé) 
<YannK> Comme il tente de faire des vidéos pas trop longue, il implémente un concept à la fois, donc des fois il laisse les choses un peu "en l'état", mais il l'expliquait je ne sais plus quand 
<Tycho> YannK: exact, il en parle 
<Tycho> j'avais juste pas atteint l'endroit 
<Tycho> c'est dans la même vidéo, mais un peu plus loin 
<YannK> ouf, ça va alors :) 
<YannK> Comme ile me paraissait sérieux, j'ai eu peur qu'il ait laissé un éléphant dans la pièce ^^ 
<YannK> (ce qui aurait hypothéqué le sérieux de l'ensemble je trouve) 
<Tycho> ya encore la génération du token qui est pourrie 
<Tycho> et j'ai pas encore vu sa correction sur le stockage du mot de passe 
<YannK> Disons que ce qui m'intéresse aussi, c'est la logique générale, si elle te semble sérieuse et cohérente. Les méthodes utilisées pour implémnter la logique m'inquiètent moins car ça peut toujours s'améliorer, comme tu le propose juste en regardant rapidement, déjà :) 
<Tycho> je suis quand même déçu qu'il fasse le test en conservant sa fonction vulnérable à une modification du token 
<Tycho> allez hop, go « DTLS Encryption with SSL Certificates | Godot Dedicated Server #7 » 
<Tycho> oula, j'aime pas le début 
<Tycho> OMFG 
<Tycho> un certif auto-signé 
<Tycho> désolé mais c'est merdique 
<Tycho> NE PAS LIER LA GÉNÉRATION DU CERTIFICAT AU SERVEUR 
<Tycho> on fait ça à coté 
<Tycho> punaise c'est de la torture cette vidéo de création de certif auto-signé 
<Tycho> puis RSA bien entendu, c'est pas mauvais mais c'est pas le plus optimal 
<Tycho> et puis RSA 4096, genre le mec crois que parce que 4096 est supérieur à 2048 c'est forcément mieux (pas trop, ça prend juste plus de ressources) 
<Tycho> ha, il cause enfin de la différence entre un vrai certif et une bouze auto-signée 
<Link Mauve> (Beaucoup plus de ressources.)
<Tycho> le mec qui dit qu'un certif bien signé ça coûte du fric... 
<Tycho> dans une vidéo de 2020, donc quand let's encrypt existe déjà 
<Tycho> et fournit des certif gratos et qu'en plus c'est automatisable 
<Tycho> je me pose des questions sur l'utilisation de DTLS au lieux de TLS 
<Tycho> vu qu'il ne chiffre que les communications qui ne sont pas critiques (donc en UDP ou similaire), il n'en met que sur les connexions qui peuvent se permettre d'etre en TCP et donc TLS 
<Tycho> peut-etre que c'est une limitation de godot 
<Zatalyz> Tycho, tu es OK pour que je mette tout ça sur le forum par la suite ? ça facilitera pour retrouver les infos :) 
<Tycho> Zatalyz: yep ! 
<Tycho> bon, ya pas de véritable config de DTLS, du coup faut faire confiance à godot 
<Tycho> allez, je passe rapidement sur « Create New Account Function | Godot Dedicated Server #8 » 
<Tycho> a priori ya pas grand chose d'intéressant mais au cas où je regarde à certains moments 
<YannK> C'était surtout l'architecture de connexion sur laquelle j'avais envie d'avoir tes retours, mais si tu es curieux du reste, fais toi plaisir ^^ 
<YannK> Et du coup tu penses qu'on devrait mettre en place avec un certificat Let'sEncrypt dès le départ ? 
<Tycho> allez hop, go sur « Salting and Hashing Passwords | Godot Dedicated Server #9 » 
<‎Link Mauve> YannK, oui, ça ne coûte rien de plus que de l'utiliser pour un site ou quoi. 
<Deed>: humm, je vais peut-être dire une bêtise mais je ferai une connexion en "ssh" avec une clé pour la connexion client - serveur 
<Tycho> YannK: perso j'utiliserai vraiment un token client signé avec un HMAC plutot que de transférer le token au serveur de jeu, mais sa solution reste correcte, modulo la génération de la partie aléatoire 
<Tycho> bon, génération du sel pour le hachage de mot de passe : même erreur 
<Tycho> sérieux, c'est quoi la facination morbude des devs pour les fonctions de hachage ? 
<Tycho> OH SHIT 
<Tycho> sa fonction de hachage maison est, sans surprise, totalement pourrie 
<Tycho> après, comme il l'a expliqué avant, les vraies fonctions de hachage ne sont pas implémentées de base 
<Tycho> le mec ose comparer sa méthode à la con à bcrypt, ça me tue 
<Tycho> rien que sa manière d'intégrer le sel est mauvaise 
YannK imagine Tycho en train de faire des bonds sur sa chaise :D 
<Tycho> et du coup ya une autre failel de sécurité qu'il n'a pas vu venir : un utilisateur qui balance un mot de passe volontairement erronné mais absolument énorme (plusieurs milliers de caractères) 
<Tycho> sans limite haute, sa fonction de hachage va prendre un temps monstrueux 
<Tycho> sérieusement, réimplémenter PBKDF2 c'est pas bien compliqué vu qu'il a déjà les fonctions de hash qui vont bien (et sans doute un HMAC) 
<Tycho> en plus (comme PBKDF2), ya juste une protection sur le temps, yen a pas sur l'utilisation de la mémoire 
<Tycho> YannK: si tu as la doc du langage python-like qu'il utilise ça m'intéresse 
<YannK> https://docs.godotengine.org ^^ 
<Tycho> merci 
<Tycho> grrrrrr, il compare les hash direct avec ==, c'est pas bien >.< 
<Tycho> bon, il y a les HMAC de base, c'est cool 
<Tycho> sérieux, il aurait pu au moins utiliser ça 
<Tycho> tiens, ya un constant_time_compare donc, dès qu'on touche à de la crypto, faut l'utiliser au lieux de == 
<Tycho> au passage, la partie crypto dispose aussi d'un generate_random_bytes, ce qui semble bien mieux que ses truc d'int random 
<Tycho> bon, du coup je vais m'arreter là je pense 
<Tycho> YannK: du coup, tu penses utiliser son système en corrigeant les soucis ou bien passer sur ma méthode à base de HMAC ? 
<YannK> Je te fais confiance pour les meilleurs choix à faire en terme de sécurité :)
On en est très loin de faire le système, mais de savoir qu'on peut faire un truc très propre en restant dans Godot pour tous les éléments me plait bien. Si tu n'y vois rien de réellement problématique dans l'infra proposée et les seules problématiques comme étant améliorables à un niveau acceptable, ça me va parfaitement :) 
<YannK> Je compilerai tes remarques sur HMAC et Let's Encrypt en particulier pour lui faire un retour :) 
<Zatalyz> L'idée est plus de voir quelle architecture sera correcte pour tout ça 
<YannK> C'est ça, si on peut avoir un seul environnemùent de développement avec des fonctions intégrées qui se complètent, j'aime bien :) 
<Zatalyz> là, il semble y avoir des bases desquelles partir, modulo plus d'attention à certains aspects de sécurité (genre le choix des librairies, si j'ai compris, mais pas que) 
<YannK> Surtout que Godot a bossé sur cette partie pour la 4.0 
<Zatalyz> plus le temps passe et moins vous gardez de trucs du Nel par contre. Bon, ok, sur la partie sécu c'est aussi bien, mais... 
<Deed‎> j'allais le dire Godot 4 a bien bosser ce côté 
<Tycho> en totu cas godot n'a pas l'air d'avoir intégré de fonction de hachage de mots de passe :/ 
Zatalyz se demande si un jour elle verras le MMORPG :P 
<YannK> C'est à dire qu'on a un dev qui bosse sur Godot, là contre 0 qui étudient NeL, donc je préfère aller par là ;) 
<YannK> (l'article sur le Multiplayer dans Godot 4 : https://godotengine.org/article/multiplayer-changes-godot-4-0-report-3
<Deed‎> Zatalyz: on s'appuie sur NeL pour l'exemple quand même 
<YannK> Tout à fait Deed, je suis d'ailleurs en train de réfléchir à la façon dont on pourrait se baser sur les datasheets en XML pour penser une achitecture des données dans Godot :) 
<Zatalyz> oui   
<YannK> Tycho, dans l'article, il y a un exemple de code avec une méthode appelée dtls_server_setup ça te plaît ? ^^ 
<Tycho> YannK: quel article ? 
<YannK> Celui que je viens de partager :) 
<Tycho> ha, vu 
<Tycho> je regarde 
<Tycho> nope, ça load juste la clé privée et le certif 
<Tycho> confirmé : https://docs.godotengine.org/en/latest/classes/class_enetconnection.html#class-enetconnection-method-dtls-server-setup 
<Zatalyz> Le souci c'est le manque de monde. Chaque chose qu'on recode autrement demande du travail (sans parler de tout le reste : penser au gameplay, au gamedesign, au monde, etc). Donc attention, la priorité doit vraiment être d'avoir un bout de démo qui fasse envie. Il faut laisser de côté toutes les fonctionnalités secondaires pour éviter de perdre du temps dessus. Et le réseau, c'est un gros bout, donc je préfère vraiment qu'on s'y attaque quand il y aura du monde (ou alors si quelqu'un n'est motivé que par ça), mais qu'avant on est un bout de carte joli où se balader (même si on ne fait pas grand chose de plus) 
<YannK> Ah oui. Ça n'a rien à voir avec le premier client sur lequel on bosse, Zatalyz :) 
<Zatalyz> oui oui, je sais, mais je préfère bien enfoncer le clou :P 
<YannK> C'est juste pour savoir si on sera coincé par Godot à un moment ou pas. Et là il semblerait qu'on puisser petit à petit développer tout ce dont on aura besoin dedans, sans devoir chercher de quoi le compléter 
<Zatalyz> Oui, moins on a besoin de recoder des bloc, mieux c'est aussi; 
<Zatalyz> là, de ce que dit Tycho (tu me corrige si j'ai mal compris), il y aurait des blocs à coder pour utiliser des librairies de crypto correctes  ; mais, sachant ça, on peut y remonter à godot, les orienter vers les bonnes solutions, et espérer que d'ici à ce qu'on bosse sur le réseau, ça soit implémenté 
<YannK> Il y a plein de parties dans le NeL qui sont des outils que Godot intègre nativement, donc si ils conviennent, autant prendre els fonctions les plus haut-level du NeL et els réimplémenter dans Godot proprement plutôt que de chercher à bidouiller en connectant ce qu'on peut à un NeL boiteux 
<Zatalyz> oui 
<Tycho> Zatalyz: pour le token d'auth basé sur un HMAC c'est simple à faire car godot intègre ce qu'il faut, je peux meme contribuer 

Ça continue de discuter, l'idéal sera d'éditer et caler la suite de la discussion ici une fois que ça sera fini :)
06 Février 2022 à 16:40:04
Cliquez pour afficher le message
Cette discussion est en lien avec celle sur le vol.

Si Godot nous permet sans souci de faire un jeu façon "plate-forme", je suis pour ma part vraiment motivée à ne pas aller là-dedans et proposer un autre type de déplacement. Avant tout parce que je veux un jeu où on raconte des histoires et où on prends son temps, pas un jeu où on s'agite de façon frénétique. Or, si on doit faire gaffe à ne pas tomber des bords d'un obstacle, si on peut rejoindre un point en faisant des bonds, on finit forcément par avoir des joueurs qui courent partout et sautent tout le temps et des leveldesigners qui inventent des endroits avec des plate-formes où il faut sauter pile au bon moment pour traverser. Je n'ai pas envie de ça.

Je résume ce qui a déjà pu être pensé ici et là.

- "Chutes" : Bord de falaises, pont, pontons, etc. une collision empêche de tomber dans le vide, cependant la zone du bord devrait pouvoir offrir une action contextuelle du type "sauter quand même", déclenchant le placement du personnage de façon à ce qu'il puisse sauter/tomber/faire un plongeon (que ce soit pour le plaisir du revif ou pour faire le malin sur un plongeoir, donc). Tel que je le vois, on créera des zones (invisibles) sur ses bords, avec différents tags (le bord "falaise" étant différent du bord "au dessus de l'eau") ; on fait un clic droit sur son perso et suivant ses capacités et son équipement, diverses options sont alors proposées (descendre en rappel, tomber bêtement, faire le saut du pigeon, faire un triple salto arrière, etc).
- "Monter" : pied des falaises, depuis l'eau par rapport au rebord de piscine, face à une barrière, etc. Idem, des action contextuelle quand on approche et suivant le type de "bord", on pourra "sauter la barrière, sortir de l'eau, grimper à la falaise", etc.

Dans un premier temps, ces divers bords ont surtout besoin d'être lié à une collision, en particulier pour empêcher de tomber. La mise en place des divers types de "bords" et des actions contextuelles qui peuvent y être liés demandera du temps à être posée. À noter que ça va être assez pénible dans la génération des paysages !

Concernant les formes de saut : il s'agira uniquement d'emotes, sur place, ne permettant pas de traverser un quelconque obstacle OU d'animations contextuelles liées à la détection de ces "bords" (et là, oui, on peut faire saute-mouton par dessus la barrière). En cas d'abus des emotes, le sort "Frog mode" sera là quand même.

Quel rapport avec le vol ? Et bien... comment on gère les atterrissages/décollages entre autre, par rapport à ces contraintes pour les terrestres. Par exemple un drone-caméra peut-il passer la falaise et voler au delà ? la collision est-elle ignoré par ce dernier (et dans ce cas ça doit être des collisions spéciales, indiqués comme étant traversables en mode vol), ou bien doit-il passer au delà d'une certaine hauteur pour que ça marche ?
Cliquez pour afficher le message
Salut à toutes,

Dans le dernier test autour du client Khanat, le déplacement de type "vol" a été implémenté. Pour le moment cela reste très basique, mais je sais que ce genre de fonctionnalité a énormément d'impact.

Pour petit rappel, quand on ajoute une fonctionnalité, il ne faut pas seulement voir à quel point c'est fun et plein de possibilités, il faut aussi impérativement penser aux contraintes que cela va amener en jeu et aux comportements que cela peut générer, y compris les trucs pas chouette et les déséquilibres. Le vol, c'est vraiment très compliqué dans les ramifications.

Avant tout (et c'est aussi pour ça que c'est important de l'intégrer rapidement dans le client), le vol est un déplacement à part entière qui n'est plus contraint par les obstacles au sol. Cela veut dire qu'il devient difficile de fermer une carte en mettant une falaise au bon endroit : avec une entité volante il est possible d'aller au delà, de se jouer des falaises les plus abruptes. Au niveau du design des lieux, cela demande de penser à beaucoup, beaucoup plus de choses. Une barrière au bon endroit n'empêche plus les indiscrets de passer.

Cela peut être limité en mettant certaines contraintes sur le vol : par exemple l'impossibilité de dépasser une certaine altitude (assez délicat à justifier cependant) ou une maniabilité laborieuse (tenter de faire passer un avion de ligne dans un tunnel ou de le faire atterrir sur un porte-avion est impossible). Ou encore une portée limitée (via de l'énergie dépensée pour se maintenir en l'air, qu'il faut recharger). Mais quoi qu'il arrive ça ouvre quand même énormément les frontières, et cela d'autant plus que ce qu'on peut envisager de "volant" est plutôt passe-partout.

YannK parlait du fait que les Quetzaras peuvent voler. Je ne sais plus si on avait déjà abordé la question... de mon côté je ne suis pas motivée par ça, pour plusieurs raisons. D'abord, une bestiole de grande taille qui vole, c'est physiquement compliqué et contraint énormément la gueule de la bestiole. L'humanoide avec des ailes à la place des bras ou des ailes dans le dos (encore pire) est biologiquement difficile à justifier. Les oiseaux ont un sacré système cardiaque pour faire fonctionner leurs ailes et les plus gros piafs volants sont toujours dans une situation précaire. Par exemple les vautours (parmi les plus grands piafs) planent plus qu'ils ne volent, et s'ils se posent, le décollage est complexe et leur demande beaucoup d'énergie, raison pour laquelle ceux qui survivent 1) décollent des falaises (en se laissant tomber puis planer) ou 2) décollent après avoir mangé une carcasse près de laquelle ils ont fait leur atterrissage. Ok, pour les Quetzara, on peut trouver du TGCM avec des plumes trempées dans de la poudre de Krili, mais bon... Le 2e point qui m'embête, c'est que cela donnerait une façon de jouer très différente pour cette race et si on équilibre mal, tout le monde voudra faire un quetzara pour pouvoir voler. Or les quetzaras sont un peuple minoritaire dans le Khanat actuel. Personnellement je préfère les voir comme des sortes d'autruches que comme des sortes de vautours, leurs plumes sont déjà l'occasion de faire beaucoup de choses.

Il y a d'autres trucs qui volent.

Nous avons en particulier la majorité des véhicules qui lévitent grâce à l'effet Tsupa'a Galton - Cfiden Mojig. Mais c'est de la lévitation, pas du véritable vol : cela permettait de s'affranchir des contraintes des roues (pas si simple à faire bien en jeu, en gérant les divers types de sol). Ces véhicules sont donc, dans les faits, terrestres : ils ne peuvent pas passer au dessus de l'eau ou traverser des gouffres, ils restent à une certaine distance du sol, toujours la même.

Nous avons des créatures volantes, mais là aussi c'est à la base un faux vol : les animations les montrent au dessus du sol mais leur déplacement est lié à ce dernier. C'est cependant ici que l'ajout du vol en jeu me semble le plus utile : cela permettra qu'un essaim de vidvoi poursuive les pauvres ra innocentes qui approchent, même en traversant des étendues d'eau ou en remontant les falaises. Il faut par contre être conscient que cela rend le jeu plus mortel, certains prédateurs devenant quasiment impossible à fuir facilement. Ces créatures étant par ailleurs scriptées, les risques d'abus sont limités et seront uniquement du fait des leveldesigners.

Nous avions aussi évoqué la possibilité d'avoir des sortes de drones, en particulier pour simuler les caméras et permettre en jeu de "filmer". Dans mon esprit, ce sont de petits bots en vol stationnaire, et en même temps c'est là qu'on va vite approcher des soucis. Gérés par les joueurs, ce genre de créature pourrait aller à peu près partout. On peut mettre une contrainte de distance par rapport au personnage contrôlant la créature, mais cela permet quand même beaucoup de choses.

Enfin, nous avions aussi parlé d'autres types de véhicules volants, et en particulier des dirigeables. Je n'ai pas trop envie d'avoir des avions ou hélicoptères dans le Khanat, ni des moyens de vol personnels (type parapente, deltaplane, monture ailée). Pour des raisons de goût personnel, parce que je n'ai pas envie que ça bourdonne trop dans les airs. Les dirigeables, c'est des trucs sur des trajets fixes, c'est du transport en commun scripté, c'est un peu différent.

Merci de compléter ce message avec ce que vous pouvez envisager dans les trucs volants du Khanat, quels limitations et avantages ils peuvent avoir, etc.
17 Janvier 2022 à 22:09:02
Cliquez pour afficher le message
Salut à toutes et tous,

Je relance le marronier concernant le bordel des outils et les questions à se poser autour de ça.

Depuis le début du projet, le manque de dev a été un souci. Nous avons mis du temps à mettre en place des outils adaptés à ce genre de public (dépôt git, structuration des dépôts en question), et nous nous révélons incapables de motiver une quantité de dev suffisamment importante pour que la partie "jeu vidéo" avance. Il y a bien sûr eu quelques devs géniaux qui sont venus et quelques uns qui restent encore, mais ça n'est vraiment pas assez pour qu'on puisse espérer voir un jour la partie MMORPG fonctionnelle.

Nous avions déjà fait ce constat et essayé de voir plus petit, en se concentrant sur un client solo, réalisé avec Godot.

Mais à l'expérimentation, Godot ne résouds pas le problème de base. Il faudrait, encore une fois, plus de devs pour avancer et passer un point critique. Pire que ça ; Godot, sur la 3D, n'est pas encore un logiciel mature et chaque changement de version demande de tout reprendre à zéro. Avec nos moyens limités, c'est une tâche que nous ne pouvons pas mener.

Cela m'ennuie que le travail des bénévoles soit régulièrement mis à la poubelle à cause d'outils inadaptés, de manque de moyens généraux et de changements en tout genre (que ce soit sur les outils ou sur les mises à jours de ces outils). C'est un vrai problème, d'autant que depuis 2020 il y a une sacrée chute de motivation générale (pour des facteurs tant internes qu'externes).

J'aimerais donc qu'on essaie de prendre ça autrement. Quelle sorte de projet peut-on mener pour que les contributeurs actifs restent motivés et que leur production soit à la fois utilisable dans la durée et percevable par des gens qui ne bossent pas dans le domaine ?

Par exemple, YannK a pris assez de niveaux en graphisme pour réaliser des choses magnifiques, et il est actuellement très motivé, avec des procédures de travail efficaces sur une partie des outils (textures et modélisation 3D). Mais il se retrouve bloqué pour intégrer ça dans Godot, pour un tas de détails techniques qui ne sont pas facilement dépassables et qui pourraient se résumer par "il faut un outil plus abouti pour faire une scène de jeu où se promener". Personnellement je crois qu'il serait plus récompensant (pour lui et pour toutes celles qui lurkent) de travailler sur des scènes 3D sans forcément aller plus loin ; d'avoir de jolies images pour parler du projet, voir même de quoi tourner des animations (si un jour quelqu'un veut s'y essayer). Scènes qui pourront de toute façon servir de base dans le jeu ensuite, modulo les divers soucis d'imports, mais ça fait quand même un truc sur lequel s'appuyer.

Autre exemple, Aleajactaest a bossé un bon moment sur la façon dont client et serveur communiquent. Mais en plus de soucis techniques auquel il s'est heurté et où il manquait d'autres gens compétents pour discuter, le fait que ça soit un travail qui ne se "voit pas" (= faudra du temps avant qu'un client communique avec le serveur) a joué sur de la démotivation. Actuellement il travaille sur des trucs autour de Godot, c'est plus visible et testable et donc probablement plus récompensant ; seulement chaque montée en version de Godot pète des trucs et finalement ce travail n'est pas garanti d'être utilisable dans la durée.

Par ailleurs, la feuille de route pour le client comme pour le MMORPG lui-même manquent de finalisation. Ce qui n'aide pas à la contribution et amène parfois à se disperser un peu. Certaines d'entre nous ont, à certains moment, beaucoup contribuer sur ces sujets, mais à titre personnel je dois dire que l'indifférence associée à ce travail et le fait de ne pas voir d'application concrète à ce qui a été fait, voir du travail réalisé sans prendre en compte les éléments posés dans ces documents, m'ont peu à peu complètement démotivé.

Et comment fait-on pour trouver d'autres contributrices, les accueillir et les motiver à rester ?

Enfin, au delà de ça... oui, la période est difficile, pour nombre d'entre nous (et là encore que ce soit personnel ou contextuel, on a tous nos vies). Mais il y a une sacrée perte d'énergie et il faudrait trouver comment enrayer ça. J'attends vos suggestions. Là, on est à 4,5 personnes encore investies dans la contribution au projet (hors contribution financière, qui baisse aussi ceci dit), cela pose vraiment question sur la viabilité à courte échéance de Khaganat.

J'attends vos retours.

Pour des raisons d'archivage et de structuration des échanges, si vous papotez de tout ça sur XMPP, merci de résumer ensuite ici le principal. Et répondre sur le forum est une excellente idée, ce media est plus adapté pour prendre le temps de poser ses réflexions ;)
28 Septembre 2021 à 23:11:06
Cliquez pour afficher le message
Les choses changent au fil du temps, et nous avions actuellement des personnes ayant des droits élevés sur les dépôts de Khaganat, mais qui ne sont plus présentes depuis longtemps.

Afin de limiter les surface d'attaque, nous avons "déclassé" ces comptes. Puisque les gens ne sont ni présents, ni actifs, si leur compte est piraté, ils ne s'en rendront pas facilement compte... et ça ouvrirait la possibilité de faire pas mal de dégât. Donc :
- Si les dépôts sont publics, les accès passent en "guest", ce qui laisse la possibilité de réagir aux tickets, regarder les dépôts, mais pas de changer le code.
- Si les dépôts sont privés, les personnes sont enlevés des groupes, afin de ne pas avoir accès à des choses "secrètes". En fait de secret, on parle surtout de trucs concernant la sécurité (genre des scripts de sysadmin) ou des trucs tellement en chantier qu'on a honte d'y mettre en public (de mémoire, un seul dépôt réellement concerné...).
- Si les dépôts sont privés MAIS sont la propriété de la personne, ben, forcément, on lui laisse l'accès. Un certain nombre de personnes se servent de notre gitlab pour expérimenter des trucs, faire des projets persos, et c'est OK. S'ils sont les seuls sur le projet en question, alors ils en restent propriétaires. S'ils sont avec d'autres personnes, faut voir suivant les autres personnes.

On note comme "inactif, susceptible de déclassement" les gens qui n'ont eu aucune activité sur le gitlab depuis au moins un an et qu'on n'a pas plus vu ailleurs depuis ce temps.

Notez que si vous revenez, il suffira de nous envoyer un message pour qu'on vous redonne plus de droits !
19 Janvier 2021 à 13:50:01
Cliquez pour afficher le message
J'ai réparé un bug d'envoi de mail, ce qui a révélé des bugs dans le Kloud.

C'est un sacré travail d'y réparer, et dans l'absolu avec Deed on aimerait migrer ça sur le nouveau service Numenaute, donc ça m'embête de passer 3 jours à réparer le Kloud, puis une semaine à paramétrer la Soute et 2 jours encore à transférer le Kloud dans la Soute. Alors je vais réduire un peu en évitant la première étape.

Le plan d'action que je propose :
1) On laisse le cron du kloud de khaganat éteint, et ses erreurs etc. Cela veut dire que le Kloud n'est pas entièrement fonctionnel pour le moment ! Mais vu l'activité je ne pense pas que ça sera gênant.
2) Sur la Soute :
  - On traque les erreurs restantes. Je ne veux ni error, ni warning.
  - On paramètre pour avoir plusieurs noms de domaines sur la même instance ET un thème par nom de domaine (cf https://help.nextcloud.com/t/howto-individual-themes-per-domain/27585 ). C'est faisable, reste à le faire...
  - On regarde si on ne peux pas transférer les users, voir les partages (j'ai un doute sur ça...)
3) On transfère les données du Kloud vers la Soute ; j'ai les commandes qui vont bien pour ça, ça ne devrait pas être long.

Licences Mentions légales Accueil du site Contact