From Gnoll's Wiki

(Cette page est en français, car je voulais que ce soit clair, si quelqu'un se propose pour en faire une version anglaise, il est libre à lui de contribuer :)).

Contents 1 Introduction 2 Problèmes/Solutions 2.1 Viracocha se sentent considéré comme inactif 2.2 Communication externe 2.3 Manque de direction/objectifs claire 2.4 Difficulté (voir impossibilité) de portage vers d'autres plateformes autre que GNU/Linux 2.5 Une crainte de tout refaire 3 Comparatif

Introduction

Au vue de la situation actuelle, nous nous sommes posés la question de : comment améliorer Gnoll dans sa productivité ? Quels outils sont nécessaire ?

A partir de là, plusieurs solutions s'offre à nous :

• Ne rien faire : inenvisageable, cela voudrait dire garder la situation actuelle et donc ne pas avancer.
• Chercher des contributeurs : selon Mokona, et cela parait tout à fait logique, les contributeurs d'un projet qui n'avance pas ont tendance à fuir. Il est nécessaire d'avoir un noyau de contributeurs actif.
• Remplacer ogre par un autre moteur graphique : tout le monde est à peu prêt d'accord pour dire que c'est une bibliothèque lourde à utiliser et déployer.
• Trouver un moteur de jeu sur lequel se baser : pour cela, il faudrait éclaircir les objectifs de Gnoll, mais il faudrait avant tout qu'il existe un moteur de jeu libre en C++, ce qui n'est pas le cas actuellement (merci de nous contacter dans le cas contraire).
• Changer de langage : au vue de tout ce qui a été dit, il semble que ce soit l'option la plus intéressante, mais encore faut il trouver un langage qui remplit nos besoins.

A travers les discussions actuelles de la mailing list plusieurs problèmes ont été remontés, ils vont être énuméré un par un, et une solution va essaié d'être proposé pour les résoudres. Enfin, dans un dernier point, je convierais tous ceux qui passent par là, à faire un retour d'expérience afin d'avoir un tableau comparatif des langages, des bibliothèques, des outils, etc. existants susceptible d'aider Gnoll dans cette démarche.

Problèmes/Solutions

Viracocha se sentent considéré comme inactif

problème : d'après les membres de viracocha, Gnoll considèrerait ce projet comme inactif.
solution : bien entendu, c'est faux, au contraire Vira est très important pour Gnoll et il est loin d'être considéré comme inactif, surtout vu le temps passé de Gabriel et Antonin pour corriger des bugs et effectuer des tests. Par ailleurs, c'est grâce à Vira que Paf a démarré Gnoll.

Communication externe

problème : Il existe apparemment un manque de communication avec les projets autour de Gnoll (les ... avec Vira vu que c'est le seul :)? Il y a une part une difficulté de la part des gens de Vira de suivre les discussions techniques de Gnoll, mais aussi de communiquer entre les deux entités. Les discussions a propos de Gnoll ont lieues sur la ML, les discussions a propos de Viracocha ont lieues sur le forum de Viracocha. Or toutes les discussions liees a Gnoll par Viracocha ont eu lieu sur le forum de Viracocha, il est très difficile d'y répondre à tous (que ce soit à cause du temps que du suivi des forums).
solution :

• Poster un message sur la mailing-list
• Venir parler a Gabriel ou moi-meme via messagerie instantané
• Ouvrir un ticket (le plus efficace)
• Recruter un programmeur pour qu'il bosse sur les tâches prioritaires a Viracocha

Manque de direction/objectifs claire

problème : Selon la plus part des gens qui suivent notre projet, un des problèmes principales est le manque de direction claire, faire un Moteur (A)RPG n'est pas une réponse, quels sont les buts de Gnoll ?, à quel besoin répond il ?, ... Il est donc très important de mieux établir les objectifs
solution :

Difficulté (voir impossibilité) de portage vers d'autres plateformes autre que GNU/Linux

problème : Gabriel en a fait l'expérience, il est très difficile à l'heure actuelle d'avoir un environnement de développement sur différente plateforme. Ceci est due à plusieurs raisons, notamment le fait que des bibliothèques disponible facilement sous GNU/Linux le sont beaucoup moins sur d'autres OS (par exemple Windows).
solution : Se pencher vers des langages (semi) interprété qui nous déchargerait de la portabilité de notre application.

Une crainte de tout refaire

problème : En cas de changements de langage, il y a une crainte de devoir tout refaire, d'avoir une baisse de motivation, que ce nouveau langage soit une barrière à beaucoup de gens qui devront l'apprendre et que ça ne change rien.
solution : Au vue des 12 derniers mois, on a rien à perdre. De plus, nous avons pu regarder des alternatives de bibliothèques dans d'autres langages tel que sgine, ardor3, jmonkeyengine, donc au final, nous n'aurions pas tout à refaire si nous restons proche de l'architecture actuelle. En effet, nous aurions sans doute à refaire le système de message, l'abstraction des entrées, et les caméras. Le système de page dynamique serait à oublier pour revenir sur quelques choses de plus simple. Donc au final, passer à quelques choses comme Scala par exemple pourrait être intéressant puisque :

• On gagne en portabilité et facilité d'installation/compilation/deploiement
• On reduit nos responsabilités puisqu'un moteur de jeu nous delesterait des parties mondaines
• Nous n'avons plus a nous occuper des outils tierces
• Utilisation d'un langage plus expressif et stimulant (tout nouveau tout beau)

Scala est juste un exemple et nous sommes ouvert à toute proposition (constructive bien entendu)

Comparatif

Scala (Langage)

Pour	Contre
Gain en portabilité + facilité d'installation/compilation/déploiement Langage plus expressif et stimulant Maven Compatibilite avec la plate-forme java Bibliotheques/outils de serialisation/modelisation deja disponible Les contributeurs actuels doivent apprendre scala	Base de contributeurs pas forcément très grosse. Les contributeurs actuels doivent apprendre scala

JMonkeyEngine (bibliothèque)

Pour

Contre

Troisième version, la deuxième était déjà plutôt mature. Éditeur de ressources basée sur Netbeans fournie et extensible par plugins Beaucoup de domaines déjà gérés Multiplateforme dont Android (accessoire) Capable de distribuer et faire tourner une application directement depuis un applet java Encapsule pas mal de bibliotheques telles que bullet, OpenGL, OpenAL, entrees utilisateurs... Projet tres actif Fournit pas mal d'outils autour de la bibliothèque

jME3 n'a pas encore de version finale

Sgine (bibliothèque)

Pour	Contre
Ecrit en et pour Scala	Tres jeune et immature Le code semble assez propre et bien pense, mais leur facon de faire me semble tres crados Communauté faible autour Pas de version stable Aucun outil autour

Xith (bibliothèque)

Pour	Contre
Encapsule pas mal de bibliotheques Gère pas mal de formats (textures et modèles) Bonne communauté autour	Pas de version stable Aucun outil autour (du moins j'ai pas trouvé ...)

Ardor3D (bibliothèque)

Pour	Contre
Projet tres actif Support d'android (superficiel mais ça peut jouer en sa faveur :))	API Documentation inacessible (si quelqu'un a trouvé un lien ...) Communauté assez petite

Maven (Outils)

Pour	Contre
Tres propre Makefile tres simples a ecrire Gestion automatique des dependances transitives Gestion de depots maven Multiplateforme De nombreux plug-ins Tres facilement extensible	Rien, il est parfait.