Godot: C# comme langage de script

Ajouter plus de fonctionnalités à GDscript serait une meilleure façon d'aborder les scripts à mon avis

Pour moi, la principale raison de choisir Godot plutôt que d'autres moteurs de jeu est un schéma de script simplifié. Godot ne propose pas d'apprendre un nouveau langage de programmation. Il propose d'apprendre Godot et son langage de script en tant qu'outil combiné pour le développement de jeux. C'est une approche moins intimidante que de proposer aux nouveaux arrivants d'apprendre le C++ ou tout autre langage de programmation pour les scripts.

Merci d'avoir ouvert ce problème, je pense que c'est un sujet où il y a une grande différence entre le meilleur choix rationnel et ce que la majorité demandera.

La raison la plus importante pour laquelle plus d'un moteur existe est qu'en plus de facteurs unidimensionnels tels que les performances dans les tâches générales ou l'accessibilité des interfaces, il existe des facteurs multidimensionnels tels que les performances dans des situations spécifiques (il n'y a pas de gagnant évident si vous comparez un moteur optimisée pour les jeux 3D et une optimisée pour les jeux 2D) ou la convivialité pour des groupes d'utilisateurs spécifiques (une interface conviviale pour les débutants doit généralement masquer des fonctions avancées).
Donc, pour trouver une place parmi les autres moteurs, un moteur doit choisir une "philosophie".

Maintenant, un langage de script fait partie intégrante d'un moteur, donc la philosophie du langage doit correspondre à la philosophie du moteur, ou du moins ne doit pas la contredire.

Quelle est donc la philosophie de Godot ? Regardons quelques faits :

• Comparé à Godot, tous les autres moteurs majeurs sont gonflés.
  Le téléchargement de Godot est inférieur à 20 Mo, l'ensemble de "l'installation" est un exécutable d'une taille inférieure à 50 Mo. Lumberyard, d'autre part, a une taille de téléchargement initiale d'environ 5,5 Go, actuellement mon dossier d'installation est de 15,3 Go. La raison principale en est la philosophie d'Amazon concernant les dépendances. Ce téléchargement initial contient 10,5 Go d'images construites de 42 dépendances, et si vous avez travaillé avec les services Web Amazon avant de savoir que le SDK AWS n'est pas si différent à cet égard, donc ce n'est pas une question de nécessité ou de capacité, c'est une question de choix. Par exemple, alors que Lumberyard inclut boost et Lua, Godot contient ses propres versions des conteneurs STL les plus importants et utilise GDScript plutôt que lua, ce qui réduit la taille, supprime les dépendances et rend le code beaucoup plus lisible et accessible.
• Le code source de Godot est très accessible.
  Cela commence par le choix du système de construction (SCons) qui utilise python comme langage de construction. La plupart des autres projets utilisent des systèmes de construction existants avec des langages de construction propriétaires ou écrivent leur propre système de construction propriétaire, ce qui a un impact négatif sur la lisibilité du code de construction.
  Le code source lui-même est également supérieur à la moyenne à cet égard. Il m'a fallu à peu près le même temps pour savoir comment écrire un seul nœud Unreal Blueprint en C++ qu'il m'a fallu pour écrire le code de ma première demande d'extraction à Godot. Cela ne veut pas dire que le code C++ d'Unreal était illisible, il n'est tout simplement pas aussi propre que celui de Godot car il utilise plus de macros et oblige l'utilisateur à comprendre davantage le code de projet par défaut d'Unreal que Godot.
• Godot promeut les principes KISS et OO.
  Afin d'illustrer cela, regardons quelques objets simples dans Unity. Le premier concept auquel vous êtes confronté dans Unity est celui de GameObjects avec des composants attachés. "la composition plutôt que l'héritage" comme on l'appelle souvent (je préfère la formulation de Michael J. Dickheiser "Containment versus Inheritance" de "C++ for Game Developers" qui ne sonne pas comme un cri de guerre et encourage la réflexion sur le sujet) est un modèle réussi en raison de la flexibilité qu'il offre. Cette flexibilité a cependant un coût. Si tout dans votre jeu est un GameObject, vous ne pouvez pas vraiment obtenir une référence au "joueur", car il n'y a pas de joueur, il y a juste un GameObject qui peut ou non avoir un composant de joueur attaché (ou plutôt ces plusieurs composants qui font vers le haut du lecteur).
  Les développeurs Unity ont vu le même problème, parfois vous voulez simplement créer un bouton, pas un GameObject avec un composant Button. Donc, ce qu'ils ont fait est ceci : ils vous ont permis de créer "un bouton" via l'interface de l'éditeur qui crée en fait un GameObject avec un composant Button attaché. En plus de cela, ils ont acheminé les membres les plus importants de GameObject à travers chaque composant, de sorte que vous pouvez maintenant utiliser une référence à un bouton comme vous utiliseriez une référence à un GameObject. Vous pouvez demander à un bouton sa position, vous pouvez lui demander une liste de ses composants - même si le bouton est en fait un composant, pas l'objet auquel il est attaché.
  Nous avons donc maintenant un mélange des deux façons les plus populaires de décrire un monde de jeu - basé sur la composition et en objets simples. Mais lorsque vous regardez les projets des débutants (et même certains projets avancés), vous constaterez que Unity facilite également la troisième manière d'interpréter un monde de jeu : la programmation procédurale.
  Dans Unity, chaque objet fait toujours partie d'une "scène". Contrairement à Godot, ce terme décrit une partie de haut niveau du jeu (avertissement : maintenant Unity a un SceneManager qui se trouve au-dessus des scènes, mais mon point est toujours valable), ce qui signifie que si un ennemi veut tirer sur le joueur, il peut juste recherchez sa scène actuelle pour le joueur et interagissez avec elle. C'est l'idée centrale de la programmation procédurale - vous avez une séquence de commandes qui modifient l'état de l'environnement sans tenir compte de la propriété. Bien sûr, techniquement, il s'agit toujours de programmation orientée objet, mais comme chaque objet peut s'attendre à faire partie de la même scène, vous pouvez écrire du code qui se comporte comme du code global. Par exemple, si vous souhaitez instancier un objet, il vous suffit d'appeler "Instantiate(templateObject)" et une copie de templateObject sera instanciée et ajoutée à la scène. Il n'est pas nécessaire de demander à quelle scène ajouter l'objet car il y a toujours une scène dont tout fait actuellement partie.
  Ainsi, Unity promeut un mélange de composition, de pensée orientée objet et de programmation procédurale.

Godot, d'autre part, favorise la pensée orientée objet, car par exemple, chaque objet de votre jeu peut être construit comme une scène à part entière. Ces scènes peuvent être démarrées par elles-mêmes, vous permettant de les tester, de les modifier par elles-mêmes, etc. Cela vous oblige à construire ces scènes d'une manière qui ne nécessite pas d'accéder à l'environnement. Par exemple, si un ennemi veut interagir avec le joueur, il est beaucoup plus faisable d'utiliser des signaux pour indiquer à la scène sous-jacente qu'une interaction est demandée ou simplement demander à la scène de donner à l'ennemi une référence au joueur. Vous pouvez toujours rechercher la scène de jeu pour le joueur, mais si vous faites cela, la scène ennemie ne pourra pas fonctionner seule, de sorte que la conception ne correspond tout simplement pas aux outils.

Alors, comment cela fait-il une différence concernant le choix des langages de script ?
C# est aux langages ce qu'Unity est aux moteurs. La philosophie de C # a toujours été que si une fonctionnalité serait agréable à avoir, elle est ajoutée au langage. Regardez simplement la liste des fonctionnalités qui ont été ajoutées avec chaque version : https://en.wikipedia.org/wiki/C_Sharp_ (programming_language)#Features_added_in_versions
Maintenant, vous pouvez dire qu'avoir une fonctionnalité n'est pas quelque chose de mal, n'est-ce pas ? Vous n'êtes pas obligé de l'utiliser, laissez-le simplement si vous ne l'aimez pas. Malheureusement, ce n'est pas vrai pour une langue. Avec l'importance d'internet aujourd'hui, les langues ne sont plus des outils, ce sont des cultures. Tôt ou tard, vous devrez rechercher de l'aide sur Google, vous utiliserez des modules ou des objets créés par d'autres, vous utiliserez de nouvelles fonctionnalités intégrées au moteur par la communauté, et tôt ou tard, cela vous obligera à utiliser des fonctionnalités linguistiques que vous n'aviez jamais prévues. utiliser.
De plus, si vous travaillez en équipe, vous apprendrez à apprécier l'utilisation d'un langage qui favorise un style de codage commun et ne vous offre pas des dizaines de façons d'écrire le même code.

Maintenant, vous vous demandez peut-être si je veux dire qu'un langage avec moins de fonctionnalités est toujours meilleur qu'un autre avec plus de fonctionnalités. Bien sûr, ce n'est pas le cas. Comparons comment Java a résolu le problème.
C# vous permet d'écrire du code non managé. Utilisez simplement le mot-clé approprié et vous pourrez l'utiliser directement dans le même fichier. Il vous permet également d'écrire du code fonctionnel à l'aide de LINQ, qui se lit comme du code SQL et se comporte comme du code fonctionnel. Afin de comprendre complètement ce que fait un fichier, vous devrez peut-être en savoir beaucoup sur les paradigmes de programmation.
Si vous écrivez Java, vous pouvez également utiliser la programmation fonctionnelle, il vous suffit de l'écrire dans un fichier séparé, d'utiliser un compilateur différent et de l'appeler "programmation Clojure". Si vous préférez combiner la programmation orientée objet et fonctionnelle, vous pouvez l'appeler "programmation Scala". La partie importante est que vous écrivez toujours du code pour la JVM qui peut facilement interagir avec le code d'autres langages JVM.
Les langages .NET ont la même capacité, mais ils ne sont tout simplement pas utilisés dans la philosophie C#. Ils auraient tout aussi bien pu décider de s'en tenir à un ou deux paradigmes de programmation en C # et de créer un nouveau langage pour ajouter de nouveaux paradigmes, mais à la place, ils sont allés avec "un langage pour les conquérir tous" - ce qui est tout à fait bien, c'est génial d'avoir une langue comme ça. Vous devez simplement être conscient de cette philosophie et des choix que vous avez en tant que programmeur.

Pour faire court : de tous les langages que nous avons, je pense que C# est le pire pour Godot. C'est un choix naturel pour Unity, mais si vous avez toutes ces options, pourquoi choisir un langage qui favorise le mélange et l'appariement des paradigmes dans un moteur qui promeut des principes OO propres et une programmation KISS dans chacune de ses autres parties ?

Donc, si vous pensez que C # serait un bon ajout à Godot, je ne suis PAS en désaccord avec vous - je dis simplement qu'il existe des alternatives encore meilleures, qui devraient être évaluées en premier et qui seraient immédiatement oubliées une fois C # implémenté.

@hubbyist

Ajouter plus de fonctionnalités à GDscript serait une meilleure façon d'aborder les scripts à mon avis

Cela peut arriver à coup sûr, je ne pense pas que ce soit incompatible avec les autres propositions.

Pour moi, la principale raison de choisir Godot plutôt que d'autres moteurs de jeu est un schéma de script simplifié. Godot ne propose pas d'apprendre un nouveau langage de programmation. Il propose d'apprendre Godot et son langage de script en tant qu'outil combiné pour le développement de jeux. C'est une approche moins intimidante que de proposer aux nouveaux arrivants d'apprendre le C++ ou tout autre langage de programmation pour les scripts.

Mais Godot peut déjà être utilisé depuis C++, donc rien ne changerait vraiment (à condition de conserver GDScript) si ce n'est que coder en C++ serait facilité pour ceux qui le souhaitent (actuellement écrire des modules nécessite de compiler tout Godot, et il n'est pas intégré dans le flux de travail).

@Warlaan belle analyse. Si vous avez lu mon article, je n'étais pas non plus d'accord avec le fait que C# soit un bon choix pour Godot, c'est pourquoi j'ai proposé d'étendre les capacités C++ déjà existantes pour permettre de l'utiliser comme langage de script, GDScript restant le langage par défaut pour la plupart des utilisateurs.

Les utilisateurs devraient être capables d'écrire à peu près en GDScript, mais il est déraisonnable de penser qu'un grand jeu serait écrit en GDScript. A mon sens, rien n'empêche Godot d'être adapté aux gros jeux si ce n'est les performances GDScript, car le moteur est très bien conçu et a déjà d'assez bonnes performances (et Vulkan va sans doute le rendre encore meilleur).

À mon avis, la performance ne plaît pas à la plupart des utilisateurs de Godot, mais elle pourrait amener plus de professionnels à Godot, ce qui signifie plus de contributions, ce qui signifie un meilleur Godot pour tout le monde.

@paper-pauper J'ai compris que nous étions du même côté. Quand j'ai écrit "si vous pensez que C# serait un bon ajout", je m'adressais à "vous, le lecteur anonyme", pas à vous personnellement. ;-)
Et oui, tout nouveau langage de script détournera l'attention de GDScript. Je doute que la communauté s'occupe de plus d'une langue, tôt ou tard, certaines fonctionnalités seront indisponibles ou cassées dans l'une d'elles, peut-être même jusqu'au point où l'une des langues sera abandonnée.

Je conviens également que les seuls vrais problèmes ici sont les temps de compilation de C++ et les performances de GDScript.
L'argument selon lequel les gens connaissaient déjà C # est tout simplement faux à mon humble avis. Je travaille professionnellement avec C # depuis environ 4 ans maintenant (principalement avec C ++ et SQL) et la seule chose que j'ai apprise à cette époque est que je ne pourrai probablement jamais dire que je connais vraiment cette langue. Après tout avec C# 6 et les propositions pour 7 le nombre de fonctionnalités ne cesse de croître.
Ainsi, lorsque nous parlons de "connaître C #", tout ce à quoi nous pouvons faire référence est de connaître la syntaxe la plus élémentaire que même le pire débutant devrait être capable de réapprendre en quelques jours. J'ai récemment donné une conférence sur différents moteurs de jeu à une classe de concepteurs de jeux qui utilisaient exclusivement Unity auparavant et aucun d'entre eux n'a mal commenté la syntaxe de GDScript alors qu'en fait plusieurs qui avaient abandonné la programmation sont maintenant à nouveau motivés.

Alors oui, une solution qui accélère GDScript et rend C++ moins lourd à compiler et à utiliser serait également ma préférée.

Beaucoup de gens qui "connaissent" C # n'utilisent pas beaucoup de ses fonctionnalités qui le différencient de Java. Jetez un coup d'œil à la myriade de scripts Unity qui ne vont pas beaucoup plus loin que les sous-classes.

Pour cette seule raison, je suis très sceptique quant aux avantages pratiques que C# apporterait. Ils sont agréables dans de nombreux contextes, mais pas dans le développement de jeux. De plus, C++1x offre déjà beaucoup de ces choses (y compris l'inférence de type, les itérateurs et certains outils fonctionnels de base) sans aucune surcharge.

De plus, il est possible que la surcharge apportée par le CLR (ou même la JVM) puisse aggraver les performances de Godot, bien que je vois certains avantages à utiliser le ramasse-miettes de la JVM (quelqu'un en sait-il plus sur la gestion de la mémoire de Godot) ?

J'ai lu sur des forums des personnes qui n'utilisent pas Godot à cause de GDScript. Je pense que c'est étroit d'esprit, car il n'y a rien de mal à cela, sauf le fait qu'il a une mauvaise sélection de bibliothèques, ce que j'ai essayé de résoudre dans un autre ticket, # 3943, en suggérant une solution sans frais généraux et multiplateforme Support.

Sans avoir à implémenter un JIT C++ via LLVM, il existe une solution qui s'exécute sur du code natif et ne nécessite aucune manipulation des sources de Godot : le lien dynamique.

Le premier autoriserait le code natif sans avoir à recompiler Godot à partir de zéro : il vous suffit de le compiler en tant que fichier .so, puis de l'ajouter à votre chemin de chargement, puis de l'utiliser à partir de GDScript sans surcharge (puisque ce sont tous des appels de fonction).

Cela devrait être très facile à faire (via libdl?) Mais pour autant que j'ai compris, ce n'est pas fait en raison de problèmes multiplateformes.

Il y a aussi l'idée de compiler GDScript en C++, un peu comme ENIGMA le fait avec son langage. Ce n'est pas facile, mais offre évidemment les meilleures performances.

quelqu'un en sait-il plus sur la gestion de la mémoire de Godot ?

De la doc :

Si une classe hérite de Reference, les instances seront libérées lorsqu'elles ne seront plus utilisées. Il n'existe pas de ramasse-miettes, juste un simple comptage de références. Par défaut, toutes les classes qui ne définissent pas l'héritage étendent Reference. Si cela n'est pas souhaité, une classe doit hériter manuellement de Object et appeler instance.free(). Pour éviter les cycles de référence qui ne peuvent pas être libérés, une fonction lowref est fournie pour créer des références faibles.

Juste pour noter...

Un avantage majeur de GDscript est qu'il s'agit d'un langage entièrement sous le contrôle de Reduz et des autres développeurs, son fonctionnement pour les développeurs Godot ne dépend pas d'une équipe externe et en tant que tel, il peut être développé d'une manière spécifique à la la conception du moteur et ont ce que les utilisateurs demandent.

Une autre chose est que même si GDscript n'est pas un véritable langage haute performance pour le moment, il existe probablement de nombreux domaines dans lesquels les performances peuvent être grandement améliorées tout en préservant sa simplicité et sa nature de frappe dynamique.

Ensuite, il y a le fait que GDscript ne nécessite aucune connaissance en compilation et que vous n'avez besoin de rien en dehors de l'éditeur intégré de Godot (ce qui rend le flux de travail agréable et bien rangé, sans parler de la facilité et de la rapidité).

Juste une question, comment fonctionne l'interpréteur GDscript en interne ? Analysez chaque ligne au moment de l'exécution comme l'ancien langage Basic ou convertit-il tout le script en tables de bytecode puis exécute le bytecode?

@RebelliousX

https://github.com/godotengine/godot/blob/master/modules/gdscript/gd_compiler.cpp
https://github.com/godotengine/godot/blob/master/modules/gdscript/gd_parser.cpp

Je ne pense pas qu'il existe plus de langages sérieux qui fonctionnent comme le BASIC ! :)

Salut!
Voici l'historique de GDScript :
//////////////////////////
Histoire
Initialement, Godot a été conçu pour prendre en charge plusieurs langages de script (cette capacité existe toujours aujourd'hui). Cependant, seul GDScript est actuellement utilisé. Il y a un peu d'histoire derrière tout ça.

Au début, le moteur utilisait le langage de script Lua. Lua est rapide, mais la création de liens vers un système orienté objet (en utilisant des replis) était complexe et lente et nécessitait une énorme quantité de code. Après quelques expériences avec Python, il s'est également avéré difficile à intégrer.

Le dernier langage de script tiers utilisé pour les jeux livrés était Squirrel, mais il a également été abandonné. À ce stade, il est devenu évident que Godot fonctionnerait de manière plus optimale en utilisant un langage de script intégré, car les obstacles suivants étaient rencontrés :

• Godot intègre des scripts dans des nœuds, la plupart des langages ne sont pas conçus dans cet esprit.
• Godot utilise plusieurs types de données intégrés pour les mathématiques 2D et 3D, les langages de script ne le fournissent pas et les lier est inefficace.
• Godot utilise beaucoup de threads pour soulever et initialiser des données à partir du réseau ou du disque, les interpréteurs de scripts pour les langages courants ne sont pas favorables à cela.
• Godot dispose déjà d'un modèle de gestion de la mémoire pour les ressources, la plupart des langages de script fournissent le leur, ce qui a entraîné des efforts en double et des bogues.
• Le code de liaison est toujours désordonné et entraîne plusieurs points de défaillance, des bogues inattendus et une impossibilité générale de maintenance.

Enfin, GDScript a été écrit comme une solution personnalisée. Le langage et l'interpréteur pour celui-ci ont fini par être plus petits que le code de liaison lui-même pour Lua et Squirrel, et tout aussi fonctionnels. Avec le temps, avoir un langage intégré s'est avéré être un énorme avantage
////////////////////////

À mon avis, c++ peut être le meilleur. Il existe des solutions comme :
https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledCPlusPlus
Même le script Angel peut généralement ressembler à un runtime compilé.
En scripting, j'adore python car j'aime toujours les solutions qui mélangent jeu et simulations scientifiques (python possède de nombreuses bibliothèques scientifiques). Alors je porte plainte ! dans un autre numéro, pourquoi godot a sa propre bibliothèque de physique: https://github.com/godotengine/godot/issues/4217
Il y a quelques problèmes avec des langages comme C# : https://github.com/godotengine/godot/issues/2790

Belle trouvaille, @ alabd14313 - cela résoudrait à peu près la plupart des problèmes, tout en laissant GDScript seul.

Quant au RCCPP, c'est une très bonne idée. Je pense que si Godot le supportait en mode éditeur puis le désactivait dans les builds, il y aurait des performances maximales et les temps d'itération seraient assez rapides. J'ai entendu d'autres moteurs comme Unreal Engine faire quelque chose de similaire avec C++, et je pense que ce serait plutôt bien si Godot autorisait un codage C++ de type script transparent.

Il semble que les auteurs connaissent leur affaire, car dans cette page, ils ont répertorié la plupart des alternatives à leur approche (y compris celle que j'ai mentionnée, le LLVM JIT).

Je pense que cette approche est la plus logique, car Godot est écrit en C++ (et je ne pense pas que cela changera jamais, étant donné que C++ sera encore meilleur dans quelques années), il a déjà une API C++ fonctionnelle et C++ a à peu près les performances maximales souhaitables sans surcharge et il n'y aurait pas d'exécutions ou de gestionnaires de mémoire supplémentaires. J'espère que les devs y jetteront un œil.

Je suis un peu surpris de constater que ce fil qui, autant que je sache, a été lancé en réaction à la proposition d'ajouter C # en tant que langage de script ne contient pas encore un seul argument POUR C #, même après que six personnes ont exprimé leur opinion.
Peut-être que la décision d'ajouter C # n'est pas aussi préméditée que je le supposais d'après les rumeurs que j'ai entendues.

@Warlaan , que se passera-t-il si vous publiez cette URL sur le groupe Facebook ? :)

Veuillez changer le titre en quelque chose comme "C++ comme langage de script".
C++17 a plus de fonctionnalités :
http://blog.mattnewport.com/why-c17-is-the-new-programming-language-for-games-i-want/
J'admire les développeurs de godot et les remercie pour leurs travaux. mais je résiste sur les librairies Box2D/LiquidFun/Bullet. De cette façon, les développeurs peuvent se concentrer sur le pipeline, et non sur des composants comme la physique. Avec C++, ils peuvent se concentrer sur les performances, et non sur la maintenance et la mise à jour de gdscript. Théoriquement, RCCPP peut mieux implémenter certaines nouvelles fonctionnalités telles que le mode outil. Peut-être...

@reduz a mentionné il y a quelques mois qu'il souhaitait implémenter des scripts visuels, quelque chose comme des plans irréels. Avec RCCPP, le flux de travail entre C++ (pour les programmeurs) et Visualscripting (pour les concepteurs de niveaux et les artistes) peut être implémenté comme :
Introduction à la programmation C++ dans UE4
C++ et plans
Ainsi, en groupe, les programmeurs peuvent développer de nouvelles classes de plans pour les artistes et les artistes les utilisent au lieu de coder directement.

@Warlaan IMHO, c'est parce qu'une grande partie de la discussion sur C # a été alimentée par des personnes qui veulent que Godot soit une arnaque Unity, mais heureusement, beaucoup ici réalisent que Godot est sa propre chose et déjà en avance sur Unity à bien des égards et ce ne serait pas juste de le laisser être affecté par les mêmes problèmes.

@ alabd14313 Je changerais le titre mais peut-être est-il préférable de créer un problème séparé et de le conserver pour la postérité afin qu'il puisse être lié lorsque quelqu'un propose C # (comme c'est souvent le cas).

J'hésite sur le script visuel, pour être honnête, mais s'il peut être implémenté sous forme de module, pourquoi pas ? Bien sûr, je pense qu'avoir des scripts visuels (concepteurs et débutants), GDScript (personnes capables de programmer ou désireuses d'apprendre) et C++ (programmeurs) ferait de Godot un programme assez équilibré adapté à tous les niveaux de compétence, mais rendant le codage C++ moins lourd et permettant une interface plus facile avec des bibliothèques tierces devrait avoir une priorité plus élevée, à mon humble avis, car il peut attirer de nombreux utilisateurs professionnels (et par conséquent, des contributeurs).

À mon humble avis, les scripts visuels sont loin d'être suffisamment raffinés pour avoir un sens. C'est génial pour le marketing et parler aux débutants de la programmation, mais d'après mon expérience, la phase d'apprentissage au cours de laquelle les débutants préfèrent les organigrammes est très courte.
Pour tout sauf les séquences d'appels les plus élémentaires, les systèmes que je connais (Unreal, Cryengine, Fungus, Stingray) ne sont tout simplement pas utiles. Je veux dire que cette capture d'écran, par exemple, provient de la vidéo publicitaire officielle du moteur Stingray. C'est ce que j'appelle le code spaghetti. Et les exemples officiels du moteur Cry ne semblent pas meilleurs, même si vous pouvez dire par la quantité d'éléments de commentaire que beaucoup d'efforts ont été déployés pour rendre le graphique lisible, ou plutôt pour essayer de le faire.
Si vous pensez que ce n'est pas si mal, laissez-moi vous rappeler que si vous voyiez ce code dans un langage textuel, chaque ligne de connexion qui commence hors écran serait une variable avec un nom (espérons-le) significatif.

Les graphiques de flux sont quelque peu utiles en ce qui concerne les shaders / matériaux, car les résultats intermédiaires peuvent être affichés, mais même là, le système souffre grandement du fait qu'une courte équation comme
flottant x = (ab)*(a+b)/(1-(a+b))
remplit facilement tout un écran lorsqu'il est fait sous forme de graphique, puisque chaque multiplication, somme ou différence est un nœud avec deux entrées et une sortie. C'est au moins 10 nœuds pour la formule ci-dessus, et si vous ne voulez pas provoquer un chaos de connexions, vous devrez dupliquer les nœuds a et b.

Les systèmes de graphes de flux que nous avons aujourd'hui (du moins ceux que je connais) suppriment la possibilité de donner aux valeurs des noms significatifs, car au lieu de mettre un résultat dans une variable nommée intermédiaire, vous le connectez simplement au nœud suivant. Cela rend le code auto-documenté presque impossible et vous oblige à consacrer beaucoup plus d'efforts à la documentation.
Ce que ces systèmes ajoutent, c'est la possibilité de placer des nœuds où vous voulez, ce qui, selon mon expérience, se traduit le plus souvent par un code moins lisible plutôt qu'un code plus facile à lire.

Et s'il vous plaît, ne parlez pas des graphiques de flux comme s'ils ne codaient pas. Ils sont autant de codage que n'importe quel autre langage de programmation. Ils ne tapent pas, c'est tout.

Les scripts visuels permettent aux concepteurs et aux artistes d'apporter des modifications sans avoir à apprendre à coder. Certains artistes sont également capables de créer des jeux interactifs simples avec. Il a sa cible où il est définitivement utile, ce n'est tout simplement pas pour les programmeurs.

@Warlaan Eh bien, cela dépend de la façon dont vous définissez la "programmation". Certes, les scripts visuels s'apparentent à la définition d'algorithmes, donc ce n'est pas loin de la programmation, mais la programmation concerne aussi d'autres choses.

Il existe cependant de bonnes implémentations de la programmation visuelle. PureData en est un et il y a aussi GDevelop , un très bon programme de création de jeux FLOSS (dommage qu'il ne soit pas plus populaire). En bref, même si je ne l'aime pas personnellement (pour certaines des raisons que vous avez mentionnées), il est également vrai que nous pouvons tous les deux programmer, donc pour nous, la programmation visuelle est lente et fastidieuse pour obtenir des résultats comparativement médiocres.

Pourtant, je suis d'accord avec @reduz que certaines personnes y voient un attrait. Ce ne sont pas les gens qui traîneraient autour de fils comme ceux-ci, mais ils font aussi des jeux. Je pense qu'ils pourraient apporter quelque chose à Godot.

La raison pour laquelle les organigrammes fonctionnent bien pour l'édition des shaders est qu'ils sont très visuels (vous avez des nœuds qui vous permettent de charger des images, de sélectionner des couleurs, etc... sans taper manuellement les chemins de fichiers et les valeurs). Vous n'avez également aucune crainte à vous assurer que la syntaxe est correcte et que les fonctions sont correctement orthographiées. Il n'est pas non plus nécessaire de comprendre des tâches aussi complexes telles que la façon de travailler avec une matrice (tout est calculé pour vous).

La méthodologie de Godot pour l'édition des shaders s'avère être une bonne approche car elle sépare proprement les composants de sommet, de fragment et de lumière et donne également des indications claires sur le type de données avec lesquelles vous travaillez (qu'il s'agisse d'informations normales ou d'informations sur la caméra).

Maintenant, avec le script visuel, je pense que cela pourrait être utile même pour des choses modérément complexes si les nœuds sont à un niveau suffisamment élevé en termes de mécanique de jeu (ils font des choses plus complexes et ont plusieurs entrées) et s'il y a des nœuds qui vous permettent d'exécuter un script ou de créer une expression/équation (qui à son tour peut être utilisée pour manipuler des valeurs de manière complexe). Les problèmes que j'ai rencontrés avec d'autres systèmes de nœuds visuels de ce type sont qu'ils essaient d'être aussi proches que possible de la programmation littérale (c'est-à-dire d'avoir un tas de fonctions de bas niveau en tant que nœuds au lieu d'être plus comme une version nodale de les briques logiques de Blender ou le drag & drop de GameMaker).

Bien sûr, cela ne permettra toujours pas quelque chose d'aussi fin et d'aussi avancé que ce que vous pouvez faire avec des scripts purs, mais cela aurait toujours une utilité pour des choses comme des types d'objets simples dans un jeu (qui n'ont pas besoin d'une logique très complexe ) ou si vous avez besoin de sortir rapidement quelque chose.

Je suis d'accord que certaines personnes y voient un attrait, et je suis également d'accord que ce n'est pas pour les programmeurs (c'est juste nos définitions de "programmeur" qui diffèrent ;-) ), donc je suggère que nous laissions la discussion là-dessus car c'est quelque peu hors sujet.

Une autre fonctionnalité utile de C++ est son type statique. Les fonctionnalités "auto" et "decltype" peuvent détecter le type d'un objet. L'éditeur et l'achèvement du code peuvent être plus faciles. Au lieu de se concentrer sur l'éditeur de code interne, nous pouvons utiliser un autre IDE externe. Pour l'instant, je pense que codelite et qtcreator ont un meilleur statut dans l'achèvement du code. Les blocs de code ont des problèmes avec les mots-clés c++11. Eclipse-cdt a également une bonne complétion de code. Un plugin pour qtcreator est une bonne idée (comme unreal-visual studio et Unity-Monodevelop). L'IDE externe peut être identifié avec un chemin système dans les paramètres de godot (comme /use/bin/qtcreator), il n'est pas nécessaire d'être compilé et emballé avec godot (contrairement au package Unity avec monodevelop intégré).
Il existe d'autres outils comme cppcheck et valgrind qui ont des plugins dans qtcreator.
Si vous souhaitez avoir un aperçu de ce qu'est le RCCPP :
démo

J'aimerais voir un langage de script basé sur C++ pour Godot, mais la mise en œuvre de toutes les fonctionnalités C++ serait fastidieuse, comme la programmation de modèles. Il doit y avoir certaines limitations à ce type de langage de script (STL) et les modèles ne doivent pas être utilisés. De plus, RTTI peut entraîner des problèmes de performances.

J'adore GDscript, mon seul reproche à ce sujet est la pollution de l'espace de noms des variables, lorsqu'il s'agit de gros scripts, les définitions de variables avant ready() peuvent devenir très compliquées et sujettes à des bogues dans le code en raison du partage de variables entre les fonctions du même fichier de script .

Mes 3 centimes. (euh... ça a fini par faire 20, mais que ce soit...)

Comme @ alabd14313 mentionné plus tôt "il en est au point où il en est" en raison de l'évolution au fil des ans qui a conduit godot à la forme qu'il est aujourd'hui.
Peu importe que ce soit la nature ou nous les humains, corriger les choses au moment de la création apparaît comme la meilleure façon de se développer, et je dois admettre que grâce à cela, j'apprécie beaucoup Godot tel qu'il est et où l'évolution l'a amené.

Il a toutes les pièces nécessaires.

Des nœuds qui peuvent être combinés en un objet plus complexe, enregistrés en tant que scène, puis réutilisés à nouveau en tant qu'objet "simple" dans une autre scène, ce qui est génial et méga flexible, vraiment limité uniquement par l'imagination et la créativité de l'utilisateur.

Simple à utiliser et à apprendre GDScript, assez puissant pour contrôler tous les nœuds comme nous, les codeurs, sommes habitués à le faire - en tapant des lignes de code.
En plus de le faire de manière simple et rapide (complétion de code / documentation intégrée / info-bulles utiles ici et là) sans avoir besoin de compiler, il suffit de taper, d'essayer, d'ajuster et encore une fois, de le peaufiner à la perfection.

Déploiement sur plusieurs plates-formes avec VRAIMENT un clic (sans parler de ces déploiements sur Android via wifi/adb, édition de la vie, débogage, ect n'est qu'un chef-d'œuvre d'art, non... C'est plus, c'est magique !)

De plus, toutes ces familiarités avec les outils couramment utilisés comme le mélangeur, etc.
(importez des trucs et ça marche hors de la boîte, tout est où et comment ça devrait être)

Et enfin, j'avoue que parfois même l'ultra créativité peut ne pas suffire quand il s'agit de faire quelque chose des millions de fois en boucle et tient dans 1 frame. C'est là que les trucs C entrent en jeu. Si vous connaissez C, en avez besoin, rien ne vous empêche de créer un plugin, un nœud personnalisé, etc., qui fait exactement ce que vous souhaitez.

Il a presque tout, et avec le temps, je crois qu'il aura tout.
(Cela signifie que les choses qui aujourd'hui ne sont "pas encore implémentées" et qu'il faut le faire "d'une manière ou d'une autre" ou "à mains nues" (lire : utilisez un outil externe pour cela), par exemple, ajustez quelque chose de gréé en 3D de manière simple (vous devez utiliser un mélangeur )

Godot est incroyable et une chose magique, parfaitement parfaite sur sa route où elle va.A besoin d'ajustements et d'ajouts de trucs ici et là, mais c'est tout.

Script visuel ?
euh. Cela pourrait nous obliger, nous les codeurs, à changer notre façon de penser "un peu" d'une manière inhabituelle, et je ne crois pas que cela puisse être aussi flexible et lisible qu'un code normal.
Imaginez que vous codez et que vous ayez une ligne simple comme celle-ci ( abc / def ) * ghi
puis le moyen rapide, comme d'habitude (?) Pour économiser la frappe, vous marquez une partie de quelque chose, collez ici, coupez là, collez à nouveau et en 5 secondes et quelques touches, vous vous retrouvez avec "simple" (parce que vous savez ce que ça fait) une doublure comme ((((abc/def+((abc/def)_ghi^4))_ghi)+(abc/def_(100))_ghi)+abc)
C'est courant, peut-être que beaucoup d'entre nous le font de cette façon de manière très rapide.
Imaginez maintenant le faire de manière visuelle...
Cela pourrait prendre tout l'écran, beaucoup de travail à la souris, et cela n'aurait pas l'air aussi lisible qu'il le devrait.
(bien sûr, une telle doublure n'a pas non plus l'air facile après un an, mais c'est à cela que servent les commentaires)

Et si quelqu'un avait 100 lignes de ce type les unes sous les autres ?
Visuellement, il pourrait obtenir un terrain de football pour l'afficher. Qu'en est-il de l'analyser, de le changer, c'est un gâchis et un gros casse-tête.
Bien sûr, les codeurs peuvent le faire parce que ce n'est pas un langage utilisé, faire de quelqu'un un codeur, mais une façon spécifique de penser, de créer des algorithmes, de manipuler des données en petites parties et dans leur ensemble.
Le langage, qu'il s'agisse de scripts C, Python, PHP, Java ou Visual, n'est qu'un outil pour écrire les pensées.
Et ici, à mon humble avis, la saisie normale avec le clavier est la forme la plus rapide et la plus lisible pour l'écrire.
De l'autre côté, si quelqu'un ne sait pas coder, vous attendez-vous à ce qu'il révèle soudainement son génie et sa perspicacité algorythmiques pour ne pas se perdre dans sa propre idée et sa représentation visuelle, étant donné que lorsque nous pensons au jeu, nous parlons de quelque chose de plus complexe que deux balles bashing l'autre avec la physique.

Alors, à qui s'adresse vraiment le Visual Scripting ?
Rendre la vie des codeurs plus difficile ou limiter godot au niveau - moteur de "jeux simples" pour débutants ?

Les gens, il y a une longue discussion sur les scripts visuels dans #1220. S'il vous plaît, ne discutons plus des mêmes sujets ici.

Les gens, il y a une longue discussion sur les scripts visuels dans #1220. S'il vous plaît, ne discutons plus des mêmes sujets ici.

La plupart des articles ici étaient si longs que je me suis peut-être perdu en lisant.
Désolé :relax:

@RebelliousX Même avec RTTI, C++ aurait toujours de bien meilleures performances que GDScript. Bien qu'il soit vrai que les modèles pourraient être un problème.

La solution proposée par @reduz dans #3936 rendrait déjà le codage en C++ assez trivial - il vous suffit de le faire avec votre éditeur et compilateur de choix et de le lier à l'API de Godot. Si cela est implémenté, même si les scripts en C++ seraient bien, ce ne serait pas très différent d'écrire du code en C++ puis de l'appeler depuis GDScript, en termes de performances. En bref, je pense que se concentrer sur #3936 (qui est une solution simple) améliorerait grandement :

• Performances (car écrire des parties en C++ serait extrêmement facile)
• Disponibilité de bibliothèques tierces (puisque les wrappers peuvent être distribués plus facilement, mais pas aussi facilement que #3943)
• Base d'utilisateurs et contributeurs (de nombreux programmeurs C++ adopteraient Godot)

Ensuite, on pourrait se concentrer sur le typage statique dans GDScript et l'optimisation de l'interpréteur (via un JIT ou en compilant GDScript en C++), mais cela peut venir plus tard si l'écriture de modules est facilitée.

Je veux juste mentionner quelques points qui se sont glissés dans cette discussion mais qui n'ont pas encore été abordés :

• Certains d'entre nous parlent d'améliorer le système existant (GDScript comme langage de script, C++ comme langage backend) en facilitant le développement C++ et en augmentant les performances de GDScript. D'autres parlent d'utiliser C++ (ou Java / C# / ...) comme langage de script. Il peut sembler qu'il n'y ait pas de réelle différence entre permettre un développement rapide en C++ et en faire un langage de script, mais je me ferai un plaisir d'expliquer comment j'ai expérimenté et observé l'effet négatif des langages de script puissants sur la qualité de la conception de jeux. Et à moins que cela ne devienne le sujet de la discussion, je le ferai volontiers sur les forums ou ailleurs où cela ne détournera pas ce fil.
• @RebelliousX : Lorsque vous parlez de "espace de noms variable", de "grands scripts" et de "partage de variables entre fonctions", il semble que vous n'ayez pas entièrement compris la nature orientée objet de GDScript (sans vouloir vous offenser). Chaque fichier GDScript est une classe, donc les conflits de noms entre les variables (membres) doivent se produire exactement aussi souvent que dans tout autre langage orienté objet. Vous ne partagez pas de variables entre les scripts, vous écrivez plusieurs fonctions qui peuvent accéder à l'état de l'objet englobant.

@Warlaan À propos du premier point, je pense que vous pourriez poster ici, car il est lié au sujet.

@Warlaan aucune infraction prise. Je sais que GDscript est une classe à part entière et je sais que les variables sont comme des variables membres normales dans la classe C++, mais il semble que vous ayez complètement raté mon propos. Vous le comprendrez lorsque vous aurez un script avec plus de 1000 lignes de code. Ce que je veux, ce sont des références ou des pointeurs, au lieu de créer des myriades de variables membres, il suffit de les transmettre entre les fonctions membres. C'est plus sûr ainsi.

J'aime C#, mais je vois des avantages et des inconvénients.

Avantages:

• Bon support d'outillage (avouons-le, coderiez-vous en C# sans Visual Studio ou MonoDevelop ?)
• Adapté aux projets de grande envergure
• Largement utilisé et mature, il existe des tonnes de fils de support sur Internet.
• Bonnes performances, compromis entre C++ et les langages de script tout en étant multiplateforme
• Relativement facile à lier à C++

Les inconvénients:

• Garbage collecté : les projets de jeux à grande échelle doivent également mettre en œuvre des stratégies d'allocation pour éviter que les coups de pied de GC ne se produisent trop souvent, cela peut être désagréable
• Pas aussi intégré que GDScript (complétion du chemin de nœud ? Variables de membre de script sur les nœuds ? Modèle d'allocation de mémoire ?)
• Le runtime est lourd, et le framework .NET encore plus. Comme dans Unity, les bibliothèques standard doivent être remappées sur celles de Godot.
• Ce n'est pas le meilleur choix pour les scripts réels, dans le sens de faire avancer les choses rapidement et salement. C# est plus verbeux et restrictif que GDScript.
• Pas encore de directives concernant le développement de Godot. Le langage est générique et peut faire beaucoup de choses, et comme l'a dit Warlaan, les développeurs ont des cultures différentes (vous pourriez littéralement avoir un codeur WPF essayant Godot et se demandant pourquoi il n'y a pas de moyen MVVM de créer des interfaces graphiques :p)

La plupart de ceci s'applique également à Java.
Peut-être que j'ai oublié d'autres choses parce qu'il est tard ici.

Ok, c'est mon expérience concernant les langages de script riches en fonctionnalités resp. une absence totale de langage de script selon votre définition de "langage de script". Je vais essayer d'être bref. ;-)

Je travaille depuis plusieurs années en tant que doyen de l'ingénierie à School4Games à Berlin, en Allemagne. Dans cette école, nous n'avons pas de faculté de conception de jeux "purs", mais notre cours de conception de jeux s'appelle "développement de jeux" et comprend suffisamment de cours de programmation pour enseigner aux concepteurs de jeux comment développer leurs propres prototypes et comprendre les possibilités et les limites. des architectures matérielles et logicielles communes.
Donc, les étudiants que j'enseigne sont des gens qui ont parfois un intérêt accru pour la programmation mais dont aucun n'a postulé pour devenir programmeur.
Chaque semestre, ils doivent former des équipes et développer un jeu. Étant donné que presque tous les futurs employeurs potentiels de nos étudiants utilisent Unity, il a été obligatoire pendant les deux premiers semestres de travailler avec ce moteur.

Passons maintenant au point concernant l'effet des langages de script :
Ces élèves se sont répartis en deux groupes. Celui qui essaie d'éviter la programmation ou qui a perdu espoir (ce qui signifie qu'il suivra des cours de programmation mais ne demandera pas d'aide s'il rencontre des problèmes mais abandonne silencieusement) et celui qui plonge dans la programmation si profondément qu'il passe directement aux sujets qui généralement, vous ne vous préoccuperiez pas de l'écriture des prototypes de jeux. Par exemple, un de mes étudiants du premier semestre a récemment publié un tutoriel sur la façon d'écrire un Singleton en C # en utilisant des génériques afin que vous puissiez transformer une classe de composants Unity en un singleton en héritant de la classe générique du tutoriel. Le point intéressant n'est pas tant qu'il ait pu écrire cet article, après tout, il a bien sûr reçu l'aide de ses professeurs et il existe de nombreuses ressources sur le sujet sur Internet. Le point intéressant est qu'un étudiant qui a postulé pour un cours axé principalement sur la conception de jeux plutôt que sur la programmation serait intéressé par un sujet de programmation aussi spécifique. Le code de ce didacticiel ne changera jamais en raison des modifications apportées à la conception du jeu, c'est une pure construction de programmation.
Quelque chose de similaire s'est produit avec un étudiant différent qui a utilisé une classe similaire pour transporter des informations d'une scène de jeu à une autre. Il a été assez surpris quand je lui ai montré qu'il pouvait faire la même chose avec un membre statique public, ce qui montre qu'il cherchait des solutions complètes et compliquées avant d'en comprendre complètement tous les éléments de base.

Donc, si vous sautez devant, ceci résume le texte jusqu'à présent : bien qu'il soit possible d'écrire du code simple dans des langages riches en fonctionnalités, j'ai observé à plusieurs reprises que les gens sont susceptibles de rejeter des solutions simples là où des alternatives compliquées existent.

Ce n'est pas seulement dû à des préjugés. Bien sûr, c'est probablement un facteur. Si vous voyez que le code dans les didacticiels, les exemples ou d'autres classes de votre projet semble compliqué, vous pouvez en conclure que le vôtre devrait également avoir l'air compliqué. Mais je pense que la vraie raison est qu'en programmation, il est logique d'essayer de créer un code à l'épreuve des erreurs. C'est un désir naturel d'écrire du code qui ne casse pas dès qu'il est utilisé dans un endroit différent ou dès qu'il reçoit une entrée différente. Et cela vous oblige à découvrir les options auxquelles vous devrez peut-être vous préparer.
Je pense que ce sentiment d'avoir à vérifier chaque éventualité est ce qui divise mes étudiants entre ceux qui se noient dans le grand nombre de fonctionnalités de C # et ceux qui sautent directement et perdent la concentration dans la langue.

Zylann a mentionné l'expression "rapide et sale". Nous utilisons souvent ces deux termes comme une phrase, mais quand on y pense, ce sont en fait deux facteurs différents. Qu'il soit ou non possible de coder rapidement est tout à fait mesurable. Le fait que le code résultant soit sale ou non dépend en revanche de nombreux facteurs, le plus important étant le nombre de fonctionnalités du langage utilisé.
Par exemple, créer un nœud de niveau supérieur et l'utiliser comme singleton dans Godot est tout à fait correct puisque GDScript n'offre pas les fonctionnalités nécessaires pour implémenter le modèle de la même manière que vous le feriez dans des langages comme C#. Bien sûr, utiliser la fonction de chargement automatique serait préférable car c'est le premier endroit où les autres développeurs chercheraient des singletons (et cela rend la syntaxe un peu plus agréable), mais si une équipe décide de l'implémenter de cette façon, je doute qu'il y ait beaucoup d'un argument. Imaginez d'un autre côté que quelqu'un implémente un singleton dans Unity simplement en ajoutant un membre statique public à une classe. C'est tout aussi rapide, d'une certaine manière c'est même la même chose (les deux sont des instances de classe dans l'endroit le plus public), mais puisque C # offre la possibilité de rendre le constructeur privé, d'accéder au singleton via une propriété avec initialisation paresseuse, etc. c'est attendu que vous le fassiez, sinon le code sera perçu comme très sale s'il n'est pas cassé.

Maintenant, le fait que les étudiants en conception de jeux se plongent dans des sujets comme ceux-ci peut être un vague indice de ce que je veux dire, mais je pense que je peux l'illustrer encore mieux en parlant de la situation lors de mon premier emploi chez un grand développeur de MMO F2P. L'équipe que j'ai rejointe est l'un des développeurs de jeux les plus expérimentés d'Allemagne. Leur responsable du développement crée ses propres moteurs en interne depuis 1995 et même s'ils venaient d'être rachetés par une autre société, ils étaient toujours l'un des développeurs les plus performants à l'époque.
Au moment où j'ai rejoint l'équipe, ils utilisaient la troisième version du moteur interne, qui n'avait pas de langage de script. Ils en avaient implémenté un auparavant, mais dans cette version du moteur, ils sont revenus à l'absence de langage de script car il y avait des problèmes avec la qualité du code fourni par les concepteurs de jeux. En d'autres termes, comme le langage de script était trop puissant, la décision a été prise de déplacer la barrière entre les programmeurs et les concepteurs de jeux au point où les concepteurs de jeux ne feraient que modifier les niveaux et modifier les paramètres dans les feuilles de configuration pendant que les programmeurs faisaient toute la programmation - rétrospectivement, je remarqué que c'est à peu près la même situation dans laquelle se retrouvent mes étudiants (et il semble que de nombreux studios professionnels travaillant avec Unity se retrouvent dans).
Maintenant, pourquoi m'en soucierais-je ? Si cela se produit encore et encore, cela ne prouve-t-il pas que c'est une méthode de travail efficace ? Ma réponse est non, car il y avait des problèmes, à la fois techniques et de conception de jeux, qui pourraient facilement s'expliquer par le fait que la communication entre les programmeurs et les concepteurs de jeux se réduisait à écrire des tâches dans un sens et à exposer des paramètres dans l'autre. Du point de vue des concepteurs de jeux, les fonctionnalités sont devenues des boîtes noires qui pouvaient être activées et désactivées, mais de ce côté de l'équipe, personne ne pouvait discuter ou même prototyper des alternatives.
Les programmeurs, d'autre part, ont été poussés presque naturellement dans une mentalité de backend. La mentalité KISS "rapide et sale" avait disparu, car aucun de nous ne pouvait prédire comment les fonctionnalités que nous avions créées allaient être utilisées. Je me souviens très bien comment une fois que la base de données est tombée en panne parce qu'un concepteur de jeu avait mis en place une chasse aux œufs de Pâques, les inventaires ont augmenté beaucoup plus qu'avant. C'était la dernière fois que je supposais que les exigences d'une fonctionnalité resteraient probablement à peu près les mêmes.

C'est pourquoi je pense qu'il est extrêmement important d'avoir un langage de script à faible fonctionnalité comme zone définie pour le code du jeu et pourquoi je pense que ne pas l'avoir a un mauvais effet sur la conception du jeu.

• Écrire du code rapide signifie ignorer les fonctionnalités qui le transforment en code "rapide et sale".
• Le désir d'écrire du code propre divise les développeurs entre ceux qui ne codent pas et ceux qui passent plus de temps à penser au codage et moins de temps au jeu.
• Cela divise à son tour toute l'équipe en une moitié qui travaille sur la conception de jeux sans connaître la base de code et une qui travaille sur les fonctionnalités sans savoir comment elles vont être utilisées, ne laissant personne qui pourrait proposer des fonctionnalités de moteur basées sur le jeu concevoir ou suggérer une conception de jeu basée sur des fonctionnalités qui pourraient facilement être mises en œuvre.

Il n'est pas possible d'imaginer le développement de jeux aujourd'hui sans utiliser des bibliothèques de classes prédéfinies, après tout c'est ce qui fait le succès des moteurs avec des outils comme Godot, Unity, Unreal etc. Mais la différence entre tous ces moteurs réside dans l'endroit où la ligne entre la programmation et la conception de jeux est tracée et dans quelle mesure l'écart est créé entre les deux parties.
Et sur la base de mes observations, je pense que le choix du langage de script est l'un des facteurs les plus importants qui peuvent créer un tel écart ou le combler.

Soit dit en passant, la raison pour laquelle je me suis tellement impliqué dans Godot est que je travaille à l'établir comme moteur obligatoire pour le premier semestre. Juste pour que vous sachiez que je ne parle pas seulement, mais que je tire aussi mes conséquences. ;-)

@RebelliousX Je dois admettre que je ne comprends toujours pas très bien où vous voulez en venir. Mais puisque vous avez dit que ce que vous voudriez, ce sont des références ou des pointeurs, pourriez-vous ouvrir une nouvelle demande de fonctionnalité et y publier un exemple de code pour votre problème ? Pour être honnête, il semble toujours que votre problème soit lié à l'architecture du code plutôt qu'à l'une des fonctionnalités manquantes du langage.

J'aurais dû ajouter que KISS profite surtout aux petites équipes. Godot est tellement riche en fonctionnalités qu'un seul développeur peut créer un jeu. Mais dès qu'un projet a plus de développeurs, les choses "rapides et sales" deviennent moins probables et sont laissées pour le prototypage ou des correctifs temporaires, alors des règles/directives doivent être mises en place. Donc, cela dépend vraiment de qui utilise le moteur et pour quoi.

Godot en général a aussi plus de contraintes qu'on ne le pense. Vous ne pouvez pas créer de singletons ou de variables globales de type "c-static" pour une raison : les fuites de mémoire et la convivialité des threads. GDScript n'est pas aussi présenté que Python pour une raison : il est axé sur les tâches et les performances de développement de jeux. Le système de scène est également orienté objet pour une raison : vous pouvez créer des "boîtes" indépendantes qui peuvent être testées et réutilisées :)

Cette rubrique concerne l'ajout d'un support de module C # (ou Java), mais je ne vois aucun exemple de code. Essayons quelque chose à la volée :)

using GodotEngine;

// Inherit a node type
public class Spikeball : RigidBody2D {

    // Exported variables
    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

    // Notice the naming convention. Should Godot API follow languages or should languages follow Godot?

    void _Ready() {
        SetProcess(true);
        // Should we use the generic system?
        Connect("BodyEnter", this, "_OnBodyEnter")
        // Or use C# features?
        this.bodyEnterEvent += _OnBodyEnter;
    }

    void _Process(delta) {
        var sprite = (Sprite)GetNode("Sprite");
        sprite.SetRot(sprite.GetRot() + delta*rotationSpeed);
        // Or we can have properties
        sprite.rot = sprite.rot + delta*rotationSpeed;
    }

    public void _OnBodyEnter(PhysicsBody2D body) {
        // We cannot invent C# members on the fly, so we can do this if the other script is in C# too.
        // ScriptInstance GetScript();
        var health = body.GetScriptInstance() as IHaveHealth;
        if(health != null) {
            health.TakeDamage(damage);
        }
        // But what if the other is GDScript?

        // A generic approach would look like this, a bit like SendMessage in Unity3D
        // object Call(string funcname, object arg1, ...); // where object can be seen as Variant
        body.GetScriptInstance().Call("TakeDamage", damage);

        // Same thing if we want to get a script variable
        var category = (string)body.GetScriptInstance().Get("category")
        Console.Print(category);
    }

}

Qu'en penses-tu?
Ce fichier pourrait ensuite être compilé en tant qu'actif DLL (ou exécuté à la volée). Mais en parlant de cela, aurions-nous besoin de générer un csproj comme Unity ?

@Warlaan merci de partager votre expérience. Corrigez-moi si je me suis trompé (c'était un long article), mais êtes-vous en train de dire que proposer un langage avec moins de fonctionnalités est préférable pour le bien des programmeurs, afin qu'ils puissent se concentrer sur le développement de leurs jeux plutôt que sur le surcodage ?

Si c'est le cas, c'est une observation très subtile. Je pense que les développeurs de Godot doivent faire ce qui est le mieux pour leur base d'utilisateurs - ils savent ce qui est le mieux.

Et je me demandais moi-même aujourd'hui si certaines personnes ici (moi y compris) ne demandaient pas subtilement Urho3D , tandis que d'autres demandaient GDevelop . Godot est clairement un outil intermédiaire entre les deux (mais parfaitement adapté aux pros, plus comme Urho3D), et je pense qu'il devrait le rester, mais Unity va toujours jeter une ombre dessus parce que beaucoup de gens ici venir d'elle.

Je ne pense pas qu'il soit juste de s'attendre à ce que Godot soit une arnaque Unity - Godot a clairement un meilleur design et pour autant que je sache, de meilleures performances. Mais certaines personnes pensent que GDScript n'est pas adapté au développement "sérieux" et ne le sera jamais car il s'agit d'un environnement d'exécution personnalisé, malgré le fait que l'ancienne version de Mono utilisée par Unity est également en quelque sorte un environnement d'exécution "personnalisé". Et en plus, lorsque vous écrivez du C# dans Unity, vous écrivez du code qui ne fonctionne que dans Unity pour la plupart et suivez leurs modèles de conception, alors autant utiliser un autre langage.

Je pense que ceux qui veulent C# ont tort, mais un bon compromis à mon avis serait de proposer :

1) Meilleures performances (typage statique, peut-être un JIT)
2) Meilleure prise en charge des bibliothèques tierces (via FFI et une intégration C++ simplifiée)

pour GDScript. Le reste peut être fait en C++, y compris l'écriture de modules qui implémentent d'autres langages de script (qui n'ont pas besoin d'être propriétaires - tout le monde peut écrire un module C#, s'il le souhaite).

@Zylann Je ne vois aucun avantage à écrire ce code au lieu du C++ équivalent, honnêtement, et le code C++ aura de meilleures performances.

@paper-pauper l'avantage d'écrire ce code est le même que GDScript : vous n'avez pas besoin de recompiler le moteur pour chaque plate-forme vers laquelle vous souhaitez exporter, et... eh bien, vous avez le choix du langage (et les performances sont pas le seul point, comme je l'ai mentionné plus tôt). Je conviens qu'actuellement, l'expérience GDScript est supérieure et que C++ est le meilleur choix pour des performances pures. Mais, il y a des gens qui ne veulent tout simplement pas faire du C++, aussi bon soit-il.
Je ne suis pas personnellement intéressé par Godot+C#, j'évalue simplement ce qui se passe si vous l'ajoutez à Godot. Et ce n'est pas si simple :p

Après avoir lu l'excellent livre Game Scripting Mastery (vous ne trouverez pas beaucoup de livres sur le sujet, à l'exception du livre non ludique sur les compilateurs Red Dragon). Ma conclusion est que, GDscript est adéquat, il est si facile de continuer à ajouter des fonctionnalités à un langage de script qui lui fait perdre de sa puissance. Le plus important est d'implémenter un langage de script non gonflé et aussi général que possible pour le rendre adapté aux différents projets. Dans le même livre, il est dit qu'Unreal utilise C++ avec LLVM.

Une autre idée qui pourrait être plus légère que l'implémentation d'un runtime séparé : qu'en est-il d'adapter un transpiler comme TypeScript (qui est très similaire à C#, sans le runtime) pour émettre du GDScript au lieu de JavaScript ? Cela n'a pas besoin d'être inclus dans Godot, en fait il peut s'agir d'un module tiers. Il offrirait au moins un typage statique (au moment de la compilation) et un certain nombre de bibliothèques, avec les mêmes performances que GDScript (car ce serait GDScript).

J'aime TypeScript, mais je ne vois pas l'intérêt d'ajouter une telle complication. Si quelqu'un le fait, il devra le maintenir pour qu'il soit compatible avec les nouvelles versions de TS. De plus, TS est un sur-ensemble de JS, donc serait-il capable de transpiler JS en GDScript ? Et puis, nous aurions des gens avec des bugs dans le transpiler pensant que c'est un bug dans le moteur.

Je pense toujours qu'une meilleure idée est d'avoir une version statique de GDScript qui peut recourir plus facilement au JIT et qui reste étroitement liée au moteur et au GDScript actuel lui-même.

L'intérêt de C# est d'utiliser un langage établi qui pourrait également être utilisé en dehors de Godot. TypeScript peut correspondre à cela, mais je ne suis pas convaincu qu'il soit plus facile de créer un transpileur TS que d'intégrer un runtime Mono.

Pour moi, comme je l'ai dit sur IRC, la meilleure option serait la possibilité de créer des modules liés dynamiquement. Ainsi, vous pouvez travailler plus facilement en C++ et il peut également y avoir des modules tiers avec différents langages, comme un pour C# et un pour C++ en tant que langage de script. Cela augmenterait la capacité de développer les ressources de Godot sans avoir à gonfler le binaire du moteur principal.

@vnen

Pour moi, comme je l'ai dit sur IRC, la meilleure option serait la possibilité de créer des modules liés dynamiquement. Ainsi, vous pouvez travailler plus facilement en C++ et il peut également y avoir des modules tiers avec différents langages, comme un pour C# et un pour C++ en tant que langage de script. Cela augmenterait la capacité de développer les ressources de Godot sans avoir à gonfler le binaire du moteur principal.

Oh, je suis d'accord à 100 % - en fait, j'ai exprimé un point de vue similaire au n° 3936. Je le lançais simplement depuis que nous avons mentionné le runtime de C # comme un inconvénient :)

Pour moi, cet exemple de module C # de @Zylann est charmant, je passerais de Unity dès maintenant s'il était disponible - il ne s'agit pas des performances supérieures de C++ ou de la "facilité" de GDScript, il s'agit d'être à l'aise.

Je suis encore super nouveau sur Godot et j'ai à peine eu la chance de faire un jeu de test pour le moment donc vous ne trouverez peut-être pas mon opinion valable, mais pour moi GDScript est le plus gros obstacle, pas dans la façon dont il est censé fonctionner avec Nodes et Scènes - Je comprends cela (et c'est plutôt chouette !).

Mais pour moi, c'est littéralement la syntaxe de GDScript qui est vraiment pour le moins rebutante, sans parler de l'éditeur de code qui fait cruellement défaut - j'adorerais utiliser VS car je connais déjà tous les raccourcis.
J'ai des années d'écriture en C# entre mes mains et honnêtement, je me sens comme un enfant qui essaie d'écrire en GDScript.

Que perdrait-on en permettant aux développeurs d'écrire confortablement ? Je n'ai pas besoin de la pléthore de Mono ou de fantaisie comme Linq, je veux juste être à l'aise pendant que j'écris mon code.
Je me contenterais d'une syntaxe de type C # pour GDScript, au moins la possibilité d'utiliser des parenthèses bouclées, des points-virgules et des types explicites - je ne supporte pas personnellement les types implicites, ils me rendent fou.
Je pense que GameMaker permet des variations de syntaxe pour s'adapter à différentes données démographiques.

Ce n'est bien sûr que mes 2 cents de plusieurs heures avec Godot - n'hésitez pas à être en désaccord (comme je suis sûr que la plupart d'entre vous le feront).

De plus, je pense qu'il me manque quelque chose - qu'est-ce que c'est exactement à propos de GDScript que tout le monde aime tant?
Je n'essaie pas d'offenser, je ne le vois pas encore.
Je connais bien Perl, donc je connais la puissance des types implicites et ainsi de suite, mais il doit y avoir plus que cela, n'est-ce pas?

@Pikl :

De plus, je pense qu'il me manque quelque chose - qu'est-ce que c'est exactement à propos de GDScript que tout le monde aime tant?
Je n'essaie pas d'offenser, je ne le vois pas encore.

Le point sur GDScript n'est pas beaucoup sur la syntaxe (qui est Pythonesque) mais plus sur la façon dont il est intégré au moteur. Cela peut sembler pédant, mais la syntaxe est le cadet des soucis lors du passage à un autre système. Ce qui compte le plus, c'est l'API. Même si nous ajoutions C # dès maintenant, vous vous sentiriez probablement mal à l'aise avec le nouveau paradigme, car la façon dont vous le faites dans Unity n'est pas la même que celle que vous faites dans Godot.

Désolé, mais si nous ajoutions des langues pour accéder à la zone de confort de chaque programmeur, nous passerions l'éternité à faire exactement cela. Bien qu'il puisse être logique d'amener les utilisateurs d'Unity avec le moins de stress (en ce moment, nous essayons de créer un guide Godot pour les utilisateurs d'Unity), je ne pense pas que Godot devrait s'adapter pour fonctionner comme Unity. Sinon, il faudrait faire la même chose pour les utilisateurs d'Unreal, Urho3D, GameMaker, etc.

Cela ne veut pas dire que C # ne se produit pas (cela pourrait l'être si c'est faisable et dans l'intérêt du moteur), c'est juste que ces arguments s'appliqueraient également à de nombreux autres langages et moteurs.

@Pikl Tout d'abord merci d'avoir fourni le premier argument en faveur de C#. Maintenant, laissez-moi vous expliquer pourquoi je pense que votre opinion est invalide. ;-P

Examinons de plus près le début de l'exemple de code de Zylann :

    using GodotEngine;

    public class Spikeball : RigidBody2D {

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

En règle générale, chaque mot-clé et chaque caractère non-mot-clé a une signification. Si ce n'est pas le cas, il ne devrait pas être là.
Cela commence par
using GodotEngine;
ce qui signifie que ce code fait référence à des fonctions importées du package "GodotEngine". Étant donné que chaque script de Godot fait référence à ces fonctions et qu'il n'y a pas d'autres packages à importer, il est inutile d'ajouter cette ligne, alors supprimons-la.

Ensuite nous avons
public class Spikeball : RigidBody2D {
Tout dans GDScript est public alors pourquoi le mentionner ?
class Spikeball : RigidBody2D {
Chaque fichier GDScript contient une classe portant le même nom que le script. Ce n'est pas juste une convention de codage comme dans d'autres langages, c'est défini comme ça, alors à quoi bon répéter le nom de la classe ?
: RigidBody2D {
Maintenant, puisque le : est le seul "mot clé" significatif dans cette ligne, remplaçons-le par quelque chose d'un peu plus lisible.
extends RigidBody2D {
Tout codeur avec un peu d'expérience utilisera l'indentation pour marquer les différentes zones du code. Cela signifie que le code à l'intérieur de la classe peut être identifié par les accolades ET par l'indentation, c'est pourquoi les développeurs de Python ont décidé de rendre l'indentation obligatoire et de se débarrasser des accolades désormais redondantes.
Dans notre cas, l'indentation n'est même pas nécessaire au niveau de la classe puisque chaque fichier de script est défini comme une classe (sauf si vous utilisez des sous-classes marquées par une indentation).
extends RigidBody2D

Ensuite, nous avons les lignes d'exportation.

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

Les caractères [] marquent les attributs qui sont définis dans les classes du même nom, ce qui est un mécanisme qui n'existe pas dans Godot, donc il utilise simplement des mots-clés à la place.

    export public float damage = 60f;
    export public float rotationSpeed = 2f;

Encore une fois, tout est public :

    export float damage = 60f;
    export float rotationSpeed = 2f;

et vous n'avez pas besoin de spécifier le type de données.

    export var damage = 60f;
    export var rotationSpeed = 2f;

Les exportations sont une exception car l'inspecteur a besoin de savoir quel widget vous montrer, donc le type n'est vraiment qu'une information supplémentaire pour le mot-clé d'exportation.

    export(float) var damage = 60f;
    export(float) var rotationSpeed = 2f;

Donc la différence entre ce code C#

    using GodotEngine;

    public class Spikeball : RigidBody2D {

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

et ce code GDScript

extends RigidBody2D

export(float) var damage = 60f;
export(float) var rotationSpeed = 2f;

est simplement que chaque caractère et mot-clé a été supprimé qui ne décrivait pas les options que vous avez dans Godot.
Je suppose que maintenant il est assez clair ce que les gens aiment à propos de GDScript. Vous n'êtes pas obligé de taper des éléments sans signification ou redondants et la syntaxe reflète les options dont vous disposez au lieu de faire allusion à des options ou à des fonctionnalités de langage qui n'existent pas dans Godot.

Venant d'une formation C++/C#/TorqueScript, je dois dire qu'il faut quelques jours pour s'habituer au paradigme de Godot, mais une fois que sa simplicité "clique", vous pouvez passer de l'idée à l'exécution à peu près aussi vite que vous pouvez taper.

@vnen :

c'est juste que ces arguments s'appliqueraient également à de nombreux autres langages et moteurs

Assez juste, je ne retiens pas mon souffle et je ne m'attends pas à être accommodé - ce n'est pas mon territoire.

en ce moment nous essayons de faire un guide Godot pour les utilisateurs d'Unity

Peut-être que je pourrais aider avec ça ? J'utilise Unity depuis plusieurs années et je connais assez bien la chose par rapport à n'importe quel autre moteur - je serais un bon rat de laboratoire pour ce guide.

@Warlaan :

Je suppose que maintenant il est assez clair ce que les gens aiment à propos de GDScript. Vous n'êtes pas obligé de taper des éléments sans signification ou redondants et la syntaxe reflète les options dont vous disposez au lieu de faire allusion à des options ou à des fonctionnalités de langage qui n'existent pas dans Godot.

Cela est parfaitement logique - cela va de pair avec l'idéologie de Perl de réduire le nombre de frappes nécessaires pour taper un script. Mais vraiment, le nombre de frappes que je taperais pour cet exemple serait le même - j'utilise la saisie semi-automatique de VS au maximum et je dois rarement taper plus de 3 caractères pour n'importe quel mot-clé, type ou nom de variable avant d'appuyer sur espace ou ouvert support pour le compléter. Et en ce qui concerne les caractères supplémentaires "inutiles" là-bas, je préfère les avoir là-bas, celui-là n'est qu'une préférence de sucre syntaxique.
Godot a une saisie semi-automatique mais c'est lent, cela prend tellement de temps que j'ai souvent tapé toute ma ligne de code avant même qu'elle n'apparaisse la plupart du temps.

Donc, ce que les gens aiment à propos de GDScript, c'est qu'il est dépouillé pour être aussi minimal que possible, fournissant la fonctionnalité exacte disponible à l'utilisation et rien de plus, ainsi que la réduction des frappes.

Je comprends, mais cela ne m'aide plus à en profiter - je ne suis tout simplement pas à l'aise pour taper GDScript, mais je peux le lire parfaitement bien. Je n'ai pas de mal à l'apprendre, je n'aime pas ça, semble-t-il.
Peut-être que quelques heures de plus à faire un clone de Space Invaders m'aideraient à me convaincre - je veux aimer GDScript plus que moi.

Après coup :
Est-il possible d'utiliser uniquement C++ dans Godot ? Honnêtement, je pense que je préférerais apprendre le C++ et l'utiliser plutôt que GDScript.

Peut-être que je pourrais aider avec ça ? J'utilise Unity depuis plusieurs années et je connais assez bien la chose par rapport à n'importe quel autre moteur - je serais un bon rat de laboratoire pour ce guide.

@StraToN a publié un message dans le groupe Facebook demandant ce type d'aide. Contactez-le (je ne sais pas s'il y a quelqu'un d'autre qui travaille là-dessus aussi).

@neikeq Merci, c'est fait !

@Warlaan Je comprends votre comparaison de code, mais pour moi, cela prouve principalement que C # a plus de fonctionnalités et, en tant que tel, est plus verbeux.

Vous avez besoin using car il existe des espaces de noms pour éviter les collisions de noms avec de nombreuses classes (ce qui m'arrive déjà dans mon propre projet de jeu).
Vous avez besoin public car il existe une notion d'encapsulation pour éviter les erreurs de codeur dans le temps.
Vous avez [SomeClass] car nous pouvons étendre les annotations intégrées pour répondre aux différents besoins du projet et améliorer l'outillage.
Quant aux accolades... je n'y vois pas d'avantage, sauf pour définir des portées.

Ces fonctionnalités sont là pour une raison. Parmi eux, je dirais l'évolutivité. Souhaitez-vous développer un énorme jeu 3D multiplateforme avec toute la base de code en GDScript ? Bien, vous pouvez. Mais beaucoup d'utilisateurs préféreront C++, C# ou Java, à cause des avantages que j'ai énumérés (et je parle uniquement du langage, pas du framework).

Mais en même temps, il n'y a pas de "gros" projet de jeu que je connaisse développé avec Godot, donc pas tellement d'exemples :p
De plus, je vois quelques mauvaises fonctionnalités en C # (avertissement : opinion personnelle à venir) :

Vous pouvez avoir des variables statiques. C'est faux, tant d'erreurs proviennent d'états/singletons globaux. Contrairement au chargement automatique, ils ne sont liés à aucune portée de scène.
Vous pouvez mal saisir un point-virgule à la fin d'une instruction while() of if(), ce qui le rend inutile et difficile à trouver.
Vous pouvez surcoder. Je suis d'accord que, lorsqu'il est utilisé dans le mauvais sens, le code C # peut devenir très compliqué alors qu'un autre code plus simple ferait de même. Mais cela dépend des personnes/de l'expérience.

Oh. Je n'ai pas mentionné preload() . Cela ne peut tout simplement pas arriver à C#/Java, à moins que vous ne vous appuyiez sur des astuces de compilateur :p

Quelqu'un a-t-il déjà commencé à expérimenter un module Mono ?

Pour ajouter mon opinion la plus humble, en tant que développeur C #, à cela ...

Je ne pense pas qu'il y ait beaucoup de valeur à ajouter C # à Godot, car vous devriez encore apprendre les cours de Godot pour faire quoi que ce soit et la seule chose que vous gagneriez vraiment à ajouter C #, c'est le style C plus familier (pour beaucoup) syntaxe et typage statique.
La syntaxe est discutable, Python a la réputation d'être facile à apprendre pour les débutants et puisque GDScript est très similaire à Python, je pense qu'il en va de même pour lui.
Les programmeurs un peu expérimentés ne devraient de toute façon pas avoir de mal à comprendre cette syntaxe, elle est cohérente et présente considérablement moins de pièges que la syntaxe de style C plus libre.

Maintenant, le typage statique peut avoir une certaine valeur, en plus d'aider à la performance, il peut également aider à la vitesse de développement à certains égards. Les outils d'auto-complétion adorent savoir quel type une fonction/méthode donnée attend et renvoie, mais seuls les conseils de type peuvent y parvenir.
Cela pourrait cependant être ajouté à GDScript, pas besoin de langage supplémentaire.

De plus, la mise en œuvre de C # ne serait probablement pas si facile et beaucoup de temps et d'efforts seraient consacrés à mettre le moteur dans l'état dans lequel il se trouve actuellement, mais maintenant avec C # au-dessus ou à la place de GDScript.

En guise de conclusion, que je sais que certaines personnes prendront dans le mauvais sens, j'ai ceci à dire :

J'ai observé que certains programmeurs qui pourraient ne pas être aussi solides qu'ils le devraient dans notre métier ont tendance à s'accrocher à ce qu'ils savent avec toute la force dont ils disposent.
Ce phénomène me semble être particulièrement répandu dans les communautés de développement C #, même si cela pourrait être mon parti pris.
Si l'une des personnes qui lisent ceci pense qu'elle pourrait correspondre à cette description, je ne peux que recommander de sortir de cette boîte familière et de commencer à apprendre quelque chose de nouveau, ce n'est pas une tâche aussi intimidante que vous pourriez le penser et une fois que vous avez une entreprise compréhension de cette nouvelle chose, vous aurez probablement aussi accru votre compréhension de ce que vous saviez déjà. Cela en vaut la peine.

J'adorerais les types statiques, mais si cela se produisait, comment traiteriez-vous les génériques ? Utiliseriez-vous simplement un type dynamique dans cette instance ou voudriez-vous pouvoir utiliser des contraintes ? - n'autoriser que les entiers et les booléens par exemple.

Les espaces de noms seraient extrêmement bienvenus, je suis surpris qu'ils n'existent pas déjà dans GDScript.

L'option d'utiliser des accolades au lieu de deux-points pour les méthodes serait bien aussi, je sais qu'elles sont inutiles mais j'aime les avoir là-bas - c'est comme lire un livre sans arrêts complets, c'est choquant.

Les indications de type pourraient combler l'écart empêchant la complétion du code de fonctionner totalement. Une fois, j'avais travaillé sur un projet utilisant Lua, et ils voulaient aussi avoir cela. La recherche m'a conduit ici : https://github.com/andremm/typedlua/blob/master/examples/http-digest/http-digest.tl#L48
C'est ce qu'un paramètre de fonction peut devenir, si vous plongez trop loin dans l'indication de type xD
Mais je pense qu'il devrait y avoir un compromis. Voyez simplement comment TypeScript ou Haxe fonctionnent (ils permettent tous les deux de mélanger des variantes et des typés). De plus, l'indication de type est déjà présente dans Godot. Il n'est utilisé que dans export() :)

Quelqu'un a-t-il déjà commencé à expérimenter un module Mono ?
@Zylann

Découvrez GodotSharp . L'état actuel du référentiel n'est pas encore utilisable. Dans mon référentiel local, j'ai réussi à implémenter suffisamment de choses (seuls Vector2 et Matrix32 sont disponibles en tant que types de base) pour traduire la démo 2d/plateforme en C #, à l'exception des ennemis et des instanciations de balles qui se font à partir de GDScript puisque les références ne fonctionnent pas encore.
Voici un exemple de la classe player : https://github.com/neikeq/GodotSharp/blob/master/platformer_cs/Player.cs

@Pikl

Après coup :
Est-il possible d'utiliser uniquement C++ dans Godot ? Honnêtement, je pense que je préférerais apprendre le C++ et l'utiliser plutôt que GDScript.

Oui, c'est possible, mais actuellement ce n'est pas si facile et/ou pratique et vous devez recompiler Godot à partir de zéro. Veuillez montrer un support pour # 3936 si vous souhaitez que C++ soit un citoyen de première classe, afin qu'il puisse être utilisé avec GDScript (ou exclusivement) sans trop de travail.

@Zylann Pikl a posé des questions sur la modification de la syntaxe de GDScript pour qu'elle ressemble à celle de C # afin qu'elle devienne plus facile à lire pour les développeurs Unity. C'est ce que je commentais. Oui, C # a plus de fonctionnalités, c'est la seule raison pour laquelle les mots-clés et les caractères que j'ai supprimés étaient là en premier lieu. Et c'est pourquoi les ajouter juste pour avoir du code GDScript qui ressemble à du code C # n'est pas simplement inutile, à mon humble avis, c'est faux, car vous utiliseriez une syntaxe qui fait allusion à des fonctionnalités de langage que GDScript n'a pas.

@Pikl Il ne s'agit pas de la quantité de touches, mais de la quantité de choix et de la signification implicite des caractères supplémentaires. GDScript n'a tout simplement pas certaines des fonctionnalités qui légitimeraient les mots-clés supplémentaires. Par exemple, chaque variable, classe et fonction devrait être précédée du mot-clé "public", puisque le modificateur de visibilité par défaut de C # n'est pas public (sauf pour les espaces de noms - il change en fonction du cas d'utilisation ... une autre situation où Microsoft a décidé que KISS n'est qu'un groupe des années 80) et depuis dans GDScript tout est public.

Alors pourquoi ne pas ajouter C# avec toutes ses fonctionnalités ?
Comme Zylann l'a déjà mentionné, l'effet de l'ajout de C # à Godot n'est pas si simple à prévoir. Si vous ne l'avez pas encore fait, j'apprécierais que vous lisiez mon long message dans ce fil (https://github.com/godotengine/godot/issues/5081#issuecomment-225226235). En tant que développeur, j'aurais toujours demandé des langages plus puissants. Pendant mon temps libre, je regarde actuellement Kotlin simplement parce que Paper-pauper l'a mentionné dans le premier message.
Mais depuis que j'ai eu l'occasion de regarder l'effet des langages de programmation sur le résultat et le comportement des développeurs de jeux, j'ai réalisé à quel point il est important de choisir un langage adéquat plutôt qu'un puissant.
Comme je l'ai expliqué dans le post lié, je suis certain que C # a une influence notable sur la culture de la communauté Unity qui considère les programmeurs comme des personnes qui

• écrire des trucs pour le magasin d'actifs
• écrire des tutoriels
• corriger les bugs.

D'après mon expérience, il n'y a pas beaucoup de culture de programmation de gameplay dans Unity. Dès que vous rencontrez un problème quelconque, vous commencez à rechercher des modèles ou des ressources prédéfinies pour le résoudre. Il y a en fait un nombre important de personnes qui choisissent leurs modèles avant même de savoir quoi que ce soit sur un projet, et ce genre de rigidité mentale affecte les résultats du gameplay.

Et c'est juste mon contre-argument préféré, il y en avait plusieurs autres bons dans les premiers messages. ;-)

Le problème avec JVM est qu'il est trop lourd. Est-ce que quelqu'un a jeté un œil à Avian ? Dans quelle mesure est-il compatible avec le monde Java ?

@neikeq Cela ne signifie pas qu'il a de moins bonnes performances - AFAIK, la JVM a de meilleures performances que le CLR, et aussi un Garbage Collector bien mieux adapté au développement de jeux. Il est également installé sur la plupart des ordinateurs, qu'ils soient Windows, Mac ou GNU/Linux.

Il dispose également d'une plus grande richesse de bibliothèques FLOSS de meilleure qualité et, quoi qu'en disent certaines personnes, d'un meilleur support multiplateforme.

Je dirais qu'entre les deux, la JVM est nettement meilleure pour le développement de jeux (mais j'éviterais à la fois celle-ci et le CLR tout de même).

Avian a l'air intéressant. Je n'en ai pas l'expérience, donc je ne peux pas répondre à votre question, et je crains que sa compatibilité ne s'avère aussi problématique que la version Mono d'Unity, ce qui rend vraiment difficile l'utilisation de bibliothèques tierces à moins que vous arriver à en trouver un pour l'une des versions .NET fournies.

Mais avoir une implémentation Java légère comme option supplémentaire en plus de GDScript et C++ pour les cas où vous avez besoin de délais d'exécution rapides et pouvez sacrifier la qualité du code (comme les jams de jeu ou le prototypage rapide de nouvelles idées de backend) serait bien.

@neikeq Avian est conçu pour fournir des scripts java pour les projets c++, c'est donc vraiment un bon candidat. Il peut être très petit (quelque chose comme 100kb si je me souviens bien). J'ai entendu parler de certains jeux libGDX qui utilisaient Avian pour libérer les ports iOS... Le moteur jMonkey utilise également Avian sur iOS). En général, Avian est livré sans emballage complet qui vient normalement avec JVM comme les classes sun/oracle. Cependant, je ne pense pas que ce soit un problème car les classes Java "originales" ne conviennent pas du tout aux jeux, c'est pourquoi des bibliothèques comme libGDX fournissent leur propre implémentation sur des vecteurs ou des structures de données .. et à la fin je pense que nous le ferions besoin de réimplémenter ces classes ainsi. (Cependant, il est facile d'intégrer diverses parties des classes Java originales, mais plus nous en incluons, plus Avian deviendra grand)

@paper-pauper Je voulais dire lourd, en supposant qu'il soit fourni avec le jeu. Mais comme vous l'avez dit, il est installé sur la plupart des ordinateurs, et compte tenu de la popularité des frameworks comme libGDX, cela pourrait être la meilleure option.
Mon problème avec C++ comme alternative à GDScript est que sa syntaxe est horrible. C'est un tueur de productivité. C'est bien pour le développement de moteurs et de modules, mais je n'écrirais pas un jeu entier avec. Cela dit, je suis en faveur de # 3936 et d'avoir quelque chose comme ce que fait Unreal, mais je ne le considérerais pas comme un langage de "script" alternatif.

@ kubecz3k Prend -il en charge d'autres langages JVM ? ex: Kotlin

@neikeq ouais pour autant que je sache, il est entièrement compatible avec le bytecode java donc il prend en charge n'importe quel langage prêt pour jvm (kotlin, scala, jpython et ainsi de suite)
Je pense que nous pourrions poser quelques questions sur le groupe google aviaire : https://groups.google.com/forum/#!forum/avian
il semble être assez actif

+1 pour ne pas considérer C++ comme un langage de script alternatif. Comme je l'ai déjà dit, c'est une bonne chose que Godot ait un langage optimisé pour les scripts et un autre pour le développement backend, au lieu d'avoir un langage qui est un peu "meh" dans les deux domaines.

Cela ne veut pas dire que la prise en charge dynamique des bibliothèques et un développement C++ plus rapide n'étaient pas quelque chose que j'aimerais voir.

Mais pour ne pas être trop enthousiaste à propos d'Avian, voici un article de blog du développeur principal de libGDX dans lequel il explique pourquoi libGDX n'utilise pas Avian pour les ports ios. http://www.badlogicgames.com/wordpress/?p=3925 (faites défiler jusqu'à la partie aviaire)
Je ne suis pas un programmeur/hacker jvm (mais l'auteur l'est - puisqu'il travaillait également sur RoboVm (encore un autre jvm qui a été acheté et fermé par Microsoft)) donc je ne sais pas dans quelle mesure cela se transformerait vraiment en situation dans laquelle Avian est utilisé uniquement comme langage de script (n'alimentant pas le moteur principal)

La plupart d'entre vous sont probablement des programmeurs avec plus d'expérience que moi, mais il y a mes 2 cents. Il y a un an, je m'enracinais pour C#. Mais j'ai appris la syntaxe GDScript très rapidement. En fin de compte, vous devez toujours apprendre l'API et c'est probablement la chose la plus longue à apprendre. Alors oui, je n'ai pas besoin de C #. @Warlaan a sorti beaucoup de bonnes raisons contre C#. Implémenter C# prendrait également beaucoup de temps. Cela signifierait également plus de bugs. Oui, nous avons une grande communauté qui contribue à la base de code mais nous n'avons toujours qu'un seul @reduz Je pense que le temps nécessaire pour implémenter C # devrait être investi dans les fonctionnalités dont nous avons vraiment besoin. Combien de développeurs Godot sont satisfaits de GDScript ? Oui, ça pourrait être plus rapide, mais je n'ai pas d'autres problèmes avec ça. Je préférerais avoir un langage de script génial plutôt que deux moins bons. Même Unity est à la traîne avec l'ancien Mono.

Ce que je voudrais avoir, c'est le typage statique dans GDScript. Pas C++ en tant que langage de script, pas C#. Concentrons-nous sur GDScript et rendons-le encore meilleur qu'il ne l'est actuellement.

Étant donné que le moteur sur lequel j'ai dirigé le développement pendant 14 ans a été mentionné dans le fil de discussion Visual Scripting, j'ai pensé ajouter mes 2 cents ici car nous développions un nouveau moteur entièrement écrit dans notre propre langage de type C#.

Nous avons écrit notre propre compilateur (également écrit dans notre propre langage après l'avoir amorcé en C++) qui a été compilé en code C++ (C presque pur) qui a ensuite été introduit dans les compilateurs de toutes les plates-formes que nous avons prises en charge (XBox/PS/PC/Wii/ etc). Nous avons écrit notre propre ramasse-miettes générationnel pour pouvoir ajuster ses performances selon les besoins - le faire de cette façon signifiait qu'il était utilisé dans tout le moteur, ce qui signifiait qu'il était bien testé et profilé. Et puisque nous faisions de la compilation croisée en C++, nous pouvions facilement écrire du code C++ dans des fonctions "natives" qui pourraient appeler des API système selon les besoins ou inclure des opérations spécifiques à la plate-forme (SIMD).

Je ne peux pas vraiment imaginer à quel point cela doit être frustrant pour Unity d'avoir dû fusionner un tas de code C++ avec Mono - ce qui explique probablement pourquoi il est à la traîne comme l'a souligné @GlaDOSik . Ce n'était certainement pas quelque chose qu'aucun d'entre nous n'était intéressé à faire.

Notre objectif principal était d'unifier les langages utilisés entre le moteur, l'éditeur et les outils, et le code de gameplay en un seul langage. Auparavant, le moteur et les outils étaient entièrement en C++ et un langage de script visuel (il ressemblait au moins à du code C) était utilisé pour tout le gameplay préféré des concepteurs de niveaux, mais ennuyait la majorité des programmeurs de gameplay qui écrivaient la majorité du code. Cela nous a également permis d'adapter le langage aux éléments dont nous pourrions avoir besoin pour le développement du gameplay (comme le support de la machine d'état).

_Cependant, vous ne pouvez pas plaire à tout le monde._ Si je devais travailler ou essayer d'aider quelqu'un à déboguer un vilain gâchis de "code" basé sur des nœuds spaghetti blueprint/etc, je voudrais m'arracher les yeux en représailles. Je m'attendrais à ce qu'un artiste essayant de lire du code C++ fasse de même. Ce que vous pouvez faire, c'est perdre _beaucoup_ de temps à discuter de la _meilleure_ solution et encore plus à essayer de plaire à tout le monde. À un moment donné, vous devez simplement vous concentrer sur la création des outils les plus productifs possibles pour les bonnes personnes - et parfois cela signifie que quelques personnes devront peut-être apprendre quelque chose de nouveau.

"Si ce n'est pas du C++, c'est lent" semble souvent être le mantra, mais je dirais que la majorité des jeux _expédiés_ sont écrits avec autre chose que du C++ pour le code de jeu de nos jours. En fait, je n'ai jamais vu quelqu'un publier des problèmes de performances spécifiquement à partir de GDScript, même si je serais certainement curieux d'entendre ce qui était lent.

En ce qui concerne mon introduction à GDScript, cela ressemblait à ceci :

• OMG comme Python ! ? C'est fou, les espaces blancs ne devraient pas avoir d'importance !
• Hmm, pas un fan du style "lower_case" (voir vous ne pouvez pas plaire à tout le monde).
• Bon ok, c'est plutôt cool et bien pensé.
• Ouais, c'est bien intégré à l'éditeur, je pourrais certainement voir être très productif avec ça pour le code de gameplay et certains plugins d'éditeur !

Il semble que beaucoup d'efforts et de temps aient été consacrés à GDScript, et cela semble être le bon outil. Donc, je voulais vraiment dire bravo à ceux qui ont travaillé pour le faire!

@Ziflin Salut ! heureux de vous rencontrer ici, Vicious a été l'un des premiers moteurs de jeu que nous avons utilisé professionnellement (bien que nous ayons été embauchés avec @punto- pour le pirater et résoudre les problèmes avec lui plus que de l'utiliser réellement).

Le langage de script visuel était vraiment un cauchemar, mais le code source était vraiment bien fait, propre et organisé. Après avoir travaillé avec Torque, c'était un bonheur. J'ai beaucoup appris en travaillant avec. Sony a fait un excellent travail en le vendant en Amérique latine parce que tout le monde l'utilisait ici il y a dix ans.

Je pense que le moment le plus étonnant dont je me souviens de travailler avec lui est de tomber accidentellement sur un morceau de code qui répertorie les langues, et il y avait un commentaire "Portugais non pris en charge"

Nous étions vraiment en train de rire et de faire des blagues, et le producteur du jeu (qui était derrière nous et nous ne l'avons pas remarqué) tremblait de peur et a dit : "Attendez quoi ? Il ne reste plus qu'à traduire le jeu en portugais. , C'est une blague, n'est-ce pas?"

Mais nous avons juste utilisé le chinois pour le portugais, tout a bien fonctionné et le jeu a été expédié. Heureux de savoir que vous êtes encore en train de le développer !

(citation de @Ziflin ) Je n'ai jamais vu quelqu'un publier des problèmes de performances spécifiquement à partir de GDScript, même si je serais certainement curieux d'entendre ce qui était lent.

J'ai personnellement atteint un goulot d'étranglement CPU / Gdscript dans ce projet : http://godotdevelopers.org/index.php?topic=15519.0

J'ai écrit une IA de base et une pseudo-physique de base à l'ancienne dans GDscript pour contrôler chacune des 8 voitures.
Je n'ai pas crié haut et fort en public à propos de ce problème de performances car il restait encore quelques petites marges d'optimisation.
Mais si je voulais ajouter plus de voitures, j'aurais été obligé de laisser tomber Gdscript pour C++ ( edit : ce que j'aimerais éviter car je ne veux pas vraiment avoir à compiler encore et encore).

Aussi, je pense que j'ai rencontré le même goulot d'étranglement CPU / Gdscript l'année dernière avec cet autre projet qui utilisait GDscript pour l'IA de base pour chaque bug (animaux) : http://ludumdare.com/compo/ludum-dare-32/? action=aperçu&uid=50893
Plus j'ajoutais de bugs (animaux), plus les performances étaient faibles.

Je pourrais partager mon expérience dessus si quelqu'un le souhaite.

@SuperUserNameMan S'il vous plaît, allez-y, mais je pense que cet autre ticket que j'ai ouvert # 5049 (qui parle spécifiquement des performances de GDScript) est plus adapté à cela.

@paper-pauper : je ne suis pas sûr de pouvoir contribuer #5049 (qui est plus sur l'ajout de JIT, sur ce que je pourrais juste ajouter un pouce levé). L'expérience que je pourrais partager concerne davantage le type de goulot d'étranglement que j'ai atteint, quels étaient les symptômes spécifiques, comment j'ai dû contourner, comment j'ai optimisé et quels "avantages de conception de Godot" j'ai dû sacrifier.

@SuperUserNameMan Je n'ai pas encore beaucoup réfléchi à l'implémentation de JIT via l'inférence de type, mais pour cela, la machine virtuelle doit d'abord prendre en charge le typage statique

Je serais très intéressé de savoir à quel type de code AI vous faites référence.
Ma préconception serait que tout code pouvant causer des problèmes de performances lorsqu'il est exécuté sur seulement 8 entités n'est probablement pas vraiment du code de jeu et, en tant que tel, devrait de toute façon être placé dans une classe C++, c'est pourquoi je demande.

@reduz Haha, ben apparemment c'est un petit monde ! Et yah, le genre de script visuel est devenu incontrôlable (il était vraiment destiné à traiter uniquement les déclencheurs et les petits morceaux de logique d'événement). Vicious a en fait fermé ses portes plus tôt cette année, mais c'était très amusant d'y travailler.

@paper-pauper Je vais vérifier l'autre sujet que vous avez mentionné. Je ne voulais pas vraiment que les gens commencent à publier des problèmes de performances dans ce fil.

Si GDScript devait ajouter un typage statique, il serait peut-être plus simple d'avoir une option pour le convertir directement en C++, ce qui éviterait une surcharge supplémentaire des transitions IL->C++ et maintiendrait le temps d'exécution petit (pas de compilateur JIT, etc.). Vous pouvez ensuite prototyper dans GDScript ou créer des mods avec, mais vous pouvez également le convertir automatiquement en C++ pour plus de vitesse en cas de besoin pour les versions finales.

Cela permettrait également de conserver les IDE existants (VC++, etc. et l'éditeur Godot) que les gens avaient l'habitude d'utiliser. En fait, nous venons d'utiliser VC++ pour déboguer notre langage et notre compilateur a généré des directives #LINE dans les fichiers .cpp afin que vous puissiez facilement parcourir le code d'origine et définir des points d'arrêt. Donc, en théorie, vous seriez capable de prototyper et de déboguer avec GDScript normal dans l'éditeur, mais pendant les constructions activées par 'GDScript->C++', vous pourriez toujours utiliser votre IDE/débogueur C++ et définir des points d'arrêt/débogage dans les fichiers gdscript. Pour nous, les fichiers C++ générés étaient temporaires et nous ne les regardions que s'il y avait un problème de génération de code.

Quoi qu'il en soit, juste une pensée. Le fait que vous ayez maintenant un bon langage de script est définitivement un plus et cela permet certainement de faire des choses comme des mods créés par l'utilisateur, un prototypage rapide et l'ajout de nouvelles fonctionnalités au langage.

En effet, je n'ai pas compris que j'étais censé poster mes problèmes de performances dans ce fil non plus. Ici était plus adapté : https://github.com/SuperUserNameMan/kart-zero/issues/1

@Ziflin En fait, ce dont nous discutions dans d'autres problèmes est d'abord, ajouter une API C minimale pour écrire des modules/scripts godot en utilisant du C ordinaire via une API minimale qui expose toute l'API de réflexion de Godot, cela résoudrait un problème commun que nous avons concernant la distribution des liaisons à différents types de bibliothèques sans avoir à recompiler Godot

Des exemples de ceci sont des gars qui veulent lier l'API Steam, ODBC, SQLite, Kinect, etc. Tout cela nécessite d'écrire des modules en C++. Faire cela avec une API C résout le problème de la liaison dynamique avec C++ (ce qui est très limité en raison du fait que chaque compilateur ou version de compilateur a son propre ABI et les problèmes d'incompatibilité de taille de symbole qui peuvent survenir entre les versions de Godot). C n'a aucun de ces problèmes.

Une fois que cela fonctionne, il devrait être très facile de compiler GDScript en C et de le charger au moment de l'exécution lorsque le jeu s'exécute ou est exporté.

@reduz Ah cool. Donc, fondamentalement, vous parlez de pouvoir écrire une DLL "plugin" qui peut exposer ce qu'elle veut à GDScript ? (ou j'ai mal compris ?)

Une fois que cela fonctionne, il devrait être très facile de compiler GDScript en C et de le charger au moment de l'exécution lorsque le jeu s'exécute ou est exporté.

Cela fonctionne-t-il pour quelqu'un qui souhaite écrire une DLL contenant, par exemple, plusieurs nouveaux types dérivés de nœuds C++ ?

Il est un peu triste que la nouvelle prise en charge des "modules" C++ semble suffisante pour résoudre certains des problèmes liés aux DLL.

Pourquoi ne pas utiliser un langage de script intégrable tel que Lua ou Ruby ?

@jersten car lisez la documentation - http://docs.godotengine.org/en/latest/reference/gdscript.html

@Ziflin oui, mais vous devrez utiliser l'API C via la réflexion (bien que vous puissiez demander des pointeurs de fonction via la réflexion, cela devrait donc être assez rapide ..). L'objectif serait principalement d'avoir un moyen simple de charger des DLL qui évite le problème ABI, et aussi un moyen simple de compiler GDScript en C et de le charger en tant que .so.

Je vais donner mes 2 cents ici pour ce qui vaut. Je n'ai jamais codé en C# mais uniquement en Java. Bien que je préférerais personnellement Java parce que je l'ai utilisé et que je l'ai aimé, je prends en charge C# plutôt que Java. C # est ce que les développeurs de jeux Unity utilisent, donc l'avoir ferait de Godot une partie de cet écosystème de développement indépendant créé par Unity. De plus, Java n'est même pas un bon choix si vous voulez un langage JVM. Il existe d'autres meilleurs langages qui compilent en JVM.

Je pense que les gens manquent le point de toute façon. C#/Java != langage de script. GDScript est suffisant ; assez facile à apprendre, etc.

Ajouter un langage comme Java (construire une JVM dans quel but ?! Syntaxe ?! Nécessite une JVM avec une version spécifique pour fonctionner ?!?) ou C# (implémenter mono et brouiller le moteur ; ou construire le vôtre ?) empoisonnerait le moteur .

S'il y a un problème avec GDScript, il faut le signaler ; puis a tenté d'être corrigé.

Je ne suis pas d'accord. Je pense que C # attirerait beaucoup de développeurs Unity ou de développeurs qui connaissent les langages de type C, offrant une belle alternative au python comme GDScript. La dernière pièce du puzzle serait une scénarisation visuelle qui attirerait des artistes qui n'ont pas l'habitude de coder. Cela devrait couvrir à peu près tout le monde.
De plus, peu importe ce que vous codez, vous devez toujours apprendre les classes et les fonctions de Godot qui seraient les mêmes dans n'importe quelle langue.

À tous ceux qui soutiennent C# parce que les développeurs Unity le connaissent, considérez ceci : beaucoup de développeurs Unity ne savent rien sur la programmation en C#. Ce qu'ils savent, c'est comment utiliser l'API Unity, qui se trouve justement avoir des liaisons C#. Vous les amenez à Godot, même si c'est C #, ils ne sauront pas ce qu'ils font de toute façon et seront tout aussi perdus que de leur fournir un langage de programmation différent.

L'inclusion de langues supplémentaires est simplement plus lourde et plus que le projet doit maintenir qu'il ne devrait pas avoir à le faire.

J'y pensais beaucoup, et ma principale préoccupation concernant la prise en charge de quelque chose comme C # est que la plupart des personnes qui l'utiliseraient seraient des utilisateurs d'Unity venant à Godot. De toute évidence, nous n'inclurions pas C # avec les modèles officiels, et je doute fortement qu'ils construiraient le module eux-mêmes ...
Cela pourrait finir par être un gros effort pour soutenir un langage qui ne serait utilisé que par quelques-uns.

Je pense qu'il y a un malentendu :

• Ils voient GDScript et pensent que GDScript est comparable à C# ; manquant le point fondamental que C # n'est pas un langage de script.
• En raison du fait ci-dessus, quand quelqu'un dit "Java ou C#" ; ce qu'ils demandent vraiment, c'est une réécriture du moteur en C#/Java ou l'ajout de liaisons pour prendre en charge ces langages (lol non).

Puisque je suppose ce dernier; le débogage en C#/Java est un cauchemar sur plusieurs plates-formes ; car ces deux langages ne sont pas indépendants de la plate-forme (inb4, il existe des runtimes sur pratiquement tous les systèmes d'exploitation); il se transforme en "Ecrire une fois, déboguer partout" (c'est pourquoi les jeux écrits sur Monogame sortent d'abord sur Windows, puis éventuellement sur Linux/Mac car les développeurs doivent déboguer pour ces plates-formes). C'est pourquoi JVM met à jour les applications de rupture.

L'ajout de la prise en charge de ces langues n'ajoute aucune valeur au moteur.

Si l'argument est "moar Unity devs" ; ensuite, une documentation doit être créée pour aider les développeurs Unity à faire la transition ; que les différences de mise en page, etc.

C'est pourquoi j'ai dit à la fin que peu importe la langue que vous utilisez, vous aurez toujours besoin d'apprendre les classes de l'API Godot et tout. Ce n'est pas comme si les développeurs Unity étaient des experts d'insta parce qu'ils connaissent C#. Je suppose que c'est plus une "aura de bonté" pour Godot s'il prend en charge C#. Les gens ont l'impression d'en savoir plus et tout d'un coup Godot est plus accessible et moins effrayant. La première chose négative à propos de Godot pour les non-utilisateurs de Godot est qu'il a son propre langage de script. En tant qu'utilisateur de Godot, vous savez que BS parce que GDScript est un langage amusant et simple, mais pour un étranger, cela peut sembler peu attrayant.
Je ne peux pas parler du point de vue des développeurs, mais cela représente peut-être plus d'efforts que ce qui en vaut la peine, à moins que les développeurs n'obtiennent quelque chose de l'implémentation de C #, alors cela en vaut la peine. En fin de compte, c'est la décision des développeurs principaux et quoi qu'ils décident, je m'en accommoderai. Je suis sûr que ce sera une bonne décision.

Je suis d'accord avec vous sur le fait que GDScript est un peu rebutant car c'est un langage pratiquement inconnu. Mais, après avoir lu pourquoi Lua et Python ont été supprimés et les avantages de l'ajout de GDScript, j'étais moins inquiet.

Une autre chose qui pourrait être pertinente : il existe un autre moteur sous licence MIT qui prend déjà en charge C# et qui ressemble davantage à Unity, Atomic Game Engine . Je suggère à toutes les personnes qui ont désespérément besoin de quelque chose d'aussi proche que possible d'Unity d'essayer.

Je vais juste ajouter mes 2 cents ici. Pour moi, le gros avantage de C# est la performance, tout en étant plus facile à utiliser que C++. GDScript, étant typé dynamiquement et tout, est très rapide à écrire, mais ne sera jamais ultra rapide à exécuter (bien qu'il puisse être beaucoup optimisé, ce qui est prévu). Les modules C++ sont très rapides, mais ils sont assez difficiles à utiliser ; C++ n'est pas exactement un langage convivial, et devoir recompiler le moteur pour les utiliser n'est pas vraiment optimal. Pour moi, C# est une sorte de compromis : beaucoup plus rapide que GDScript, et avec le support approprié, beaucoup plus facile à utiliser que les modules C++.

Tout cela étant dit, il n'est pas nécessaire que ce soit C#. Tout ce qui aurait un effet similaire ferait l'affaire, en ce qui me concerne, qu'il s'agisse de GDScript compilé/JIT typé statiquement, ou de quelque chose d'autre comme Swift ou quelque chose du genre. C# est peut-être le meilleur à des « fins de marketing » ; même sans une API similaire, les développeurs d'autres moteurs/frameworks seraient probablement plus à l'aise avec. Le GDScript modifié peut être plus facile à mettre en œuvre et serait probablement beaucoup mieux intégré.

Je sais que le fil est très long maintenant, mais veuillez lire tous les messages ci-dessus avant de poster quelque chose par vous-même. L'argument selon lequel C# allait attirer les gens et était très pratique pour les utilisateurs d'Unity n'est plus valable s'il est mentionné une douzaine de fois plus.

Voyez ici pourquoi à mon humble avis C # est excellent pour Unity et mauvais pour Godot, voyez ici pourquoi à mon humble avis l'ajout de C # conduira à du code sale, non seulement dans vos propres projets mais aussi dans des didacticiels en ligne, le magasin d'actifs à venir, etc. et voyez ici pourquoi à mon humble avis le L'argument selon lequel les gens devaient apprendre beaucoup de nouvelles choses lors du passage de C # à GDScript n'est pas valide.

Permettez-moi d'ajouter un commentaire sur l'argument selon lequel C # apporterait de nouvelles personnes.
Pourquoi voulons-nous que plus de gens utilisent Godot ? Je comprends tout à fait que les projets open source ont besoin d'une communauté qui

• ajoute des fonctionnalités
• corrige des bogues
• crée des actifs réutilisables
• fait des suggestions pour de nouvelles fonctionnalités
• trouve des bogues ou des problèmes avec le flux de travail
• écrit des tutoriels

mais tout ce qui précède a besoin de personnes qui comprennent et apprécient l'idée de base du moteur. Les personnes qui ajoutent des fonctionnalités inutiles à une bibliothèque n'aident pas et il y a eu plus d'un projet qui a souffert de telles fonctionnalités, parfois jusqu'au point où le projet a été abandonné ou divisé.
Unity souffre particulièrement des personnes qui écrivent des tutoriels même s'ils ne comprennent pas vraiment ce qu'ils font, ce qui est en grande partie la faute de C#.

Si les gens ne veulent même pas ou ne peuvent pas apprendre un langage aussi simple que GDScript, il est très douteux qu'ils prennent le temps de bien comprendre la philosophie de conception de Godot avant de commencer à contribuer activement à la communauté. (« Contribuer activement », c'est-à-dire tout ce qui va de l'envoi de demandes d'extraction à la publication de leur opinion sur Godot sur Facebook.)

Godot n'est pas un moteur commercial. Unity a intérêt à faire venir le plus de monde possible car ce sont tous des clients potentiels et de la publicité pour le moteur. Ce serait certainement bien d'avoir une grande communauté d'utilisateurs qui apprécient Godot tel qu'il est, mais il ne sert à rien de sacrifier certaines des qualités de Godot pour répondre aux besoins d'une communauté plus large.

@Warlaan les gens ne veulent généralement pas perdre de temps et ils utiliseront tous les extraits de code qu'ils trouveront lors de la construction de leurs projets, en particulier au début lorsque vous apprenez. Pour les débutants, vos points sont légèrement pertinents car ils finiront par apprendre quelle que soit la langue dans laquelle les extraits de code qu'ils utilisent sont écrits. Je le sais parce que c'est ainsi que j'ai appris à regarder des exemples et que je ne connaissais pas le script GD mais je l'ai appris. Le problème n'est pas ce qui est le mieux ou comment cela affectera ou compliquera les tutoriels, etc. Le problème (pour moi) est C # plus que tout autre langage fera de Godot une partie de cet écosystème de développement indépendant dont Unity fait partie. Il ne s'agit même pas d'Unité, il s'agit de Godot.

EDIT : suppression d'un langage inutilement dur ;-)

@trollworkout Aucune offense, mais vous n'avez pas vraiment compris mon point de vue et j'ai l'impression que vous n'avez pas vraiment réfléchi à ce que vous avez dit non plus.

1. Oui, les gens ne veulent pas perdre de temps. Les spécifications complètes de GDScript : quelques écrans. Livres expliquant C# : généralement au moins 500 pages. J'ai passé quelques jours à apprendre GDScript et je suis certain qu'il n'a pas une seule fonctionnalité que je ne connaisse pas. J'ai travaillé à la fois professionnellement et pendant mon temps libre avec C # depuis des années (en utilisant Window Forms, WPF, XNA et Unity) et je trouve toujours des extraits de code qui utilisent des fonctionnalités que je n'ai pas entièrement comprises. Demander C # parce que c'était moins une perte de temps n'a pas vraiment de sens.
2. "les débutants finiront par apprendre quel que soit le langage dans lequel les extraits de code qu'ils utilisent sont écrits" - voir point 1. L'idée que vous pourriez apprendre C # à partir d'extraits de code est loin d'être vraie. Les choses que vous pouvez apprendre de cette façon sont si basiques qu'il ne vous faudra pas plus de quelques jours pour "apprendre" une autre langue. Vous avez dit vous-même que vous avez appris GDScript de cette façon.
3. "C # fera de Godot une partie de cet écosystème de développement indépendant". Et qu'est-ce que c'est censé vouloir dire ?
   Pourriez-vous utiliser des extraits de code Unity en C#-Godot ? Non.
   Pourriez-vous réutiliser les ressources Unity dans C#-Godot ? Non.
   Pourriez-vous lire les tutoriels Unity et les appliquer mot pour mot à C#-Godot ? Non.
   Alors, quel est cet "écosystème de développement indépendant" auquel vous faites référence ?

Comme l'a dit paper-pauper, il existe de nombreux moteurs et bibliothèques parmi lesquels choisir.
Voulez-vous un système de composants comme celui de Unity ? Regardez Atomic Game Engine.
Voulez-vous continuer à utiliser C# dans un moteur, mais souhaitez-vous abandonner le système de composants ? Regardez CryEngine / Luberyard.
Voulez-vous continuer à utiliser C # mais souhaitez-vous abandonner le moteur ? Regardez MonoGame.

L'idée que l'ajout de C # à Godot aidait les débutants est erronée, puisque vous avez dit vous-même que vous avez appris les scripts dans Godot en regardant des extraits de code. Si c'est ainsi que vous apprenez à travailler avec un moteur, ne voudriez-vous pas un langage qui vous indique implicitement comment le moteur fonctionne plutôt qu'un langage conçu pour des milliers de cas d'utilisation différents ?

Je vais juste ajouter mes 2 cents ici. Pour moi, le gros avantage de C# est la performance, tout en étant plus facile à utiliser que C++. GDScript, étant typé dynamiquement et tout, est très rapide à écrire, mais ne sera jamais ultra rapide à exécuter (bien qu'il puisse être beaucoup optimisé, ce qui est prévu). Les modules C++ sont très rapides, mais ils sont assez difficiles à utiliser ; C++ n'est pas exactement un langage convivial, et devoir recompiler le moteur pour les utiliser n'est pas vraiment optimal. Pour moi, C# est une sorte de compromis : beaucoup plus rapide que GDScript, et avec le support approprié, beaucoup plus facile à utiliser que les modules C++.

Tous les problèmes que vous avez mentionnés avec C++ que vous avez mentionnés sont valides et pourraient être résolus via # 3936. Nous en avons déjà discuté plusieurs fois, mais juste pour plus de clarté, voici les problèmes avec GDScript que nous pouvons objectivement reconnaître :

1. Mauvaise prise en charge des bibliothèques tierces
2. Mauvaise performance

Être capable d'écrire des parties en C++ corrige facilement les deux. C# (ou un autre langage) corrigerait également ceux-ci, mais avec un temps d'exécution supplémentaire, de moins bonnes performances et une prise en charge multiplateforme et beaucoup de travail supplémentaire nécessaire (alors que Godot est déjà écrit en C++). Le choix rationnel est donc d'utiliser ce qui existe déjà (C++) et de l'améliorer, et bien sûr de résoudre ces problèmes avec GDScript.

J'ai rapidement lu ce fil, et j'ai vu que GDScript vers C était envisagé.

Si c'est la manière choisie, ce serait une bonne chose d'envisager d'intégrer le compilateur C tcc dans l'éditeur pour compiler le C généré. Il a un temps de compilation très rapide, est très petit et facilement intégrable. Ce serait peut-être le meilleur moyen d'accélérer les choses.

TCC est distribué sous la licence publique générale limitée GNU.

(la source)

Cela le rend probablement impropre à l'inclusion dans Godot. Il semble également ne plus être entretenu.

@Warlaan Je n'ai pas trop à réfléchir. À ce stade, nous avons tous dit la même chose environ 10 fois déjà, je pense que nous savons à peu près où nous en sommes tous. À part mes 2 cents et quelques idées, je n'ai pas grand-chose d'autre à apporter puisque je ne suis pas un développeur et que je ne connais pas très bien le moteur. Je laisse parler ceux qui s'y connaissent mieux. Je voulais juste exprimer mon soutien et c'est tout.
Hors sujet:
Mais oui en ce qui concerne le point 2. sur lequel vous avez fait beaucoup de bruit, vous avez dû modifier votre commentaire. Donc, vous dites que vous ne pouvez pas apprendre une langue basée sur des exemples ? Je pense que vous SUPPOSEZ que les gens sont incapables de l'apprendre à moins qu'ils ne lisent des manuels de 500 pages dont C # est connu pour vous dire la raison 1 de le rejeter. Eh bien, je suis la preuve vivante que vous vous trompez. Comment pensez-vous que j'ai appris GDScript ? Avec les exemples d'API et de démos et en posant des questions. Remarquez que j'avais 0 connaissance de Python avant de commencer, donc tout était assez étranger. En passant, je me demande combien de personnes achètent des manuels libGDX par rapport à combien de personnes recherchent réellement sur Google "comment faire X dans libGDX", probablement pourquoi le magasin d'actifs est si dur à cuire dans Unity. Et avec ça j'en ai fini pour le moment parce que je n'ai plus rien à dire.

( @Calinou : Bellard a permis à un fork de TCC de devenir BSD ou MIT. Mais la dernière fois que j'ai vérifié, le développeur du fork n'avait pas publié le code source. Alors, peut-être que Bellard accepterait de laisser la communauté Godot relicencier TCC également ?)

Je ne suis pas sûr que TCC soit aussi bon que GCC ou Clang en tant que compilateur - leur taille permet de prendre en charge de nombreuses architectures et une génération de code assez optimisée (meilleures performances).

Qu'en est-il de Godot qui dépend éventuellement de GCC ou de Clang pour compiler C ? Ils sont installés sur les machines de la plupart des gens qui construiraient les jeux de toute façon (donc la taille n'est pas vraiment un problème), et c'est la façon dont les autres langages qui compilent en C (comme Chicken ) le font. Ils prennent également en charge C++, au cas où cela serait nécessaire.

S'ils deviennent des dépendances facultatives, ceux qui n'ont pas installé GCC ou Clang (ce qui est bizarre pour un développeur qui est censé créer un jeu pour la distribution, mais de toute façon) peuvent simplement utiliser l'interpréteur GDScript tel qu'il est actuellement.

J'ai suggéré d'utiliser TCC comme JIT pour GDScripts. La caractéristique la plus importante était donc la vitesse de compilation. Et je pense que les résultats pourraient déjà être beaucoup plus rapides que la solution actuelle.

La plupart des gens veulent C/C++ pour les performances et Lua/Javascript pour être plus facile et plus rapide à écrire, alors pourquoi ne pas avoir le meilleur des deux mondes ?

Nim - http://nim-lang.org/

Efficace comme C, expressif comme Python et flexible comme Lisp

Avantages:

• Compile en C, C++, Obj-C ou JS ( http://nim-lang.org/docs/backends.html )
• (Python / Pascal) comme ( https://learnxinyminutes.com/docs/nim/ )
• GC ou Manuel ( http://nim-lang.org/docs/gc.html )
• Peut être utilisé ailleurs que godot
• Multiplateforme (Windows, Linux, OSX, Mobile)
• Aide à convertir le code C en Nim
• Prend en charge les bibliothèques C
• Compilateur modifiable
• Licence MIT
• Open source
• Type-safe

Les inconvénients:

• Nécessite un compilateur C/C++ dans l'ordinateur du développeur -> gcc , vcc , llvm_gcc , icc , clang ou ucc _(pas vraiment un con, à mon avis)_
• Petite communauté
• Pas encore 1.0

La liste TODO de Nim est petite, elle est proche de 1.0 :
https://github.com/nim-lang/Nim/blob/devel/todo.txt

comme l'a dit paper-pauper (à propos d'avoir un compilateur dans l'ordinateur du développeur):

Ils sont installés sur les machines de la plupart des gens qui construiraient les jeux de toute façon
https://github.com/godotengine/godot/issues/5081#issuecomment -227706106

https://hookrace.net/blog/what-is-special-about-nim/
https://hookrace.net/blog/what-makes-nim-practical/

https://github.com/nim-lang/Nim/wiki/Nim-for-C-programmers
https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programmers

Ce n'est pas ma solution préférée, mais si vous devez emprunter cette voie, je vous suggère fortement d'utiliser Haxe ( haxe.org ) au lieu de Nim.

Je ne peux pas commenter la licence de Haxe (le compilateur lui-même utilise "GPLv2+", la bibliothèque standard utilise MIT), mais tous les autres facteurs en font un choix supérieur à mon humble avis.
C'est une plate-forme testée (actuellement en version 3.2.1) contrairement à Nim qui n'est même pas encore en version 1.0, mais ce qui pour moi est beaucoup plus important, la syntaxe est beaucoup plus proche d'autres langages bien connus. En lisant les exemples Nim, il me semble que les développeurs derrière ce langage ont essayé de trouver des solutions inhabituelles et/ou laides.

Mais comme je l'ai mentionné, ce n'est pas ma solution préférée et voici pourquoi :
Les langages intermédiaires comme Nim ou Haxe ont de nombreuses "dépendances sémantiques". Je ne parle pas de dépendances sur des bibliothèques ou des exécutables qui doivent être présents, je veux dire qu'ils se rapportent à d'autres langages. Maintenant, comme je l'ai dit plus tôt, les langues ne sont plus des outils, ce sont des cultures. Et même si vous ne les voyez que comme des outils, ils ont différents domaines de base pour lesquels ils ont été conçus. Par exemple, il est tout à fait logique que la commande "echo" imprime du texte sur la sortie standard lorsqu'elle est entrée sur l'entrée standard. L'utilisation de la même commande dans un script batch n'est qu'une conséquence. En suivant cette logique, il est compréhensible que PHP utilise la même commande. L'utiliser dans un langage à usage général comme Nim n'a aucun sens, car fondamentalement, tous les autres langages à usage général ont des méthodes appelées quelque chose avec "écrire" ou "imprimer" dans le nom.
Je n'ai aucune idée de pourquoi Nim utiliserait encore "echo" comme nom pour cette commande, mais c'est le genre de chose que vous pouvez observer beaucoup avec Haxe et que j'attendrais de Nim à l'avenir sinon déjà dans la première version . Par exemple, la bibliothèque standard de Haxe contient à la fois une méthode substr(int, int) et une méthode substring(int, int). L'un des deux renvoie la sous-chaîne du premier au deuxième index, l'autre renvoie la sous-chaîne du premier index avec la longueur du deuxième argument. La raison pour laquelle les deux existent est que, comme le langage peut être utilisé pour remplacer des langages de différents types, il a des utilisateurs qui viennent de différentes plates-formes, et à moins qu'il y ait quelqu'un avec une main très forte pour décider ce qui va dans cette bibliothèque open source et ce qui ne le fait pas vous vous retrouverez facilement avec un tel mélange de styles de codage.

Il est très important de choisir les bons outils pour le bon travail. Des langages comme Haxe (ou C# d'ailleurs) essaient de vous donner un langage qui convient à tous, donc le plus souvent vous finissez par utiliser "un seul outil" qui ressemble malheureusement à ceci .

J'aimerais ajouter mes 2 cents après avoir travaillé avec Godot pendant un certain temps.
Ce que j'aimerais voir (et que j'ai également examiné, avec... un succès limité), c'est le C++ comme langage de première classe dans Godot.
Écriture de la logique lourde de calcul (résolution de collisions, physique, transformations et IA) en C++ et script des nœuds à l'aide de GDScript (déclencheurs, conditions, animations et sons).

GDScript EST assez facile à apprendre, plaçant Godot un peu plus près de Gamemaker que d'Unity à cet égard.
Mais après avoir écrit 3 petits jeux et joué avec un tas de démos, je dois dire que GDScript manque pour autre chose que des jeux très basiques.

Les fichiers de code deviennent trop longs et l'éditeur de code manque de nombreuses fonctionnalités utiles que l'on trouve dans d'autres IDE, telles que : réduire les portées, les régions, sauter au début/à la fin de la portée actuelle.

GDScript manque également de nombreuses fonctionnalités de base des langages procéduraux telles que : boucles _ for _ appropriées, boucles _ do...while _ appropriées (il prend en charge les boucles _ while _), _ switch...case _, _ opérateur ternaire _ , _ énumérations _.
_ Il n'y a pas de conscience de la relation classe-scène _ donc si ce n'est pas préconstruit, c'est une classe "externe" et doit être préchargée.

De plus, étant donné la nature de GDScript, il n'y a pas de références de fonctions ni de modèles.
Ce n'est rien de spectaculaire, mais c'est très ennuyeux.

Eye776 ; GDscript n'est inutilisable que pour des jeux plus que simples si vous décidez d'ignorer les autres fonctionnalités (telles que l'utilisation de nœuds et de rappels si possible) au lieu de vous en tenir exclusivement à des fonctions telles que _get_overlapping_bodies()_

La raison en est que lesdits rappels et l'utilisation des nœuds sont beaucoup plus rapides que d'essayer de tout faire avec un gros script et très peu de nœuds. L'arbre s'agrandit, mais ce n'est pas un problème avec le système d'instanciation de scène de Godot.

Par exemple, les objets qui ont besoin d'un taux de rotation constant peuvent simplement utiliser une animation pour cela au lieu de définir la rotation manuellement à l'aide de GDscript, les éléments qui reposent sur la synchronisation peuvent utiliser des nœuds de minuterie, etc. Je pense qu'un moyen immédiat (et simple) de permettre des jeux plus rapides serait de choisir parmi plus de types de nœuds (chacun avec ses propres rappels et connexions).

Les fichiers de code deviennent trop longs

Vous voulez dire des scripts comme celui-ci ? https://github.com/Algorithmus/CastlevaniaClone/blob/master/game/players/player.gd
Pensez-vous que C# peut empêcher que cela se produise ? Personnellement, je ne le fais pas. En fait, il est plus facile de refactoriser et de détecter les erreurs plus tôt dans ces longs scripts en raison de l' outillage (oui, quand les gens veulent dire C #, ils signifient souvent VS implicitement) et du typage statique, bien que les erreurs de chemin de nœud soient indétectables jusqu'à ce que le jeu s'exécute. Mais à part cela, une bonne conception et une bonne utilisation des nœuds peuvent grandement simplifier les scripts.

l'éditeur de code manque de nombreuses fonctionnalités utiles que l'on trouve dans d'autres IDE telles que : réduire les portées, les régions, sauter au début/à la fin de la portée actuelle.

Ceux-ci peuvent être ajoutés à l'avenir si vous le demandez, bien que vous puissiez utiliser un éditeur externe sans problème (https://atom.io/packages/lang-gdscript), Godot a même des services d'auto-complétion.

Si vous créez un jeu ÉNORME, il est probable que vous souhaitiez étendre Godot en utilisant C++.
En fait, je trouve cela un peu intimidant actuellement à cause du processus de reconstruction du moteur, mais il y a des raisons à cela .

Il n'y a pas de conscience de la relation classe-scène

Que veux-tu dire? Vous savez que vous pouvez mettre un script à la racine d'une scène, n'est-ce pas ? De plus, les éditeurs C # ne peuvent pas deviner ce qu'il y a dans la scène où ils sont utilisés, contrairement à GDScript.

De plus, étant donné la nature de GDScript, il n'y a pas de références de fonctions ni de modèles.

Il y a funcref et signal si vous recherchez quelque chose de similaire aux lambdas et aux événements, et les modèles ne sont pas une chose car le langage est dynamique. Les langages dynamiques préfèrent souvent utiliser le typage canard au lieu des interfaces et des génériques. De plus, la composition plutôt que l'héritage joue très bien si vous voulez des choses réutilisables.

GDScript manque également de nombreuses fonctionnalités de base des langages procéduraux

Je suis un peu d'accord. Certaines ont été demandées mais je ne me souviens plus des enjeux, il faudra chercher. Par exemple, j'aimerais voir un for qui peut itérer sur autre chose que des plages d'entiers et des conteneurs (flottant ?), donc j'utilise while . C'est effectivement un peu gênant mais rien de bien grave.

Vous voulez dire des scripts comme celui-ci ? https://github.com/Algorithmus/CastlevaniaClone/blob/master/game/players/player.gd

Je dois dire que même si le fichier est long, j'ai vu bien pire et ça reste assez lisible malgré que le code soit assez procédural. Maintenant, je comprends enfin pourquoi une syntaxe simple est meilleure pour GDScript : c'est la meilleure pour la logique de jeu moyenne, qui est principalement composée if et d'appels de fonction.

J'aimerais voir quelqu'un affirmer que le même fichier écrit en C # est plus facile à lire ou à écrire, ou offre des avantages pratiques autres que les performances (ce qui est de toute façon pire que C++). Je pense que C # serait une exagération pour ce type de script, qui est plus compliqué que le script qui va dans certains jeux 2D professionnels.

Je suis un peu d'accord. Certaines ont été demandées mais je ne me souviens plus des enjeux, il faudra chercher. Par exemple, j'aimerais voir un for qui peut itérer sur autre chose que des plages d'entiers et des conteneurs (flottant ?), donc j'utilise while. C'est effectivement un peu gênant mais rien de bien grave.

Pourriez-vous approfondir un peu la partie for et quelques exemples de ce à quoi vous faites référence dans le pseudo-GDScript ?

@paper-pauper les choses qui manquent à GDScript ne sont pas liées à C#, mais par exemple for i in range(-PI, PI) ne fonctionne pas dans GDScript, ainsi que for i=0, i < size and stuff, ++i . J'aimerais aussi écrire en ternaire au lieu d'avoir à écrire un si de trois lignes. Mais comme je l'ai dit, il y a déjà des problèmes dans le tracker et cela ne va pas m'empêcher d'utiliser GDScript :p

Mais même si tous vos scripts font 200 lignes maximum et sont relativement bien conçus, si vous en avez des milliers dans votre jeu, vous aurez du mal à maintenir et refactoriser cette base de code : et ce n'est pas tant à cause du langage, mais à cause des outils : Une grande partie de la popularité de C# est due au fait que Visual Studio est un sacré bon IDE pour cela. Je suis à peu près sûr que si Godot intègre des outils adaptés (définition goto, renommage fiable de classe/fonction/membre, recherche de toutes les références, etc.), le travail sur d'énormes bases de code GDScript sera beaucoup plus facile. Plus généralement, c'est ce que j'aimerais voir dans Godot, comment peut-il bien s'adapter aux jeux BIG, car jusqu'à présent je n'en ai pas vu (y compris mes propres projets).

for i in range(-PI, PI)

Cela fait tourner ma tête sur son axe jusqu'à ce qu'elle atteigne une division par zéro et commence à détruire l'entropie. J'espère qu'aucun langage n'implémente une déclaration aussi imprévisible. Qu'est ce que ça fait? Itère sur des nombres entiers entre -PI et PI (c'est-à-dire -3, -2, ..., 2, 3), ou entre des multiples de PI (c'est-à-dire -PI et 0), ou itère-t-il sur des flotteurs avec une étape par défaut vaudou comme 0.176 ou ln(2) qu'un programmeur de langage a trouvé le plus approprié ?

@akien-mga oups désolé. J'aurais dû ajouter un argument d'étape en effet xD mais cela ne fonctionne toujours pas. Voici le problème que j'ai créé pour cela https://github.com/godotengine/godot/issues/4164

Je suis d'accord que ce qui manque à Godot, c'est l'outillage. Le problème majeur est la nature canard de GDScript, ce qui rend plus difficile de savoir ce qui est quoi et rend donc difficile certaines actions comme "trouver des références" ou "aller à la définition".

Il est prévu d'ajouter des indications de type à GDScript, mais comme cela sera facultatif, je ne suis pas sûr de ce qui peut être amélioré. Cela fera certainement beaucoup pour l'achèvement du code et peut faciliter le travail sur de meilleurs outils.

@vnen Un mode EMACS pour GDScript dans (M)ELPA serait déjà un pas dans la bonne direction, dans mon livre :)

Oh oui, j'ai presque oublié ces deux problèmes qui, assez drôles, m'ont en fait ralenti dans la pratique :

• Les arguments ne font pas partie de la signature d'une fonction. Cela signifie que vous ne pouvez pas remplacer les fonctions.
  En pratique, avoir un function doFoo(a,b,c,d) et function doFoo(a,b) dans la même classe entraînera un échec de la compilation. J'ai fini par les renommer en doFoo4(a,b,c,d) et doFoo2(a,b) et refactoriser un tas de fichiers de script.
• Puisqu'il n'y a pas de support pour les énumérations, tous les drapeaux et codes de retour sont, par nécessité, des entiers, vous devez donc les deviner et beaucoup ne sont toujours pas documentés en ce moment.

PS : Évidemment, les fonctions n'étaient pas littéralement nommées doFoo . ;)

EDIT : @Ace-Dragon : d'autres moteurs m'ont appris que des nœuds/composants intégrés complexes/etc. peut et va changer, brisant le jeu dans le processus. C'est pourquoi, à part les rappels de déclencheurs de base (collisions, valeurs, minuteries), je préfère éviter de trop m'appuyer sur eux.
Je ne suis pas non plus un très grand fan du paradigme signal-slot, donc j'ai tendance à l'éviter si possible. Là encore, je préfère aussi les threads aux coroutines, appelez-moi un luddite :)

@Zylann : ~1200 LOC ?... pffft Non, je parle de la vraie affaire... 20k+ LOC par fichier. Un développeur RPG qui utilise Unity, qui ne doit pas être nommé (non, je ne travaille pas pour eux), a régulièrement des classes avec 25k+ loc. Là encore, ils rendent toutes leurs fonctions statiques et utilisent C # comme s'il s'agissait de C. :fearful:

Désolé pour le hors sujet.

@ eye776 Je ne vois aucun langage dynamique qui permette le remplacement (il peut être truqué avec des arguments par défaut dans certains cas), mais ce serait une bonne idée de l'avoir dans GDScript.

Et les changements révolutionnaires apportés au moteur peuvent être facilement détectés et annulés dans un programme libre comme Godot, ils ne devraient donc pas être un souci.

@ eye776 Je n'ai jamais vu non plus de langages dynamiques avec remplacement de fonction. GDScript a des paramètres par défaut, qui peuvent donc être utilisés à la place.

Aussi, qui est le fou qui fait 20K+ LOC en un seul fichier ? Le problème ici ne réside pas dans l'outil... Dans toute la source de Godot, il n'y a pas un seul fichier que j'ai pu trouver avec 10K LOC.

Ce que je suis d'accord, c'est donner un peu plus d'amour à C++. Mais pour les utilisations que vous avez citées plus tôt, je ne suis d'accord qu'avec l'IA. Et aussi la génération procédurale, pour n'en citer qu'une. Maintenant, si vous refaites la physique du moteur, le rendu, etc., je dis que vous n'utilisez même plus Godot, vous venez de faire un fork. Si vous ne pouvez pas compter sur les types intégrés, pourquoi avez-vous besoin du moteur ?

Bien sûr, GDScript n'est pas parfait (aucun langage ne l'est). Il n'est pas non plus gravé dans la pierre. Les énumérations, les opérations switch/case et ternaires sont des ajouts probables à l'avenir (il y a déjà des problèmes ouverts à ce sujet). Ce n'est pas parce qu'il n'a rien en ce moment qu'il n'en aura jamais.

Enfin, les "doutes" n'aident pas vraiment. Ce dont nous avons besoin, ce sont des références et des cas d'utilisation. Il existe déjà des jeux assez complexes écrits en GDScript, donc je ne vois pas ce qui manque vraiment.

@vnen juste pour le plaisir : godot/drivers/gles2/rasterizer_gles2.cpp est 11K LOC :p (c'est le plus grand que j'ai trouvé, mais c'est une rare exception).

@vnen

Si vous ne pouvez pas compter sur les types intégrés, pourquoi avez-vous besoin du moteur ?
Eh bien, comme un contexte multiplateforme de qualité pour les débutants. Mais cela ne veut pas dire que j'écrirai mes propres classes de sprites ou de modèles.

Godot m'a brûlé une fois en mars (v 2.0.1). J'étais en train de jouer avec une caméra et un personnage à la troisième personne et j'ai essayé d'utiliser la propre physique de Godot pour le mouvement (traînée et forces) et je l'ai fait fonctionner.
La prochaine mise à jour de la version mineure (v 2.0.2) a essentiellement cassé la vitesse du personnage (2 à 3 fois plus rapide) pour exactement les mêmes valeurs.
J'ai compris qu'il valait mieux le garder cinématique et faire ma propre "physique".

De plus, sans rapport avec Godot, je me suis brûlé plusieurs fois en m'appuyant sur des trucs automatisés comme les storyboards de XCode.
J'ai en quelque sorte cessé d'être courtisé par le brillant et je prie pour que le code généré automatiquement par l'IDE derrière mon dos ne dérange pas le mien.

Quoi qu'il en soit, je suis vraiment, vraiment désolé d'avoir fait dérailler le fil.

@ eye776 Avez-vous vérifié le diff de validation de 2.0.1 à 2.0.2 pour voir ce qui a cassé votre jeu ? Cela aurait pu être un bogue et le signaler pourrait profiter à toute la communauté.

Mono ou CoreCLR ? Et pourquoi?

Mono:

• Licence MIT
• stable
• possibilité d'être abandonné
• bonne documentation

CoreCLR :

• Licence MIT
• toujours pas 1.0 (actuellement c'est RC2)
• petit
• mauvaise documentation

Nous utilisons Mono car il se déploie sur mobile et sur le Web. je pense que voici
aucune chance qu'il soit abandonné car il est beaucoup plus portable. Mon intuition
est que les deux bases de code finiront par fusionner.

Le jeudi 4 août 2016 à 13h45, Hubert Jarosz [email protected]
a écrit:

Mono ou CoreCLR ? Et pourquoi?

Mono:

• Licence MIT
• stable
• possibilité d'être abandonné
• bonne documentation

CoreCLR :

• Licence MIT
• toujours pas 1.0 (actuellement c'est RC2)
• petit
• mauvaise documentation

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/godotengine/godot/issues/5081#issuecomment -237611905,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AF-Z2zRjC8u_owFzCCyeqIhF8W5XqCtLks5qchchgaJpZM4Ivn7R
.

En plus de ce que @reduz a mentionné ci-dessus, l'API est encapsulée, il n'est donc pas trop difficile de passer à CoreCLR plus tard si nécessaire.

CoreCLR : toujours pas 1.0 (actuellement c'est RC2)

Il a atteint 1,0 stable le 14 juin.

Mono : possibilité d'être abandonné

Basé sur quoi ?

Mono : bonne documentation

ahahah

Basé sur quoi ?

Pourquoi Microsoft développerait trois piles de .NET ? Ce n'est pas bon du point de vue des ressources. (.NET Framework, Mono, .NET Core)

ahahah

J'ai vérifié les deux documents sur l'interopérabilité C++/C# (ce dont nous avons besoin pour godot) et c'est assez bien documenté dans Mono. Dans coreCLR, j'ai dû creuser une partie de leur code et demander de l'aide aux développeurs pour que mon application fonctionne.

Le guide de référence a trop de fonctions non documentées, liens brisés...

En théorie, je suis partial ici... Mais j'espère que mes arguments sont objectifs...

• Je ne vois aucun déclin dans le développement Mono : https://github.com/mono/mono/graphs/contributors
• Le développement pour Mono sur Windows n'a jamais été aussi fort qu'aujourd'hui (un peu la preuve (sans lier des tonnes de commits) https://github.com/mono/mono/pull/3231 Miguel disant "puisque nous avons maintenant de vrais mainteneurs") point précédent encore plus clair
• L'intégration de l'API dans Mono est testée au combat (pas seulement Unity, il existe de nombreux autres utilisateurs privés)
• Mono AUJOURD'HUI fonctionne sur PS4, Android, Windows, iOS BITCODE (des années de travail ont été consacrées à cela), AppleTV et bien d'autres plateformes...

Donc, à mon humble avis, si vous voulez livrer cela dans un avenir proche (moins de 3 ans) et sur la plupart des plates-formes de jeu... Optez pour Mono.

Bonjour,

Certains commentaires:

• En plus des plates-formes répertoriées par David Karlas, nous ajoutons également la prise en charge native de WebAssembly, XboxOne, UWP et Win64.
• L'échantillon qui est partagé peut également être fait avec des méthodes virtuelles (envoi plus rapide) ou peut être fait avec des événements C#.
• C # a toujours été à l'avant-garde de nombreuses innovations linguistiques, tirant de bonnes idées de n'importe où. Il a popularisé et apporté au marché de masse de nombreuses idées issues de la recherche linguistique et que nous tenons maintenant pour acquises, des choses comme les itérateurs, les génériques non effacés, les lambdas, la programmation asynchrone, les propriétés, l'invocation de plate-forme, mais c'est l'un des langages qui sont le plus activement développé en public . Par exemple, la prochaine version ajoute une multitude de nouvelles fonctionnalités, y compris ma correspondance de motifs préférée.
• En général, Unity ne présente pas le C # moderne car il utilise un runtime plus ancien. J'espère que cela changera bientôt. Cela dit, Mono actuel prend en charge toutes les nouvelles fonctionnalités C #, parmi celles de la programmation "asynchrone" qui est idéale pour le code de jeu, car vous pouvez l'écrire de manière linéaire, et le compilateur réécrit automatiquement votre code en tant que machine d'état - comme les coroutines ou les avancées version de "rendement" telle qu'utilisée dans Unity.
• Les contextes de synchronisation signifient que vous pouvez écrire du code asynchrone qui s'exécute dans un contexte spécifique. Par exemple, vous pouvez avoir une exécution liée au jeu, ou une exécution liée aux E/S, ou une exécution liée au thread principal ou à l'arrière-plan, tout cela fait partie du système.
• Lors du déploiement, vous avez le choix entre la compilation JIT ou la compilation statique (AOT) avec ou sans LLVM, de sorte que vous obtenez à peu près aussi vite que C++, modulo le fait que C# vérifie les limites des tableaux (cela dit, si vous utilisez natif tampons, vous récupérez vos performances, au détriment de la sécurité)
• Au cours des dernières années, compte tenu de l'accent mis par Mono sur le mobile, le GC de Mono a été réglé non pas pour les serveurs, mais pour les charges de travail interactives. Notre nouveau GC est générationnel avec de petites pépinières qui peuvent être collectées très rapidement et ne nécessitent pas de scanner tout le tas.

Quant à la raison pour laquelle Microsoft développe plusieurs CLR (nous en avons trois : CoreCLR pour les charges de travail JIT ; la famille CoreRT, pour la compilation statique dans UWP ; Mono pour les charges de travail mobiles), c'est parce qu'ils ont tous des objectifs légèrement différents. Les composants internes convergent dans la mesure du possible, par exemple, Mono a désormais remplacé environ 60 % du code principal par du code partagé directement avec le reste de .NET. Il s'agit simplement de savoir quelle charge de travail vous convient le mieux.

Vous pouvez commencer avec une machine virtuelle aujourd'hui et passer à une autre à l'avenir. Actuellement, Mono a une plus grande surface d'API, fonctionne sur mobile, a été optimisé pour les charges de travail interactives et prend en charge plus d'architectures (comme ARM64).

La bonne nouvelle est que l'échange d'une machine virtuelle contre une autre, ou la prise en charge des deux, nécessite quelques jours de travail, vous ne vous enfermez donc pas dans une implémentation spécifique.

@migueldeicaza Bienvenue ! Génial que vous ayez décidé de participer à notre discussion et que vous vous intéressiez à Godot :+1: J'espère que vous resterez avec nous pendant un certain temps :)

Merci pour la belle répartition @migueldeicaza! J'ai deux questions rapides pour vous ou d'autres développeurs Mono.

1) Quelle est la configuration actuelle pour le débogage de Mono intégré sous Windows avec Visual Studio ? Unity a son plugin, mais je n'ai rien trouvé d'autre que des plugins qui se connectent aux machines Linux/OSX.

2) Quelle est la méthode recommandée pour gérer la recompilation à l'exécution (compilation, déchargement et rechargement, par exemple, d'un assemblage pour les plugins de gameplay ou d'outils dans l'éditeur) ? C# (très) malheureusement n'expose pas une méthode Assembly.Unload() et le traitement des AppDomains et des problèmes croisés AppDomain semble être trop ennuyeux pour cette situation.

Pour référence, non seulement Unity utilise Mono - https://github.com/xamarin/urho (liaisons C#/Mono pour le moteur Urho3D) - celui-ci est sous licence MIT, nous pouvons donc facilement rechercher leur solution.

Mes deux centimes:

C # est de loin supérieur pour la programmation de jeux que d'autres langages de niveau similaire dans la mesure où il prend en charge les types de valeur personnalisés. Il s'agit d'une fonctionnalité extrêmement importante pour les performances, que Java (et JVM en général) n'a littéralement _aucune_ alternative.

Vous obtenez:

• Types mathématiques alloués par la pile, qui prennent en charge les opérations mathématiques et les objets temporaires sans aucune allocation de tas.
• Collections continues optimisées et compatibles avec le cache.
• Génériques utilisant des types valeur (y compris les types primitifs)

En plus de cela, C # a d'autres fonctionnalités qui vous facilitent la vie. Je ne vois aucun mérite à utiliser Java à la place de C # alors que C # bat simplement Java dans à peu près tout ce qui compte dans la programmation _game_.

Salut tout le monde,
je n'ai pas lu tout ce qui précède (simplement trop :) )
mais j'ai eu quelques vacances alors j'ai créé un module prototype pour godot qui agit comme msDotNetHost, donc je peux fournir quelques résultats que j'ai parcourus, peut-être qu'ils sont utiles. Malheureusement, mes vacances se sont terminées et je dois encore coder pour de l'argent :), mais c'est/c'était amusant :)

l'état actuel est :
o) le module étend la classe de nœud pour exposer les événements de nœud à netCode
(init, tree_entered, ready, process, fixedprocess....)),
o) "net host/wrapper module" terminé (à l'aide du mécanisme d'hôte Microsoft dotNet)
il est encapsulé dans une bibliothèque dynamique, donc un passage à Mono devrait être facile plus tard
o) les méthodes dotNet sont liées et appelées (init, tree_entered, ready, process, fixedprocess....)
o) la classe de nœud est enveloppée et liée à netAssembly (code écrit manuellement pour le prototypage)
o) les appels à godot (depuis netCode) fonctionnent via un mécanisme de liaison auto-écrit
(de dll dans godot-exe ) afin que l'exe n'ait pas besoin d'exporter des fonctions.
o) en raison de l'utilisation de msDotNet, il est lié à Windows dans un avenir proche.

ma feuille de route pour inclure .Net serait :

1. module pour Godot utilisant le mécanisme d'hébergement Microsoft .Net (fait)
2. wrappin godotClasses
   (mon état actuel : écrire un générateur de wrapper, qui analyse le code godot c++,
   l'analyse est terminée, la génération est en cours)
3. sortir le projet de l'état de prototype (compléter les bords, le tester...)
4. écrire le mécanisme d'hébergement Mono, pour se débarrasser des liens Windows
5. permettre en quelque sorte à Visual Studio de déboguer mono, de se débarrasser de xamarin/monodev (comme unity vs-plugin)
6. amusez-vous avec des centaines de nouveaux développeurs godot .net :)

quelques questions:

1. Je me demande si je pourrais réutiliser le mécanisme de liaison utilisé pour gdscript. mais je n'ai pas le temps de tout évaluer, y a-t-il un bon tut ou des conseils de haut niveau pour moi ?

2.
actuellement, je génère un wrapper qui encapsule toutes les méthodes godot dans des fonctions afin qu'elles puissent être appelées facilement via dll-boundary et c++/netCode. (mécanisme de liaison auto-écrit pour netCode)
je ne veux pas changer le code godot (sauf mon code de module) pour rester compatible.
aussi statique, non statique, virtuel non virtuel m'a fait pleurer, c'est pourquoi j'ai choisi cette voie.
une meilleure solution à cela?

quelques réflexions supplémentaires :

Microsoft .Net contre Mono :

Je pense que cela n'a pas d'importance si vous utilisez mono ou msDotNet, car dans la plupart des cas, le code dotNet fonctionne sans changement sur les deux. Le seul effort pour prendre en charge les deux consiste à écrire un "hôte" pour chacun d'entre eux (c'est la plus petite partie d'un "GodotDotNet"). J'ai choisi msDotNet pour le prototypage.
eh bien, mono prend en charge de nombreuses plates-formes msDotNet uniquement Windows, alors pourquoi prendre en charge/utiliser msDotNet ?
La réponse : productivité, débogage

MSDotNet :
Surtout lors de l'écriture/prototypage du DotNetModule, j'ai besoin/veux d'une compilation et d'un débogage FAST, cela signifie que votre débogueur doit sauter dans netCode à partir de c++ et vice versa.
Je choisis VisualStudio, car il peut déboguer les deux. MAIS seulement si vous utilisez msDotNet.
Ce faisant, vous modifiez un morceau de netCode, appuyez sur Exécuter et en 1 seconde ! c'est compilé et en cours d'exécution !!! y compris la possibilité de déboguer dans godot. (si vous n'avez pas changé quelque chose dans godot, alors vous devez attendre généralement 30sek à 1min... damn u slow scons ! :) )

Mono:
Mono doit être la cible finale, il n'y a pas de discussion à ce sujet (indépendance de la plate-forme), mais :
si on utilise mono, vous avez un gros problème de débogage : mono a son propre mécanisme de débogage !
pour moi, c'est un grand succès pour la productivité, car à moins que vous n'écriviez un plugin monodebug pour visualstudio (unity l'a fait), vous ne pouvez pas déboguer le netcode mono hébergé dans visual studio et déboguer en code c++ (il existe des solutions de piratage mais ...).
J'ai essayé de mettre en place une solution basée sur Mono, mais j'ai fini par utiliser les deux en parallèle, VisualStudio (pour c++) et xamarin/monodev (netcode).

Conclusion:
état du prototype : msDotNet
lateron : mono, pour les utilisateurs non intéressés par le débogage dans godot/c++ et l'indépendance de la plate-forme
après cela : créer un vs-plugin pour déboguer mono

c# contre java :
la réponse est claire c# ! java est pour les scritpkids ! (oh qu'est-ce que le codeur c++ pense des développeurs c# :) )
non c'était une blague :)
Je ne comprends pas la discussion ... lorsque le système .net est mis en œuvre, vous pouvez utiliser toutes les langues prenant en charge dotNet, y compris les deux langues et plus encore.
ce n'est pas le cas si le système java est supporté...

@Ziflin :
question 1:
a fait cette recherche aussi ... seul monoRemotedebugger est la (pas) solution atm :(
ma recommandation est, comme indiqué ci-dessus : utilisez l'hébergement Microsoft dotNet pour le prototypage
puis plus tard, passez en mono.
alternative:
démarrez xamarin dans son mode piraté, laissez-le écouter localhost, définissez les points d'arrêt, puis démarrez votre projet en vs. ive l'a testé, cela fonctionne, mais ...
pour moi ce n'est pas une solution ! je veux un "hit run and debug in 1 second"- mécanisme et ceci en 1 clic !
Je n'ai pas beaucoup de temps libre, donc la productivité est mon objectif principal.

question 2:
Je ne connais pas encore très bien mono, mais je pense que vous devez le faire en c++, implémenter l'hébergement mono, le gérer de "l'extérieur" en c++.

@CharlesWoodhill Les liaisons C # officielles sont déjà WIP et peuvent être vues ici https://github.com/neikeq/GodotSharp/

cool tnx, alors je sais comment je passe certaines de mes prochaines vacances ;)

Salut, je viens de tomber sur godotSharp mais c'est abandonné.

c'est tombé.

La version officielle que j'ai entendue sur IRC était quelque chose comme :

@neikeq n'aime pas pousser du code inachevé, il travaille donc sur sa branche locale

Bon à savoir, j'étais sur le point de faire mon propre module mais j'imagine que je pourrais aussi bien pour Godot 2.2 ou 3.0

Il n'y aura pas de version 2.2, les développeurs de Godot ont déplacé toutes les fonctionnalités de la 2.2 vers la 3.0.

C'est la première fois que je commente. Je viens d'Unity et le passage à GDscript a été un rêve. J'ai appris la langue en moins d'une journée. J'aime la façon dont le langage est implémenté dans le moteur et ma productivité a considérablement augmenté.

Ma principale préoccupation est qu'avec l'ajout de la prise en charge de C #, GDscript sera laissé pour compte ou verra moins de développement après un flot de développeurs Unity. C# est un bon langage mais pas mon préféré

Aussi, je suis inquiet de voir Godot essayer d'être plus comme un autre moteur au lieu de se tenir seul. Unity est une réussite fabuleuse, mais ce n'est pas le meilleur moteur que j'aie jamais utilisé. C'est gonflé et bogué. Une fois, il a supprimé tout mon projet sans confirmation. Traiter les bogues et les choses qui ne fonctionnaient pas comme elles le devraient était une lutte constante. Je ne peux pas compter le nombre de fois où j'ai dû reconstruire complètement une scène sur laquelle je travaillais parce que les choses ne fonctionnaient pas correctement. Une fois, j'ai copié et collé tout le contenu d'une ancienne scène de buggy dans une nouvelle scène pour qu'elle fonctionne soudainement bien que les deux scènes soient identiques. J'ai perdu des semaines à chasser des bugs physiques qui apparaissaient et disparaissaient comme par magie.

J'aime vraiment que Godot soit léger et simple à comprendre. Travailler avec Godot a été comme utiliser un instrument de musique bien accordé. Après presque un an de travail, je sais juste comment faire tout ce que j'ai besoin de faire, même si je ne l'ai jamais fait auparavant. J'espère juste que l'afflux d'utilisateurs d'Unity n'orientera pas davantage la direction du moteur vers Unity. Si je voulais Unity, j'utiliserais Unity.

@zaywolfe Votre préoccupation a été exprimée à plusieurs reprises par d'autres utilisateurs. Vous n'avez rien à craindre. GDScript restera le langage principal de Godot.

Je n'aime pas GDScript . Je comprends que cela a été calqué sur Python, mais je me sens très chétif. C++ ou Java inclus (prêt à l'emploi) serait une excellente idée à mon avis. Personnellement, je me sens dégoûté d'utiliser GDScript dans le développement, au point de me demander s'il faut quitter Godot et revenir quand un nouveau langage (ou un langage alternatif) a été implémenté. Désolé, mais si vous voulez les faits concrets d'un programmeur, vous les avez.

Aussi, j'aimerais mentionner que parfois j'utilise même Godot pour du prototypage logiciel simple. Ainsi, un langage de programmation profondément intégré ouvrirait peut-être des portes au développement de logiciels au sein du moteur. Ce serait vraiment un tueur d'unité. (Si, bien sûr, Java ou C++ a été choisi)

Merci aux développeurs fidèles pour votre travail acharné, je vous admire tous et j'attends avec impatience les futures versions mises à jour !

@VenHayz Je ne sais pas si vous avez lu la documentation de Godot, mais vous pouvez déjà écrire vos jeux en C++, depuis la première version de Godot - http://docs.godotengine.org/en/stable/reference/custom_modules_in_c++.html

qu'en est-il de l'utilisation du noyau microsoft .net ? il est multiplateforme et axé sur les performances, il est également open source et se développe activement

Bonjour juste un gars au hasard qui passe

Je voulais vous faire savoir que je n'utilise pas Godot car je n'aime pas le langage de script que vous utilisez

Si vous ajoutez Java ou C #, j'installerai et utiliserai godot juste après votre annonce :)

@RUSshy au revoir alors, c'est votre perte, godot est génial, GDScript est génial, si vous êtes un vrai programmeur, il vous faudra littéralement deux heures pour en savoir plus qu'assez pour démarrer n'importe quel projet. Les vrais programmeurs doivent maîtriser de nombreux langages, vous pouvez vous en tenir à votre java/C# et être un gars "au hasard" qui passe comme amateur pour toujours. Je n'essaie pas d'être grossier, j'énonce juste des faits. Si vous n'aimez pas quelque chose à propos de ce moteur, alors contribuez avec du code, il est gratuit contrairement à la plupart des autres moteurs.

Dieu du marketing favorise C#. :en riant:

@RebelliousX Choisir Java ou C # signifie que vous aurez en main une CHARGE de bibliothèque à utiliser

Se limiter à un langage de script fait maison est tout simplement inutile, vos nouvelles connaissances ne seront pas applicables ailleurs, et vous ne pourrez pas trouver une tonne de bibliothèques, ou ne pourrez pas réutiliser vos connaissances ou les ressources d'apprentissage existantes

Le choix est fou de nos jours, ne soyez pas fermé d'esprit

@RUSshy Tu te moques de moi ? J'ai (et plusieurs autres) écrit littéralement des pages d'explications sur les avantages de GDscript par rapport à C# et vous pensez pouvoir résoudre la discussion avec un court paragraphe sans lire tout ce qui a été dit auparavant ?

"Ne soyez pas fermé d'esprit" - bonne idée, que diriez-vous de commencer par être ouvert d'esprit à propos de GDscript ?
"vos nouvelles connaissances ne seront pas applicables ailleurs" - c'est tout simplement faux. Vous ne pourrez pas compenser un manque de connaissances en copiant-collant du code que vous n'avez pas compris.
"vous ne pourrez pas trouver des tonnes de bibliothèques" - apprenez la différence entre un langage de script et un langage backend. Ou - idée folle - lisez ce que j'ai écrit à ce sujet.

Sérieusement, l'audace de certaines personnes...

Il a été dit à plusieurs reprises à divers endroits qu'un module d'intégration C # est en préparation. Cela va aussi vite que le temps dont disposent les gens pour le faire. La seule façon de le rendre plus rapide est de contribuer à cette intégration :)

@Warlaan à propos du deuxième point : si vous avez déjà écrit beaucoup de code en C#, vous ne pouvez pas le réutiliser à moins de le porter en entier. Vous n'avez pas non plus besoin de comprendre le code d'une bibliothèque pour pouvoir l'utiliser. Le fait est que si vous avez besoin de quelque chose qui était en C # auparavant (un seul fichier ou un ensemble de bibliothèques, source potentiellement fermée), vous devez soit tout porter, intégrer un runtime C # ou trouver une implémentation C. Ce n'est pas impossible, mais cela prend du temps.
Cela ne veut pas dire que Godot ne peut pas utiliser des tas de bibliothèques existantes... C/C++ en a aussi des tonnes.

Cela risque de devenir une guerre incendiaire.
Le journal est si long que les gens répètent les mêmes questions ou le même sujet au lieu de le lire.
Il ne reste pas beaucoup de choses techniques à discuter non plus.

L'avenir de Godot en termes de scénarisation est déjà assez clair :

• GDScript restera le langage principal et il existe des plans ou des idées pour l'optimiser (mais ce n'est pas le bon endroit pour en discuter).
• À partir de la version 3.0, C# sera pris en charge comme alternative de script. Nous fournirons des binaires séparés pour éviter de forcer la taille supplémentaire causée par le runtime mono sur les personnes qui ne l'utiliseront pas.
• DLScript est également sur le travail. Cela permettra aux gens d'utiliser des bibliothèques partagées pour les scripts. Ces bibliothèques peuvent être écrites dans n'importe quel langage prenant en charge la liaison c et les bibliothèques partagées (sauf les langages comme Rust et D). Il n'est pas encore clair s'il sera prêt pour la version 3.0 (sauf si je suis obsolète).
• N'oubliez pas qu'il y aura aussi Visual Scripting dans la version 3.0 !

Si quelqu'un envisage de contribuer autre chose, ce ne sera pas non plus le bon endroit pour en discuter.

Je pense que ce problème peut et doit être clos.

D'accord.

Pourriez-vous fournir un lien vers les codes sources d'intégration C# ?

https://github.com/neikeq/GodotSharp

Comment l'intégration de GodotSharp est-elle fonctionnelle ? Est prêt à être utilisé pour les tests ?
Peut être utilisé avec la construction source de godot master ?

@nictaylr Il ne construit pas avec le maître actuellement. Si vous voulez le tester, vous devez utiliser 2.2-legacy. Il fonctionne très bien avec cette version

Je travaille pour qu'il soit prêt pour une alpha 3.0 en avril.

Idée aléatoire, mais après avoir profondément réfléchi au C++ avec Godot, j'ai pensé à quelque chose de peut-être mieux. Le langage D. Il relève sans doute d'un quota de langage "de bas niveau", avec une interface avec le support C et (certains) C++. Il a des cours et est très moderne. Bien que cela semble effrayant, cela ressemble beaucoup à GDScript , et je pouvais voir qu'il était utilisé pour alimenter de très gros projets. Il est assez puissant pour rivaliser avec C et C++ (gcc/g++) avec un compilateur appelé GDC. (DMC peut également être utilisé pour compiler, mais GDC compile directement en gcc) voir plus sur GDC ici

Quoi qu'il en soit, juste une suggestion rapide ou peut-être des idées.

@VenHayz Je travaille sur un module qui permet l'utilisation de bibliothèques partagées pour les scripts. J'ai déjà fait des efforts pour rendre C++ plus facile à utiliser avec. Vous pouvez également utiliser D pour créer ces bibliothèques. Si vous êtes intéressé par la création de liaisons D, contactez-moi sur IRC ou Discord.

@karroffel c'est vraiment cool. Je n'ai aucune expérience dans l'écriture de bibliothèques et d'API (référence à votre mention de "liaisons") bien que je pourrais probablement faire des recherches dessus pendant une journée et le faire ; Je suis fier d'apprendre rapidement. J'aimerais vous contacter sur Discord, si cela ne vous dérange pas ? Mon discord : _hasCat#3941

@VenHayz Je ne peux pas vous ajouter, vous n'autorisez pas les autres à vous ajouter. Karroffel#8409 ou rejoignez le serveur Godot

@neikeq Votre dépôt GodotSharp est-il la base de code utilisée pour la prise en charge de C # dans Godot 3.0 ? Je demande simplement parce que j'essaie d'avoir une idée approximative des fonctionnalités qui seront disponibles et que je fouillerai dans cette base de code si c'est le cas. Merci!

je regarde godotsharp, est obsolète? nouvelle fonctionnalité ? ou est prêt à être utilisé dans la version de développement ?

comment puis-je compiler godosarp à partir de soruce pour moi?

@nictaylr Vous devrez utiliser la branche 2.2-legacy comme build de développement.

Je pense que j'en ai assez lu pour savoir si quelqu'un d'autre l'a mentionné.

Personnellement, je ne veux tout simplement pas apprendre une autre langue que je ne peux utiliser nulle part ailleurs. Je ne prévois pas de faire beaucoup de programmation 3D, juste quelques petites choses ici et là.

Oui, il y a beaucoup de contre-arguments contre cela mais ... c'est un projet open-source. Il n'est pas nécessaire de détester quelqu'un qui contribue à un nouveau langage de programmation.

Imaginez apporter de la bière à une fête d'enfants. Diriez-vous qu'"il n'y a pas lieu de haïr quelqu'un qui contribue une nouvelle boisson" ? Il y a de fortes chances que l'ajout de C# nuise au développement de GDscript. Je sais que tout le monde est déterminé à garder GDscript comme langage principal pour Godot, mais cela m'agace encore lorsqu'on m'a expliqué à plusieurs reprises pourquoi l'ajout de nouvelles fonctionnalités a des inconvénients et que les gens demandent toujours "où est le mal ?".

Demander également C # au lieu de GDscript parce que "vous ne voulez pas apprendre" est un argument vraiment stupide. De tous les langages que je connais dans le développement de jeux, GDscript a le moins de fonctionnalités et C# en a de loin le plus. Si vous ne voulez pas apprendre, vous devriez être reconnaissant envers GDscript.

Je ne veux vraiment pas réchauffer cette discussion maintes et maintes fois, alors s'il vous plaît, si quelqu'un veut commenter ce fil, VEUILLEZ LE LIRE À PARTIR DU HAUT.

Demander également C # au lieu de GDscript parce que "vous ne voulez pas apprendre" est un argument vraiment stupide.

Cela ne me dérangerait pas d'apprendre C # car je pourrais peut-être l'utiliser ailleurs.

Verrouillez simplement le fil, ça devient méchant.

C'est vrai que ce fil a rempli son rôle, fermons le.