Changement à venir pour le client (Résumé Khanathon 22 juin 2018)

Nota : j'ai repris les logs et les aie un peu retravaillé pour en extraire les informations importantes, ça me semblait important d'archiver publiquement et durablement cette proposition.


YannK -- C'est à propos de la direction stratégique du système de jeu. On n'arrive pas à recruter suffisamment d'énergie pour avant sur les outils nécessaires à la création de contenu ni à la modernisation nécessaire du client, seul osquallo a pu avancer dessus, malgré ses soucis, mais ce n'est évidemment pas viable. Je me disais qu'on pourrait peut-être prendre la question par l'autre bout, donc. On a toujours dit qu'on voulait pouvoir avoir différents clients pour jouer de façons variées (à terme), donc il serait peut-être plus pertinent de bosser sur la partie réseau du client et de rendre ça plus facile à connecter à un nouveau système, d'autant qu'on a la chance que Godot soit désormais très mature et fonctionnel, avec plein de features dont on n'ose pas rêver pour notre client, Armory 3d qui est pas mal parti (système de création intégré dans Blender) et le Blender game Engine qui va renaître, surtout avec l'annonce faite aujourd'hui par Blender du projet All Nodes. Bref, il existe au moins 1, voire à terme 2 ou trois solutions libres pour développer des clients modernes, auxquels il ne manquerait que l'interfaçage avec notre système serveur (que est un euphémisme, il faut aussi traiter les données). Le boulot demeure énorme, mais il aurait l'avantage de se faire dans des frameworks modernes, dont nous n'aurions pas la charge de maintenance. Il faudrait donc se focaliser dans les objets NeL non graphiques pour pyNeL et réfléchir à une lib moderne qui permette d'échanger avec nos sytèmes serveur, tout en essayant de documenter lesflux de données qu'on récupère, à quoi ils correspondent : ce serait notre priorité.

osquallo -- En gros maitrise la langue que parle le serveur et savoir communiquer avec. Faut déjà documenter les échanges client/serveur après on verra pour la suite.

YannK -- En parallèle à ça, je pense que vers la fin de l'été, j'aurai du temps (j'espère) à consacrer à du graphisme et je me disais que je ferai bien une petite démo d'un cmedzu dans Godot (a priori), histoire qu'on ait enfin un visuel vraiment khanatien à montrer, de ce vers quoi on veut aller visuellement; Ça nous (me) ferait du bien de voir en vrai le Khanat dont on rêve, même si ce ne sera pas en multijoueur.

Deed -- Si j arrive à faire fonctionner snowball , je pense que ça ira vite très vite

Lyne -- Je pense que je n'en maîtrise pas bien les implications. Présentée comme ça, elle semble intéressante.
YannK -- Les implications, c'est qu'on laisse "tomber' le client actuel, faute d'énergie. Et qu'on tente de trouver un moyen de se brancher sur des frameworks plus récents, où, je l'espère, on peinera moins à trouver des gens motivés.
Lyne -- Le client Ryzom ? On ne garde que le moteur ? Ou même pas le moteur ?
YannK -- On se focalise sur la partie serveur, on laisse tomber le client. Du moins, on n'y consacre plus d'énergie, ni à lui, ni à ses outils dédiés.
Lyne -- Y'a quoi sur le serveur. Et y'a quoi dans le client ? Où est le moteur ?
Deed -- le client c'est ce que tu vois, entend. Et le server c est ce que tu fais.
YannK -- Le serveur, c'est un ensemble de services, qui gèrent la connexion à ton compte, lévolution du monde, les IA de région, les traductions et messages, la localisation etc. Le client se contente de rendre tout ça visuel et avec des moyens pour interagir.
osquallo -- c'est l'interprete entre nous et le serveur en gros. En fait en general on parle de moteur 3d surtout en parlant de moteur, donc le client, la partie qui est sur ton pc :p
Lyne -- Ok. Donc le serveur, c'est ce que j'appelle le moteur. C'est là qu'est l'intelligence.
YannK -- oui Lyne
linkmauve -- Le serveur est aussi celui de Ryzom ou c'en est un custom ?
YannK -- Le serveur Rzyom Core est celui utilisé par le jeu commercial aussi, linkmauve. Le client original demeure fonctionnel, c'est just qu'il ne pourra pas afficher le nouveau contenu, vu qu'on n'a pas les outils qui le permettent.
linkmauve -- Ok.
YannK -- C'est dommage que StraToN ne soit pas là, il connait mieux Godot que nous je pense, mais mon calcul, c'est que si on arrive à avoir une interface 'standard' pour récupérer les flux de données de notre serveur pour ensuite développer un client Godot, ça pourrait intéresser la communauté Godot d'avoir un moteur de MMORPG compatible, et ça pourrait permettre d'avancer plus vite
Lyne -- Ah, ça, je comprends *_*
merlun8282 -- a priori je serais de l'avis de Yannk ; au pire on pourrait toujours revenir sur le client originel (vous saisissez aussi le jeu de mots hein ?)
Lyne -- Ça rendrait l'édition de cartes plus faciles, par exemple ?
osquallo -- et comme le seul qui se lance dans le taff pour changer ca est dans la choucroute ...
IsilinBN -- hum Yannk, un moteur de mmorpg, c'est peu envisageable. ça serait beaucoup trop générique donc pas du tout optimisé.
YannK -- IsilinBN, si on a un truc plus propre, c'est une base qui peut être forkée, adaptée, mais on aurait un moteur 100% libre de MMORPG, ce serait le seul
linkmauve -- Ça pourrait peut-être intéresser les gens de Ryzom non ?
YannK -- linkmauve, non, ils sont très frileux sur le développement aussi radical car ils ont une base de clients et des systèmes en production, donc ils préfèrent conserver l'existant plutot que prendre des risques. Ils ont une posture assez conservatrice en général
osquallo -- de toute façon faut doc le bordel deja
YannK -- Et vu qu'on aura un framework moderne, ce sera l'occasion aussi de changer des choses visuellement, bien sûr, et donc de modifier de plus en plus les services distribués par le serveur, forcément. Du coup j'aimerais en profiter pour nettoyer la base de code d'un maximum de choses, car là c'est juste effrayant pour le nouveau venu.
Deed -- bah snowball est tres petit et on a tous ce qui nous faut pour débuter. Je vais le mettre en ligne demain.
YannK -- En effet Deed, mais snowball n'a pas tous les services Mais déjà avoir un dépôt où ne se trouve que ce qui est nécessaire au serveur, ça serait moins labyrinthique Ce pourrait être l'occasion de réorganiser pour éviter d'avoir les .cfg, les sources et les exécutables tous mélangés, aussi :-° Enfin bref, axer notre travail sur la mise en place d'un dépôt OpenNelServer mieux structuré et développer une lib qui serve à communiquer avec.
osquallo -- decoupler le depot RC et les "outils" aussi
Deed -- faire des bricks , de toutes les fonctions serait obligatoire même
YannK -- Il me semble que c'est le moment, on a des partenaires logiques, avec des communautés comme Godot/Blender, désormais, où se trouve tous les outils dont on a besoin. Allons vers eux plutôt que de tenter de forcer à les faire venir à nous. Ceci dit, ça veut dire qu'il faut quand même qu'on trouve plus dénergie en développement, si on veut que ça avance
Lyne -- On ? :-p
YannK -- que nous trouvions, de façon collective, tu as raison, pas 'on'
* Lyne note : Se mettre à plusieurs pour kidnapper Straton...
YannK -- Pour avoir vu les réactions, je me dis que le projet sera moins effrayant pour d'éventuels nouveaux contributeurs. Et si en parallèle, on bosse sur des visuels dans Godot avec un mini client hors ligne de démo, ça peut aussi motiver Et avec Godot, on peut même faire de la VR pour faire visiter le Khanat aux gens pendant les salons Il ne nous manque qu'un casque de VR et un ordi pour le faire tourner

YannK -- Bon, vu que personne n'a hurlé, on part sur ma proposition, voir si on arrive à mieux avancer que précédemment.

Je n'étais pas là hier, et j'ai quelques points à ajouter.

Comme nous avons pu en discuter par ailleurs, il faut de toute façon, à terme, étudier comment fonctionne les échanges réseaux afin de faire évoluer cette partie. Pour rappel, l'infra réseau développé par Nevrax a des points forts (très faible charge en bande passante en particulier, bonne résilience), des points faibles (développé dans les années 2000 sans mise à niveau depuis, la sécurité a beaucoup évolué depuis et on risque de trouver des trous) et des aspects qu'on peut faire évoluer grâce aux évolutions techniques (cf l'idée de faire des clients qui redistribuent les échanges, sur un concept apparenté au p2p : http://kiwano.li/ ).

Comme le travail doit être fait... aujourd'hui ou plus tard, c'est pareil. Par contre, si cela nous évite de faire du travail inutile, alors il faut commencer par là en priorité. Actuellement, pour utiliser le client actuel, il faut que nous développions divers outils et librairies associées, et même comme ça, le client lui-même accuse son âge sur certains points, ce qui demandera un jour du boulot pour le faire évoluer (en particulier sur la gestion de certains paramètres 3d). À côté de ça, il existe déjà des clients de jeux qui ont ces paramètres modernes et des outils adaptés... il reste à les brancher sur notre réseau, afin de communiquer avec le serveur.

Rien de tout ça n'est trivial, mais pour moi, cette façon de poser l'équation aide à la décision.
- D'un côté on a "Faire des librairies pour le client, faire les outils, puis dans un second temps se plonger dans le code réseau, le modifier et sans doute faire des librairies pour ça"
- de l'autre "Se plonger dans le code réseau et faire des librairies pour le connecter à un autre client".

Bon ben même si ça reste énorme y'a une étape de moins dans le second cas.

Je reprends aussi la remarque d'Isilin sur le fait qu'un moteur de MMORPG est trop générique : il faut voir qu'on va pouvoir proposer à Godot une brique possible, du type "mmorpg Nel" ; ce moteur de MMORPG a évidement des contraintes qui lui sont propres et qui font que ce n'est pas un moteur adapté pour un MMOFPS par exemple, ni sur un MMORTS. Mais la base est quand même à la fois solide et versatile, permettant de couvrir des besoins assez variés. Typiquement, nous concevons pour Khanat un système d'expérience et un arbre de compétence très différent de l'expérience gameplay de Ryzom, ce que le moteur permet de faire sans difficulté autre que de remplir des tableaux de paramètres. Donc même si ce que nous proposerons ne couvrira pas tous les types de MMO, cela sera quand même un sacré apport, permettant de faire des jeux variés. 

J'apprécie aussi l'idée de travailler avec d'autres communautés du libre, d'une façon plus complète que les simples bavardages. C'est une des grandes forces du libre, de pouvoir agir en collaboration et non en compétition.

Enfin, je reprends aussi quelques mots...
"On n'arrive pas à recruter suffisamment d'énergie pour avant sur les outils nécessaires à la création de contenu ni à la modernisation nécessaire du client"
"Pour avoir vu les réactions, je me dis que le projet sera moins effrayant pour d'éventuels nouveaux contributeurs."
"Ceci dit, ça veut dire qu'il faut quand même qu'on trouve plus dénergie en développement, si on veut que ça avance"

Là dessus, le souci n'est pas que les contributrices n'existent pas ou sont effrayées par notre projet, mais vient avant tout d'un défaut de communication de notre part. Enfin, oui, ok, forcément certaines prennent peur en voyant le bordel, mais des projets bien plus horrifiants ont su motiver du monde (regardez l'histoire Open Office...). Pour le moment, notre publicité s'est adressé à un petit public, et pas forcément le plus adapté pour les compétences que nous recherchons. En même temps, nous n'étions pas complètement sûr de ce que nous cherchions.

Pour moi, la priorité serait donc de faire venir les gens ayant les compétences qui nous manquent. Cela veut dire de faire des communication au sein de communautés ayant pleins de gens avec ces compétences. Malheureusement, je n'ai pas un profil assez technique pour être certaine de ce qu'il faut chercher, et où. Si je ne me trompe pas, il nous faut des gens :
- sachant lire le C++ et documenter : on trouve ça où ?
- sachant déchiffrer les échanges réseaux : Linuxfr est l'un des endroits où on peut trouver ce genre de compétence, et sinon il faut trouver où les administratrices réseaux (pas système !) se nichent,
- sachant coder des librairies en python vu qu'on va passer par ce langage et ce format : là il semblerait que ce soit Zeste de savoir, où il y a un réservoir de pythonistes
- pouvant lier le bazar à Godot/Blender/Armory3D ; Godot me semble le choix logique car il y a une communauté active et que le logiciel est très abouti pour le jeu vidéo, et donc c'est facile, on va chercher chez Godot.

Et c'est à peu près dans cet ordre là qu'il faut les chercher. Nous avons commencé à travailler avec Akberid sur plusieurs publications à destination de Zeste de Savoir, et il me semble important de mettre nos efforts dans la finalisation de ces écrits, qui serviront aussi de base dans d'autres communautés.

Parallèlement à ça il y a toujours l'aspect "accueil des arrivant⋅e⋅s". On est sympa, ça semble bien marcher mais notre point faible reste toujours de guider ces nouvelles venues dans la jungle khantique, de trouver de leur donner un boulot en rapport avec leurs envies et leurs capacités, qui ne soit pas trop gros afin qu'elles aient le sentiment d'accomplir des trucs et pas de se noyer dedans. Pour le moment on ne peut avoir que des contributions de gens très autonomes, ce qui n'est pas forcément le profil des analyseurs de code et documentratrices.

Voilà, donc du job "non technique" (rédiger des présentations c'est avant tout de la rédaction ), pour lequel on a quand même besoin de très  technique afin que les gens soient alléchés par le défi. On peut y arriver