Messages

Hello Zatalyz,

Ne venant pas de manière physique à l'AG/AFLK ma présence à distance sera elle aussi une coincidence fortuite. Je verrai néanmoins certains d'entre vous au JDLL la semaine qui suivra.

Pour ce qui est de faire partie de l'AG pour l'instant je ne pense pas pouvoir apporter de contribution significative, du coup je vais passer pour cette année

Amusez vous bien à l'AFK 

Ca aurait été avec plaisir malheureusement j'arrive genre à 22h30 :/

J'aimerai votre point de vue sur : "comment rendre compatible Godot au shard puis à Nel".
Il y plusieurs facteurs à prendre en compte, beaucoup de fonction du shard peut être désactiver dans les .cfg pour aider au portage.
Le login python de Tycho a été porté en Gdscript par Stan mais utilise le système actuel en PHP.

Une petite précision concernant le port du script de Tycho. Le mien ne supporte pas le chiffrement coté client. J'ai juste ajouté la possibilité de se connecter en HTTPS en envoyant en clair les credentials. Si chiffrement supplémentaire il doit y avoir, on pourra envisager de générer des clés publiques et privées de chaque coté, avec la clef publique du serveur déjà connue par les client. Cependant je ne sais pas si c'est possible avec le code actuel de Godot, et il ne me semble pas.

De toute façon on aura besoin de chiffrement pour XMPP. Il sera peut être interessant de porter libsodium en GDNative, et d'utiliser ça.

La première partie serait :
    - Nettoyer la DB SQL actuel
   - Créer un mini-site Django pour remplacer le PHP (création de compte, ...)
   - Relier Godot à Django donc avoir un login complet
   - Désactiver les contrôles du shard
   
Cette liste demande peu de dev , au niveau du code openNel !
Mais on peut aussi choisir de changer mysql pour autre chose qui demandera de changer la librairies du shard donc "beaucoup plus" de travail C++.

Puis on réactive petit à petit les services porter dans godot qui demanderont des compétences de Dev.

Dango doit contenir :
    - une installation facile (à coté du shard)
    - les services minimum (création de compte )
    - passage de apache2 à nginx ?

La suite est la connexion UDP de Godot ......
   
A vos clavier, bon Dev !

Je pense que dans les services minimum il devrait y avoir au moins
- Login
- Création de Compte
- Reset du mot de passe
Afin que on puisse avoir une interface godot complètement fonctionnelle.


De ce que j'ai compris on laisse tomber Snowball et on repart sur lyrria ?

Je serais ravi de participer à celle de cette année avec ma petite amie. Normalement, je n'aurais pas de soucis pour venir, il restera à voir l'hébergement

D'accord je ne savais pas que Ryzom était payant, je pensais que c'était juste
un MMORPG Open Source et gratuit.

Q8:
> Osquallo:
> parce que c'est trop bien parce que django est cool et parce que ca sera plus propre
> que le bricolage actuel et plus facile a gerer et qu'il faut de toute façon
> dépoussièrer tout ca parce que mine de rien ça date quand même
> Zatalyz:
> Plus sérieusement : nous avons un besoin important en web pour l'évolution du projet,
> et ça tombe bien, on a des experts django dans le coin. On a aussi besoin d 'interragir
> avec les données du serveur, et ça tombe bien, les librairies python sont simples à
> faire et plus rapide à tester que le C++. On a besoin d'outils autour de Blender/Godot/Nel
> et ça tombe bien, python se branche bien entre tout ça, toujours avec le côté "pas de
> compilation, développement itératif rapide et accessible, pas besoin de grosses
> connaissances pour se mettre à python". Python s'impose peu à peu comme un langage
> pertinent sur le projet. Toujours pour faire face aux manque de dev, je préfère privilégier
> un langage commun. Php, moi j'aime bien mais depuis 6 ans, je suis la seule à vraiment
> y toucher. Et je ne suis pas dev. En python, il y a au moins 3 personnes à qui je peux
> demander de me faire un petit outil ici et là.
> Donc on ne remplace pas par python, parce que python, c'est bien, mais parce qu'aucun dev
> ne veux toucher php.

Dans ce cas, plutôt que d'utiliser le code PHP vieillissant et ne suscitant pas d'interêt
de la part des développeurs, est-ce que ça aurait du sens et une utilité sur le long terme
de développer une web API en Python avec Django avec 3 fonctionnalités principales.

1. LogIn
2. Inscription
3. Changement de mot de passe.

cette web API se connecterait à la base de données en MySQL existante soit la version
actuellement, sur Lyrria, ou celle que deed est en train de mettre en place, utilisée
pour Snowball.

On se connecterait à cette Web API par le client Godot que Osquallo à fait. On étendrait
ensuite cette API au autres fonctionnalités dont vous avez besoin.

Q9:
> Zatalyz:
> À première vue, je dirais que les erreurs du client Nel manquent de précision, ce qui
> rend certains débuguage laborieux. Mais de toute façon, on a pas trop prévu de toucher
> au serveur (enfin un peu sur les bords...) donc ça ne devrait pas changer les erreurs
> qu'il envoie. Il faudra juste le rendre plus clair sur "pourquoi 2002 plutot que 2003".

Si on recode une Web API, il semble judicieux de garder le même type d'erreur non ?
Ces codes correspondent à des texte d'erreur non ? C'est aussi le moyen que le serveur
à de communiquer les identifiants, les ports, les permissions etc.


Q11:
> Zatalyz:
> Moi, je vous ai proposé de bosser sur un client solo Godot, et de voir le lien avec
> le serveur quand on aurait des personnes compétentes sur le C++ et le réseau,
> personnes que je compte attirer avec une démo solo qui envoie un peu plus de
> rêve que notre Silan où on ne peux pas ajouter un pendo. La partie "online"
> ne me parait vraiment pas être la priorité.

Ca ne te semble pas étrange de vendre une démo solo comme un moyen d'inciter des
gens à contribuer à faire un MMORPG ? Ou est-ce que tu vois ça comme un jeu comme
Fallout, ou beaucoup de gens auraient aimé pouvoir explorer l'Univers à plusieurs ?

Je trouverais ça beaucoup plus interessant vu de l'exterieur si des personnes me
présentaient un jeu fait sur Godot capable de se connecter à un serveur de MMO qui
a fait ses preuves (C'est discutable mais je pense que tu saisis l'idée)

> Mais le principe sur Khaganat est aussi de vous faire plaisir. Si cela vous
> amuse de regarder le réseau, ok. Si vous documentez le résultat de vos tests
> (ce que vous avez compris, qu'est-ce qui est envoyé, reçu), ça ne sera pas perdu.
> Par contre, si vous faites des petits softs en suivant des idées "comme ça", qui
> vont marcher de façon boiteuse sans correspondre à la vision plus générale, et
> que vous vous découragez parce que vous n'aurez pas de retour (impossible de
> faire des retours sur ce qui ne marche pas de façon "point and clic") ou parce
> que vous devrez tout recoder à chaque fois que vous comprendrez un peu mieux le
> projet général, alors là, ça n'aura servi à rien. Quoi que vous fassiez, ce qui
> compte est 1) d'entretenir votre motivation 2) de laisser des traces pour que
> les suivants puissent vous rejoindre plus vite. Si vous perdez ça de vue,
> arrêtez-vous tout de suite, ça évitera les déceptions

Ce qui "m'amuse" c'est de rendre service et d'apprendre des trucs. Le réseau c'est
toujours monstrueusement compliqué pour moi. Mais j'ai le sentiment que je peux le faire
et que ca vous rendrait un peu service, donc c'est motivant. Si ca n'est pas utile pour
vous je ne le ferais pas.

Q13: Quelqu'un parlait de Blender2Nel tout à l'heure. Quel est le statut de ce
tool ? Est-ce qu'il peut aussi faire Nel to Blender ?

Ce serait genre vraiment cool d'avoir ça pour les personnes de chez Ryzom, parce
que quand vous aurez un MMO fonctionnel, ils n'auront qu'a switcher de moteur

Hello,
Comme discuté sur la #krypte j'ai fait une liste non exhaustive de toutes les questions que j'ai actuellement sur le futur jeu.
Q1 : J'ai cru comprendre que Ryzom ne fonctionne pas vraiment, faible affluence, problèmes de mises à jour, joueurs impatients, du coup pourquoi ne pas reprendre le serveur de Ryzom actuel sans rien changer et bosser main dans la main avec eux, pour transformer le client en un client Godot, plus facilement maintenable, pour leur permettre de mettre à jour avec vous le serveur ?
Q2 : Vous parlez souvent de votre fork, en quoi diffère-t-il de Ryzom, ne pouvez-vous pas faire des PR sur le dépôt, toujours dans une optique de travail en commun ?
Q3 : Est-ce que vous avez une bonne raison de vous désolidariser de Ryzom ?
Q4 : Est-il possible que vous hébergiez un serveur XMPP mutuel pour leur faire profiter un peu de votre bonne humeur et échanger des informations ?
Q5 : Si/Lorsque vous aurez un client fonctionnel Godot, est-ce qu'il sera envisageable de faire de la publicité en vue d'un crowdfunding ? (Les crowdfundings sans publicité préalables ne marchent pas vraiment)
Q6 : Si oui à la question précédente est-ce que vous considériez d'utiliser une plateforme de crowdfunding non libre (ex : Kickstarter) pour avoir une plus grande visibilité
Q7 : Avez-vous considéré d'ouvrir un Patreon, pour un ajouter des fonds à votre caisse dans un premier temps, voire embaucher quelqu'un si ça dépasse un SMIC ?
Q8 : Est-ce que la raison pour laquelle vous voulez réécrire/supprimer le PHP pour le remplacer par du python c'est parce que « "OMG le python c'est tro b1en" ou juste à cause de Django.
Q9 : Toujours dans l'optique de travailler avec Ryzom, ne serait-il pas cool de garder le même système d'erreur, pour que leur vieux client soit compatible avec votre nouveau Shiny Frontend, fût-il finalement codé en Python. L'idée étant d'avoir les anciennes fonctionnalités tout en ayant des trucs comme l'authentification Https et retirer au client le besoin de chiffrer ses identifiants, (Comme ce qui a été fait sur ma branche du Login)
Q10 : Si vous deviez changer de base de données (actuellement MySQL) qu'est-ce que vous prendriez ?
Q11 : Dans le contexte actuel on fait des clients compatibles avec un serveur, on déglingue le serveur, on met à jour le client, on rédéglingue le serveur.  Peut-être qu'il serait temps de se poser avec deed, de créer une nouvelle branche, et de commencer à construire quelque chose de durable. Je pense et ce n'est que mon opinion, que ce serait plus motivant pour tout le monde si on arrivait à faire un petit client en lien avec le serveur en sachant que le lendemain on arrêtera pas tout. Qu'en pensez-vous ? L'idée serait de fixer les technos, de décider de si vous désolidarisez Ryzom ou pas de vos plans, et de construire en partant de là. (Dernière VM à setup pour deed) Une démo vaudra toutes les promesses.
Q12 : Est-ce que vous avez pensé à contacter les associations « féministes » (n'ayez pas peur) comme Elles bougent pour voir si vous pouviez recruter des gens et faire valoir la position des filles dans la tech et le monde du libre ?
Q42 (Bonus) : Est-ce qu'on est tous d'accord que Osquallo, ben il gère ? 😊
Voilà, désolé si je suis relou, mais j'ai vraiment grand espoir pour votre projet, et je voudrais que ça bouge un petit peu (No offense)
PAMJAI et GUIMAUVES pour celles qui veulent.

 

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

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

Par les temps qui courent la sécurité est de plus en plus importante et c'est la raison pour laquelle je crée ce Thread.
Pour l'instant on a un système qui a été désigné à l'époque ou les certificats HTTPS coutaient très chers, et qui offrait
une sécurité relative à l'époque. @Tycho à rendu ça un peu plus robuste en passant de DES à Sha-512. Le souci de la
méthode actuelle est qu'elle requiert un travail supplémentaire d'authentification au niveau du client, que Godot ne
supporte pas nativement.

L'idée serait donc de déporter tout ce travail de hashage et de salage sur le serveur, et d'envoyer les identifiants en clair
via HTTPS. C'est une solution raisonnable, mais ce n'est pas la plus sécurisée. Le hashage passerait aussi d'une méthode
SHA-512 à Argon2 qui est plus récent, et serait plus robuste.

Link Mauve parlait de passer par le processus de SCRAM qui est utilisé par XMPP, pour chiffrer et sécuriser nos communication
ce qui demanderait un travail supplémentaire. Il semblerait cependant qu'il y ait moyen d'avoir le support natif dans une version
ultérieure, les briques étant déjà là dans le code CPP. (Via mbedTLS)

Dans la mesure du possible pour des procédures aussi simples il serait idéal d'éviter de passer par des plugins et des librairies
externes pour des soucis de compatibilité cross-plateform.

Dans un second temps pour le chiffrement des paquets UDP (qui synchronisent tous les clients) il serait bien de définir un plan
de sécurité.

Voilà j'aurais aimé avoir votre avis sur les deux questions (Login, et communications). La cryptographie n'est pas mon domaine
du tout donc je vous prie de m'excuser si j'ai écrit des horreurs un peu plus haut.

J'en profite pour poster le schéma de fonctionnement actuel

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 ?

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 ?

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

Nous faisons rarement des réunions formelles sur Khaganat parce qu'il y a, en fait, peu de gens compétents sur un même sujet. Du coup on fait confiance aux experts sur les trucs à faire ; on en discute de façon informelle et voilà.

D'accord, je ne savais pas. Je pense cependant que des profils techniques peuvent bénéficier d'un avis extérieur non technique lors de leur prise de décision. Souvent les profils techniques perdent un peu de vue la globalité du projet et quelqu'un d'autre peut soulever un point valable (Par exemple, l'interaction entre les différents éléments du jeu) qui remettent en question un choix. C'est aussi une bonne occasion pour les profils techniques de faire de la vulgarisation.

Sur 0AD on commence en effet par le résumé puis on discute puis on planifie la suite. Ce qu'il nous manque c'était la prise de décision.