Rencontre avec les développeurs du moteur de jeu libre Godot Engine @ Mozilla Space Paris

23
31
mar.
2017
Jeu

Le samedi 22 avril 2017 aura lieu une journée de rencontre intitulée Meet the Nodes entre les développeurs et les utilisateurs du moteur de jeu libre Godot Engine (sous licence MIT), au Mozilla Space de Paris.

Bannière de l’événement Meet the Nodes Paris

Agenda et activités

Le détail sera donné dans les prochaines semaines, mais cette journée sera sans aucun doute intéressante à la fois pour les membres de la communauté (grandissante) de Godot, mais aussi pour les simples curieux : nous invitons donc toutes les personnes intéressées par le développement de jeux vidéo à nous rejoindre et découvrir ce fantastique moteur de jeu libre !

Cette rencontre comportera plusieurs conférences données par les développeurs du moteur, mais aussi par des développeurs de jeux vidéo qui l’utilisent. Notamment, nous mentionnons la venue depuis Buenos Aires du développeur principal de Godot, Juan « reduz » Linietsky, ce qui est une très grande opportunité pour les utilisateurs européens de le rencontrer en personne.

Quelques ateliers seront également mis en place pour aider au développement de vos projets ou vous aider à débuter avec Godot. Nous mettrons à disposition des tables et des prises électriques ; aussi, n’oubliez pas vos ordinateurs portables si vous le désirez.

Il est important de noter qu’il s’agit d’un événement international et donc anglophone. Il y aura néanmoins de nombreux francophones et donc la possibilité d’échanger en petits groupes dans la langue de Molière.

Appel à contribution

Nous appelons à contribution toute personne intéressée pour parler de tout sujet concernant le développement de jeu vidéo avec Godot, mais éventuellement aussi des sujets connexes (par exemple WebAssembly), pendant une présentation de 20 minutes et 10 minutes de questions. N’hésitez pas à proposer d’autres sujets qui vous paraissent intéressants !

Si vous souhaitez organiser un atelier, vous êtes également les bienvenus.

Dans tous les cas, veuillez prendre contact avec les organisateurs ou via IRC (#godotengine-devel sur Freenode) en fournissant les informations suivantes :

  • nom, nickname (si besoin) ;
  • titre de la présentation ;
  • résumé ;
  • route information ou remarque supplémentaire que vous jugez nécessaire.

La date butoir est fixée au dimanche 12 avril (inclus).

Informations pratiques

La journée se déroulera au Mozilla Space de Paris (16 bis Boulevard Montmartre, Paris 75009, France) le samedi 22 avril 2017 de 9 heures à 19 heures.

Pour simplifier l’organisation, merci de vous inscrire sur le Framadate de l’événement. Entrée libre (as in free speech as well as in free beer).

Pour les transports en commun :

  • métro lignes 8 et 9, station Richelieu‐Drouot ;
  • bus lignes 67, 74 et 85, arrêt Richelieu‐Drouot - Mairie du 9e.

Aller plus loin

  • # Woot

    Posté par  (site web personnel) . Évalué à 6.

    Durant mes vacances, l'été dernier, je m'étais fixé l'objectif de tester Godot et de faire un petit jeu. Comme toujours j'ai été un peu ambitieux, j'ai juste eu le temps de faire les différents tutoriels. Mais j'ai vraiment été impressionné par la qualité du logiciel ; il semble plutôt complet (pour faire de la 2D en tout cas—la 3D est en chantier) et simple à prendre en main.

    J'espère arriver à me motiver pour l'utiliser plus sérieusement (avec un petit jeu que j'ai en tête). Pour le moment je ne peux pas garantir que sur un vrai projet il n'y a pas d'écueil ; mais j'encourage tous ceux qui sont intéressés par la programmation de jeux à regarder ce projet de près.

    • [^] # Re: Woot

      Posté par  . É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

      • [^] # Re: Woot

        Posté par  (site web personnel) . Évalué à 1.

        Au minimum, j'attendrais une vraie version 3.0 considérée stable avant de me lancer là-dedans.

        Tout à fait d'accord.

        Comme tu dis l'équipe est petite et si le moteur une dizaine d'années, il n'a été libéré que fin 2014 ce qui fait qu'il est encore dans une phase d'expansion avec des release apportant beaucoup (la v3 est incroyablement fourni avec entre autres un nouveau moteur audio et de rendu !).
        En tout cas les bases sont de qualité, la communauté est réellement présente et le projet avance de manière très encourageante (ayant testé le moteur à sa libération, le chemin parcouru est énorme).

        À ce rythme, je vois bien ce projet devenir une vrai alternative libre à Unity à l'image de ce que fait Gimp ou Blender dans leurs domaines respectifs.

        Par contre, il est question de wrapper avec C#.

        Python est aussi en chantier ;-)

        PS: allez voir le devblog du projet qui est super intéressant et mis à jour régulièrement !

      • [^] # Re: Woot

        Posté par  (site web personnel) . Évalué à 3.

        Merci pour ta réponse détaillée.

        Alors, peut-être pour les projets 2D ? Hum… à voir, mais évaluez bien la concurrence avant, et surtout jetez un coup d'œil à Love2D
        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'un autre coté des moteurs de jeux avec éditeur associé en libre, il n'y en a pas tellement (Superpowers a l'air sympathique, pas encore pris le temps de tester). Sinon on retombe sur des love2D/Pygame/… qui sont très bien, mais qui n'offrent pas la même chose ; par exemple pouvoir régler graphiquement le timing d'une animation plutôt qu'aller dans le code modifier des valeurs dans un tableau me semble quelque chose d'appréciable (surtout s'il on a quantité de contenu, ce qui arrive dans un "vrai" jeu). Évidemment si le reste ne suit pas, le jeu peut ne pas en valoir la chandelle.

        Et du coup tu as choisi un autre moteur de jeu pour faire de la 3D ?
        Pour ma part quand je jouais avec de la 3D, j'aimais beaucoup Ogre3D, ne serait-ce que parce que l'exporter Blender fonctionnait bien pour des personnages avec animation par squelette (sur les autres moteurs il fallait se contenter de mesh texturés statiques). Mais de base il ne s'agit que d'un moteur 3D, donc sans éditeur, et sans binding (prototyper en C++ m'a rapidement gonflé, ce n'est pas vraiment fait pour ça). Le binding Python avait l'air pénible ne serait-ce qu'à builder (c'était y a longtemps, peut-être que ça a changé); et il y avait un éditeur en C#, mais je ne suis même pas sûr qu'il tournait sous Linux (pas testé). Si Godot arrive à fournir quelque chose de simple et fonctionnel (même si on doit se cantonner à des petits jeux) avec ses futures versions (puisque tu pointes les problèmes qu'il y a actuellement) ça serait bien.

      • [^] # Re: Woot

        Posté par  (site web personnel) . Évalué à 3. Dernière modification le 03 avril 2017 à 16:27.

        Merci pour ton commentaire. Je vais essayer de répondre à plusieurs de tes remarques.

        Concernant les limitations dont tu fais part au sujet de la 3D, on est un peu dans la situation du serpent qui se mord la queue : jusqu'à la version 2.1, la plupart des utilisateurs intéressés par la 3D (ça doit représenter 10-15% des utilisateurs, mais ça augmente) se plaignent de la faible qualité du renderer 3D de Godot, donc peu de monde l'utilise. Et comme peu de monde l'utilise, nous avons très peu de retours de bugs, donc peu de modifications, donc peu d'utilisateurs (mais c'est en train de changer).

        Pire, au sein même de l'équipe de développement (dans laquelle j'inclus les documenters dont je fais partie, et aussi le Bugsquad), très peu utilisent la partie 3D du moteur. On se retrouve donc dans la situation que tu décris, avec des utilisateurs expérimentés qui remontent des bugs, mais derrière bien peu de monde qui en comprend la subtilité. Et surtout, pas assez de développeurs suffisamment expérimentés pour attaquer des features orientées 3D, ce qui explique le retard sur le bug du normal mapping dans l'éditeur.

        En ce qui concerne l'exportateur Better Collada, c'est une création de Juan 'reduz' Linietsky qui a depuis longtemps souhaité l'inclure dans Blender pour remplacer l'exportateur Collada actuel qui ne fonctionne pas, ce qui lui a été refusé et je n'ai pas très bien capté la raison (a priori, le core-dev de Blender est réticent, mais c'est un peu politique) : tu peux lire la discussion sur le sujet ici https://developer.blender.org/D1787 .

        Au sujet des performances, et notamment de GDScript, c'est un sujet récurrent. GDScript est le choix qui a été fait pour répondre au plus grand nombre de cas d'utilisation (http://docs.godotengine.org/en/stable/reference/faq.html#i-don-t-believe-you-what-are-the-technical-reasons-for-the-item-above). Beaucoup aiment, beaucoup détestent (c'est d'ailleurs une des raisons pour laquelle C# est incorporé), mais il suffit largement dans les cas classiques.

        Pour répondre au besoin de performance, d'autres solutions existent et doivent être envisagées par l'utilisateur :
        - soit développer un module en C++ pour effectuer la partie posant problème afin d'améliorer les performances ;
        - soit utiliser l'extension PLScript, qui permettra d'accéder facilement à des librairies externes en GDScript ;
        - soit éventuellement passer à C#, mais on ne connaît pas encore les performances pour ce langage ;
        - soit, si les performances sont VRAIMENT un problème globalisé, envisager de développer le jeu directement en C++ en se servant de l'API Godot (l'éditeur Godot est développé de cette manière).
        Des benchmarks ont déjà été effectués par le passé, mais tout le monde sera d'accord pour dire qu'ils sont largement insuffisants. Il existe aussi une probabilité importante pour que les projets ayant des soucis de performances soient tout simplement mal pensés (avec tout le respect, ça ne s'applique pas à tout le monde, mais on a déjà vu des utilisateurs qui veulent instancier 2000+ meshes sans aucune optimisation ou LOD).

        Quelques remarques par-ci par-là :
        - Le forum n'est pas officiel. Il est géré par la communauté, mais absolument pas maintenu par l'équipe de développement. Le Q&A, lui, est officiel.
        - L'aspect "changeant" que tu relates est un effet causé par le développement de Godot 3.0. Il a été rappelé plusieurs fois que dès le moment où le développement de la branche 3.0 commençait, alors il faut s'attendre à une instabilité très importante. De plus, il est assumé que les versions 2.x et 3.x seront partiellement incompatibles, ceci à cause de nombreux bugs qui n'ont pas été résolus avant 3.0, justement pour ne pas casser la compatibilité dans la branche 2.x.
        - Par contre je ne vois pas bien où le cadre d'utilisation de Godot est changeant. Chaque utilisateur en fait ce qu'il veut, que ça soit 2D ou 3D.

  • # LudumDare

    Posté par  . Évalué à 3.

    C'est vraiment (très) dommage que ça tombe le même week end que les LudumDare ( http://ludumdare.com/compo/ )…
    Après, je suppose que ça ne doit pas être évident de trouver un créneau où le créateur de Godot est en France et les locaux de Mozilla sont libres…
    En tous cas super initiative.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.