Journal Cette année on a pas mal parlé d’Epic à la GodotCon

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
16
4
fév.
2020

Ces deux derniers jours, et dans la plus pure tradition du « il en reste un peu je vous le met aussi ? », se tenait hier et aujourd’hui à Bruxelles la GodotCon.

À côté de la grande fête au village en plein air qu’est le FOSDEM, la conférence annuel autour du moteur de jeu Godot fait plus figure de réunion de famille dans le calme feutré des locaux de la Ludus Académie.

Cette année, c’est donc une centaine de personnes (oui, ça commence à faire une sacrée famille !) qui étaient réunies pour des conférences, des démonstrations de jeux, des discussions sur la roadmap du moteur et, bien sûr, du café (parce qu’on est des développeurs) et des gaufres (parce qu’on est en Belgique) !

L’événement ayant était diffusé en direct, tout est disponible sur la chaîne YouTube du moteur.

Et cette année, c’est une sacrée nouvelle qui a été annoncée : Godot a été retenu pour un Epic MegaGrant de 250 000 dollars !

Ce financement permettra de soutenir le développement des fonctionnalités clé de la version 4.0 du moteur (la 3.2 vient de sortir) : le passage à l’API graphique Vulkan pour le moteur de rendu, ainsi que la refonte de GDScript (le langage de script du moteur) afin d’en améliorer les performances.

  • # Psyonix laisse tomber Linux et macOS

    Posté par  . Évalué à 10. Dernière modification le 04 février 2020 à 22:05.

    Et pendant ce temps là, Psyonix (studio racheté par Epic Games en 2019) annonce que leur jeu Rocket League (sorti en 2016 sous Linux et macOS) ne sera plus supporté sous Linux et macOS dès le mois de mars 2020.

    La principale raison invoquée, la réécriture du moteur qui passera de DirectX 9 à DirectX 11 (version d'une API Microsoft sortie en 2019).

    D'après Psyonix, pour que Rocket League reste fonctionnel sous Linux et macOS il faudrait investir beaucoup de ressources supplémentaires pour ajouter un rendu Vulkan et OpenGL 4 sur Linux et un rendu Metal pour macOS. Toujours d'après Psyonix Le nombre de joueurs actifs sur macOS et Linux représenteraient ensemble moins de 0,3 % de la base de joueurs actifs (mais aucune information sur le nombre de joueurs total, actifs et inactifs).

    On pourrait regretter que Psyonix utilise une vieille API DirectX 11 qui a dix ans alors que Vulkan fonctionne bien sur Windows (semble-t-il) et sous Linux. Malheureusement Apple ne supporte pas Vulkan, mais il existe MoltenVK qui implémente Vulkan sur Metal.

    Psyonix suggère aux joueurs Linux d'acheter la version Windows et de l'exécuter via Proton (la version Wine de Valve), mais qui n'est pas officiellement supporté par Psyonix. Comme toujours les éditeurs et les constructeurs acceptent l'argent des utilisateurs de Linux, mais ne fournissent que rarement du support !

    • [^] # Re: Psyonix laisse tomber Linux et macOS

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

      Petite faute de frappe ici :

      DirectX 11 (version d'une API Microsoft sortie en 2019).
      On pourrait regretter que Psyonix utilise une vieille API DirectX 11 qui a dix ans.

      Bien sûr il faut lire « sortie en 2009 ». (cf. DirectX#DirectX_11) 😉

      Mais sur le fond, oui, c’est un peu absurde d’aller dans cette direction en 2020.

      J’ai découvert récemment par exemple que la version Steam de Quake Live était pour processeur Intel 32-bit uniquement. Qu’ils avaient supprimé la prise en charge de Linux je le savais, mais que seule la version 32-bit soit distribuée m’a laissé pantois. Ce choix a été fait il y a quelques années, mais l’idée de faire un choix qui suppose que Microsoft maintienne indéfiniment la prise en charge du 32-bit est un choix qui apparaît comme de moins en moins évident. Soyons clair, Microsoft ne semble pas prêt d’arrêter, mais je serai quelqu’un de chez Microsoft en charge de la compatibilité antérieure je dirai « mais pourquoi tu fais ça ? ».

      ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: Psyonix laisse tomber Linux et macOS

      Posté par  . Évalué à 3.

      Il reste encore Wine/Proton mais ce qui m'inquiète le plus, c'est qu'ils intègrent leur anticheat EAC. Ils sont parfaitement au courant, depuis plusieurs mois, qu'il n'est pas fonctionnel sous Wine/Proton.

      Après, la version actuelle tourne très bien sous Wine/Proton (oui c'est inutile puisqu'on a une version native pour le moment), une proportion de jeux DX11 non-négligeable fonctionne relativement bien également, on peut supposer que ça ne devrait pas être le principal problème…

      Au passage, Psyonix a annoncé que l'on pourrait demander un remboursement à Valve même si l'on n'est pas éligible aux conditions de remboursement de Steam (-1h de jeu ou -2 semaines écoulées depuis la date d'achat). Mais il n'a rien annoncé pour ceux qui ont acheté du contenu IG…

      La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.

  • # Et pourquoi Godot?

    Posté par  . Évalué à 4.

    Et pourquoi donc Epic soutiendrait un moteur graphique alors qu'ils en ont un déjà?

    Au-delà du coup marketing et PR, il faut se rendre compte qu'Unreal Engine est bien supérieur techniquement à Godot, et de ce fait pas une menace. Cependant, leur principal concurrent, Unity, se positionne entre ces deux derniers! Ainsi, à moyen terme UE grappe des part de marché dans la partie supérieure, Godot dans la partie inférieure, et Unity n'a plus que les yeux pour pleurer!

    • [^] # Re: Et pourquoi Godot?

      Posté par  . Évalué à 7.

      Unity3D est quand même beaucoup plus proche de Unreal Engine que de Godot.

      Alors pourquoi Epic soutient Godot, mystère. C'est peut-être tout simplement fiscal, avec des dons qu'ils choisissent de faire à des entreprises du secteur, pour l'image de marque.

      Discussions en français sur la création de jeux videos : IRC freenode / #gamedev-fr

    • [^] # Re: Et pourquoi Godot?

      Posté par  (site web personnel) . Évalué à 3. Dernière modification le 06 février 2020 à 07:52.

      Ainsi, à moyen terme UE grappe des part de marché dans la partie supérieure, Godot dans la partie inférieure, et Unity n'a plus que les yeux pour pleurer!

      Faudrait-il encore que UE ait un retour sur investissement pour cette partie inférieure, par contre l’éventualité d’affaiblir Unity à perte pourrait serait une stratégie qui fait sens, mais c’est un pari risqué, d’une part parce que c’est jouer par la bande, d’autre part parce que l’argent donné à Godot pourrait aussi lui servir à devenir concurrent d’UE4 pour la partie inférieure.

      Bien que cette hypothèses soit difficile à invalider (et difficile à valider également), j’adhère plus facilement à l’idée que Godot n’est pas vu comme une menace, pas une menace suffisante comparé à ce dont il pourraient gagner de l’opération (à déterminer: communication, etc.)

      ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: Et pourquoi Godot?

        Posté par  (site web personnel) . Évalué à 9. Dernière modification le 06 février 2020 à 08:09.

        Sur l’aspect « communication », avec Blender et Godot, Unreal se construit une réputation de mécène de logiciel libre, à défaut de faire du logiciel libre.

        Lors du rachat de GitHub par Microsoft, j’avais trouvé pertinente l’analyse suivante (article désormais payant, j’avais fait une copie d’écran de la phrase toutefois) : « Developers love GitHub, and Microsoft needs the love of developers / Les développeurs aiment GitHub, et Microsoft a besoin de l’amour des développeurs ».

        Le bourgeois dépense sans compter pour entretenir sa maîtresse et s’assurer de sa constante disponibilité.

        ce commentaire est sous licence cc by 4 et précédentes

        • [^] # Re: Et pourquoi Godot?

          Posté par  . Évalué à 1.

          Le bourgeois dépense sans compter pour entretenir sa maîtresse et s’assurer de sa constante disponibilité.

          Viser à satisfaire les développeurs n'est pas nouveau chez Microsoft, c'est même probablement ce qui a fait leur force. Le rachat de GitHub est logique.

          Où pour le dire plus crûment (en réponse à ton tweet): il n'y a que certains libristes qui croient que Linux vis d'amour et d'eau fraîche, en pratique c'est ni plus ni moins que la tune. Ça fait des années qu'on parle de l'"année du Desktop Linux", et bien, en vérité, avec WSL c'est Microsoft qui l'a fait :P

          • [^] # Re: Et pourquoi Godot?

            Posté par  . Évalué à 7. Dernière modification le 07 février 2020 à 09:19.

            Ça fait des années qu'on parle de l'"année du Desktop Linux", et bien, en vérité, avec WSL c'est Microsoft qui l'a fait :P

            Il faudrait déjà définir ce qu'on appelle « l'année du bureau sous Linux » ?

            Si l'année du bureau sous Linux signifie avoir à disposition un bureau sous Linux fonctionnel, je pense que l'année du bureau sous Linux est déjà passé. Si l'année du bureau sous Linux signifie que des constructeurs vendent des ordinateurs avec Linux préinstallés, c'est arrivé en 2007 quand Asus a proposé à la vente l'ordinateur Eee PC avec Linux Xandros. Dell propose aussi des ordinateurs sous Ubuntu depuis plusieurs années et d'autres constructeurs proposent Chrome OS, qui est aussi un bureau sous Linux.

            Si l'année du bureau sous Linux signifie que Linux détrône Windows sur le bureau, alors oui effectivement l'année du bureau sous Linux n'arrivera sûrement pas. Même si on considère WSL (ce qu'il n'est pas) comme un bureau Linux, WSL vise uniquement les développeurs, donc un marché de niche.

            La couche de compatibilité WSL n'est pas un bureau Linux, mais au contarire juste un moyen trouvé par Microsoft pour que les développeurs n'utilisent pas le bureau Linux et restent bien sagement sous Windows. Si Microsoft a intérêt à ce que Linux tourne sous Microsoft Azure, Microsoft n'a aucun intérêt à ce que les développeurs utilisent Linux comme bureau.

  • # Équivalent Godot

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

    Bonjour à tous,

    Je profite de ce journal pour poser une question, je recherche une alternative plus légère que Godot permettant de faire des jeux 2d, j'ai un petit portable (Acer swift 1) qui rame énormément avec Godot le rendant inutilisable.

    L'idée étant d'apprendre et de s'amuser sur des petites réalisations, et pas de faire le nouveau FPS à la mode.

    Il y a pas mal de projets, mais beaucoup sont mort ou propriétaire

    • [^] # Re: Équivalent Godot

      Posté par  . Évalué à 3.

    • [^] # Re: Équivalent Godot

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

      Tu as essayé de configurer le système de rendu pour utiliser OpenGL 2.1 ? (par défaut il est en OpenGL3 qui est prévu pour les machines plus haut de gamme, cf. https://docs.godotengine.org/en/3.2/tutorials/misc/gles2_gles3_differences.html)

      • [^] # Re: Équivalent Godot

        Posté par  (site web personnel) . Évalué à 1. Dernière modification le 07 février 2020 à 14:37.

        Oui et c'est un peu mieux, toutefois cela reste inutilisable rien que de se balader dans les menus provoque une latence terrible

    • [^] # Re: Équivalent Godot

      Posté par  . Évalué à 7. Dernière modification le 07 février 2020 à 19:31.

      Tu veux des jeux natifs ou dans un navigateur ?
      Alors tu recherches peut-être avec une interface graphique autour du moteur, mais si tu étends un peu ton choix et accepte la perte de l'interface, tu as pas mal de possibilités. Bon d'accord, ce n'est peut-être plus dans tes critères. Mais si ça t'intéresse, voici ce que je te propose.

      En natif (avec éventuellement export dans browser via emscripten), tu as:

      L'incontournable Love2D que tu as surement déjà rencontré. Scripting Lua, très simple à apprendre, beaucoup de libs. Pour la 2D, c'est à mon avis le meilleur quand on accepte de coder «bas niveau» («bas niveau», par rapport à une interface graphique qui génère le framework).

      Sinon un autre bon moteur est Defold , hélas pas libre. Ils ont un peu ouvert le dev en permettant de créer et d'interfacer ses propres modules. Ils ont également une équipe vraiment à l'écoute des utilisateurs, et qui s'intéresse vraiment aux problèmes soulevés. Defold possède une interface graphique facile à utiliser, et se scripte avec Lua. Par contre, c'est écrit en java, et je crains qu'il ne rame sur ta config.

      Amulet pour scripter en Lua et faire des jeux très simples.

      Sokol me semble bien aussi, mais je n'ai fait que l'effleurer.
      exemples emscripten de Sokol

      Très ambitieux, mais léger (malheureusement peut-être un peu trop ambitieux), il y a Raylib qui vise également la 3D. Ça devrait tourner sur une machine ancienne.

      Si c'est dans un navigateur, tu as encore plus de choix. Par exemple, me vient à l'esprit:

      Phaser

      [pub]
      Si tu veux parler de tout ça, il y a un channel freenode en Français: #gamedev-fr.

      Il y a même quelques pros qui trainent, et en plus des petits potins de la scène JV, le choix d'un moteur est un sujet récurrent.
      [/pub]

      Discussions en français sur la création de jeux videos : IRC freenode / #gamedev-fr

      • [^] # Re: Équivalent Godot

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

        Super merci beaucoup

        Je vais regarder tout ça, pour le moment j'ai un peu joué avec cocos et effectivement ça semble pas mal, bon j'essaye d'avoir un compte chez eux depuis plusieurs jours mais sans succès …

        Je développe déjà un peu, mais je ne connais rien au monde du jeu, du coup je ne sais pas trop de quoi j'ai besoin

        Idéalement, j'aimerais pourvoir faire du code de manière confortable (çàd pas que de l'interface graphique, mais un un peu quand même) et générer des jeux multiplateformes

        Merci pour le channel

    • [^] # Re: Équivalent Godot

      Posté par  . Évalué à 3.

      Après avoir passé pas mal de temps sur du C++, et en remarquant que c’est difficile d’avancer rapidement quand tu es toujours à penser à ta gestion mémoire et ou multithreading, j’ai changé mon fusil d’épaule et me suis dit que j’allais tenter avec du Go, comme ça, des perfs plus proche du C++, mais pas la complexité qui va avec, donc du coup, une logique de code plus proche du python.

      Du coup, je suis un peu les projets Ebiten, Oak pour la 2D/Web.

      En 3D, je lorgne surtout du côté de g3n. Un des développeur a fait un Sokoban en 3D plutôt léché pour du hackathon : Gokoban.

      • [^] # Re: Équivalent Godot

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

        C'est marrant, je me disais justement hier que j'aimerais bien apprendre le Go en même temps, c'est excellent !

        Tu as commencé quelque chose ?

        Dommage que je ne puisse pas mettre plusieurs "pertinent" :)

  • # Des retours <3

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

    Hey ! Il y en a parmi vous qui l'utilisent et qui peuvent en parler ?

    J'ai eu utiliser Unreal et Unity mais je dois avouer que Godot me fait énormément de l'oeil en ce moment. Comment ça se passe en vrai la prise en main par rapport à Unity par exemple ? J'ai fais une gamejam récemment et un de mes teammate n'avait jamais touché à Unity et s'en est très bien sorti. J'ai seulement lu un peu la doc, mais j'ai eu l'impression que la courbe d'apprentissage était un peu plus élevée sur Godot, ou alors c'est moi qui ai un peu plus de mal :) Si vous avez un avis éclairé je prend !

    Je note que le moteur supporte le déploiement sur Haiku ! Je ne m'y attendais pas dis donc ^

Suivre le flux des commentaires

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