Sur un vrai projet, il y a hélas des écueils.
Je l'ai utilisé sur un vrai projet 3D pendant un peu plus de deux mois, et j'ai fini par jeter l'éponge devant les problemes.
Il y a surtout un problème de ressources: le projet est ambitieux (bel éditeur), mais des efforts sont surtout orientés vers le rendering du futur 3.0 (la branche 2.2 actuelle est déjà considérée comme abandonnée, quand on soumet un bug, il faut prouver que ça saute également dans l'alpha 3).
Le rendering c'est bien, ça fait des jolis screenshots et ça donne un sentiment immédiat de satisfaction (un peu comme quand on coupe du bois: on voit tout de suite le résultat).
Le problème, ce sont tous les bugs qui restent. J'ai par exemple eu un mal de chien à faire accepter comme un bug le fait que le normal mapping ne fonctionnait pas avec les materials prédéfinis. Pour ceux qui ne connaissent pas le moteur, ça veut dire que si vous voulez faire du normal mapping (un peu la base de tout éclairage) dans l'éditeur, ça ne fonctionne pas. Ce n'est pas très sérieux, c'est une fonction de base, et le bug a été rapporté et ignoré depuis un certain temps (une feature de base pareille, je n'étais bien sûr pas le premier à tenter de l'utiliser).
Ceci pourrait ne pas être bien grave, mais il y a des problèmes fondamentaux beaucoup plus génants: le support 3D est limité avec un exporteur Collada «maison» pour Blender («better collada exporter») qui ne fonctionne pas bien, alors qu'il est censé faire mieux que l'exporteur interne de Blender (pourquoi ne pas corriger celui-ci, d'ailleurs ? Ou carrément utiliser un exporteur dédié à Godot, ce qui semble d'ailleurs être la piste pour Godot 3).
J'ai véritablement laché l'affaire quand je me suis mis à avoir des fuites mémoires dans le moteur avec ma géométrie générée. Je me tapais les asserts mystérieux du moteur (silence radio quand j'ai demandé un coup de main, manifestement seul l'auteur du projet aurait pu me renseigner je pense). Je n'avais même pas d'erreur dans l'éditeur, tout sortait sur stderr ce qui n'est pas un signe de bonne santé pour un moteur :)
D'autre part, le gdscript, pénible tentative de réécriture d'un énième langage de script, est vraiment pénible par sa lenteur et ses limitations. Pourquoi pas Lua ? Parce que d'après eux, Lua est trop lent, et ne permet pas de wrapper facilement sur du C++ (il faudra raconter ça à tout ceux qui le font déjà sans problèmes).
Par contre, il est question de wrapper avec C#.
Alors, peut-être pour les projets 2D ? Hum... à voir, mais évaluez bien la concurrence avant, et surtout jetez un coup d'œil à Love2D. Je reste pour ma part assez sceptique, ayant un peu commencé par là pour me faire la main.
Je ne me souviens pas de toutes les difficultés, mais il me semble avoir trouvé la partie Viewports inutilement compliquée, avec beaucoup de non-dits dans la doc.
J'en retiens quand même quelques points positifs: pour celui qui n'a jamais utilisé un moteur de jeu accompagné de son éditeur, c'est une très bonne introduction car les possibilités étant limitées, on le prend rapidement en main.
D'autre part, la communauté est vraiment sympa et cherche vraiment à aider.
Pour celui qui veut s'y mettre, il faut aller sur freenode/#godot , et poser les questions sur le site Q&A (le «vrai» forum est assez désert, et ne semble d'ailleurs pas vraiment en voie de développement).
Si je n'ai pas contribué au moteur (en cherchant quelques jours, je pense que j'aurais pu bien isoler le problème de ma fuite mémoire sur ma géométrie générée), c'est bien parce que je voulais faire un jeu, et non pas un moteur. Donc toutes mes excuses pour ça, mais pas le temps ni l'envie.
En conclusion, je recommande Godot à celui qui veut s'amuser un peu et avoir des résultats rapides.
Pour un «vrai» jeu, surtout bien prototyper au départ, ça évite les mauvaises surprises bloquantes.
Je suis persuadé qu'on peut en faire quelque chose, mais en restant bien dans son cadre. Le problème, c'est que son cadre est quand même assez changeant, avec une tendance à tout casser régulièrement.
Au minimum, j'attendrais une vraie version 3.0 considérée stable avant de me lancer là-dedans.
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: Woot
Posté par jseb . En réponse à la dépêche Rencontre avec les développeurs du moteur de jeu libre Godot Engine @ Mozilla Space Paris. Évalué à 4. Dernière modification le 01 avril 2017 à 13:36.
Sur un vrai projet, il y a hélas des écueils.
Je l'ai utilisé sur un vrai projet 3D pendant un peu plus de deux mois, et j'ai fini par jeter l'éponge devant les problemes.
Il y a surtout un problème de ressources: le projet est ambitieux (bel éditeur), mais des efforts sont surtout orientés vers le rendering du futur 3.0 (la branche 2.2 actuelle est déjà considérée comme abandonnée, quand on soumet un bug, il faut prouver que ça saute également dans l'alpha 3).
Le rendering c'est bien, ça fait des jolis screenshots et ça donne un sentiment immédiat de satisfaction (un peu comme quand on coupe du bois: on voit tout de suite le résultat).
Le problème, ce sont tous les bugs qui restent. J'ai par exemple eu un mal de chien à faire accepter comme un bug le fait que le normal mapping ne fonctionnait pas avec les materials prédéfinis. Pour ceux qui ne connaissent pas le moteur, ça veut dire que si vous voulez faire du normal mapping (un peu la base de tout éclairage) dans l'éditeur, ça ne fonctionne pas. Ce n'est pas très sérieux, c'est une fonction de base, et le bug a été rapporté et ignoré depuis un certain temps (une feature de base pareille, je n'étais bien sûr pas le premier à tenter de l'utiliser).
Ceci pourrait ne pas être bien grave, mais il y a des problèmes fondamentaux beaucoup plus génants: le support 3D est limité avec un exporteur Collada «maison» pour Blender («better collada exporter») qui ne fonctionne pas bien, alors qu'il est censé faire mieux que l'exporteur interne de Blender (pourquoi ne pas corriger celui-ci, d'ailleurs ? Ou carrément utiliser un exporteur dédié à Godot, ce qui semble d'ailleurs être la piste pour Godot 3).
J'ai véritablement laché l'affaire quand je me suis mis à avoir des fuites mémoires dans le moteur avec ma géométrie générée. Je me tapais les asserts mystérieux du moteur (silence radio quand j'ai demandé un coup de main, manifestement seul l'auteur du projet aurait pu me renseigner je pense). Je n'avais même pas d'erreur dans l'éditeur, tout sortait sur stderr ce qui n'est pas un signe de bonne santé pour un moteur :)
D'autre part, le gdscript, pénible tentative de réécriture d'un énième langage de script, est vraiment pénible par sa lenteur et ses limitations. Pourquoi pas Lua ? Parce que d'après eux, Lua est trop lent, et ne permet pas de wrapper facilement sur du C++ (il faudra raconter ça à tout ceux qui le font déjà sans problèmes).
Par contre, il est question de wrapper avec C#.
Alors, peut-être pour les projets 2D ? Hum... à voir, mais évaluez bien la concurrence avant, et surtout jetez un coup d'œil à Love2D. Je reste pour ma part assez sceptique, ayant un peu commencé par là pour me faire la main.
Je ne me souviens pas de toutes les difficultés, mais il me semble avoir trouvé la partie Viewports inutilement compliquée, avec beaucoup de non-dits dans la doc.
J'en retiens quand même quelques points positifs: pour celui qui n'a jamais utilisé un moteur de jeu accompagné de son éditeur, c'est une très bonne introduction car les possibilités étant limitées, on le prend rapidement en main.
D'autre part, la communauté est vraiment sympa et cherche vraiment à aider.
Pour celui qui veut s'y mettre, il faut aller sur freenode/#godot , et poser les questions sur le site Q&A (le «vrai» forum est assez désert, et ne semble d'ailleurs pas vraiment en voie de développement).
Si je n'ai pas contribué au moteur (en cherchant quelques jours, je pense que j'aurais pu bien isoler le problème de ma fuite mémoire sur ma géométrie générée), c'est bien parce que je voulais faire un jeu, et non pas un moteur. Donc toutes mes excuses pour ça, mais pas le temps ni l'envie.
En conclusion, je recommande Godot à celui qui veut s'amuser un peu et avoir des résultats rapides.
Pour un «vrai» jeu, surtout bien prototyper au départ, ça évite les mauvaises surprises bloquantes.
Je suis persuadé qu'on peut en faire quelque chose, mais en restant bien dans son cadre. Le problème, c'est que son cadre est quand même assez changeant, avec une tendance à tout casser régulièrement.
Au minimum, j'attendrais une vraie version 3.0 considérée stable avant de me lancer là-dedans.
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr