Messages

Pour le bug, si vous arrivez à décrire une procédure pour le reproduire, ça pourrait aider à tester

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.

Il y a quelque chose à creuser. Cependant attention, pouvoir looter l'inventaire des autres amène des ambiances assez lourdes. Tout le monde n'a pas envie de partager ; y compris les PK. Qu'ils soient au courant de la règle ne diminuera pas les enflammements et insultes. Au contraire, c'est leur donner une bonne raison de râler...

Mais j'aime bien cette idée que suivant si tu es peinard dans ton coin, ou en mode ardeur meurtrière, cela aie un impact. Si je reprend la logique, on a donc (oui je reformule avec mes mots) :
- Depho : pas attaquable, mais avec des malus sur le PvE
- Vert "tout va bien" : on est attaquable, mais on n'a attaqué personne depuis X temps. État qui devrait concerner la majorité des gens.
- Violet : tant qu'on n'a pas tué de Vert mais qu'on se bagarre quand même, OK.
- Rouge : avoir tué un perso vert (pas bien !), statut qui reste un certain temps (10 minutes ?).

Ce qui veut dire que si on est Vert, qu'on se fait attaquer, et qu'on riposte avant de mourir, les deux passent en Violet. Donc, ça, c'est un statut PVP consensuel : les deux acceptent le combat. Ici, soit on veut favoriser les bagarres de rue et on donne des bonus à ce statut, soit on considère que c'est OK et fun sans vouloir l'encourager, et c'est juste "neutre" : ni bonus, ni malus.

Ce qui ne nous plait pas, c'est le mode rouge/vert : quelqu'un qui tue une autre personne qui ne se défend pas. Ça c'est mal, pas bien, pas Honorable ! Donc, déjà, je proposerais une perte d'Honneur pour le Rouge à chaque meurtre de Vert. Et, tiens, quitte à gagner/perdre des points :

- Violet tue un Violet : tous les deux gagnent un point
- Violet tue Rouge : Violet gagne le nombre de point que Rouge a perdu dans la dernière heure.
- Rouge tue Violet : Violet gagne un point.
- Rouge tue Vert : Rouge perds un point. Vert en gagne ? Est-ce honorable de se faire tuer sans rien dire ?

Évidement dans cette logique, il suffira que le PK fasse du pvp consensuel avec ses amis et alts (en violet donc) pour regagner ses points et compenser ses meurtres le reste du temps, mais il me semble que ça donnerait un signal assez claire de "hou, là, ça, c'est pas bien !".

Dans cette optique, ce n'est pas un joueur qui prend quelque chose à l'autre. Sachant que par ailleurs, quoi qu'il arrive, on laisse tomber sur place tout ce qui n'est pas dans l'inventaire "poches" et qu'il faut venir le rechercher ; et que c'est débloqué à tout le monde après un certain temps. Ce temps pourrait être plus court pour les Rouges, plus long pour les Verts.

Quand aux points d'honneur, je me dit qu'en plus du côté kikimeter, leur intérêt pourra être chez les marchands : quelqu'un avec beaucoup d'honneur aura des réductions à Natca. Mais dans ce cas, je verrais bien une jauge avec un maximum (pour le pourcentage de rabais), et qui se remplit avec des points ayant une durée de vie (ceux du pvp durent 10 jours par exemple, ceux d'un combat de source durent quelques mois, etc).

Je vais oublier d'ici jeudi donc je le note dès maintenant.

J'ai repris le thème des wikis avec en particulier une grosse modification de la barre des outils à droite (en mode Bureau, pas sur mobile). J'attends vos retours, voir ce qu'il y a encore à améliorer dans ces thèmes. Sachant que je suis assez contrainte par dokuwiki lui-même. Par exemple la loupe de la recherche, elle est grise et pénible à placer, mais dans mon thème je n'ai qu'une appel à la fonction "recherche" de dokuwiki donc pas évident à bidouiller. De même, j'aurais aimé personnaliser ces icônes et les mettre en violet, mais il me faudrait un expert php pour voir comment hacker mieux, là je n'ai pas trouvé mieux.

Et j'aimerais vraiment une critique constructive :  est-ce que niveau ergonomie, c'est bien ? Est-ce correctement accessible ? Si non, que peut-on changer ? Parce que même contrainte, il y a quand même pas mal de choses que je peux faire

J'en ai profité aussi pour mettre à jour la barre de navigation générale (visible sur les wikis), en enlevant le lien vers le serveur de jeu (mort...) et en redirigeant le chat sur la page hébergée par Jabberfr, infiniment plus propre que mes anciennes bidouilles.

[financement]

Je continue mon tour d'horizon, cela permet aussi de (re?)noter des éléments décidé pour Khanat, et de les discuter.

Concernant le financement, on est sur le point où, pour moi, on a un foirage. Je reste persuadée que notre modèle économique final est viable et vertueux. Mais, pour y arriver, il nous manque des étapes.

Pour rappel, le modèle économique que nous visons est le suivant :
- l'accès au serveur Khanat, où se concentrera l'animation, est ouvert à tous, sans contre-partie, en période calme. Il est possible de souscrire un abonnement pour soutenir le jeu (et encouragé, mais uniquement dans l'optique de participer à soutenir ce qu'on aime). En période d'agitation cependant, l'accès au serveur est réservé aux personnes ayant un abonnement OU un investissement bénévole important (voir les deux). Une période d'agitation, ça peut aussi bien être une attaque de spambot (le temps de réduire la pression), qu'un trop grand nombre de connexion par rapport aux possibilités du serveur ; l'abonnement sert alors à prioriser les accès, jusqu'à un retour à la normale. Je suis certaine que cela suffira à payer les serveurs et probablement quelques postes salariés, si la communication est bien faite.
- Il sera possible de financer directement certaines améliorations, via un mécanisme tel que celui de Redbricks. C'est une incitation supplémentaire au don, de façon ciblée.
- Le serveur Tepsne (qui veut dire "cauchemar"), conçu comme un espace de test, aura probablement une boutique IG permettant de littéralement TOUT acheter. Ce ne sera jamais un serveur de "jeu", le fait même d'avoir un mécanisme de pay2win rendant le lieu imbuvable (mais, par design, ce serveur est là pour se défouler et être invivable). C'est une façon de répondre aux critiques et attentes d'une certaine population de joueuses, qu'on n'a pas vraiment envie de voir s'installer et râler sur le "bon" serveur. Si accessoirement ça fait rentrer des sous, tant mieux. Évidement aucun transfert de perso entre les deux serveurs n'est possible.

Maintenant, là où ça pêche, c'est que tous ces modèles demandent un jeu fonctionnel. Le financement en amont n'a pas été prévu. Le sujet a été abordé ailleurs, je ne développerais pas plus ; ou plutôt, un de ces jours, il faudra trouver comment financer réellement le développement du jeu, car espérer suffisament d'énergies bénévoles sur un projet de cet ampleur... on en voit les limites.

À propos du feedback et des retours des joueurs, je plussoie.

Pour moi, nous devons faire quelque chose en ayant en tête une certaine population. Cette cible a été suffisamment décrite par ailleurs : on sait à quel type de joueuse on s'adresse. Si le jeu plait à d'autres cibles, génial, mais nous devons toujours avoir en tête que les désirs de notre population-cible sont absolument prioritaires. Cela veut aussi dire que lorsque notre population sera plus grande, toute modification importante devra auparavant être vérifiée via des enquêtes. Pour moi, le processus sera le suivant :
- un espace où tout le monde peut faire des propositions et les discuter
- Si certaines propositions semblent populaires ou pertinentes, on les intègrent dans une enquête où on demandera "est-ce que la fonction X implémenté de telle façon vous intéresse ?"
- Il y aura maximum une enquête par mois (le but n'étant pas de submerger les gens), ouverte à toute personne impliquée dans le jeu (bénévoles et/ou mécènes). Oui, j'excluerais de base les touristes de ce genre de chose. L'enquête permet que ceux qui ne se sont pas intéressés aux propositions valident ou non, sans avoir besoin de se mettre en avant sur un espace public.
- Suivant les résultats, on mettra la fonctionnalité dans la pile de trucs à développer. Ou pas.

Concernant la boulimie vidéoludique, et de façon générale les mécanismes de consommation, nous nous inscrivons vraiment contre ça... Cela implique des communications marketting différentes (éviter les grandes promesses, les dates de sorties annoncés en grande pompe), des mécanismes en jeu spécifique (porter attention aux possibles mécanismes d'addiction et les questionner). Notre objectif est de faire un monde où il fait bon vivre et où, au final, les joueurs reviendront après consommation de grands titres. En langage marketting, on va s'adresser non pas au public qui cherche la nouveauté, mais à celui qui cherche la stabilité (et qui est trop souvent délaissé). Mais, il est évident que les soutiens auront des vagues, suivant les calendriers de sortie de certains jeux AAA. Il est aussi évident qu'à un moment, une partie des gens part, parce que "plein de choses" : changement de vie, impression d'avoir fait le tour, besoin de changer d'air... Peu importe, pas grave, le but n'est pas de garder les gens ad vitam, mais de proposer une bonne expérience le temps qu'ils sont là. C'est la meilleure pub qui soit.

[Attrait social]

Je répond ici à certaines choses, je trouve ça plus simple.

Attrait social
C'est un point que nous avions déjà identifié comme central. Sur Ryzom, l'une des quêtes du tutoriel est de "trouver une équipe" (pour tuer des créatures). La mission est, en réalité, absolument faisable seul, mais le fait que le PNJ incite à créer une équipe fait que beaucoup de joueurs, à ce moment, se mettent à chercher des gens avec qui jouer. Lorsqu'il y avait du monde en jeu, c'était le moment où la phase de socialisation commençait pour de bon. Par ailleurs, le jeu lui-même demande d'avoir des gens avec qui jouer pour monter ses niveaux. Avec la désaffection des serveurs, cela a été remplacé par un usage massif des rerolls, au détriment de la socialisation.

La leçon est assez simple : il faut que le gameplay incite à avoir des échanges avec les gens, mais aussi que cet échange soit suivi. C'est l'un des grand échecs de GW2 (à mon goût, mais en réalité réussite dans ce que GW2 vise) : si former des groupes et équipes est nécessaire pour certaines tâches, il n'y a besoin d'aucune coordination ou suivi, juste d'avoir un gros tas de monde qui tape les mêmes trucs. Bon, pour être honnête, ce n'est pas complètement vrai ; sur GW2, des équipes soudées peuvent explorer des résolutions de quêtes inédites, là où les bourrins auront toujours la même histoire. Mais tout le design est là pour que les bourrins casuals dominent.

Notre optique vise aussi à appuyer la partie RP. Comme le dit Nomys, que le joueur soit incité à "faire partie du monde", en ayant des liens avec des joueurs et PNJ (mécanisme des lanzu, des kagni), avec beaucoup d'outils renforçant le jeu social (rp politique, déco et housing, etc). Nous incitons aussi au pvp, mais de manière consensuelle (possibilité de ne pas être attaquable, au détriment de quelques bonus en jeu ; apprentissage du "jouer ensemble" dans les tutoriels, combats consensuels via les Sources et l'Arène).

Sur ce que Nomys résume en "de créer de faux serveurs (!?)", je crois que c'est un truc que m'a résumé YannK : limiter le transfert de perso d'un"monde" à un autre. Dans notre cas, cela ne se pose pas trop, car il n'y a pas d'xp ; la "valeur" d'un compte tient dans les histoires qui lui sont attachées et les amis qu'il se fait en jeu (ou qu'il y amène). On peut potentiellement permettre, à l'extrême limite, d'exporter/importer un skin de perso ; tout le reste n'a pas de sens. (Si c'est autre chose, je veux bien plus de détails)

Concernant l'automatisation, l'ajout de contenu et le grinding, voir la partie sur les Bot dans l'article sur les Rerolls. Ma position sur le sujet n'a pas changé : si on a des bots qui apparaissent, c'est que ce n'est pas fun. Si je ne suis pas fan du grinding par ailleurs, je reconnais que cela a aussi une valeur de flow dans certains cas et en particulier dans les moments où la population sur un serveur est basse. Que ce soit le forage sur Ryzom, ou dans des jeux solo comme Stardew Valley où on plante des navets, on arrose des navets, on ramasse des navets... on ne peut pas exclure ce genre de gameplay complètement. J'aurais cependant tendance à le réserver à des phases de jeu absolument facultatives, du "jeu dans le jeu" ; typiquement des mécanismes de jardinage/culture. Mais il faut des mécanismes à la fois très léchés, ET incluant des "coupures" dans le flow afin de lutter contre les mécanismes d'addictions.

Concernant l'endgame, on a vraiment évacué ça avec le mécanisme de gameplay de base de Khaganat. Si, potentiellement, un perso peut apprendre "toutes" les compétences, il ne peut en avoir qu'un certain nombre actif à un moment donné et doit en oublier pour en apprendre des nouvelles. Cela force à la fois à jouer avec d'autres (pour se compléter sur les compétences) et fait qu'on n'est jamais à un moment où on sait "tout". Nous avons aussi décidé de délimiter les zones casual des zones à haut challenge : trainer en ville ne demande aucun "skill", aller se balader dans certaines régions demandera des équipes soudées avec des compétences spécifiques et des stratégies adaptées. Cependant, un casual pourra toujours se greffer sur une expédition de gamer hardcore, sans être forcément un poids.

J'aurais encore des choses à dire, mais plus tard

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.

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.

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.

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.

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

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

[Spoiler]

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

Vous vous demandez si vous êtes inscrit à la lettre d'information ? Vous pouvez le vérifier ici. Cette liste est visible uniquement par les membres inscrits sur le forum. Il n'y a que les pseudos, pas d'adresse mail, bien sûr. 

Personnellement, je ne suis pas favorable à une rencontre "en vrai". Sauf si on est très peu et en été (pour pouvoir ouvrir les fenêtres non stop). Tant que l'épidémie ne sera pas réellement sous contrôle, je préfère limiter les risques autant que possible, de façon très égoïste. Après si vraiment vous y tenez, je ne suis pas obligée d'être là 

Je serais pour expédier la paperasse avec préparation en amont (via pads et forum), avec un mumble/jitsi pour l'AG afin de voter "ok on valide" et voilà. Efficacité avant tout... Je dois aussi dire que je suis encore dans ma phase ronchon et donc absolument prête à vous présenter un bilan moral en 3 phrases et un bilan financier résumé à "on a encore X € sur le compte". Celles qui ne seront pas contentes pourront se présenter au collège ! Mais bon, je dis ça, il est probable que je trouve la motivation d'assister mes collègues du collège dans cette préparation

Le plus gros travail en amont va être de vérifier qui était membre cette année et peut donc voter à l'AG ; je n'ai pas tenu cette liste à jour.

Pour la partie convivialité, qui nous manque grandement, je préfère qu'on s'organise des AFK en petits groupes quand il fera beau.

Pour la date, mercredi 11 mai 2022 à 21h30, sauf si une membre a un veto pour cette date et dans ce cas elle en propose une autre. On valide ça jeudi soir

Ouais, c'est légèrement directif, c'est pour expérimenter le degré d'aliénation de tout le monde 

Il n'y a pas eu de hauts cris sur la refonte du gitlab de Khaganat en gitlab de Numenaute, donc j'acte et je bosse sur le sujet. Le nom pressenti pour l'instance officielle sera port.numenaute.org ; les anciennes adresses continueront de fonctionner.

Les compte-rendus des réunions hebdomadaires sont la voie d'entrée pour répondre à toutes ces questions et même plus. 

Un point intéressant soulevé par Deed à propos de la forge gitlab : est-ce qu'on la garde au nom de Khaganat ?

Héberger une forge logicielle demande pas mal de ressources. C'est même le logiciel qui prend le plus de ressources actuellement (surtout si on lance des CI, héhé). Cela demande aussi une maintenance assez régulière. De ce fait, faire tourner plusieurs versions du logiciel est trop coûteux à tout point de vue.

Il nous est possible de faire que git.khaganat.net et git.numenaute.org pointent sur la même forge. Cela ne change donc rien pour les adresses et les dépôts. Par contre, pour le moment ça ne semble pas évident d'avoir un thème et une page d'accueil différente suivant le nom de domaine par lequel on accède au site. C'est peut-être possible techniquement mais on n'a pas encore trouvé comment le mettre en place.

Vv222 a soulevé cet argument important : "Khaganat n'a pas grand chose à gagner en affichant son identité visuelle sur une forge git. Contrairement à Numénaute. "

Effectivement, nous avons pris la décision de séparer le rôle d'hébergement de celui de la création au sein de Khaganat. Dans ce sens, avoir une forge "Khaganat" continue de nous placer comme hébergeur d'un service pourtant ouvert à des projets tiers (nous avons du code qui n'est pas pour Khaganat) ; alors que Numenaute a justement vocation à accueillir plus de variété. Deed disait : "je pense qu'on peut fournir un service à quelques Dev Godot en échange d'un peu d'argent et un peu de contribution sur client khanat. J'ai eu quelqu'un par exemple qui avait juste besoin de compiler son jeux donc  lui fournir juste le CI ."

Il faut aussi voir que si une forge demande du temps humain de maintenance et de la puissance serveur, ça ne change pas grand chose d'héberger 1 ou 20 projets. Tant que tout le monde ne lance pas les CI au même moment ! Il y a beaucoup de moment où la puissance au service de Gitlab est inutilisée. Si, à un moment, on découvre qu'un usage ralentit tout le monde, on pourra aussi adapter les règles (par exemple donner des créneaux horaires pour ça aux divers organismes, demander qu'il y aie communication sur un canal dédié, ou simplement ajouter un peu de puissance, payée par nos utilisateurs en plus).

De mon côté, je suis OK pour changer l'identité visuelle du Gitlab, en passant du violet Khaganat et de la page d'accueil liée, au bleu Numénaute et à une autre présentation sur la page d'accueil. L'enregistrement restera limité à des règles strictes pour le moment, qui évoluera en fonction de notre lutte contre les spammeurs.

Moi ça me plaît bien