Khanathon : que fait-on avec Godot ?

Nous avions l'été pour explorer Godot et voir si on l'utilisait pour le client, en remplacement du NeL actuel, ou pas. Il va être temps de faire le point et voir où on va.

Au menu de ce Khanathon :
- Est-ce qu'on fait un client de jeu avec Godot ? Je crois que la réponse penche vers un oui. Mais est-ce qu'on le fait multijoueur ou est-ce qu'on se contente dans un premier temps de s'en servir en mode "solo" afin de tester des hypothèses au niveau design et visuel ?
- Est-ce qu'on lâche complètement le client actuel ? Pas de librairie blender2nel ?
- Qui veut bosser sur quoi ?
- Qu'est-ce qu'on va faire ?

Je suis un peu fatiguée au moment d'écrire ce message donc mes idées sont peu claires et la présentation du Khanathon mérite d'être affinée. Ça tombe bien, vous pouvez le faire aussi

Côté réunion, je vous propose deux choses :
- Avant tout, ce sujet est là pour ça, vous pouvez laisser vos réactions, et puis c'est bien adapté pour développer des argumentaires et des idées.
- Je ne vous propose pas "une" réunion pour le moment, ne connaissant pas les disponibilités de chacune, mais je vous invite à causer du sujet lorsque vous êtes en ligne Et afin de suivre le plus important, merci de recopier ensuite ici les bouts de discussions utiles (ce qui a fait avancer le schmilblick).

Je vous laisse vous emparer de tout ça. J'aimerais que d'ici vendredi prochain, un plan d'action se dessine, afin d'éviter de se disperser trop et de perdre du temps à faire des trucs qui ne serviront pas.

Je pense que dans un premier temps il serait bon de voir quel genre de compétences vous avez à disposition.

Ensuite faire une liste méga exhaustive des avantages et inconvénients. Je pense notamment à la partie qui partait du fait qu'on pouvait utiliser le python pour le client Godot. C'est vrai mais celui s'appuie sur un plugin experimental, Il faudra aussi le prendre en compte. Il semble que la non utilisation du C# dans Godot soit assez certaine (Vive le libre) ça fait une décision de moins.

Un des inconvénients que je vois en ayant planché un peu sur le côté réseau du jeu ( rien de bien sérieux juste de la lecture de documentation et des discussions avec Tycho notamment.) C'est que d'autant que je puisse en juger il risque de falloir hacker godot et ses fonctions pour communiquer avec Nel. Ca passe par de la réécriture de fonction de chiffrement mais aussi au niveau du réseau car si j'ai bien compris Nel a son propre type de paquet réseau qui est non standard. A voir avec un expert de Godot (StraToN I'm looking at you)

L'avantage majeur sera la qualité graphique qui bien que non prioritaire va rendre votre jeu beaucoup plus attractif. Les gens sont toujours choqué par la qualité graphique de 0AD parce que ce n'est pas du tout a quoi ils s'attendent.

Je ne sais pas ce qui est possible avec le client d'origine, les devs graphiques  (Côté code) sont assez rares

Quoi que vous choisissiez ça va être un gros investissement technique.
Pamjai a tous ce qui veulent.

Il y a plusieurs choses.

Avant tout, et c'est effectivement important de le rappeler, parce que l'info n'est pas passée partout, on ne code pas dans Godot en python ; Godot utilise un langage proche de python et qui permet de faire un peu tout ce qu'on peut imaginer dans le client. Mais ce n'est pas du python, même si ça y ressemble. Le plugin pour utiliser python n'est pas encore au point ; c'est dans les cartons, si j'ai suivi, mais ce n'est peut-être pas pertinent de partir dessus (à voir, en tout cas ça me parait pas forcément pertinent tant que c'est expérimental). Je parle bien de ce qui se fait à l'intérieur de Godot.

Ensuite, il y a le côté "Godot communique avec le reste du net", dont le serveur. Là, on a plusieurs possibilités, mais il me semble pertinent de rester dans la logique des librairies : des petits morceaux, qui font un truc et le font bien. Il est important de bien séparer le client de jeu et ce avec quoi il communique. C'est là qu'il va y avoir un travail de code d'un niveau complexe. Il faut bien être conscient des diverses couches qui sont en relation ; par exemple le compte joueur (login+password) va tout à la fois être appelé dans le serveur de jeu pour autoriser l'utilisation d'un personnage, et sur le serveur web, dans la partie forum par exemple. Et sur la partie chat (xmpp, en principe). Ce login sert donc sur 4 outils (au moins) qui sont physiquement et techniquement très différents. Et bien que j'ai besoin d'envoyer le login au forum, ça ne sert à rien que j'envoie la position de mon personnage aussi (par contre le serveur de jeu en a besoin). Il y a un bon travail d'analyse à faire, donc avant de partir bille en tête pour brancher les trucs, prenez le temps de lister et documenter ce qui est nécessaire.

Dans ce que nous allons coder pour faire ces liens entre les logiciels existants (et quelques uns à créer), dans l'absolu n'importe quel langage peut être utilisé : c'est des librairies donc, hein, vous faites ce que vous voulez, tant qu'on sait ce qu'on doit appeler. Maintenant, nous avons fait le choix de favoriser python et il me semble important de rappeler pourquoi :
- c'est un langage facile à apprendre ; et de fait beaucoup de dev même débutants le connaissent, donc ça augmente les possibilités de participation et de maintenance par la suite
- il permet de développer et tester rapidement des hypothèses (pas de compilation, peu de possibilité de faire des vraies erreurs)

D'autres langages ont des arguments similaires... mais là, c'est un fait, ce doit être le langage le plus parlé par nos membres actuels. Encore une fois, si vous voulez faire appel à des librairies en rust ou en C++, pourquoi pas, mais dans ce cas soyez conscients que vous serez probablement la seule personne à pouvoir la maintenir dans le temps. Python a ses propres limites, cependant, et pour des questions de performance entre autre il sera probablement utile, une fois les hypothèses testées, de refactoriser, peut-être dans un autre langage. Ceci dit, la priorité est de tester les hypothèses, de voir et tester comment ça marche, de documenter les processus.

Pour tout ce qui est question de chiffrement, notre expert local, c'est Tycho, et il a plus d'une fois donné la preuve de ses compétences sur le sujet. Si vous voulez jouer avec cette partie du réseau, allez obligatoirement discuter avant avec Tycho : il vous indiquera les librairies déjà existantes et pertinentes, pointera les faiblesses éventuelles, évitera de perdre du temps sur des voies de garage et des tâtonnements. De façon plus générale, il a une bonne vision des questions de sécurité (pas sur tout, mais probablement plus que tout le monde ici), donc allez lui présenter vos hypothèses avant de travailler. D'autant qu'il n'aime pas du tout quand il voit des erreurs (genre choisir le mauvais protocole) et il se met alors à mordre

Pour la partie réseau plus générique... C'est la partie qui m'effraie le plus. Le serveur de jeu est un sacré bébé. Il accuse son âge et sur les questions de réseau, cela veut aussi dire des problèmes potentiels derrière, MAIS il est aussi extremement performant sur l'aspect réseau. Ce n'est pas du tout trivial, le réseau d'un MMORPG. Je ne suis pas chaude du tout pour qu'on joue avec ça sans savoir ce qu'on fait. Regardez, oui ; documentez ; par contre avant de brancher le serveur et un client Godot... Je ne veux pas qu'on se précipite.

Ce qui m'amène au point principal... La partie multijoueur est (relativement) secondaire à ce stade du projet. C'est un peu bizarre de dire ça pour un MMORPG, mais je le dis

Actuellement, nous avons un souci avec le client Nel : tout ajout de contenu est bloqué, très fortement, par le pipeline graphique (et sonore ; on l'a pas débuggué celui-là, et la doc manque vraiment). L'ajout de mission/quêtes se fait (laborieusement), mais globalement toute participation "de base" (de la part de gens sans gros bagage technique) est impossible à cause d'un coût d'entrée technique et financier absolument aberrant : on ne peux pas dire aux gens d'acheter 3DSMax, quant à leur faire installer le plugin, faut pas rêver.

Godot nous permet de contourner ça. Là, le coût d'entrée est plus bas, la prise en main relativement rapide, et on peut utiliser des objets créés dans n'importe quel logiciel 3D, des sons de divers formats, des textures, etc. Bref, Godot nous permet de construire le visuel et le gamedesign, de l'interface aux lieux où jouer. Il serait possible, au pire, de retranscrire ça dans Nel ensuite ; il est cependant probable qu'on utilise Godot...

Parce que, une fois qu'on aura l'équivalent d'une instance solo dans la zone de départ, une démo jouable et présentable, fun, ça va avoit plusieurs effets positifs :
- ça va nous faire du bien au moral, de pouvoir marcher dans le Khanat, même si c'est tout seul (on peut aussi brancher un serveur multijoueur de godot, pour croiser un copain, mais attention, ça sera pas du "massive" compatible)
- ça va permettre d'avoir un truc "vendeur", et donc d'aller recruter les compétences qui nous manquent
- ça va permettre d'accueillir tous les types de contribution, et c'est important quand on débute de pouvoir rapidement voir ce que donne nos contributions "en jeu"
- ça va potentiellement pouvoir servir d'argumentaire pour un crowfunding/une recherche de financement.

Sur ce dernier point, on ne s'emballe pas trop : la recherche de financement se fera uniquement si nous avons quelqu'un prêt à gérer l'organisation financière, administrative et gestion de com à plein temps. Ce n'est pas le cas pour le moment.

Je m'arrête là, j'ai ptet oublié des trucs mais ça fait déjà un bon pavé.

Je partage ton analyse, Zatalyz, sur la nécessité de prototyper un petit client solo de découverte. Cela nous offrira en outre l'occasion de créer des visuels, dont nous avons cruellement besoin. Je tente de m'organiser pour y affecter un jour par semaine dans les mois qui viennent, peut-être deux, à terrme. Être dispo en journée facilitera les échanges avec Osqua et les autres bénévoles disponibles. Je vais bosser sur la modélisation et le texturing. Après une longue période sans pratiquer, j'ai besoin de me dérouiller et de passer à Blender 2.8. Ce sera l'occasion.

Tout en bossant sur ce prototype, on pourra avancer sur le document de game Design et éprouver la faisabiltié dans Godot, à court, moyen ou long terme et valdier ou pas les prévisions. Cela nous permettra d'y voir plus clair sur les besoins et nos possibilités.

Par ailleurs, je serais assez pour faire en parallèle un test  de connecteur au serveur openNeL. On a besoin de savoir ce qui sort des serveurs openNeL précisément, ce serait l'occasion de le documenter proprement, sans préjuger de ce qui y sera branché. bien sûr, il faut ensuite voir comment on se brancherait avec un client Godot. Pour celui-ci afficher son résultat dans un écran IG serait assez meta je trouve. A voir si Neolinki est motivé sur le sujet. Pour moi les questions de sécurisation, d'échange à proprement parler viendront en un second temps. La priorité, c'est de pouvoir récupérer les flux tels quels.

Avant tout, et c'est effectivement important de le rappeler, parce que l'info n'est pas passée partout, on ne code pas dans Godot en python

Le script de connexion de Tycho est en python et dépend de librairies Python entre autres. Je ne connais pas encore bien les librairies natives à Godot mais je suppose qu'elles doivent être bien plus restreintes.

Dans ce que nous allons coder pour faire ces liens entre les logiciels existants (et quelques uns à créer), dans l'absolu n'importe quel langage peut être utilisé : c'est des librairies donc, hein, vous faites ce que vous voulez, tant qu'on sait ce qu'on doit appeler. Maintenant, nous avons fait le choix de favoriser python et il me semble important de rappeler pourquoi :
- c'est un langage facile à apprendre ; et de fait beaucoup de dev même débutants le connaissent, donc ça augmente les possibilités de participation et de maintenance par la suite
- il permet de développer et tester rapidement des hypothèses (pas de compilation, peu de possibilité de faire des vraies erreurs)

Quand tu connectes des logiciels entre eux, et particulièrement quand tu fais transiter des données, il souvent plus simple de rester dans le même domaine. Par exemple, avoir un client Godot, qui bien qu'il ne puisse pas interprèter le python, charge un script de manière extérieure (Pas dans la solution) obligeant a ouvrir un Shell sur la machine de l'utilisateur, qui au préalable doit aussi avoir python d'installé c'est un peu tiré par les cheveux, mais ce n'est que m'on avis.

par contre avant de brancher le serveur et un client Godot... Je ne veux pas qu'on se précipite.

Conserver la performance d'origine du réseau, ça implique se plier en 4 aux demandes du serveur, et de ce fait trouver un moyen de connecter Godot à un tel serveur est une grande priorité, puisque si c'est n'est pas possible et qu'il faut hacker Godot ou injecter des DLLs C++ à compiler pour chaque plateforme ca peut être un frein monstrueux.

Actuellement, nous avons un souci avec le client Nel : tout ajout de contenu est bloqué, très fortement, par le pipeline graphique (et sonore ; on l'a pas débuggué celui-là, et la doc manque vraiment). L'ajout de mission/quêtes se fait (laborieusement), mais globalement toute participation "de base" (de la part de gens sans gros bagage technique) est impossible à cause d'un coût d'entrée technique et financier absolument aberrant : on ne peux pas dire aux gens d'acheter 3DSMax, quant à leur faire installer le plugin, faut pas rêver.

Si vous ditchez le client nel au profit de Godot est-ce que tout ca n'est pas un non problème ? Il me semblait que quelqu'un avait fait un plugin Blender -Nel ?

Parce que, une fois qu'on aura l'équivalent d'une instance solo dans la zone de départ, une démo jouable et présentable, fun, ça va avoit plusieurs effets positifs :
- ça va nous faire du bien au moral, de pouvoir marcher dans le Khanat, même si c'est tout seul (on peut aussi brancher un serveur multijoueur de godot, pour croiser un copain, mais attention, ça sera pas du "massive" compatible)
- ça va permettre d'avoir un truc "vendeur", et donc d'aller recruter les compétences qui nous manquent
- ça va permettre d'accueillir tous les types de contribution, et c'est important quand on débute de pouvoir rapidement voir ce que donne nos contributions "en jeu"
- ça va potentiellement pouvoir servir d'argumentaire pour un crowfunding/une recherche de financement.

La motivation est un point très important. C'est quelque chose qui bascule très vite, et je suis très bien placé pour le savoir, ayant participé à au moins 5 projets de jeux comme le votre. Fixer des objectifs simple et les atteindre est primordial. CEPENDANT, il y a des objetctifs difficiles que vous devez vous fixer aussi (Le réseau en est un grand), sinon vous n'irez nul part. Pour faire une analogie, une peintre qui peint toujours la même chose ou des choses qu'elle sait faire n'avance pas. Et avant que vous recrutiez des gens dont c'est la zone de confort, il va sûrement falloir pour un certains nombre d'entre vous que vous sortiez de cette zone. Ya plein de choses à apprendre et c'est une grande aventure dont tout le monde sortira grandi et avec un petit peu de chance, avec un MMO super populaire.

Je partage ton analyse, Zatalyz, sur la nécessité de prototyper un petit client solo de découverte. Cela nous offrira en outre l'occasion de créer des visuels, dont nous avons cruellement besoin. Je tente de m'organiser pour y affecter un jour par semaine dans les mois qui viennent, peut-être deux, à terrme. Être dispo en journée facilitera les échanges avec Osqua et les autres bénévoles disponibles. Je vais bosser sur la modélisation et le texturing. Après une longue période sans pratiquer, j'ai besoin de me dérouiller et de passer à Blender 2.8. Ce sera l'occasion.

En effet pour la partie artistique peaufiner la pipeline sur un client solo sera très bénéfique, puisque ca permettra de s'affranchir d'une perte de temps supplémentaire, et d'un serveur de développement personnel. Si le système est bien rodé, ajouter des éléments sera simple et non technique. (Il y aura surement des  quacks avec les animations il y en a toujours, mais rien d'insurmontable.) Moins les artistes ont besoin de faire de technique, mieux c'est.

Pour moi les questions de sécurisation, d'échange à proprement parler viendront en un second temps. La priorité, c'est de pouvoir récupérer les flux tels quels.

Le souci avec la sécurité, c'est que les systèmes doivent être construits autours, c'est pas un morceau de scotch que tu peux juste rajouter par dessus. Ca devra être pensé dans l'architecture, quitte à l'implémenter après.

Je réponds avec un peu de retard, mais mieux vaut tard que jamais

J'avais eu l'occasion de donner les différents objectifs à atteindre sur Jabber, les voici à nouveau. Pour chacun de ces objectifs, on peut former quelques sous-tâches, j'en donnerai quelques exemples.

• Le client solo : ça rejoint un peu ce que vous disiez tous. Il est clair qu'avoir ce client sans le serveur peut paraître étrange pour un MMORPG, mais c'est un passage obligatoire, et là je suis d'accord avec Zatalyz, pour le moral.
  
  La priorité à ce niveau, c'est vraiment les assets, car finalement on peut tout à fait mocker la scène de départ avec des cubes, c'est relativement facile, ça a déjà été fait. Mais avoir une scène de départ jolie et représentative du résultat final souhaité et un plus en termes de moral et surtout de communication. Là-dessus, les compétences requises sont plutôt situées sur la modélisation 3D.
  
  Je préconise de lister tous les assets nécessaires dans cette scène pour partager le travail dans un post séparé (une solution plus économique consiste à exporter les assets du client actuel dans un format standard). Egalement, je propose de ne pas se soucier des environnements intérieurs dans un premier temps.
  


• Le login depuis une scène Godot : c'est surtout pour avoir une sorte de "bonjour le monde" au niveau du réseau. Etre en mesure se présenter au serveur et qu'il nous réponde "bonjour, je te reconnais" serait un bon départ. Je parle ici uniquement du premier login du client.
  


• Réfléchir au moyen de communication entre le client Godot et le(s) serveur(s).
  
  Tel que j'imagine la chose, ça peut être intéressant d'envisager ça sous la forme de composants GDNative. Je m'explique.
  
  Je suis totalement d'accord avec l'idée d'un ensemble de librairies pour discuter avec les différents serveurs. L'avantage de GDNative, c'est que c'est pensé pour permettre de scripter les scènes Godot en C++, donc avec la possibilité d'inclure des morceaux de code spécifiques au serveur actuel, par exemple la définition du protocole. Plus précisément, l'idée est de créer 1 librairie GDNative par composant du serveur pour que tout soit bien séparé, tout en fournissant à Godot (côté GDScript, le Python-like) des fonctions pour discuter avec le serveur.
  
  Le désavantage, c'est qu'il faut compiler ces librairies pour chaque OS. Par contre, comme c'est compilé ça sera efficace en termes de performances. D'autre part, une fois développés, ces composants bougent peu.
  
  Je ne dis pas que c'est vraiment la bonne solution, il faut étudier la faisabilité car je n'ai pas utilisé GDNative moi-même pour l'instant. Par contre, ça peut être intéressant de partir sur un POC totalement en python d'abord, mais ça ne sera qu'à des fins de prototypage.

Par contre, ça peut être intéressant de partir sur un POC totalement en python d'abord, mais ça ne sera qu'à des fins de prototypage.

Vi, c'est l'intérêt primaire du python, permettre un prototypage rapidement et tester les hypothèses. Je suis absolument d'accord sur le fait de traduire ça en C++ ensuite, ce sera plus performant (probablement!) et plus facile à embarquer sur les divers OS. C'est probablement quelque chose sur lequel je ne suis pas assez claire (n'étant pas dev) : python peut se suffire à lui-même, par exemple sur les serveurs (on saura gérer d'installer la bonne version dans le bon pipenv), mais notre intérêt pour lui concerne la phase de développement primaire où il faut tester et casser en boucle, et où s'épargner la compilation est donc préférable.

Par contre, à terme, les clients doivent être user friendly, donc ce sera juste des binaires à lancer suivant chaque OS, en limitant si possible les dépendances. On fera ce qu'on peut, mais plus il y a de dépendances pour un client, plus on a de risque de mal faire le boulot pour windows, mac... ou n'importe quelle distribution linux qui n'est pas celle qu'on utilise et dont le nom des paquets varie un peu.  Mais ça, ce sera plus tard, hein    À ce stade du projet, on peut se permettre d'avoir un truc pas "évident" à lancer, parce qu'on teste, on casse et on développe. Là typiquement il faut avoir installé godot pour lancer le client, ce n'est pas bien complexe mais c'est une manip en plus, qui disparaîtra dans la version finale. Le fait de devoir compiler les divers binaires sur nos serveurs est pris en compte, c'est entre autre pour ça que je supporte Gitlab 

Je préconise de lister tous les assets nécessaires dans cette scène pour partager le travail dans un post séparé (une solution plus économique consiste à exporter les assets du client actuel dans un format standard).

La section Hors les brumes est là pour ça, et il y a déjà des éléments dedans. Le travail du moment, qui n'est pas technique mais du type "rêver ensemble" va être de synthétiser et mettre en forme tout ça, afin d'avoir un cahier des charges pour les artistes (quels assets faire) comme les développeurs (quelles fonctions ajouter). Personnellement, ça me va bien qu'on reprenne des assets de Ryzom, il y a déjà plein de bonnes choses, mais je sais que Yannk (qui reste notre artiste le plus actif) a une folle envie de tout refaire : textures, animations, 3d. Bref, là dessus, on va appliquer notre méthode habituelle : commencer à rêver sans limite, et sans se limiter à l'existant et au possible, puis voir ensuite ce qu'on peut en garder, ce qu'on peut faire de tout ça, ce qui est déjà facile à exploiter.

La priorité à ce niveau, c'est vraiment les assets, car finalement on peut tout à fait mocker la scène de départ avec des cubes, c'est relativement facile, ça a déjà été fait. Mais avoir une scène de départ jolie et représentative du résultat final souhaité et un plus en termes de moral et surtout de communication. Là-dessus, les compétences requises sont plutôt situées sur la modélisation 3D.

Je préconise de lister tous les assets nécessaires dans cette scène pour partager le travail dans un post séparé (une solution plus économique consiste à exporter les assets du client actuel dans un format standard). Egalement, je propose de ne pas se soucier des environnements intérieurs dans un premier temps.

La section Hors les brumes est là pour ça, et il y a déjà des éléments dedans. Le travail du moment, qui n'est pas technique mais du type "rêver ensemble" va être de synthétiser et mettre en forme tout ça, afin d'avoir un cahier des charges pour les artistes (quels assets faire) comme les développeurs (quelles fonctions ajouter). Personnellement, ça me va bien qu'on reprenne des assets de Ryzom, il y a déjà plein de bonnes choses, mais je sais que Yannk (qui reste notre artiste le plus actif) a une folle envie de tout refaire : textures, animations, 3d. Bref, là dessus, on va appliquer notre méthode habituelle : commencer à rêver sans limite, et sans se limiter à l'existant et au possible, puis voir ensuite ce qu'on peut en garder, ce qu'on peut faire de tout ça, ce qui est déjà facile à exploiter.

Si vous avez besoin d'un coup de main, je peux probablement libérer du temps pour modéliser des trucs. Le client actuel est "fun" mais vous êtes pas sortis du sable si vous montrez quelque chose de ce genre. Il a besoin de travail sur l'aspect graphique, il fait rétro mais pas le bon genre de rétro, le genre de jeu des années 2000 ou la 3D venait juste de sortir et que tout le monde voulait en faire (Je te regarde Dungeon Keeper 2)

Ce qui serait vraiment bien ce serait d'avoir la map du serveur dans un format supporté par Godot. Ca vous permettrait de gagner pas mal de temps pour vous concentrer sur les textures, et les props (végétation, objets du monde).

Je ne dis pas que c'est vraiment la bonne solution, il faut étudier la faisabilité car je n'ai pas utilisé GDNative moi-même pour l'instant. Par contre, ça peut être intéressant de partir sur un POC totalement en python d'abord, mais ça ne sera qu'à des fins de prototypage.

Quand tu dis python du parles du GDScript ?

GDNative à l'air d'avoir du potentiel, et pourrait rendre les choses bien plus faciles. Godot ne charge pas les DLL (dylib) si ?

Ce qui serait vraiment bien ce serait d'avoir la map du serveur dans un format supporté par Godot. Ca vous permettrait de gagner pas mal de temps pour vous concentrer sur les textures, et les props (végétation, objets du monde).

Concrètement on a effectivement besoin des modèles uniquement. Si j'ai appris une chose en 3D, c'est qu'on peut avoir des modèles très peu détaillés et pour peu que les textures et les shaders fassent le boulot, on se retrouve avec un résultat plus qu'honorable. Par contre c'est clair que le texturing, c'est pas la partie la plus rigolote du travail de modeleur 3D

Je ne dis pas que c'est vraiment la bonne solution, il faut étudier la faisabilité car je n'ai pas utilisé GDNative moi-même pour l'instant. Par contre, ça peut être intéressant de partir sur un POC totalement en python d'abord, mais ça ne sera qu'à des fins de prototypage.

Quand tu dis python du parles du GDScript ?

GDNative à l'air d'avoir du potentiel, et pourrait rendre les choses bien plus faciles. Godot ne charge pas les DLL (dylib) si ?

Je parlais du script Python de Tycho qui sert apparemment à gérer le login actuellement. Je n'ai pas regardé ce script, du coup je ne sais pas trop comment on peu communiquer avec lui.

Si si, Godot charge les DLL directement, voir cette partie de la doc officielle : http://docs.godotengine.org/en/3.0/tutorials/plugins/gdnative/gdnative-cpp-example.html#using-your-gdnative-module

En gros l'idée serait de créer un node custom (genre "ServerCommunicator") à ajouter comme enfant de la scène "player". Ce node aurait pour comportement de communiquer les informations nécessaires au serveur. On peut réfléchir à créer plusieurs nodes différents pour communiquer avec chaque composant de serveur spécifique, afin de spécialiser chaque node.

A noter qu'il est parfaitement faisable et facile de faire ce type de node "custom" directement en GDScript, sous la forme d'un addon (voir http://docs.godotengine.org/en/3.0/tutorials/plugins/editor/making_plugins.html#a-custom-node) pour prototyper ça avant de s'amuser à le faire en GDNative.

Concrètement on a effectivement besoin des modèles uniquement. Si j'ai appris une chose en 3D, c'est qu'on peut avoir des modèles très peu détaillés et pour peu que les textures et les shaders fassent le boulot, on se retrouve avec un résultat plus qu'honorable. Par contre c'est clair que le texturing, c'est pas la partie la plus rigolote du travail de modeleur 3D

C'est sûr, mais c'est aussi super valorisant quand ça marche !

Je parlais du script Python de Tycho qui sert apparemment à gérer le login actuellement. Je n'ai pas regardé ce script, du coup je ne sais pas trop comment on peu communiquer avec lui.

Si si, Godot charge les DLL directement, voir cette partie de la doc officielle : http://docs.godotengine.org/en/3.0/tutorials/plugins/gdnative/gdnative-cpp-example.html#using-your-gdnative-module

En gros l'idée serait de créer un node custom (genre "ServerCommunicator") à ajouter comme enfant de la scène "player". Ce node aurait pour comportement de communiquer les informations nécessaires au serveur. On peut réfléchir à créer plusieurs nodes différents pour communiquer avec chaque composant de serveur spécifique, afin de spécialiser chaque node.

A noter qu'il est parfaitement faisable et facile de faire ce type de node "custom" directement en GDScript, sous la forme d'un addon (voir http://docs.godotengine.org/en/3.0/tutorials/plugins/editor/making_plugins.html#a-custom-node) pour prototyper ça avant de s'amuser à le faire en GDNative.

D'accord, je l'ai testé il marche nickel. J'ai fait une modif pour qu'il fonctionne sous windows aussi. C'est un module python, donc il est assez facile de l'importer. Mais du coup, on va pas pouvoir le faire avec Godot Sans l'extension Python si ?

D'accord, je l'ai testé il marche nickel. J'ai fait une modif pour qu'il fonctionne sous windows aussi. C'est un module python, donc il est assez facile de l'importer. Mais du coup, on va pas pouvoir le faire avec Godot Sans l'extension Python si ?

Tel quel, non.
Je pense cependant qu'il doit être assez facile de le porter en GDScript grâce à la classe HTTPClient (voir cet exemple : http://docs.godotengine.org/en/3.0/tutorials/networking/http_client_class.html?highlight=httprequest).

Je ne suis pas rentré dans les détails, mais en termes de contenu il faut :
- le terrain (model 3D)
- le joueur (model 3D)
- le dispensaire (model 3D)
- un arbre (3D)
- 1 ou 2 PNJ (3D)
‎- des éléments de village (3D)
‎ça devrait suffire. Tout ça devrait nous permettre de créer une scène extérieure simple, dans laquelle on ne fait que se déplacer en solo. Même pas besoin que les animations fonctionnent (si elles fonctionnent c'est bonus ).

Là dessus, il y a pour moi deux options. Soit on fait ça en mode bazar, et dans ce cas, commencer en extérieur, ok. Soit on essaie de créer la séquence d'intro telle qu'elle a été décidé (y'a longtemps, infos éparpillées, etc... donc du boulot pour faire la trame proprement) afin d'affiner peu à peu. Dans ce cas, le démarrage se fait dans une des chambres d'Oublieux, avec une PNJ. L'espace est plus petit mais il y a déjà des possibilités d'interaction.

Là dessus, il y a pour moi deux options. Soit on fait ça en mode bazar, et dans ce cas, commencer en extérieur, ok. Soit on essaie de créer la séquence d'intro telle qu'elle a été décidé (y'a longtemps, infos éparpillées, etc... donc du boulot pour faire la trame proprement) afin d'affiner peu à peu. Dans ce cas, le démarrage se fait dans une des chambres d'Oublieux, avec une PNJ. L'espace est plus petit mais il y a déjà des possibilités d'interaction.

Je serais plus pour la scène d'intérieur, parce qu'elle présente moins de risques d'imprévus. De glitchs par exemple.
Il y a aussi moins de travail au niveau du ciel et de l'environnement général.

Tel quel, non.
Je pense cependant qu'il doit être assez facile de le porter en GDScript grâce à la classe HTTPClient (voir cet exemple : http://docs.godotengine.org/en/3.0/tutorials/networking/http_client_class.html?highlight=httprequest).

Je précise que j'ai testé et que pour l'instant ce n'est pas possible, on attend la prochaine version.
Le résumé de mes aventures → https://pastebin.com/cekse4CS

Tel quel, non.
Je pense cependant qu'il doit être assez facile de le porter en GDScript grâce à la classe HTTPClient (voir cet exemple : http://docs.godotengine.org/en/3.0/tutorials/networking/http_client_class.html?highlight=httprequest).

Je précise que j'ai testé et que pour l'instant ce n'est pas possible, on attend la prochaine version.
Le résumé de mes aventures → https://pastebin.com/cekse4CS

Alors pour la prochaine version, il n'y a toujours pas de demande officielle pour l'ajout des bindings SHA-512 pour Godot 3.1. Je crée un ticket tout de suite, en espérant ne pas raconter n'importe quoi car je n'y connais pas grand chose en cryptographie.

edit : en fait un ticket similaire existe déjà. J'ai ajouté la demande à la fin : https://github.com/godotengine/godot/issues/1969

Oki. Merci beaucoup. Au pire demande a tycho de checker ton ticket. Link le ici.

Pour l'instant pour vous tenir au courant j'ai modifié le code PHP pour le rendre plus propre a mes yeux (En utilisant le language objet)
J'ai créé une branche. Et je le testerais ce weekend quand la vm sera opérationnelle. J'ai gardé l'ancienne méthode de login. Et j'en ai créé une nouvelle pour le HTTPS qui ne demande pas de chiffrement côté client. Et qui passe par les mêmes fonctions que le code de base.
Avec un peu de chance il ne sera pas dur de traduire les classes en python le jour où vous déciderez de le faire.

Dès que ça marche je remplace l'authentification par login par une authentification par email