Godot: Script visuel de style feuille d'événement

Cela ne pourrait-il pas être en grande partie atténué en dotant le Visual Scripting actuel de fonctions plus nombreuses et de meilleure qualité ?

Beaucoup d'exemples sont triviaux dans le plan directeur de l'UE4. "En appuyant sur la touche W, déplacez cet acteur vers l'avant".
Vous pouvez construire la plupart d'entre eux d'une manière très similaire dans le plan et même les différences visuelles (qui seraient les seules) seraient minimes.

Nous devons nous concentrer sur le fait de rendre le script visuel que nous avons utilisable et de travailler de manière intuitive et fluide, IMO. En l'état, le script visuel que nous avons déjà semble un peu oublié et ne semble pas recevoir beaucoup d'amour. Comment le fait d'avoir deux systèmes Visual Scripting améliorerait-il cette situation ?

Une bonne idée de plugin. Mais maintenir officiellement deux systèmes de script visuel serait pénible et pour peu de gain.

@mhilbrunner malheureusement non, les Blueprints sont une approche complètement différente du script visuel. Pour vous, ils sont triviaux, mais je vous mets au défi de le dire sur le forum de clickteam ou sur le forum de construct. Ces gars-là sont coincés avec les moteurs qu'ils utilisent à cause de combien ils aiment cette approche et croyez-moi - beaucoup d'entre eux ont essayé des plans dans Unity, unreal et d'autres moteurs - y compris godot. Ils sont toujours bloqués avec construct2 ou clickteam fusion car ils préfèrent les feuilles d'événements aux Blueprints. Ils demandent toujours l'approche de la feuille d'événement sur le forum de l'unité.
Le script visuel de Godot a été mentionné sur leurs forums et les utilisateurs y préfèrent toujours les feuilles d'événements. Personnellement, je suis passé à gdscript et je préfère utiliser gdscript au lieu de blueprints, car gdscript est plus proche des avantages des feuilles d'événements que les blueprints.

C'est comme dire à quelqu'un qui aime les bananes de manger des tomates à la place - c'est une question de goût :)

@groud J'ai pensé la même chose pendant un moment, mais je ne sais même pas par où commencer - et même en tant que plugin, quelqu'un devra maintenir le plugin.

@reduz semblait plus chaleureux envers l'idée sur facebook, mais je comprends qu'il a les mains pleines avec des choses plus importantes

Dans tous les cas, je poste ceci ici pour la documentation - pour décrire le système de feuille d'événement - ce qu'il fait et en quoi il diffère des plans. Si quelqu'un d'autre est intéressé à l'implémenter dans godot ou en tant qu'addon, veuillez nous le faire savoir. Je retrousserais certainement mes manches et aiderais, diffuserais les nouvelles et obtiendrais les commentaires des utilisateurs de clickteam/construct .

Jusqu'à présent, je ne sais même pas comment implémenter correctement son interface avec la classe GUI de godot. Vous devez pouvoir faire glisser des blocs logiques entre les cellules d'une même colonne. Copier/coller des blocs/lignes aussi - imbriquer des lignes et
d'autres choses uniques. Je ne pense pas que ce soit une petite tâche

@blurymind Oui, et merci de l'avoir signalé et d'avoir pris le temps de rédiger un article détaillé. Je pense toujours que ce serait peut-être mieux en tant que plugin.

devs : Quelle est la meilleure façon d'ajouter cela avec un minimum de complexité ? Peut-être que je trouverai le temps d'examiner comment fonctionnent les scripts visuels actuels. Je me demande s'il est possible de remplacer la plupart du temps l'interface utilisateur de Visual Scripting ou de générer GDScript ou une autre façon de le faire de manière dynamique.

Je n'ai pas encore examiné tout cela, donc les pointeurs sont les bienvenus. :) Pas de pointeurs nuls, s'il vous plaît !

@mhilbrunner, nous pouvons peut-être ouvrir un autre numéro sur le tracker avec une liste de choses dont le système de plan directeur dans godot a besoin pour être plus intuitif. S'il vous plaît lien vers lui si vous le faites

Mon post ici est une proposition pour une approche alternative, pas pour un changement de celle actuellement mise en œuvre. Les feuilles d'événement sont beaucoup trop différentes de toute façon

Je pense qu'une telle feuille d'événement pourrait être implémentée via Nativescript, mais je ne vois aucune raison pour laquelle elle devrait s'appuyer sur la même base de code que Visualscripting.

@groud c'est un bon point en fait. Quelle partie de la base de code Visualscripting actuelle peut-elle être réutilisée ? Dans quelle mesure est-il spécifique à l'interface nodegraph ?

@blurymind Ouais, vous travaillez sur une telle liste pour VS et fera l'affaire, mais cela prendra un certain temps.

Besoin d'enquêter sur NativeScript :)

Nous avons maintenant plusieurs choix pour les langages de script (C++, C#, même python). Pourquoi ne pas avoir également plus d'un choix pour le script visuel :)

Je suppose que cela pourrait aussi dépendre de la flexibilité de l'API de godot pour la création d'interfaces de script visuel.
La base de code Visualscripting doit-elle être réutilisée - ou une autre complètement alternative doit-elle être écrite avec Nativescript (c++) ?
Cela peut-il simplement être implémenté en tant qu'addon gdscript ?

Pourquoi ne pas avoir également plus d'un choix pour le script visuel :)

Parce que nous prenons déjà en charge un trop grand nombre de langues intégrées. La plupart des cas d'utilisation sont déjà couverts, il n'y a donc pas beaucoup de raisons d'ajouter un nouveau langage à maintenir. Nous avons un langage pour la programmation de base (GDscript), deux pour les performances (C# et C/C++) et un pour les artistes/game designer (scripts visuels). Il n'y a aucune raison d'ajouter une autre langue en tant que langue intégrée simplement parce que certaines personnes ne peuvent pas gérer l'apprentissage d'une nouvelle langue.

Honnêtement, je ne pense certainement pas que cela devrait être ajouté au noyau. Il serait préférable de l'ajouter via un plugin comme n'importe quelle autre liaison de langue. Nous avons déjà suffisamment de travail pour maintenir les langues actuelles.

Et non, je ne pense pas qu'on puisse réutiliser le code du visualscripting.

@groud C'est un bon point, mais considérez le ratio programmeurs/artistes dans gamedev. Certains des plus grands et des plus beaux jeux 2D rétro ont été créés avec fusion 2 par des artistes qui voulaient créer des jeux d'une manière intuitive qui correspond à leur façon de penser. Voici un showreel un peu obsolète des jeux créés par Fusion :
https://www.youtube.com/watch?v=3Zq1yo0lxOU

Ils ont de nombreux projets et jeux kickstarter réussis sur Steam - des jeux sur de nombreuses plateformes. Les gens aiment utiliser cette approche dans la programmation visuelle - même les équipes professionnelles. Je ne le présenterais pas ici si je ne voyais pas le potentiel d'élargir la base d'utilisateurs

Bon peut-être, mais combien d'entre eux sont capables de comprendre les Event Sheets mais pas le VisualScripting ? Vous dites que "ces gars sont coincés avec les moteurs qu'ils utilisent à cause de combien ils aiment cette approche et croyez-moi - beaucoup d'entre eux ont essayé des plans dans Unity, unreal et d'autres moteurs - y compris godot", mais vous êtes en fait le premier à demander ça.

S'il s'agit d'une demande populaire, oui, nous pourrions l'ajouter au noyau. Mais jusqu'à présent, ce n'est pas le cas.

Pour moi, nous couvrons déjà tous les cas d'utilisation. Au moins pour un moteur de jeu professionnel et à la pointe de la technologie. Et comme nous ne ciblons pas les enfants ou les amateurs mais les entreprises, cela ne vaut pas la peine d'y consacrer du temps. Fusion 2, Construct ou encore RPGMaker se concentrent sur un autre public, même si de beaux jeux ont été réalisés avec eux, seule une infime partie d'entre eux sont des projets professionnels.

@groud ces statistiques sont difficiles à obtenir. Combien utilisent le script visuel actuel ?

J'explique également pourquoi l'approche de la feuille d'événement présente des avantages par rapport aux plans, tels que moins de clics pour faire fonctionner les choses, une présentation plus claire et une meilleure transition d'apprentissage vers gdscript.

Le moteur de création de rpg est vraiment un éditeur de niveau si vous voulez mon avis. Il n'a pas le même niveau de flexibilité que Fusion et construct2

Il est plus facile d'expliquer à quelqu'un comment fonctionne une feuille d'événement que d'expliquer le même exemple dans un plan - ils doivent apprendre beaucoup moins de concepts - pas besoin d'apprendre le type de connexions entre les nœuds, les types d'entrées et de sorties - comment régler le débit.
Au lieu de cela, les événements se déroulent de haut en bas, la gauche est la condition et la droite est l'action. Vous n'avez rien à connecter.

Est ce que ca

ça a l'air aussi difficile à comprendre que ça ?

Bien sûr, godot utiliserait plus de blocs d'événements à réaliser, mais ce serait toujours plus clair qu'un graphe de nœuds.
Même gdscript me semble plus clair que cela. Notre système de script visuel actuel semble compliqué à première vue

Je parle en tant que quelqu'un qui a utilisé les deux systèmes et qui les compare maintenant - les deux sont tout aussi puissants, l'un est clairement plus simple à apprendre et à comprendre
Essayez-le s'il vous plaît. Vous pouvez essayer gratuitement construct3 dans votre navigateur Web ici :
https://www.scirra.com/
Si vous avez un fils ou un frère ou une sœur plus jeune, demandez-leur de l'essayer, puis essayez celui de godot - voyez ce qu'ils peuvent faire et combien de temps il leur faut pour le faire sans instructions données - il existe un marché potentiel pour que plus d'écoles adoptent godot ici - améliorer les scripts visuels pour l'apprentissage des concepts de programmation et nous aurons une population plus jeune en utilisant le moteur

Combien utilisent le script visuel actuel ?

Je n'en ai aucune idée, mais je ne crois pas beaucoup pour l'instant. La plupart des gens semblent utiliser GDScript pour l'instant, car je ne vois pas beaucoup de questions/contenu concernant VisualScripting sur Facebook ou Youtube. Ajouter des Event Sheets avant d'être sûr que le VisualScripting ne répond pas à tous les cas d'usage serait un pari audacieux. Voyons juste pour l'instant si VisualScripting est suffisant, et si les gens demandent massivement un autre système, nous pourrions l'ajouter plus tard.

@groud serait génial si nous pouvions tester le script visuel de godot dans un environnement scolaire - avec des enfants apprenant les concepts de base du codage.
L'un des principaux arguments de vente de construct2 a été d'enseigner le codage aux enfants et ils vendent une licence éducative spéciale depuis des années.

Mon argument est que le script visuel dans godot pour le moment n'est pas très attrayant pour les non-codeurs et n'aide pas vraiment les gens à apprendre à coder - car son approche est purement centrée sur la machine à états et les concepts de programmation de base deviennent encore plus compliqués avec un nodegraph supplémentaire règles centrées sur le dessus.

Les programmeurs expérimentés ne sont vraiment pas le meilleur public à qui vendre cela - car ils verraient la feuille d'événement comme une simplification de ce que nous avons déjà - gdscript et verront les plans comme un nouvel outil qui pourrait être utilisé comme machine d'état par les concepteurs.

J'adorerais essayer d'écrire un module complémentaire de feuille d'événement de base dans gdscript, je ne suis vraiment pas assez expérimenté pour créer un module complémentaire de script natif. Si cela est possible et que vous avez des indications par où commencer - j'aimerais les entendre
Peut-être que s'il y a assez d'intérêt, quelqu'un pourrait le faire en natifscript

parce que son approche est purement centrée sur la machine à états

Quoi ? Je n'ai aucune idée de pourquoi vous penseriez cela. VisualScripting n'a rien à voir avec les machines à états.

Qu'est-ce qui est le plus simple à utiliser pour le moment : Blueprints ou Gdscript ? Quel est l'objectif du script visuel et qui est l'utilisateur cible

VisualScripting devrait être plus simple que GDscript pour les artistes/développeurs de jeux. Je dois admettre que ce n'est pas vraiment pour l'instant, probablement qu'un tas de nœuds pourraient être simplifiés / rendus plus attrayants. Mais honnêtement, vous vous trompez en pensant que les feuilles d'événements sont plus faciles à comprendre que VisualScript, pour moi elles ne le sont pas.

La seule chose qui fait réellement la différence dans les exemples que vous montrez, ce sont le texte et les icônes qui rendent les choses beaucoup plus compréhensibles. Ce sont le texte et les icônes qui rendent les choses plus explicites et simples, pas l'organisation verticale. VisualScripting serait aussi compréhensible si nous ajoutions de telles icônes, si nous créions une meilleure interface graphique pour les actions les plus courantes et si nous regroupions les fonctions dans des catégories pertinentes.

@groud c'est aussi l'ordre d'exécution et les types de connexions. Il y a beaucoup plus de concepts à rechercher dans le nodegraph que dans la feuille d'événements. Même si vous ajoutez des icônes aux nœuds, vous devez toujours expliquer que l'ordre des événements est dicté par les lignes blanches, ainsi que par la signification des autres couleurs. Vous vous retrouvez toujours avec un graphique spaghetti qui est plus difficile à lire - vos yeux doivent voyager partout pour comprendre ce qui se passe dans le graphique de quelqu'un d'autre

Vous n'êtes pas le bon public cible - vous êtes un programmeur c++ expérimenté. Veuillez tester ceci avec des personnes qui ne sont pas des programmeurs et vous commencerez à voir ce que je veux dire.

Allez, ce n'est pas si difficile à comprendre, encore une fois, nous ne ciblons pas les enfants.
Et concernant l'organisation du code, le problème est le même pour les fiches d'événements. Si vous ne vous embêtez pas à regrouper les nœuds et à organiser votre code, vous vous retrouvez avec un code illisible, que ce soit en raison de longues feuilles d'événements ou d'énormes graphiques de nœuds.

@groud pouvons-nous même grouper des nœuds visualscript comme dans Blender ? Je ne me souviens pas avoir vu ça. Peut-être que @mhilbrunner devrait l'ajouter à sa liste
https://github.com/godotengine/godot/issues/12418
Un autre point important est que la possibilité de créer des blocs logiques d'action/condition de niveau supérieur réutilisables via gdscript serait très bénéfique pour un système de feuille d'événement ou le système de plan directeur. Le système de blueprint l'a déjà - mais je ne vois aucun plugin conçu pour cela.

Encore une fois - construct2 est en avance sur nous. Leur communauté a créé de nombreux plugins faciles à installer qui ajoutent des conditions et des actions personnalisées - et leur API pour enregistrer une action et une condition est super simple
https://www.scirra.com/forum/completed-addons_f153
https://www.scirra.com/manual/19/actions-conditions-and-expressions

Totalement conforme à blurymind
Pour moi, il est beaucoup plus facile de comprendre le système d'événements Construct et Fusion, qui offre également beaucoup plus rapidement pour développer n'importe quel jeu qu'un système plein de lignes

lol comment est- ce plus facile à lire que gdscript

@groud pouvons-nous même grouper des nœuds visualscript comme dans Blender ? je ne me souviens pas avoir vu ça

Je ne sais pas. Mais si ce n'est pas mis en œuvre, je pense qu'il devrait l'être.

lol comment est-ce plus facile à lire que gdscript

Ce n'est pas le sujet ici.

@groud ouais c'est ça. pourquoi un développeur de jeu voudrait-il utiliser des feuilles d'événements alors qu'il est beaucoup plus désorganisé/déroutant à lire qu'un simple code gdscript ? c'est tout l'essentiel de cette suggestion de fonctionnalité, n'est-ce pas

@groud ouais c'est ça. pourquoi un développeur de jeu voudrait-il utiliser des feuilles d'événements alors qu'il est beaucoup plus désorganisé qu'un simple code gdscript ?

Non, ce n'est pas le cas, VisualScripting (ou Event Sheets) et GDscript ne ciblent pas les mêmes personnes. Le VisualScripting (ou les feuilles d'événements) est destiné aux artistes ou aux concepteurs de jeux/niveaux tandis que gdscript nécessite une expérience en programmation.

Comparer Event Sheets et GDscript n'a aucun sens.

Comparer Event Sheets et GDscript n'a aucun sens.

eh bien, c'est là que nous différons :P parce que je pense qu'il est plus que raisonnable de les comparer. d'autant plus que gdscript fait tout ce qu'ils font, à un niveau beaucoup plus simple.

aussi, je ne suis pas d'accord sur le "nécessite une expérience de programmation". si un concepteur de niveau crée déjà des blocs d'actions _dans une feuille d'événement ou un script visuel_, il _a déjà les blocs de construction fondamentaux_ pour utiliser gdscript.

Cela dit : gdscript compilé par JIT est sur la feuille de route et serait bien plus avantageux que les feuilles d'événements ou les ajouts de scripts visuels (puisque la majorité des développeurs de godot pourraient déjà en bénéficier grandement). et les cas d'utilisation potentiels de VS/Event Sheets sont actuellement assez faibles. donc tout ce que je demande s'il vous plaît soyez prudent sur le temps de développement, car votre récent message a déjà fait allusion

@girng à quel moment avez-vous décidé que j'essayais de voler la priorité d'autres fonctionnalités importantes sur la feuille de route ? Cet article explore les avantages du script visuel via une méthode alternative à celle que nous avons actuellement.
Ce n'est même pas sur la feuille de route, pourtant tu sautes dessus comme si c'était là pour prendre ton petit déjeuner. :p
Explorer une idée n'est pas tout à fait la même chose qu'exiger du temps.

Vous n'avez évidemment jamais touché à la construction ou à la fusion clickteam, si vous voulez en discuter - utilisez au moins la feuille d'événement pendant un moment - faites un jeu de plateforme avec.
J'ai lié à une démo en ligne de construct3, qui ne nécessite pas de créer un compte ou de vous connecter.
https://www.scirra.com/
c'est littéralement à trois clics

Essayez la feuille d'événement, faites quelque chose avec. Ensuite, utilisez les plans visualscript que godot a

Gdscript est simple - oui je suis d'accord et je l'aime aussi. Un gdscript compilé par jit serait génial ! D'accord, c'est plus important aussi.
Mais cette discussion ne concerne pas du tout ces choses

eh bien, c'est là que nous différons :P parce que je pense qu'il est plus que raisonnable de les comparer. d'autant plus que gdscript fait tout ce qu'ils font, à un niveau beaucoup plus simple.

Ce que vous ne comprenez pas, c'est que pour beaucoup de gens, il y a une barrière mentale entre coder et ne pas coder. Je dois admettre que VS est un peu difficile à aborder pour le moment, mais à l'avenir, cela devrait être plus facile que GDScript car beaucoup de matériel d'apprentissage aurait pu être créé et plusieurs améliorations de VS devraient être apportées.

aussi, je ne suis pas d'accord sur le "nécessite une expérience de programmation". si un concepteur de niveau crée déjà des blocs d'actions dans une feuille d'événement ou un script visuel, il dispose déjà des blocs de construction fondamentaux pour utiliser gdscript.

Oui, je suis assez d'accord aussi en tant que programmeur, mais ce n'est pas ce que l'expérience montre.
Unreal est l'exemple parfait : beaucoup de gens utilisent des plans avec Unreal, en particulier dans le domaine professionnel, car ils permettent aux non-programmeurs d'écrire du code de manière plus accueillante. Même si ce n'est pas si différent du code réel (à mon avis), cela fait les différences dans l'esprit des gens. Si les professionnels l'utilisent, cela signifie que c'est un réel besoin, pas un gadget que nous devrions laisser tomber car nous pensons que c'est la même chose. C'est pourquoi cela n'a aucun sens de les comparer, les deux doivent être disponibles et fonctionner correctement.

Quoi qu'il en soit, je vais arrêter cette discussion ici. Le bikeshedding à propos de VS ou non VS a déjà été traité.

@blurymind j'admire votre énergie et vous faites de bons points. J'ai déjà essayé les feuilles d'événements dans construct et elles étaient cool au début, mais plus mon jeu devenait avancé, j'ai immédiatement voulu revenir au code. alors oui, je les ai déjà essayés.

@groud fait un bon argument à leur sujet, car Marvel Heroes était un aRPG AAA et ils utilisaient des plans avec Unreal .

Je ne conteste pas qu'ils ont leurs cas d'utilisation, je pense juste que ce sera difficile à justifier, sur la base des critères suivants :

• main-d'œuvre de développement limitée
• quantité de problèmes en cours déjà
• désorganisation / difficile à lire (voir ici )
• je pense que la plupart des développeurs godot préféreraient utiliser gdscript
• gdscript se lie déjà si bien avec godot
• si ajouté à core , de nouveaux problèmes pourraient survenir concernant les feuilles d'événements, ce qui pourrait éliminer les problèmes de gdscript
• pas juste pour les 90% actuels des développeurs godot utilisant déjà gdscript (si le temps de développement pouvait être utilisé pour gdscript compilé par jit, qui répond aux cas d'utilisation actifs)

en tant que plugin, je pourrais le soutenir pleinement, mais mon cœur me dit que ce ne serait peut-être pas une bonne idée s'il est officiellement pris en charge

@giring merci. Encore une fois - ce n'est pas une demande de remplacement de gdscript ou de visual script.
Il s'agit plutôt d'une observation sur les scripts visuels en général et sur le fait que les scripts visuels de godot pour le moment ne sont vraiment pas conviviaux pour les non-codeurs.

Gdscript peut parfaitement s'intégrer à n'importe quel système de script visuel - feuilles d'événements ou plans.
Comme indiqué dans mon premier message - l'approche de la feuille d'événement utilise également des expressions - pour lesquelles gdscript peut déjà être utilisé. Des blocs logiques de niveau supérieur pourraient également être créés via gdscript et le système de plugins de godot - ils s'intègrent parfaitement avec un système de script visuel.

En fait, un système de feuille d'événements peut être bien mieux marié à gdscript que le système de plan directeur actuel - où les expressions sont effectuées avec un milliard de graphiques de nœuds plutôt qu'une simple entrée de champ de texte. Si vous voulez faire 1+1- utilisez un nœud. Si vous souhaitez adresser une variable simple dans une expression, utilisez un autre nœud. Vous vous retrouvez avec un désordre spaghetti d'un milliard de nœuds de base pour une expression simple qui pourrait tout aussi facilement et beaucoup plus clairement être écrite dans un petit champ de texte avec beaucoup moins d'effort et de verbosité.

Le script visuel actuel que nous avons prend beaucoup trop de clics, de nœuds et de verbosité pour faire les choses les plus simples. C'est une autre raison pour laquelle gdscript est plus simple imo - une ligne de code au lieu de 10 nœuds et 100 connexions.

C'est fondamentalement l'autre avantage d'un système de feuille d'événements - vous pouvez simplement écrire vos expressions dans les champs de saisie du bloc de code. construct2 et fusion ont même des éditeurs de saisie semi-automatique et d'expression avec un accès facile à toutes les méthodes d'un nœud avec une liste de tous les nœuds auxquels la feuille a accès dans la portée.

Godot pourrait très facilement utiliser gdscript pour les expressions en faisant la même chose - mais ces expressions sont placées dans une structure de feuille de calcul simple.

Imaginez une méthode dans godot- comme un bloc logique. Tout comme sa méthode - ce bloc prend les mêmes paramètres - mais vous n'avez pas besoin de l'accrocher aux nœuds. Vous pouvez simplement taper du gdscript dans son champ de saisie.
Les nœuds dans godot peuvent agir comme les comportements dans construct2 et une feuille d'événement dans godot serait bien plus flexible et puissante que celle de construct2. Il n'aura aucun des inconvénients que leur moteur a

L'approche de Construct pour associer des objets est horrible - entre autres - mais cela n'a rien à voir avec la conception de la feuille d'événement

Le script visuel actuel que nous avons prend beaucoup trop de clics, de nœuds et de verbosité pour faire les choses les plus simples.

Ce n'est pas un défaut inhérent à VS, mais à sa mise en œuvre actuellement limitée. Cela devrait être corrigé et ne pas être utilisé comme argument pour implémenter une autre méthode de script visuel à côté. Sinon, le VS actuel devrait être mis au rebut.

De plus, discuter de JIT pour GDscript est hors sujet. Le mérite d'une caractéristique ne peut être mesuré que par :

• c'est l'utilité par rapport à d'autres fonctionnalités similaires qui peuvent être utiles pour le même cas d'utilisation
• c'est l'utilité par rapport à la complexité qu'elle apporte à la table, la dette technique supplémentaire et la charge de maintenance pour Godot

Donc, que cela soit fait ou non n'a rien à voir avec le fait que nous implémentions ou non JIT pour GDScript. Sinon, nous devrions fermer 99% de toutes les demandes de fonctionnalités jusqu'à ce que tous les bogues majeurs soient corrigés, c'est-à-dire pour toujours. Ceux-ci sont encore plus importants que JIT pour GDScript.

@mhilbrunner JIT pour GDScript va se produire cependant, c'est déjà sur la feuille de route officielle :P. Je disais juste que cela pourrait réduire le temps de développement. et c'est difficile à justifier puisque 90% des développeurs de godot utilisent déjà gdscript (et beaucoup de gens pensent que c'est mieux que les feuilles d'événements, et ont leurs propres sentiments). désolé si je ne me suis pas bien exprimé. oui, je sais que cela ne le remplace pas, mais j'en dis plus sur le temps de développement.

Cela dit, @blurymind, je ne peux pas être en désaccord avec tout ce que vous avez dit car ce sont de très bons points. Est-ce que le fait d'avoir des feuilles d'événements dans Godot serait une fonctionnalité intéressante à avoir ? bien sûr, mais est-ce quelque chose qui arrivera bientôt dans la réalité ? je ne suis pas vraiment sûr. (juste un fervent utilisateur depuis 2014, et ce n'est que mon avis)

Ayant moi-même déjà utilisé la feuille d'événement Action Game Maker et Game Maker, je reconnais qu'il est plus facile à utiliser et à comprendre que VisualScript (vous lisez de haut en bas, sans suivre les lignes), ne prend pas autant d'espace à l'écran et peut implémenter machine d'état plus facilement (en filtrant quels événements peuvent être déclenchés après la fin d'un événement).

Ce serait un très bel ajout. Je ne l'utiliserai probablement pas moi-même car GDScript me suffit, mais je peux m'imaginer l'utiliser très bien si GDScript n'est pas une option (ce que les débutants et les non-programmeurs connaissent probablement).

Eh bien, je suis un utilisateur de Godot depuis environ un an. J'adore GDScript et sa syntaxe simple.
Mais j'utilise Construct depuis plus de 8 ans et je peux dire que je n'ai jamais vu un script visuel plus facile que Event Sheets.Je n'aime pas Blueprint et j'ai utilisé d'autres styles VS Blue Prints, comme Blender et Unity, et je ne Je ne comprends pas comment les gens peuvent dire que Blue Print est plus facile que Event Sheets. C'est peut-être parce que les artistes sont habitués à utiliser des nœuds pour configurer les shaders et les graphiques, ils sont habitués à cette esthétique. Mais je parie que si vous mettez un système de feuille d'événement dans un moteur comme Unreal, les gens abandonneraient les Blueprints.

Je travaille dans une école qui enseigne la logique de programmation aux enfants et aux adolescents. Pour les enfants, nous utilisons Construct 2 car il leur est extrêmement facile de créer quelque chose avec Event Sheets. Pour les adolescents, nous utilisons GDScript et nous avons obtenu de bons résultats. Lorsque Godot 3.0 est sorti, nous avons étudié l'idée de laisser tomber Construct 2 pour utiliser Godot VS, mais nous avons abandonné l'idée car actuellement VS est plus difficile que GDScript, très compliqué à comprendre et à utiliser. Si Godot avait quelque chose comme Event Sheet, nous ferions notre cours entièrement basé sur Godot, car nous avons tendance à privilégier les solutions Open Source à l'école.

Je pense qu'Event Sheets apporterait un autre avantage, cela augmenterait la base d'utilisateurs de Godot, car dans GDC, nous avons vu des studios de taille moyenne à grande préférer Godot, mais les petits préfèrent Unity et d'autres solutions. Je pense que les utilisateurs de Construct, Fusion et Game Maker commenceraient à migrer vers Godot.

Eh bien, en tant qu'enseignant, je vois une grande valeur dans les feuilles d'événements, car c'est très facile à comprendre et lorsque les étudiants passent à GDscript, ils ont déjà développé une pensée logique et la structure des feuilles d'événements ressemble plus à du code qu'à des Blue Prints.

Quoi qu'il en soit, j'adore ce que fait Godot et j'adore GDscript, je voulais juste partager mon expérience, car j'utilise à la fois Event Sheet et GDscript pour enseigner. Gardez le bon travail!

Quand Godot 3.0 est sorti, nous avons étudié l'idée de laisser tomber Construct 2 pour utiliser Godot VS, mais nous avons abandonné l'idée car actuellement VS est plus dur que GDScript, très compliqué à comprendre et à utiliser

C'est un retour assez intéressant. :)
Le fait est que les feuilles d'événements, sous la forme Construct2, sont de niveau beaucoup moins bas que VS ou GDscript. En effet, ils peuvent aider les enfants à se lancer dans la programmation de jeux mais ce n'est pas la cible de Godot. Je pense qu'un tel système ne devrait pas être fourni comme intégré, mais disponible via un plugin. Je suppose que ce commentaire de reduz exprime cela aussi.

@DrZanuff merci d'avoir soulevé ce point très important - quelque chose dans le même sens a également été noté par la chaîne youtube kidscancode et idéales pour un environnement scolaire et une excellente transition vers quelque chose comme gdscript. Les plans ne sont malheureusement pas

Peut-être que Godot peut aborder cela de la manière dont le créateur de jeux le fait - son code visuel par glisser-déposer est directement traduit en code gml qui peut même être prévisualisé en temps réel. De cette façon, les non-codeurs peuvent apprendre gml pendant qu'ils utilisent le système de script visuel du moteur - c'est la stratégie exacte qu'emploie les jeux yoyo pour introduire progressivement les non-codeurs à gml
https://docs2.yoyogames.com/source/_build/3_scripting/1_drag_and_drop_overview/changing_dnd.html

À la fois lors de l'utilisation de gml pour les expressions et lorsqu'ils prévisualisent ce que fait leur programmation visuelle

Même en tant qu'addon, je continue de penser que les objets de la feuille d'événement de godot devraient à la fin être traduits en gdscript. La feuille d'événement peut être un outil pour enseigner aux non-codeurs comment utiliser gdscript - en leur donnant une interface simple qui permet toujours l'utilisation de gdscript pour les expressions et à la fin génère et prévisualise quand même gdscript.

L'API de Godot a une méthode pour générer des fichiers gdscript et les attacher aux nœuds. Ainsi, une feuille d'événement peut être traduite en gdscript lors de l'exécution du jeu, ou même lors de l'édition de la feuille d'événement, comme le fait le fabricant de jeux.

L'aide à l'apprentissage supplémentaire utilisée à la fois par clickteam fusion et construct2 est une liste de menus basée sur un clic de méthodes/membres de nœuds intégrés.

Lorsque l'étudiant clique sur l'un des éléments de la liste, la syntaxe appropriée est ajoutée au champ de saisie. Lorsqu'ils commencent à apprendre, ils cliquent, mais en cliquant, ils apprennent et mémorisent la syntaxe et les méthodes. Plus tard, au lieu de cliquer, ils tapent avec la saisie semi-automatique et sans se rendre compte qu'ils ont appris l'API

En ce sens, la mise en œuvre par Godot d'un système de feuille d'événements peut avoir pour objectif principal d'introduire les non-codeurs à gdscript et aux concepts de programmation de base sans les embrouiller avec aucune syntaxe - cela placera ensuite Godot dans plus d'écoles enseignant la programmation aux pré-adolescents. Au fur et à mesure qu'ils avancent, ils apprendront gdscript et l'api de godot, au lieu de construct2 ou de game maker

Je pense que je n'ai pas bien expliqué ... :(

Quand je dis lignes, je fais référence au script visuel, aux lignes qui relient les nœuds

Le système d'événement de construction et de fusion est beaucoup plus intuitif, facile et rapide pour créer un jeu, que le script visuel Godot

Il serait bon d'explorer une alternative de ce type

Les fonctionnalités de niveau supérieur
Il faudrait beaucoup moins de travail pour créer et maintenir des fonctions de niveau supérieur pour le système de plan directeur actuel, que d'écrire une fonctionnalité de feuille d'événement de fonctions de niveau supérieur ET un système de base de feuille d'événement entièrement nouveau à partir de zéro en tant que plug-in.

Si nous avions une implémentation de bas niveau d'un système de feuille d'événement, il serait beaucoup plus facile de créer et de maintenir des actions/conditions de niveau supérieur pour cela.
Je suppose que même en tant qu'addon - je ferais d'abord l'addon de base Event Sheet avec juste un accès de bas niveau et une interface - qui suit l'architecture de godot sans le surcharger avec de nouvelles méthodes. Ensuite, des addons facultatifs séparés pour des éléments de niveau supérieur peuvent être écrits par-dessus dans d'autres plugins.

Le référentiel d'actifs pourrait avoir une section spéciale pour les modules complémentaires de script visuel

J'enseigne la programmation aux enfants de 7 à 17 ans. Actuellement, les étudiants plus jeunes utilisent le Cosntruct et les plus âgés utilisent Godot, mais si tous mes étudiants pouvaient utiliser le Godot, ce serait vraiment reconnaissant que les enfants utilisent le Godot depuis le début de leur voyage dans ce monde de développeurs de jeux.

N'est pas seulement le système de feuille d'événement. C'est aussi comment fonctionnent les plugins/comportements/familles, les UID et les propriétés des objets.

Par exemple, dans C2 dans un objet sprite, je peux avoir tout l'art du jeu, y compris les statiques/animations de décoration, le joueur, les ennemis, etc. et en utilisant une variable d'instance sur l'objet appelée "type=" pour dire s'il s'agit d'un ennemi, d'un joueur, d'un objet, cassable, etc., pour définir son comportement dans les événements. De plus, pour chaque sprite, vous disposez d'un programme de peinture de base, de propriétés d'animation, etc.

Dans Godot, j'ai essayé l'exemple de Pong dans le script visuel et quand j'ai vu qu'il utilisait un sprite pour le joueur et un autre objet sprite pour la collision, et je me suis dit , QUOI !? . De plus, C2 a une "forme de polygone devinette" qui, en un clic, fait la collision de votre sprite en utilisant 8 points. Après cela, vous pouvez ajouter plus de points et ajuster pour être plus précis ou utiliser des plugins ou des astuces pour obtenir une précision au pixel près.

Je veux dire, si godot applique le système de feuille d'événement comme dans C2, mais ne suit pas la même philosophie pour le rendre facile à utiliser, ce sera une perte de temps car cela ne fonctionnera pas. Et bien, faire tout cela dans le moteur Godot actuel peut être un travail vraiment fou.

Au cas où aller de l'avant, ils devraient peut-être demander / embaucher les grands de C2 comme RexRainbow, R0j0hound, etc. . Mais comme je l'ai dit, cela signifie beaucoup de travail et d'argent.

@matriax Je ne pense pas que vous ayez raison ici.
Godot a une architecture beaucoup plus flexible et simple que Construct2.
Comme indiqué, l'appariement d'objets est une construction pénible, parmi beaucoup d'autres choses - nous pourrions par exemple avoir un ordre des événements plus clair que celui de la construction. Nous pouvons attacher des feuilles d'événements à n'importe quel nœud - permettant une meilleure organisation que construct'2.
Pour les types/familles - dans godot, nous avons des "groupes" - l'implémentation des groupes de godot est en fait meilleure que celle de construct.
Pour attacher des comportements aux objets - Vous pouvez simplement attacher des nœuds enfants et les utiliser comme comportement du nœud parent racine qui contient la feuille d'événement attachée. C'est encore mieux que Construct.
Dans godot, vous devez faire d'un nœud de forme de collision un enfant du nœud qui a la collision. Ce n'est pas sorcier et c'est en fait mieux pour enseigner la programmation aux enfants

Certaines des choses que vous demandez doivent être faites en tant qu'addons et ont déjà été faites en tant qu'addons (deviner la forme du polygone par exemple)

La mise en œuvre d'un système de feuille d'événements dans godot qui correspond à l'architecture actuelle de godot se traduirait par un meilleur système de feuille d'événements/plate-forme d'apprentissage que construct - car godot permet beaucoup plus de flexibilité dans les styles de codage et a une meilleure architecture. L'extension de ce système avec des fonctionnalités de niveau supérieur via des plugins le rendrait aussi convivial que celui de construct2.

Rendre godot aussi convivial que Construct 2 devrait être un effort conjoint, à la fois des principaux développeurs de godot et de sa communauté. La communauté aurait besoin de créer la fonctionnalité de niveau supérieur via des modules complémentaires de feuille d'événement. S'il vous plaît, n'essayez pas de faire de godot exactement la même chose que construct2. C'est mieux à bien des égards.

@blurymind Je ne parle pas d'appliquer la même architecture que dans C2, cela n'a aucun sens, je ne connais pas non plus tout ce que Godot a déjà comme les groupes, les nœuds enfants, etc. vous avez dit.

Ce que je veux dire, c'est qu'ajouter un système de feuille d'événement sur Godot sans suivre la même philosophie pour réaliser tout le travail de manière simple comme dans C2/C3 sera une perte de temps. Comme je l'ai dit, avoir un objet pour les sprites/collisions ou tous les gamearts au lieu d'un objet pour chaque chose.

Peut-être qu'ils devraient demander à la communauté combien de personnes utilisent le script visuel réel et combien de personnes préféreront le système de feuille d'événement, puis prendre une décision.

@matriax vous devez apprendre Godot avant de faire de telles affirmations :)

La proposition ici concerne une feuille d'événement, et non une copie complète du moteur de construct2.

Connaissant les deux moteurs, je crois fermement qu'une feuille d'événement peut être réalisée de manière centrée sur godot et cela ferait de godot un outil aussi bon, sinon meilleur, pour enseigner la programmation aux plus jeunes.

En ce sens, une entité de feuille d'événement serait égale à un fichier de script - similaire à ce que fait le MDN dans le fabricant de jeux, rien dans le moteur ou son fonctionnement ne doit être modifié. Si vous voulez d'autres fonctionnalités construct2, vous pouvez faire des addons

Même en tant qu'implémentation d'addon, une feuille d'événement dans godot ne devrait rien faire d'autre que de simplement créer une autre interface pour générer des fichiers gdscript imo

@blurymind Et encore avec la même chose, ok oublié.

@matriax le retour est une bonne idée. Vous avez raison sur ce point.
Il serait bon de demander à un groupe cible de personnes - pas n'importe qui sur Internet. Un groupe cible pourrait être de jeunes étudiants et enseignants - ce serait en fait la cible parfaite pour un système de feuille d'événement.
les enseignants sauraient très bien contre quoi leurs élèves luttent et connaîtraient en même temps Godot et Construct. Les étudiants et les non-codeurs pourraient donner de bons commentaires

Si vous demandez simplement sur le tracker godot ici, vous obtiendrez principalement des programmeurs expérimentés et intermédiaires, des personnes qui connaissent et aiment déjà gdscript, l'API du moteur et même c++
Ils réagiront de manière protectrice - comme vous pouvez le voir au début du post- en pensant que ce que vous proposez n'est pas ce dont ils ont besoin et le moteur a besoin - naturellement parce que nous savons déjà comment écrire du code dans gdscript et voyons des objectifs plus importants pour le moteur que celui-ci. C'est vrai qu'il y a des objectifs plus importants.
Si vous avez de la chance, certains d'entre eux auraient commencé avec la fusion construct/game maker/clickteam avant de venir à godot, et sauront où se trouve sa valeur pour les personnes qui ne connaissent pas encore de langages de programmation.

Quelqu'un a fait valoir que les artistes 3D aiment les plans, car ils savent déjà comment créer des shaders. C'est un très bon point - un artiste 3D n'est pas un programmeur - mais toujours un individu technique qui a appris les concepts d'un système de graphes de nœuds.

Pour en revenir à la valeur de ceci, ne serait-il pas merveilleux si Godot, peut-être un jour dans le futur, devenait le premier moteur de plus d'enfants ?
Pourquoi ne pas essayer de remplacer Construct dans les écoles :) Les développeurs de Scirra ont la tâche trop facile en ce moment. Regardez comment ils se vantent de collaborer avec les écoles
https://www.construct.net/gb/blogs/construct-official-blog-1/construct-3-a-year-in-review-947?utm_campaign=blog1postemailsub&utm_medium=email&utm_source=947&utm_term=txt4-read-laura_d% 2527s-post&utm_campaign=marketing&utm_source=sendgrid&utm_medium=email

En termes d'essai de l'idée en tant qu'addon, j'ai créé une interface graphique de preuve de concept WIP. Cela ne fait rien pour le moment - c'est juste pour comprendre comment l'interface pourrait fonctionner et se lier à l'architecture de godot. Je ne sais pas encore comment faire glisser pour mélanger les éléments à l'intérieur des cellules et indenter

Ce serait cool si le nœud richtextlabel dans godot pouvait utiliser les icônes internes de l'éditeur godot

Je ferai une autre maquette pour un éditeur de conditions/actions quand j'aurai le temps :)
L'éditeur d'actions/conditions serait l'outil pour éditer les cellules/blocs logiques. Je pense à quelque chose de similaire à l'approche de Construct2 avec l'éditeur de code interne de godot comme éditeur d'expression.
Peut-être que des aides pourraient être ajoutées plus tard - comme celles de construct2 ou de fusion

Une fois qu'une interface est créée, le reste consiste simplement à enregistrer/stocker les données à l'intérieur de la scène et à pouvoir générer un gdscript propre, mais il se peut que quelque chose me manque

@blurymind Nice, j'ai aimé le concept.
Peut-être que les boutons pour ajouter des actions et des conditions devraient être sans le bouton d'arrière-plan, comme dans la construction 2

Et je pense que ce serait bien une ligne pour séparer la condition de l'action

J'aime la façon dont cela se passe.

C'est une maquette vraiment chouette. Au début, je n'ai pas vraiment compris où tu voulais en venir. Maintenant c'est vraiment clair... une sorte d'étape intermédiaire entre la programmation et le genre de script visuel que nous avons déjà ?

@DrZanuff Merci pour le retour
@Zireael07 Merci :)
Oui exactement - un outil qui nous aiderait à remplacer complètement Construct2 par Godot dans les écoles qui utilisent les deux moteurs pour enseigner la programmation.
En dessous se trouve juste une interface visuelle pour générer des fichiers gdscript - similaire à la façon dont DnD est utilisé dans Game Maker 2. Je ne demande aucune modification de l'excellente architecture de godot.
Les feuilles d'événements peuvent être une option de script visuel dans Godot qui est conviviale pour les non-codeurs (les plans ne le sont pas) et les jeunes enfants apprenant les concepts de programmation - en les facilitant dans gdscript

Godot a déjà beaucoup d'éléments pour que cela fonctionne d'ailleurs, mais cela ne peut pas être exactement le même que dans Construct2. À la manière de Godot, ce sera mieux à bien des égards si cela se produit. La feuille d'événement de Construct2 permet de très mauvaises pratiques d'organisation de code et présente des limitations/bizarreries terribles. Nous pouvons en fait créer une meilleure fiche d'événement que la leur, qui soit aussi conviviale et enseigne mieux la programmation - sans bizarreries.

À mon avis, une grande partie du travail consiste à créer l'interface pour éditer les feuilles d'événements. Ceci explique cela. Parfois, une image vaut plus que des mots. Un addon - plus qu'une image

J'adore votre travail à ce sujet. Seriez-vous prêt à le rendre disponible dans un dépôt pendant que vous y travaillez (si vous le faites) ? J'aimerais y jeter un coup d'œil, le fouiller et jouer.

@mhilbrunner Bien sûr que vous le pouvez - et

Je suis en train d'intégrer le gui dans l'éditeur de godot en tant que plugin gdscript - ce n'est pas encore assez interactif :)

Je le publierai sur github lorsque l'interface graphique de base fonctionnera de manière interactive pour communiquer les idées de conception :) Aujourd'hui, j'ai chargé l'interface graphique de la feuille d'événement sous forme d'onglet - en m'inspirant du plugin sketchfab :

Peut-être que la feuille d'événement devrait être accessible d'ailleurs?

Publiera plus de captures d'écran de mise à jour et éventuellement un lien vers le github - mis à jour mon premier message avec des notes de planification et des liens vers des démos en ligne d'autres moteurs de feuilles d'événements

• Connaissez-vous un moyen simple d'afficher les icônes de nœud godot à l'intérieur du nœud d'étiquette de texte enrichi via bbcode ?
  Dans ma maquette précédente, j'ai utilisé les balises [img] - mais c'est une approche assez médiocre car cela m'obligera à télécharger toutes les icônes de nœud utilisées par l'éditeur godot et à les stocker avec l'addon

• J'ai également du mal à comprendre comment enregistrer une nouvelle ressource de type de script de feuille d'événement via l'addon api

@blurymind très bien ! Maintenant, c'est plus lisible. Nous devons réfléchir à la manière dont la liste d'actions s'affichera pour l'utilisateur.

Une chose que j'aimais dans l'ancien Construct Classic était la possibilité de modifier les valeurs de la feuille d'événement sans ouvrir l'action ou la condition, mais double-cliquez sur la valeur pour la modifier :

Si quelqu'un veut ajouter ceci (par lui-même via un plugin, un addon, un gdnative, etc.), alors, pas de mal, pas de faute. Sinon, je suis d'accord que le script visuel peut être amélioré, ce qui rend cela superflu. GDscript est simple, vraiment simple. Et probablement plus utile pour enseigner aux enfants que certains scripts visuels janky (même basés sur des plans) Si quelqu'un a besoin de construire, alors je dis, encouragez-le à continuer à utiliser la construction. Godot n'a pas besoin d'émuler tous les autres systèmes dans son noyau. Laissez le logiciel rester concentré et ne devenez pas un " touche-à-tout, maître de rien " en raison d'une focalisation diffuse.

@spyres dépend de la volonté de @reduz et de l'équipe godot de cibler les élèves plus jeunes dans les écoles.
Personnellement, je pense que nous pouvons remplacer complètement la construction dans les écoles par godot.
Le système de plan directeur actuel ne fonctionnera pas pour cela. C'est plus compliqué à utiliser que gdscript et, comme mentionné précédemment, ce n'est pas le meilleur moyen d'initier quelqu'un aux paradigmes de programmation, car il a son propre ensemble de règles.
Le but n'est pas de remplacer gdscript ou le système de plan directeur actuel, mais au contraire de donner aux enfants un moyen d'apprendre gdscript en les aidant. C'est ainsi que les jeux yoyo utilisent leur système de script visuel DnD pour présenter progressivement Gml aux non-programmeurs.
Je ne pense pas qu'il y ait de mal à avoir un système de script visuel plus accessible aux non-programmeurs et mieux conçu pour les faire passer à gdscript. Pourquoi tu?

J'essaie de le faire comme un addon, mais je rencontre quelques limitations en termes de manque de documentation ou d'API. Je souhaite enregistrer un nouveau type de ressource de script et je souhaite injecter mon éditeur de feuille d'événement dans l'onglet scripts - pour éditer les fichiers myscript.es.
Est-ce que quelqu'un sait comment cela peut être fait ou a un exemple de cela?
Avoir son propre onglet est moche imo, et ne suit pas le design original de l'éditeur - je veux que mon module complémentaire soit intégré d'une manière transparente avec le design de godot.

@DrZanuff Godot a un moyen de répertorier toutes les méthodes qui existent dans un nœud, mais je ne sais pas encore comment les filtrer en actions ou conditions. Il faudrait peut-être trouver une façon plus centrée sur Godot de le faire. Je l'explore toujours et je suis ouvert aux idées :)

Dans tous les cas, nous pourrions ne jamais avoir un addon entièrement fonctionnel. C'est juste pour explorer l'idée de comment cela pourrait être fait de manière centrée sur godot ici - du moins pour l'instant

L'hypothèse selon laquelle le script visuel ne peut pas (ou ne sera pas) être grandement amélioré ou que les jeunes enfants ne pourront pas l'utiliser, ou devenir gdscript à partir de la construction) semble un peu stupide vraiment. Surtout que le script visuel est assez nouveau.

Si la solution pour les très jeunes enfants _ (que je n'ai jamais vu les développeurs mentionner comme un élément démographique principal pour Godot) _ est aussi grande, laissez-les utiliser la construction ou une autre solution ciblée pour les enfants, puis passez à une programmation réelle via GDscript lorsque ils sont prêts.

Si vous souhaitez le créer en tant que module complémentaire et prendre en charge ce module complémentaire, alors intimidez pour vous. Mais comme quelque chose de duplicatif, gonflant le noyau et (probablement) perdant un temps de développement officiel limité avec un support futur, une intégration, etc., _ non merci. _

@spyres êtes-vous vous-même un développeur ? Ou un professeur ? Avez-vous réellement utilisé le script visuel de godot sur l'un de vos propres projets ? Si oui, comment peut-il être amélioré pour devenir un meilleur outil pour enseigner aux gens la programmation ?

@blurymind Je pense que votre idée est bonne. De plus, vous semblez déjà en avoir une vision assez solide.

Mais, je pense que "remplacer la construction dans les écoles par Godot" n'est pas une raison valable pour avoir cette fonctionnalité. Je ne me souviens pas que Godot ait eu la vision de remplacer d'autres moteurs comme Unity, Unreal, etc. Godot n'essaie pas d'écraser d'autres outils. Si la raison est d'augmenter la productivité, je suis d'accord avec cela.

Je suis également d'accord avec @spyres que Godot n'a pas à cibler le segment de l'éducation. Si Godot ne convient pas pour être un outil d'enseignement de la programmation (pas même du développement de jeux), qu'il en soit ainsi. Cela n'a jamais voulu être en premier lieu. Mais si quelqu'un peut d'une manière ou d'une autre utiliser/transformer godot pour en faire un outil d'enseignement de la programmation, cela ne me pose aucun problème.

Pourtant, je pense que cette feuille d'événement est une idée intéressante à voir.

@blurymind Je pense que vous oubliez que godot n'est pas un outil pédagogique, godot est un moteur de jeu. Si vous souhaitez implémenter quelque chose comme construct en tant que module externe, cela ne dépend que de vous, mais n'essayez pas de transformer quelque chose destiné au développement de jeux en un jouet pour enfants. Pourquoi essayer de transformer godot en construction si ce que vous voulez vraiment, c'est construire ? pourquoi ne pas l'utiliser à la place de godot ?

@zaniar @ni-code Vous avez raison. Il est vrai que je suis personnellement plus intéressé par la création d'un outil de script visuel plus efficace et plus clair que notre approche actuelle du plan directeur - un outil qui est juste plus agréable à utiliser. Je n'aime pas Construct2- donc ce n'est pas vrai que je veux en faire Godot. Comme je l'ai mentionné plus tôt, je trouve que sa conception et ses bizarreries sont plutôt mauvaises. C'est pourquoi c'est si frustrant pour moi que les seuls endroits où trouver des feuilles d'événements ne soient pas aussi bons que Godot.

Je pense honnêtement que même si les plans sont améliorés, ils ne seront jamais aussi clairs et rapides à construire qu'une feuille d'événement - à cet égard, les feuilles d'événement sont un excellent outil pour un prototypage rapide qui est souvent sous-estimé. Mais les titres créés par Clickteam fusion devraient parler d'eux-mêmes. Certains peuvent le voir comme un jouet - mais pour moi, c'est juste amusant de construire une logique de jeu de cette façon :)

En tant que personne qui a utilisé à la fois construct2 et Fusion, j'adore l'approche de la feuille d'événement et je vois dans l'API de godot un beau candidat pour un système de feuille d'événement - sans les défauts des moteurs qui l'inspirent.
La conception d'imbrication de nœuds de Godot fonctionnera très bien avec cela, combinée à la clarté de gdscript pour les expressions.
Je ne m'attends pas à ce qu'il soit implémenté dans godot, mais je continuerai à partager les progrès du plugin ici, dans l'espoir d'obtenir des commentaires utiles et de l'aide avec l'API. Certains des développeurs ici ont utilisé Construct2 et connaissent très bien Godot, donc de bonnes idées pourraient surgir de la discussion.

J'ai en fait une idée pour le système de feuille d'événement qui nous donnera un léger avantage par rapport à la simple utilisation de gdscript - même pour les utilisateurs expérimentés. Il est censé être utilisé avec gdscript, pas à la place de gdscript - n'oubliez pas que

J'attends avec impatience les inévitables améliorations de Visual Scripting qui (parce qu'elles sont entièrement intégrées/pris en charge) seront plus utiles (et probablement plus populaires) que n'importe quel plugin janky "construct-lite" centré sur les enfants.

@spyres Veuillez garder le ton civil. Vous n'êtes pas obligé de dire aux autres leurs hypothèses sont « muets » ou que le potentiel plug - in qu'ils investissent (gratuit!) Travail va tout simplement être une chose « kiddie centrée construction-lite Janky ».

Bien sûr, les gens sont libres de passer leur temps (je pense que cela pourrait être inutile en fin de compte) comme ils le souhaitent, même si cela n'est pas propice à la conception de base de Godot.

Dans l'intérêt de la civilité (bien que "centrée sur les enfants" soit _exactement_ ce que l'OP demande ici !), allons-y avec la description des feuilles de conception de style de construction comme maladroites , non axées sur le noyau démographique de Godot, quelque chose qui, espérons-le, ne fera pas perdre de temps aux développeurs principaux , etc.

Pourquoi s'embêter à recréer la construction dans Godot _lorsque le moteur de construction réel fournit déjà cette fonctionnalité de manière robuste ?_

Le groupe démographique des enfants de 7 ans réclame-t-il vraiment ce genre de duplication ?

@mhilbrunner répondre à son post, c'est comme répondre à un troll de 7 ans :D
Il a effacé la plupart de mes messages ici - tous les avis sont en fait les siens.
Il semble inutile de discuter avec lui, car il ne répond pas réellement aux questions - je lui ai posé quelques questions valables qui pourraient m'aider à obtenir des commentaires. Ce que j'ai en retour est plus ou moins le même

Github a-t-il un moyen d'empêcher les gens de publier s'ils sont abusifs ?

Wow, alors que j'ai certainement remis en question certaines idées, je n'ai _jamais_ réellement appelé quelqu'un. _That_ est assez abusif je dirais.

Que fournirait la fonctionnalité de duplication de construct dans Godot qui n'est pas déjà bien fournie par euh... Construct.

Y a-t-il un avantage légitime à dupliquer l'ensemble de fonctionnalités de Construct (probablement d'une manière moindre) dans godot simplement pour plaire aux enfants de 7 ans ?

Pourquoi n'utiliseriez-vous pas simplement construct ? Leur configuration (que certains semblent vouloir dupliquer) fait-elle vraiment défaut ?

Y a-t-il une raison légitime de supposer que les enfants ne pourraient pas passer à gdscript ou aux scripts visuels une fois qu'ils ont dépassé la construction ?

@spyres vous utilisez des termes généralement offensants pour décrire les personnes qui utilisent des feuilles d'événements et des feuilles d'événements.
Ce ne sont pas des « kiddies » et le système n'est pas « janky ». Ayez un peu de respect pour ces communautés pour l'amour de Dieu. D'où vient cette attitude élitiste ?

Construct2 a beaucoup de programmeurs javascript très expérimentés - ce qui aurait dû être évident pour vous si vous avez eu la peine de lire ce que j'écris et de suivre les liens que j'ai fournis. Certains des modules complémentaires qu'ils ont créés l'intègrent à des moteurs 3D tels que babylon et three.js, même si oui, les développeurs expérimentés aiment également utiliser des feuilles d'événements et créer des jeux avec cela.

Clickteam fusion a fait que les jeux sont beaucoup plus nombreux que les jeux de Godot sur Steam, Kickstarter et même les magasins d'applications en termes de nombre et de revenus qu'ils génèrent. Il s'agit d'un moteur entièrement basé sur des feuilles d'événements, utilisé par les 10-80 ans. C'est un mélange de tous les âges. Certains des utilisateurs sont des cinéastes, d'autres sont des artistes - des personnes ayant un emploi qui dépensent de l'argent en licences, des exportateurs, etc. Heck, j'ai gagné plus d'argent en vendant des trucs sur leur magasin d'actifs que tout autre chose à voir avec godot jusqu'à présent.
Voici quelques exemples - Alonso Martin, cinéaste décide de faire un jeu :
https://www.kickstarter.com/projects/alonsomartin/heart-forth-alicia
Une bande de 7 ans fait un jeu
https://www.kickstarter.com/projects/galaxytrail/freedom-planet-high-speed-platform-game

regarde ici
http://indiegames.clickteam.com/
Ces enfants de sept ans savent comment faire des jeux et gagner de l'argent, hein
https://thinkgaming.com/app-sales-data/publisher/3107/scott-cawthon/

Mon point de vue de vendre cela comme un meilleur outil pour enseigner la programmation ne devrait pas être une raison pour l'étiqueter comme ça. Avec un plus grand nombre d'utilisateurs, vous vous retrouvez avec plus de personnes qui créent des jeux avec le moteur. Cela ne devrait-il pas être évident ? Pourquoi ce n'est pas évident :D

Combien de fois avez-vous besoin que je répète que je ne demande pas de copie carbone de Construct2 ? C'est comme si vous répétiez le même message sans rien lire. Ce que je propose, c'est une feuille d'événement centrée sur Godot, pas une copie de celle de construct2

Maintenant, comment la lecture de vos articles sur le système « janky » va-t-elle me motiver à créer un module complémentaire gratuit pour godot ? Réfléchis un peu à ça

Ouah ! Des poteaux de but qui changent malgré...

Permettez-moi de clarifier.

Construct est assez efficace dans ce qu'il fait. Ainsi, le besoin (?!) de greffer/dupliquer son ensemble de fonctionnalités (en tout ou en partie) dans un moteur entièrement différent (sans avantage perceptible) m'échappe.

Les questions concernant les avantages réels restent les mêmes, bien que certains puissent (inexplicablement) les trouver « offensantes ».

La suggestion qu'un module complémentaire greffé sur un moteur complètement différent sera-t-elle en quelque sorte meilleure que d'utiliser la construction ? De cela, avoir quelque chose d'incorporé (même via un module complémentaire) est quelque chose que nous nous attendrions à ce que beaucoup de gens utilisent par rapport à la solution robuste (c'est-à-dire la construction) ? Je doute que.

Mais bon, pourquoi s'arrêter là ? D'excellents outils (au-delà de la construction) existent pour enseigner la programmation aux enfants (par exemple Scratch , Styncl , code.org etc.) Pourquoi ne pas les incorporer également dans Godot !

Ou peut-être pas... ;-)

Y a-t-il quelqu'un qui a utilisé le script visuel de Godot et il semble si bien qu'il n'utilise que le script visuel de Godot ?

@Zonacas Je ne pense pas que le script visuel de Godot soit encore assez mature pour cela, mais je peux me tromper. Gardez à l'esprit que VS n'est sorti que depuis environ deux mois à ce stade. :)

@Zonacas essayez de regarder la chaîne VS sur le serveur

Salut à tous, j'ai une mise à jour sur l'avancement de mon module complémentaire de preuve de concept.

Voici un nouveau gif pour vous :

Quelques informations sur ce qu'il fait - Fondamentalement, la feuille d'événement est composée de cellules. Une cellule peut être soit pour des conditions (getters/expressions) soit pour des actions (setters qui peuvent être alimentés avec des getters/expressions).
Du côté de l'interface graphique, la cellule d'événement est créée via un nœud richtextlabel et un bbcode généré à partir de gdscript. Lorsque vous double-cliquez dessus, le richtextlabel se transforme en un nœud de boîte d'édition contenant l'expression gdscript réelle.

Ainsi, une cellule de feuille d'événement a 2 modes :

• mode d'édition - nœud textEdit qui peut être saisi avec gdscript.
  La seule différence est que l'utilisateur n'a pas besoin de taper If/else/while - c'est sensible au contexte du conteneur parent comme le montre la capture d'écran. Chaque ligne est une nouvelle condition, donc si l'utilisateur n'a pas commencé la ligne avec "ou" ou autre chose, l'analyseur sait automatiquement qu'une nouvelle ligne a un prétexte "et"

Lorsque vous cliquez loin, bascule en mode d'affichage.

• mode d'affichage - étiquette de texte enrichi - Lors du passage en mode d'affichage, un bbCode est analysé à partir du gdscript qui est en mode édition et présenté via une étiquette de texte enrichi interactive. En plus d'être interactif et facile à modifier, le but est de présenter le code gdscript de manière plus claire. Cela signifie afficher uniquement le nom et l'icône du nœud (pas le chemin entier) et se débarrasser de certains mots, lorsqu'ils sont évidents (comme get_ et set_). Étant donné que chaque partie cliquable est en fait une balise d'URL, lors du survol d'un nom de nœud par exemple, l'utilisateur peut obtenir des informations, telles que le chemin complet du nœud.

À propos du menu Ajouter une nouvelle condition/Action :
C'est ce qui crée une nouvelle ligne de code gdscript pour une condition ou une action. Ce qui est génial, c'est qu'il vous permet de parcourir facilement tous les nœuds d'une scène et leurs méthodes - cela fonctionne en quelque sorte à l'inverse de la façon dont l'autocomplétion fonctionne dans l'éditeur de gdscript. Il montre tous les nœuds et toutes leurs méthodes setter, getter ou les deux. Vous pouvez ensuite affiner ce que vous voulez via un filtre.
Si callend à partir d'une cellule de condition, ce menu affiche uniquement les getters, s'il est appelé à partir d'une cellule d'actions, il affiche à la fois les méthodes setter et getter.

Que faire ensuite pour que cela fonctionne :

• J'ai besoin de trouver un moyen de faire glisser des cellules - pour pouvoir changer facilement l'ordre des événements.
• Copier et coller également en mode aperçu.
• Ensuite, je dois créer un éditeur d'expressions qui apparaît lorsqu'un type spécifique d'URL de cellule en mode aperçu est cliqué
• comprendre comment traiter les éléments d'espace réservé. J'ai pensé à mettre des commentaires, mais malheureusement, godot ne prend pas en charge les commentaires en ligne : https://github.com/godotengine/godot/pull/18258 donc je devrai peut-être revenir à la planche à dessin sur celui-là

L'idée évolue vers quelque chose de plus qu'un simple outil d'enseignement. Je pense que je peux offrir des fonctionnalités utiles qui permettent de gagner du temps aux personnes qui connaissent et aiment déjà gdscript, mais il me faudra un peu plus de temps pour développer cela à un point où je pourrai vous présenter comment.

Merci à tous pour le soutien

Une bonne idée de plugin. Mais maintenir officiellement deux systèmes de script visuel serait pénible et pour peu de gain.

XKCD : normes

Je ne vois pas pourquoi cela ne peut pas être un véritable addon/plugin plutôt qu'une simple preuve de concept. Tout ne doit pas être fourni par défaut avec le moteur. Je veux dire, n'est-ce pas la raison pour laquelle GDNative a été développé ?

@Megalomaniak C'est vrai et croyez-moi quand je dis que si j'avais suffisamment de connaissances sur l'api de godot, je le réécrirais en tant qu'addon gdnative. Mais même en allant aussi loin, j'avais eu du mal et il me manque en fait certains éléments clés pour en faire un outil réellement utilisable. J'ai soulevé les questions ici, mais jusqu'à présent, personne ne m'a vraiment donné de réponses ou donné des exemples :

• Comment enregistrer un nouveau type de ressource de script dans l'éditeur godot et permettre à l'utilisateur de l'attacher à n'importe quel nœud ? Pour le moment, l'addon fonctionne à partir de la racine de la scène et de son hacky.
• Comment pouvons-nous ensuite faire en sorte que godot ouvre l'interface graphique de ma feuille d'événement - aussi intégrée que le système de plan directeur actuel
• Comment pouvons-nous faire en sorte que le nœud editText agisse comme l'éditeur gdscript de godot - activer la coloration de la syntaxe et la saisie semi-automatique. De plus, comment lui donner un contexte personnalisé ?

Quelqu'un avec une connaissance très faible de l'API peut le faire. Ce genre de choses n'est pas dans la documentation - il n'y a pas d'exemples existants non plus.
J'ai les idées de conception, mais pas encore l'image complète pour la réaliser

Jusqu'à présent, je peux continuer à pousser les concepts de conception et en savoir plus sur l'API, mais je ne peux pas garantir fermement que cela peut être transformé en un module complémentaire qui fonctionne réellement pleinement. Les gens semblent l'aimer beaucoup jusqu'à présent

Pour des trucs comme ça, je préfère honorer les souhaits des développeurs :

https://godot.readthedocs.io/en/3.0/about/faq.html

J'ai une idée géniale qui rendra Godot meilleur.

Votre idée sera très certainement ignorée.

Faisons ça parce que ça rendra Godot meilleur
Faisons-le dans Godot car un autre moteur de jeu le fait
Supprimons ceci parce que je pense que ce n'est pas nécessaire
Éliminons l'encombrement et les ballonnements et rendons Godot plus joli
Ajoutons un workflow alternatif pour les personnes qui le préfèrent

@spyres Je suis en train de faire cela et je recherche l'aide d'autres utilisateurs de godot sur l'API sur des choses que je ne trouve pas dans la documentation - j'essaie de contribuer à godot.
Que fais-tu ici?

Vous êtes la seule personne à tout noter et à répéter les mêmes choses dans chaque message. Cela ressemble beaucoup à ce que fait un troll, n'est-ce pas ? Vous êtes en train de suivre la conversation loin de discuter des idées de conception

@blurymind La "contribution" d'un homme est la distraction d'un autre homme (ou moteur). Désolé que le concept d'opinions divergentes (même celles des développeurs qu'ils jugeaient suffisamment importantes pour être publiées dans le cadre des documents officiels) vous semble si répréhensible.

Bonne chance avec votre module complémentaire. :sourire:

@spyres mais avez-vous réellement fait quelque chose ? Avez-vous déjà créé un addon pour godot ? Utilisez-vous godot ?

Pourquoi es-tu ici? Vous n'essayez pas de contribuer à la discussion

@blurymind Wow, des opinions différentes vous dérangent vraiment à ce point ? Quelle tristesse pour toi.

@spyres, tout le monde ici peut voir votre opinion - vous spammez le fil avec. Chaque pouce vers le bas ici est à vous. Ce n'est pas l'opinion, c'est le spam. Au moins pinailler sur le design et des choses spécifiques? Je t'ai posé quelques questions plus tôt - tu n'as jamais rien répondu

Pour être clair, je soutiens totalement tous ceux qui utilisent leur temps, mais ils souhaitent créer quelque chose comme celui-ci en tant qu'add-on qui peut être paisiblement ignoré par des gens comme moi qui n'y trouvent pas de valeur.

En tant que workflow alternatif réellement intégré dans godot core ? Euh, s'il vous plaît, non. Je suis de l'avis des développeurs sur ce genre de choses.

@spyres oui, tu l'as déjà dit. Faites défiler vers le haut et lisez-le 5 fois de plus. Il y a l'un de vous .. mais tant de fois

@blurymind Et cela semble vous déranger d'une manière ou d'une autre? Wow, des opinions alternatives et autres.

Je suppose que _vous_ n'avez rien répété du tout, n'est-ce pas ? (Qui êtes-vous, pourquoi êtes-vous ici, justifiez-vous dagnabbit !). :sourire:

Je suppose que ce peu de commentaires sur la documentation officielle écrits par les développeurs ont causé un peu d'indigestion, hein?

ouais, ça fait chaud au coeur

@blurymind Merci, câlins tout autour alors!

J'ai vraiment avec vous la meilleure des chances pour mettre en œuvre cela via gdnative, à quel point ce sera là pour ceux (très peu je suppose) qui voudront quelque chose d'officiel comme ça.

Cependant, si vous ne pouvez pas obtenir les informations, l'aide dont vous avez besoin pour y parvenir, il est peut-être temps de réévaluer à quel point la disponibilité de cette langue alternative signifie vraiment pour vous.

@spyres Veuillez arrêter de spammer. Je n'ai pas besoin de ces e-mails et notifications. Vous avez exprimé votre opinion, ce qui est bien, mais vous n'avez pas besoin de la répéter sans cesse.

@mhilbrunner Si mes opinions divergentes vous

@spyres J'ai noté dans des articles précédents que cet addon vise à utiliser gdscript, et non à servir de langage alternatif. Et oui, personne ne modère ce tracker, semble-t-il

Eh bien, plus tôt vous aurez terminé, plus nous serons tous heureux,

Dans les mots d'un homme sage, "Ne vous inquiétez pas, soyez heureux". :sourire:

Ou « C'est du plaisir et des jeux jusqu'à ce que quelqu'un s'éclate ! » (euh, attendez, je ne pense pas que c'était la citation que je cherchais...)

WOW. Je vais être honnête, c'est incroyable !

Quand j'ai lu votre message pour la première fois, j'étais d'accord mais j'étais un peu inquiet qu'il y ait une énorme dispute, mais quand vous êtes venu et que vous avez montré que vous n'aviez pas tout aboyé et que vous n'aviez pas mordu et que vous avez commencé à développer un addon, j'ai été impressionné.

J'ADORE l'interaction avec GDScript car c'était une fonctionnalité importante dans le studio de gamemaker (interchangeabilité des scripts visuels et appropriés) qui n'était pas vraiment réalisable avec un système basé sur des nœuds.

Une fois que cela sera terminé, cela aidera une tonne de personnes

Je suis un utilisateur de Construct depuis 6 ans et je peux dire que c'est le meilleur moyen d'aborder le script visuel le plus rapide et le plus simple.

Excellente idée!

Cela va être très utile. J'ai hâte qu'il sorte !

Idée brillante, collaborez avec SnailOn.

1. Il est génie.
2. Il utilise Godot vers 3 ans.
3. Il utilise les moteurs Clickteam depuis TGF
4. candidat idéal.

@boruok Je suis fan de la chaîne yt de snailon depuis les premiers jours. 😄 Ses tutos m'ont aidé à apprendre la fusion il y a longtemps. A-t-il un compte github ? J'adorerais prendre son esprit sur certaines choses.

D'ailleurs, je dois admettre que je penche vers un menu de clic plus Fusion que ce que Construct2 utilise pour décider comment remplir les cellules. Le menu d'aide présenté dans la mise à jour 1 est définitivement influencé par la conception de Clickteam. Dans cet addon, vous verrez que je ne crée pas une copie conforme d'un moteur, mais plutôt que j'emprunte des idées qui fonctionneraient mieux pour une approche godotesque d'une fiche d'événement. Il y a aussi un peu de Game maker - dans la façon dont le script visuel peut passer de manière transparente au script réel - quelque chose que les utilisateurs plus avancés pourraient apprécier

Merci à tous d'avoir suivi les progrès de cet addon. La première réaction est extrêmement positive
Cela me motive grandement à continuer à pousser l'idée plus loin, tout en essayant de la garder simple et élégante.

Sans commentaires en ligne, il est difficile de continuer à basculer facilement entre gdscript et visualscript, mais j'ai quelques idées sur la façon de surmonter cela et d'expérimenter - donc je travaille sur cet atm.
J'ai besoin d'un moyen de définir dans gdscript un espace réservé vide où une expression est attendue.
Étant donné que les expressions retourneront un type de valeur, j'ai pensé à utiliser simplement la méthode de conversion de valeur dans godot pour marquer l'espace réservé :
float() ## this will turn into a bbcode item that expects an expression resulting in a float
Mais cela pourrait être quelque peu moche car cela générera de nombreuses méthodes de conversion de type variable inutiles dans le gdscript généré final

Si godot pouvait faire des commentaires en ligne, je serais en mesure de les analyser en fonction de la méthode qui crée le bbcode à partir du gdscript à la place. Cela me permettrait de l'alimenter avec quelques informations supplémentaires

La meilleure approche est vraiment de rendre ma foutue méthode d'analyseur gdscript vers bbcode plus intelligente - c'est ce que j'essaie de faire maintenant

@blurymind je ne sais pas pour git-account. btw, il a ouvert à nouveau des vidéos. Je lui ai envoyé quelques mp via, youtube et facebook. Espérons qu'il apparaisse ici.

@blurymind, je soutiens cela à 100 % !
(Désolé d'avance pour l'anglais)

Si nous examinons correctement la page à propos au-delà de ce qui peut être utilisé pour troller les gens, voici ce que nous pouvons voir :

Les développeurs sont intéressés par (par exemple) :

Votre expérience d'utilisation du logiciel et les problèmes que vous rencontrez (nous nous soucions beaucoup plus de cela que des idées sur la façon de l'améliorer).
Les fonctionnalités que vous aimeriez voir implémentées car vous en avez besoin pour votre projet.
Les concepts qui étaient difficiles à comprendre pour apprendre le logiciel.
Les parties de votre flux de travail que vous aimeriez voir optimisées.
Des parties où vous avez manqué des tutoriels clairs ou où la documentation n'était pas à la hauteur.

En gardant cela à l'esprit :

• Le script visuel actuel ne peut être utilisé que si vous savez coder pour de vrai. Et devient vraiment plus désordonné que le code dur. Qui est-ce aider? Et les plans ne sont pas très utiles non plus, à moins que vous n'ayez une formation technique très spécifique.

• Les feuilles d'événements de niveau supérieur fonctionnent bien. Comme on le voit avec le succès de toutes les applications mentionnées ci-dessus. S'ils sont bien faits, ils sont vraiment plus simples à saisir et à utiliser pour les non-codeurs.

• Pourquoi Godot s'adresserait-il aux non-codeurs ?
  Je vois de nombreuses utilisations pour cela pour de nombreuses personnes travaillant sur des projets professionnels.
  Dans de nombreux projets, petits, moyens et grands, une partie de l'équipe fera le codage, et une autre s'occupera de ses propres affaires. Musique & sons, visuels/animations/SFX/UI, game design, scénaristes, etc...
  Parfois, ce sont même des équipes d'un seul homme ou des personnes extérieures à l'industrie comme ce cinéaste qui font un jeu assez réussi.
  Certaines personnes veulent même faire de la programmation mais pas du codage pour de nombreuses raisons différentes.
  Par exemple, des problèmes comme la dislexie font du code un cauchemar, mais la programmation serait toujours possible via une approche plus visuelle comme les feuilles d'événements.
  La plupart du temps, ces personnes ont autre chose à faire que de coder pendant qu'elles produisent des choses nécessaires au jeu.
  Une feuille d'événement permettrait à un graphiste, un concepteur de son ou de jeu de tester ou de mettre en œuvre son travail très facilement sans plonger dans le code brut.
  Cela permettrait également un prototypage ultra rapide, pour tester sa preuve de concept. Jetez un tas d'images de stock, cliquez ici et là un peu et vous pouvez vérifier si votre idée est amusante en ce moment. Même les bons codeurs et les grands noms/studios utilisent les éléments les plus simples possibles pour itérer au début d'un projet.
  Plus de commentaires et de discussions sur tout cela ici , et je suis tout à fait d'accord avec le PO.
  (Github n'est pas le meilleur endroit pour faire des commentaires à ce sujet, les gens qui viennent ici sont généralement plongés dans le codage et ne voient pas le besoin, bien qu'ils soient en fait une minorité.)

• Conclusion : Donner aux gens des outils simples mais efficaces pour interagir avec Godot serait une aubaine à plusieurs niveaux pour un grand nombre d'adultes sérieux travaillant sur des projets professionnels.
  (Pas seulement les enfants et les écoles, même si cela les aiderait aussi.)

• Soit dit en passant, il existe un autre outil appelé GDevelop qui utilise des feuilles d'événements si vous voulez regarder plus d'exemples. L'interface précédente (version 4) est plutôt sympa, l'actuelle (v 5) est un peu mauvaise cependant, l'application a de bonnes idées, mais quelques inconvénients, et sa direction est encore un peu floue mais elle peut vous donner quelques idées, ou au moins un autre point de comparaison.

Félicitations pour le travail déjà accompli, pour rester positif et motivé malgré certaines réactions, et pour avoir cru en votre idée. Je confirme moi aussi que cela serait en effet d'une utilité cruciale et résoudrait des problèmes majeurs pour moi.

@TheGoklayeh Merci pour les gentils mots d'encouragement. Je sais exactement ce que vous voulez dire. Comme indiqué précédemment ici, les jeux indie Clickteam fusionnés à succès dépassent largement le nombre de jeux indés à succès créés par Godot.
Jeux en cours de publication, nombre de ventes sur les titres steam et mobiles et kickstarter atteignant leur objectif.
Cela devrait être une preuve suffisante que les artistes et designers professionnels l'utilisent - pas seulement des "enfants"

En ce qui concerne le nouvel IDE de Gdevelop, je pense qu'il est génial, mais que ses fonctionnalités ne sont pas complètes. Une décision intelligente prise par le développeur principal a été de porter l'idée en javascript, ce qui la rend très accessible aux développeurs non C++ pour y contribuer. J'y ai en fait contribué avec de petites corrections jusqu'à présent, juste pour jouer et apprendre. Ce week-end, je vais essayer de faire quelques étapes pour y intégrer piskel 😃 - si tout va bien, il pourrait s'agir d'un éditeur de pixels intégré.
Le développeur principal a récemment fusionné une contribution d'un autre développeur en ajoutant le support des dragonbones prêts à l'emploi. Si vous le souhaitez, essayez la dernière version de github, pas la démo en ligne. Il a les marchandises
https://github.com/4ian/GD/releases

Je progresse également lentement sur cet addon. Certaines choses doivent être refactorisées avant que je puisse aller plus loin.

Ce serait peut-être une bonne idée d'obtenir tous les utilisateurs de fusion et les utilisateurs de construct2 qui utilisent également godot ici. Montrez-leur ce fil et demandez-leur des commentaires sur la conception.
Snailon ne m'a pas encore contacté - mais oui - c'est un programmeur très expérimenté en matière de fiches d'événements. Je ne savais pas qu'il était aussi un utilisateur de godot.

Cela a l'air incroyable ! Merci d'avoir développé/poussé ceci, blurymind.
J'ai fait du gamedev pendant environ 23 ans, j'ai pratiquement tout essayé - tous les outils/moteurs de gamedev populaires, les langages de programme, etc. :)
L'avoir dans une approche énumérée de haut en bas entre les conditions et les actions le rend plus ordonné et concis que tout autre système. Comme je suis plus orienté visuellement, le fait d'avoir une structure rigide verticale/horizontale me permet de parcourir le programme/les événements à l'aise.
D'autres scripts visuels qui nécessitent des connexions spaghetti sont très désordonnés et distrayants - les détails visuels sont dispersés dans une esthétique bruyante qui brise la concentration des personnes visuelles (les mêmes personnes que les scripts visuels sont censées viser).
Les feuilles d'événement sont les meilleures pour moi. J'ai passé 23 ans à tout utiliser - blitzbasic, gamesfactory, unity, c++, javascript, etc., et j'en suis certain - j'adore les feuilles d'événements !!

Je voulais juste intervenir, l'édition de Blueprints / style de nœud est extrêmement difficile à organiser / éviter le "code Spaghetti". À tous ceux qui pensent que c'est la même chose que les événements de style Clickteam/Construct/GDevelop, je suis désolé mais ils sont radicalement différents et les feuilles d'événements sont objectivement meilleures (les jeux sont de nature SI/ALORS basée sur des règles, et vous pouvez beaucoup plus facilement faire la transition des événements au code, mais les événements en général sont de toute façon plus rapides que le codage de la logique du jeu).

Je suis sûr qu'il y a des moments où l'édition basée sur les nœuds est pratique, mais l'édition basée sur les événements deviendrait rapidement l'option préférée si elle était incluse dans le script visuel de base de Godot.

@bigelod @prominentdetail merci d'avoir fourni plus de commentaires sur ce qui rend les feuilles d'événement si bonnes - pas seulement pour ceux qui apprennent à coder - mais aussi pour les programmeurs plus expérimentés.

Je pense que vous avez tout à fait raison. Tout comme @prominentdetail, j'ai commencé avec des feuilles d'événements en fusion, puis je suis passé par de nombreux moteurs différents. Python appris, puis gdscript, puis javascript. Pourtant, les feuilles d'événements me font reculer en tant que moyen préféré pour prototyper des jeux - c'est cette clarté supplémentaire qu'elles ajoutent à la logique du jeu

Je remarque également des tendances dans l'atm de la communauté des moteurs de jeux de feuilles d'événements, dont godot pourrait vraiment profiter pour élargir sa base d'utilisateurs :

• La communauté des développeurs qui utilisent des feuilles d'événements a soif d'un moteur 3D qui utilise des feuilles d'événements. La communauté clickteam fusion a essayé d'intégrer cela en tant qu'addon (firefly) et Construct (de nombreux plugins essayés) - mais ces addons ne fournissaient aucune capacité d'édition de scène 3D - ils étaient des hacks pour faire fonctionner les feuilles d'événements avec les moteurs 3D - mis sur 2D éditeur de moteur non conçu pour les jeux 3D. Vous ne pouvez construire qu'une scène 3D avec une logique d'événement, ce qui rend difficile la mise en place d'objets, de matériaux, etc.
• Les programmeurs apprenants et expérimentés aiment toujours les feuilles d'événement et les utilisent pour le prototypage - pas seulement pour l'enseignement.
• De nombreuses équipes indépendantes ont utilisé avec succès (et utilisent toujours) des feuilles d'événements pour créer des titres à succès - kicktarter, steam et autres plates-formes - mais très peu sont des projets 3D à cause du premier point

Maintenant, il est difficile de faire fonctionner cela en tant qu'addon dans godot, à cause de certaines choses dans le moteur auxquelles je ne sais pas comment accéder. L'implémentation actuelle que j'ai est rapide et désordonnée et ne fait rien d'autre que démontrer des parties de la façon dont l'interface graphique peut être effectuée. Je vais essayer de le rendre plus présentable et le posterai ici

En passant, j'ai réussi à obtenir Piskel groupé et intégré à Gdevelop. Cela m'a occupé ces dernières semaines. Tu peux essayer si tu veux :)
J'ai également regardé comment les feuilles d'événements sont faites dans gdevelop

@blurymind Ok, disons simplement que j'ai essayé d'ignorer ce message ici, car je n'aimais pas l'idée de deux scripts visuels.

Mais cela a finalement suffi, je pense qu'il est enfin temps d'entamer une discussion. Je pense que vous devez avoir utilisé la documentation pour créer l'interface graphique. La maquette est un très bon travail, je voulais demander s'il existe un dépôt, je pourrais peut-être regarder un peu le code. Probablement pourrait être en mesure de faire quelque chose pour le rendre plus semblable à l'EventSystem et plus fonctionnel.

J'avais l'intention de travailler sur le système Visual Scripting actuel. Et quand je suis tombé sur GDevelop et que je l'ai aimé, je suis venu ici pour demander. Après une heure de lecture, la conclusion est claire, nous devons trouver un terrain d'entente.

Maintenir deux systèmes Visual Scripting différents n'est tout simplement pas possible, l'un d'eux doit mourir. Mais personne, y compris moi, ne veut se séparer de la structure de nœuds Blueprints.
Mais cet EventSystem est trop délicieux (au moins pour le prototypage de base) pour ne pas être mangé.

Je voulais que VisualScripting soit davantage un outil de prototypage. Les fonctionnalités limitées n'ont pas d'importance si elles peuvent réellement augmenter la base d'utilisateurs.
Plus d'utilisateurs équivaut également à plus de dons si personne ne l'a remarqué avant, cela devrait être pris en compte.

Mais Blueprints est un outil au niveau de l'industrie, il a donc ses utilisations et pourrait apporter le plus gros poisson pour Godot, ce qui est également important pour Godot. Et j'ai dit que je n'en savais peut-être pas grand-chose aussi.

Alors la question est simple, que faire ? - Choisir les deux n'est tout simplement pas une possibilité.
Mais un hybride pourrait rendre Godot plus populaire.
Comme vous êtes au moins plus expérimenté avec les deux styles de Visual Scripting que moi. (Je suis plus un codeur qu'un artiste, j'aime donc coder mon chemin) Pourquoi ne pas essayer de trouver une solution.

Cela attirera probablement plus de personnes que EventSystem seul pourrait le faire. Et maintenir le système de nœuds en vie sera également une bonne chose.

Alors que faire si aucun terrain d'entente ne peut être atteint. Quelque chose va juste mourir. Peu importe ce que c'est.

Personnellement, je pourrais voter pour Blueprints parce que j'en ai une expérience antérieure et j'aimerais que le plus gros poisson Unreal soit comparé.
Mais juste à titre de comparaison, j'ai récupéré GDevelop en moins de 15 minutes. GDScript sous quelques heures à des jours différents et Blueprint deux fois plus que GDScript à coup sûr.
Bien que cela montre également mon niveau d'expérience en tant que programmeur.

Je n'arrive pas à me décider. Voilà voir.

1. Unité : 4011
2. Irréel : 316
3. Créateur de jeux : 274
4. Construction : 223
5. Godot : 75
   _Liste à partir du tweet de Reduz du nombre de jeux par moteur dans Global Jam._

Je veux Godot au sommet. J'espère donc qu'un peu d'amour VS aidera à y parvenir.
Mais Unreal + Godot + GameMaker + Construct ne le coupe toujours pas. Mais en fait au moins le numéro 2.

Je ne sais pas trop quoi planifier pour l'avenir de Visual Scripting de Godot. Parce qu'attendre sur le système actuel ou essayer sans réfléchir d'améliorer quelque chose qui est cassé n'aidera pas.

"EventSystem, c'est comme programmer avec Scratch à un certain niveau. Alors que le Blueprint est complètement unique mais il est plus puissant qu'EventSystem, car les EventSystems deviennent plus déroutants avec la profondeur et ont une lisibilité moindre."

Quoi?? C'est exactement le contraire si vous essayez le système d'événements de Construct, notamment en incluant d'autres feuilles d'événements et en utilisant des groupes.

Le meilleur système de nœuds sera toujours un spaghetti de code par rapport à un EventSystem moyen.

@bigelod C'est vrai qu'il ne faut pas le dire comme ça. Je pensais que c'était similaire. J'ai écrit ce commentaire sur une période de 2 heures tout en apprenant EventSystems. Désolé, ça va le réparer.

Oui, je sais que le mieux, ce sont les plans et c'est tout simplement génial d'avoir quelque chose comme ça, mais un système d'événements ajoute des éléments plus conviviaux pour les débutants. Et aide également à apprendre la programmation.

@swarnimarun il y a de nombreuses années, j'ai présenté les feuilles d'événement aux développeurs de godot sur ce même tracker. Mais je n'ai pas fait un excellent travail à l'époque et il y avait déjà plus de support pour les plans, car de nombreux utilisateurs de godot étaient également des utilisateurs ex unity/Unreal. Les Blueprints ont déjà gagné et sont maintenant à Godot.

Maintenant, de nombreux utilisateurs qui proviennent de moteurs tels que clickteam fusion, game maker et construct sont en faveur des feuilles d'événement et n'aiment pas beaucoup utiliser les plans. Ils diront le contraire de ce que vous dites et expliqueront ce qui a déjà été expliqué - pourquoi les plans sont déroutants par rapport à une feuille d'événement et même à un script. Je l'ai déjà fait aussi.

Enfer, même en regardant d'autres forums de moteurs de programmation visuels, vous pouvez voir les réactions négatives à tout nouveau moteur de système de blueprints :
https://rpgmaker.net/forums/topics/23922/?post=857285#post857285

Maintenant, à la fin de la journée, je ne vois pas de raison pour laquelle les deux systèmes ne peuvent pas exister. Ils peuvent fonctionner ensemble - de la même manière que les plans peuvent fonctionner avec les nœuds gdscript.

En fait, dans un monde idéal, vous voudriez que des feuilles d'événements soient construites et prototypes rapidement avec une logique granulaire et des plans pour les organiser dans des machines d'état.
Pourquoi? Parce que les deux systèmes ont des avantages et des inconvénients.

Les plans de Godot peuvent très rapidement devenir un gâchis lorsque vous commencez à créer une expression simple avec des nœuds. Cette même expression peut être beaucoup plus claire dans une feuille d'événement ou un script.

Les projets open source sont démocratiques - plus une communauté soutient une idée, plus il est probable qu'elle deviendra réalité. Mais cela ne signifie pas qu'une autre idée doit être tuée. Les deux idées sont largement appréciées ou détestées.

Tout le monde ici doit se rendre compte qu'avec les feuilles d'événement et les plans, ils programmeront à partir de zéro. Ce qui est le plus important, c'est la clarté avec laquelle le système leur permet de structurer leur logique. Avec les blueprints, l'ordre d'exécution peut devenir compliqué, ce qui complique le débogage. Cela prend également beaucoup plus de clics et d'étapes à configurer par rapport à une feuille d'événement. C'est mon argumentaire principal ici, à la fois pour les développeurs professionnels et les fans de programmation visuelle. Mais n'oublions pas aussi que c'est une question de goût personnel. Je ne vais pas essayer d'en faire des fans de Blueprint. Je soulignerai plutôt que de nombreux développeurs de programmation visuelle n'aiment pas les plans et préfèrent les feuilles d'événements.

La feuille d'événement peut utiliser gdscript pour ses expressions et ainsi aider ceux qui viennent d'un moteur de type feuille d'événement à l'apprendre très rapidement

Les systèmes d'événements peuvent probablement être utilisés comme outil de création de nœuds personnalisés.

J'aimerais juste soulever un point à propos de quelque chose - honnêtement, je ne pense pas que les feuilles d'événements soient uniquement destinées aux prototypes. Je pense qu'une partie du problème avec l'état d'esprit selon lequel les evensheets ne sont que pour le prototypage est parce que beaucoup d'outils qui les utilisent poussent le concept qu'il est plus facile de créer des choses sans savoir comment programmer. Quiconque utilise réellement les feuilles d'événements pendant un temps considérable sait qu'il s'agit d'un véritable moyen de programmer qui nécessite de comprendre les concepts de programmation fondamentaux et que vous pouvez créer des jeux entièrement complets et riches en fonctionnalités.
Une partie du problème est que les outils qui utilisent les feuilles d'événements essaient de minimiser la nature technique de celles-ci dans le but d'attirer des amateurs et des personnes qui n'ont pas beaucoup d'expérience dans le développement de jeux. Cela nuit en effet à l'image des feuilles d'événements et les fait sembler moins capables pour les autres personnes qui ont plus d'expérience dans l'utilisation d'autres outils. Vous avez également beaucoup de gens qui utilisent des feuilles d'événements qui ne sont pas sûrs de ce qu'ils font parce qu'on leur a dit qu'ils n'avaient pas besoin de comprendre la programmation - donc les exemples que les gens créent avec ne le représentent pas très bien. Cela ne veut pas dire qu'il n'y a pas de bons exemples. C'est juste qu'il a développé une certaine idée préconçue.

..Un hybride pourrait être un moyen de briser cette idée préconçue, permettant aux gens de l'interpréter d'une nouvelle manière qui a peut-être un ton plus sérieux. Vous auriez peut-être l'occasion de résoudre les problèmes des systèmes précédents et de faire en sorte que l'hybride paraisse meilleur que les systèmes dont il s'inspire.

@prominentdetail soulève un très bon point.
Pour compléter, je dirai simplement ceci:
Godot a l'opportunité d'être le premier moteur de jeu 3D approprié à prendre en charge les feuilles d'événements. Cela, par définition, l'élèvera au-dessus de tous les autres moteurs de feuille d'événement pour le moment.
Comme je l'ai mentionné précédemment, cela a déjà été tenté à la fois dans Clickteam Fusion et dans Construct - en tant que plugins, même dans Game Maker. Et c'est un gâchis maladroit là-bas parce que les éditeurs de ces moteurs n'ont aucune capacité 3D.

Fusion Clickteam - Moteur Firefly :
http://clickstore.clickteam.com/firefly
https://store.steampowered.com/app/267655/Firefly/
C'est en train de se passer sur Steam - car c'est un horrible module complémentaire de buggy

construction2 - q3d
https://www.scirra.com/tutorials/9456/building-your-first-3d-game-with-the-q3d-plugin

Il suffit de regarder à quel point il est compliqué de configurer une scène 3D simple sans avoir un éditeur de scène 3D
https://youtu.be/VUGsTdBpRCQ?t=6m17s

À mon humble avis, un hybride semble être un excellent moyen d'obtenir les inconvénients des deux.

L'approche devrait consister à créer un prototype de feuille d'événement pour montrer sa valeur et obtenir des commentaires.

Après avoir testé le système pendant environ plus d'une heure, il semble tout à fait capable. Et ce qui est intéressant, c'est qu'il possède probablement autant de connaissances en programmation que GDscript pour créer la plupart des choses, autres que le mouvement ou les éléments les plus basiques pour lesquels des fonctionnalités d'aide ont été ajoutées.

Je crois que les gens qui ont trop peur d'essayer la programmation sont probablement les seuls qui pourraient en avoir besoin en présence de GDScript.

Eventsheet peut facilement être un outil pour apprendre la programmation, notamment avec l'API Godot. Comme Godot a déjà bon nombre des mêmes fonctions d'assistance. Ainsi, l'implémentation d'EventSheet pourrait en fait être capable d'utiliser GDScript.
Parce que vous pouvez essentiellement créer un système qui convertit l'EventSheet en GDScript et le stocke dans un dossier caché séparé, qui est mis à jour au moment de la compilation et peut être utilisé par le moteur. Au moins c'est ce que j'ai compris. Cela pourrait être la solution la plus simple.

Bien que je puisse voir que cela ne peut tout simplement pas remplacer le Visual Scripting/Blueprints, car ce n'est pas très visuel, principalement du code dans la colonne, ce qui rend la chose plus facile à comprendre.

Je ne comprends pas pourquoi il est rendu public ainsi, à moins que quelqu'un ait des connaissances de base en programmation à l'aide d'EventSheet, cela pourrait s'avérer plus compliqué.

Actuellement, en attendant que le côté Visual Scripting soit corrigé, je pourrais essayer de créer quelque chose avec cela si je trouve le temps. Cela pourrait être amusant (m'aidera à apprendre l'API Godot) d'essayer d'implémenter une version de base d'EventSheet. Si je fais des progrès, je m'assurerai de mettre à jour ici.

En quoi les feuilles d'événements diffèrent-elles des langages gdscript/scripting ?

Pour les débutants (les choses qui le rendent plus invitant que le codage) :

• Il existe une représentation visuelle de la logique - en utilisant des icônes, des couleurs et le moins de texte possible
• Les conditions sont décrites dans la colonne de gauche, les actions dans la droite - Dans le codage, les conditions et les actions sont sur une colonne, ce qui rend plus difficile pour certains de distinguer les deux lors de la lecture de la logique d'une autre personne.
• Au lieu d'une longue chaîne de texte, les méthodes sont affichées sous forme de mots simples - en anglais et les signes de syntaxe sont supprimés lorsque cela est possible - la suppression du bruit de la syntaxe rend la lecture beaucoup plus claire
• Intelisense/autocompletion présente à l'utilisateur l'intégralité de l'API - afin qu'il puisse voir tous les setters ou getters disponibles et filtrer ceux qu'il souhaite - inversés par rapport à la façon dont cela fonctionne dans le codage IDE - où l'autocompletion s'affiche après avoir commencé à taper et l'api entière est toujours caché dans la documentation du moteur. Il a également des indices visuels pour trouver des choses (icônes). Il montre directement le type de variables retournées ou attendues
• La logique de regroupement vous permet d'en faire votre propre dossier que vous pouvez réduire/déplier et déplacer. La possibilité de réduire les blocs de logique que vous avez décidés de réduire est très pratique lorsque vous organisez votre code et que vous souhaitez en masquer les parties sur lesquelles vous ne travaillez pas.

Pour les utilisateurs plus expérimentés :

• Vous avez la possibilité de modifier très facilement l'ordre d'exécution des événements en faisant glisser et en déposant les cellules remplies. Qu'est-ce que ça veut dire? Quand tout en codant dans un ide-, nous pouvons le faire par ctrl+x et ctrl+v. Dans un système de feuille d'événements, vous pouvez réorganiser simplement en glissant-déposant une ligne logique ou des cellules d'une ligne à une autre.
• La logique déjà établie est visuellement plus claire à trouver et à lire que le code - encore une fois en raison des indices visuels et de la disposition des colonnes gauche et droite - en plus du codage couleur. C'est vraiment génial lorsque vous prototypage quelque chose
• La feuille d'événements peut prendre en charge automatiquement les chemins de nœuds pour l'utilisateur par défaut. Ainsi, lors de la création d'une feuille d'événements, vous n'aurez pas à accéder à d'autres nœuds (parents ou enfants) en déterminant leurs chemins par rapport à quelque chose. Vous avez toujours la possibilité de flexibilité du code, mais le système s'en charge pour vous dans les cas où les nœuds ne vont pas modifier dynamiquement leurs relations parent-enfant.
  Tout ce que vous faites pour accéder à un nœud est de le sélectionner dans le menu d'aide. Cela accélère les choses
• Cela ressemble toujours beaucoup à gdscript - car toutes les expressions sont en gdscript, mais cela vous offre des avantages de productivité supplémentaires. Je pense que si c'est bien fait, c'est quelque chose que les utilisateurs de gdscript vont adorer, expérimenté ou non.

Je suppose que si je dois résumer les avantages :
pour les débutants - le code est beaucoup plus clair au premier coup d'œil, il est plus attrayant en raison de la façon dont l'API du moteur leur est présentée et la logique qu'ils ont établie a des indices visuels (icônes de nœuds)

pour les plus expérimentés, vous pouvez toujours écrire gdscript dans tous les champs d'expression, mais maintenant vous pouvez également accélérer certaines parties du processus (comme pas besoin de naviguer vers d'autres nœuds avec du code de saisie), possibilité de faire glisser la logique pour modifier son exécution commande ou exigences (pas besoin de couper et coller)

Je me suis un peu laissé distraire par des trucs javascript et j'adorerais que d'autres essaient ça :) Mais j'y reviendrai

Je suis d'accord avec @mhilbrunner qu'il devrait s'agir de son propre système, mais ce serait formidable s'il était possible de le combiner avec le système de blueprints - la façon dont vous pouvez combiner gdscript avec des blueprints dans un projet

@blurymind
alors, vous avez dit que vous travailliez sur un plugin comme ça ?
quel est le nom du dépôt ? c'est déjà sur ton github ?

Je peux confirmer que eventhee est plus facile à comprendre, je l'ai appris quand j'avais environ 10 ~ 11 ans et j'avais un mauvais anglais (je ne suis pas un locuteur natif) alors qu'il m'a fallu beaucoup plus de temps et de connaissances en anglais pour apprendre à code.

Parfois, cela peut être plus rapide que d'écrire du code, lorsque vous vous y habituez, vous pouvez cliquer aussi vite que vous pouvez le penser.

le seul inconvénient que je vois est que vous devenez paresseux lorsque vous devez apprendre le code traditionnel.

je commençais à travailler dessus, mais votre code semble être plus avancé que le mien, j'ai peur de ne pas pouvoir être utile, mais j'aimerais l'essayer quand même

@Elmapul Je ne pense pas que son repo aidera beaucoup.
Et le codage est beaucoup plus rapide en réalité si vous avez une telle réflexion, cela signifie que vous n'êtes pas vraiment un bon programmeur qui a travaillé avec des langages comme Python.
Bien que EventSheet soit plus utile et indulgent pour les débutants, c'est tout.

Je pensais juste mentionner quelque chose - puisque j'ai essayé divers outils au fil des ans.
Je suis un artiste avant tout, donc je passe le plus clair de mon temps à créer de l'art. C'est ce à quoi je consacre le plus mon temps et c'est ce que mon esprit a été renforcé pour favoriser. Il y a eu de nombreux cas où je prends des pauses prolongées loin du codage, alors que je fais d'autres choses artistiques, comme en freelance, etc.
En tant qu'artiste, cela rend difficile de rester à l'affût d'un outil de développement de jeu particulier qui nécessite des modèles de syntaxe spécifiques - des modèles que vous devez constamment appliquer pour maintenir une compréhension.
Ainsi, en tant qu'artistes, on s'attend à ce que les artistes n'aient probablement pas la même cohérence et la même priorité par rapport au style de codage basé sur la syntaxe.
Les feuilles d'événements sont un moyen de contourner cet obstacle chaque fois que vous avez pris un congé de programmation (parce qu'en tant qu'artistes, il est prévu que vous ne passerez pas un temps continu à coder). Les feuilles d'événements sont plus faciles à consulter car elles nécessite moins de mémoire de la structure syntaxique et des modèles avec lesquels vous vous familiarisez avec le codage.
Pour cette raison, je privilégie les feuilles d'événements car je peux être plus productif au lieu d'avoir à réapprendre constamment.

..Donc, fondamentalement, ce que je veux souligner, c'est que le codage oui est plus rapide si vous consacrez tout votre temps à cette occupation et développez les facultés mentales qui favorisent cette ligne de pensée. Ils le tapent simplement et partent - ils ne se détournent jamais vraiment de ce mode de vie/comportement. Pour d'autres, ce ne sera jamais un choix réaliste, car ils ont consacré leur vie à d'autres domaines de travail qui ont renforcé un modèle différent de comportement et de pratique.
Alors ouais... tu peux juste être comme... oh peu importe- ça craint d'être toi... dommage que tu ne consacres pas ton temps à être un programmeur à plein temps, etc. ce qui aliénerait beaucoup de gens qui ne seront jamais pleins- programmeurs de temps ou comme techniquement d'esprit. Et bien sûr, c'est le droit du développeur de le faire.
Mais si vous souhaitez inviter d'autres types de personnes et amener plus de personnes à utiliser l'outil, quel que soit leur potentiel technique, alors cela aide d'être plus ouvert aux choses et d'essayer d'aider ceux qui ne sont pas capables de correspondre à votre système / flux de travail préféré , etc..
Je ne fais que répondre, car je pense que la feuille d'événements aide beaucoup à progresser dans le développement de jeux, sans les effets d'abandon qui se produisent chaque fois qu'une personne s'en va et revient, etc. Il y a moins à empêcher une personne comme moi d'abandonner , et revenant simplement à son travail normal. Donc au final, j'accomplis plus, même si cela prend un peu plus de temps ou est un peu moins impressionnant sur le plan technique.

@prominentdetail À toutes fins utiles, Visual Scripting peut faire exactement cela, donc pas besoin de s'inquiéter une fois l'implémentation plus complète, cela résoudra la plupart des problèmes artistiques de mémorisation de la syntaxe.

J'ai utilisé Blueprints après avoir laissé le codage pendant une déchirure entière et cela me semblait toujours naturel et approprié en quelques minutes. Donc je pense que la plupart des gens seront d'accord avec ça.

Peu importe la langue que vous connaissez, les scripts visuels avec des options d'événement et d'action correctement groupées seront plus rapides que le temps nécessaire, à moins que vous ne tapiez des noms de variables et des types de données très courts.

Cela dit, si les événements étaient mappés sur des raccourcis clavier, il serait en effet plus rapide de "taper" à nouveau, mais ce sont toujours les événements/actions qui sont plus rapides que le code standard à partir de zéro (car les actions et les conditions représentent souvent une fonction complexe , préfabriqué et flexible pour la plupart des utilisations).

Mon argument reste que la feuille d'événement est à la fois plus facile à apprendre que
plans et plus rapide à mettre en place.

De plus, il est meilleur pour la transition
de nouvelles personnes aux langages de script réels.

S'il est bien conçu, un système de feuille d'événement peut être aussi rapide que l'écriture
gdscript. Si vous regardez mon gif de maquette, c'est assez similaire à la simple saisie
Code avec saisie semi-automatique lors de l'utilisation du filtrage du menu d'aide.

Quoi qu'il en soit, je suis toujours en train de trouver comment faire cela et heureusement godot
gdscript va recevoir des scripts dactylographiés, ce qui est mieux adapté
pour générer du bbcode pour ma feuille d'événement.
Par exemple l'une des subtilités
d'un champ d'expression dans un système de feuille d'événement est qu'il vous donne un
indication claire du type de variable qu'il attend et s'allume même en
vert lorsqu'il est valide (voir les fusions de clickteam).
J'essaye actuellement de comprendre comment faire un champ d'expression qui peut
prenez gdscript mais utilisez également le menu d'aide que j'ai créé. Encore une fois, il s'agit simplement d'expérimenter comment cela pourrait fonctionner. C'est loin d'être quelque chose d'atm utilisable.

Le mercredi 30 mai 2018 à 22 h 59, Daven Bigelow, [email protected] a écrit :

Peu importe la langue que vous connaissez, le script visuel avec correctement
les options d'événement et d'action groupées seront plus rapides que le temps nécessaire
à moins que vous ne tapiez des noms de variables et des types de données très courts.

Cela dit, si les événements étaient mappés sur des raccourcis clavier, cela
en effet être plus rapide à "taper" à nouveau, mais ce sont toujours les événements/actions qui
sont plus rapides que le code standard à partir de zéro (car les actions et les conditions
représentent toute une fonction complexe, prédéfinie et flexible pour la plupart des utilisations).

-
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/17795#issuecomment-393333602 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AGMbVT30aPs63RYwxtFqDTHWVqclenRBks5t3xZTgaJpZM4S8wyr
.

@blurymind J'ai recommandé de le faire avec C++, ce sera à la fois mieux adapté et plus complet en utilisant cette méthode. Même moi qui ai commencé le C++ il y a quelques semaines, je peux maintenant l'utiliser, créer des corrections de bogues et de nouvelles fonctionnalités. Ce n'est donc pas si difficile, probablement un peu. J'ai encore besoin d'utiliser stackoverflow cependant.

Mais si vous cherchez à rester et à utiliser GDScript et à créer simplement un prototype pour que d'autres le convertissent en un outil complet, je pense que vous devriez partager le référentiel ici, même s'il est incomplet.
Je serai heureux de vous aider. J'aime beaucoup l'idée d'EventSystem. Et VisualScripting est actuellement cassé, donc pas grand-chose à faire pour moi.

Le problème est que le système d'événements peut être compliqué à implémenter, dans Godot, vous l'implémentez probablement en tant que langage de script. Mais ce n'est pas son intention, c'est le gestionnaire d'événements, donc il devrait être global ou devrait être capable de gérer toute la scène seul, puis d'utiliser des groupes pour séparer le travail en sections.
Tout cela est possible, et ne devrait pas non plus être un problème à mettre en œuvre.

@swarnimarun existe-t-il un module hello world qui crée une nouvelle interface utilisateur ou modifie celle existante ?
Pouvez-vous recommander de bons tutoriels de démarrage qui vous ont aidé ?

Dans tous les cas, je pense maintenant à changer la syntaxe gdscript que le menu d'aide générerait en gdscript tapé :
https://github.com/godotengine/godot/pull/19264
Ensuite, cela est converti en bbcode qui rend l'interface de cellule de feuille d'événement interactive

J'ai fait cet organigramme pour expliquer comment cela fonctionne en ce moment
https://www.draw.io/#Hblurymind %2FGodot-eventSheetPrototype%2Fmaster%2FEventSheetDiagramPlan.xml

@blurymind Je recommande de ne pas photographier pour des tutoriels mais d'apprendre de la pratique réelle ou d'autres développeurs.
Personne ne m'a vraiment aidé. Je n'ai pas eu besoin de beaucoup d'aide non plus. Je suis assez doué pour ramasser des trucs, donc tout s'est bien passé. Pourtant, je ne fais que commencer, c'est par rapport aux développeurs expérimentés.

Et je crois que vous utilisez GDScript pour faire toute la programmation, ou utilisez-vous C++.
Parce qu'il n'y a pas de modules qui vous permettent de faire quoi que ce soit par défaut ou au démarrage. Il faut apprendre de ce qui existe déjà. Et créez le vôtre.

La conversion en GDScript typé devrait être simple si vous utilisez GDScript et si vous utilisez C++, peu de portage sera nécessaire. Et pour autant que je sache, le PR devrait être fusionné à tout moment maintenant. Il a été revu et semble bien. Je ne l'ai pas encore essayé mais vraiment excité.

Et laissez-moi deviner actuellement, vous utilisez probablement GDScript avec get_method_list() et get_property_list(). Mais je vous recommanderais également d'utiliser des signaux et des groupes, les signaux sont le mécanisme de déclenchement des événements Godot. Je ne connais pas vraiment l'EventSystem mais si vous voulez créer quelque chose comme ça dans Godot. Assurez-vous d'utiliser Godot au maximum.

Et enfin, si vous voulez de l'aide, envoyez-moi un message sur Twitter ou Discord. Je serai libre pendant quelques jours maintenant.

@swarnimarun J'utilise gdscript pour écrire l'addon, il y a déjà une certaine utilisation de signaux pour des choses comme le déclenchement d'événements.
Oui, j'utilise get_method_list() et get_property_list() pour afficher également le menu d'aide

Avez-vous le même pseudo sur twitter et discord ?

Pour l'instant, mon plan est de prototyper l'interface graphique dans gdscript car c'est ce que je sais de plus que c++.
J'ai aussi une certaine expérience en javascrit, mais cela n'aidera pas beaucoup ici

Le gdscript tapé est ce que les menus d'aide généreront pour le mode d'expression - c'est juste mieux pour la conversion en bbcode pour rendre l'interface utilisateur avec une étiquette de texte riche

@blurymind C'est très bien alors. Je n'ai pas vu ça dans les gifs ci-dessus. J'ai donc supposé certaines choses.

Quant à mon pseudo, celui sur Discord est Swarnim. Et je pense que vous connaissez déjà mon compte Twitter.

@blurymind - Excellent travail. J'ai littéralement commencé à apprendre C++ en raison de l'amélioration des performances de Godot par rapport à GDScript (3 à 4 fois plus rapide, selon votre métrique - voir bunnymark ). Si c'est possible, je recommanderais d'aller directement vers l'or et d'utiliser C++ pour cela, même si cela signifie un apprentissage sur le tas - cela en vaudra la peine. Donnez-moi quelques semaines pour avoir une idée du C++ et je serais prêt à vous aider aussi si vous le souhaitez.

@colludium La

C++ est une douleur. Croyez-moi. Le pointeur, les références et la compilation du code ne sont rien d'autre que de la douleur. À moins que vous ne vouliez vous forger un avenir en tant que développeur de jeux pour une grande entreprise ou que vous soyez étudiant à l'université ou que vous soyez si intelligent que vous connaissiez complètement GDScript ou que vous soyez un programmeur professionnel.

Si vous voulez toujours continuer, essayez d'apprendre à créer du code GDScript de manière dynamique pendant que vous y êtes, car nous savons que la création d'un système d'exportation pour un langage est pénible, donc générer directement du code GDScript rendra le tout beaucoup plus facile à faire.
Et en prime, vous pourrez faire une vue pour voir le code et aider les débutants à apprendre le codage plus rapidement.

@blurymind Je voulais demander quelle version d'EventSystem vous utilisez comme base car je voulais créer un prototype du système en tant que module C++ donc j'aimerais qu'il soit synchronisé avec le vôtre au moins au niveau de base.

@swarnimarun - merci pour le conseil concernant : C++. Je ne suis qu'un programmeur amateur venant de JavaScript, donc une transition minimum de douleur / maximum de performance est ce que je recherche. Je n'étais pas au courant des améliorations prévues pour rendre GDScript beaucoup plus rapide - bon à savoir. Maintenant, j'ai un dilemme - C# ou le GDScript beaucoup plus facile à apprendre...

@colludium Disons que tout ce que vous trouvez plus facile, vu que votre arrière-plan est Javascript, je recommande GDScript car il a également un typage dynamique, et avec le typage statique entrant, il devrait être le compagnon idéal.
Et laissez-moi vous dire si jamais vous pensez que C++ est un langage que vous devriez apprendre, allez simplement consulter la page Rust vs C++ d'un forum.

@swarnimarun j'utilise godot 3.0.2
Voici le dépôt de test auquel j'ai ajouté le projet
https://github.com/blurymind/Godot-eventSheetPrototype
Tout le monde est libre de bifurquer ou de faire des pull requests 👍

N'hésitez pas à commencer à écrire un module c++. Ce que j'ai fonctionnel jusqu'à présent n'est que le bloc de construction de base de l'interface - le conteneur de cellules logiques.

L'analyseur bbcode (il utilise uniquement des expressions régulières) et le rendu du menu d'assistance sont les choses qui pourraient vous être le plus utiles, bien que je pense personnellement à changer leur façon de fonctionner - ils ont été battus ensemble pendant mon temps libre entre le travail et d'autres projets . La chose est un gâchis de code atmosphère, donc avoir des programmeurs plus expérimentés me serait d'une grande aide.

Le reste n'est qu'une interface statique mise en place à des fins de capture d'écran

Une chose qui est très importante à faire est de créer une sorte de dictionnaire modifiable qui garde une trace de tous les nœuds de la scène et de leurs chemins, donc au lieu de chemins de nœuds statiques, le menu d'assistance devrait générer gdscript qui utilise les chemins d'un dictionnaire qui les met automatiquement à jour et si un nœud est supprimé par l'utilisateur et non trouvé par la logique de la feuille d'événement, il peut être re-lié

Dans tous les cas, merci de partager si vous avez quelque chose - même si c'est basique. Je vais essayer d'en apprendre un peu plus sur le C++ et me joindre à vous pour l'écrire en tant que module :)

@blurymind Enfin ! quelqu'un qui a très bien compris que le script visuel Godot Engine 3.x est inutile (trop complexe pour les débutants, inutile pour les experts).

Le système d'événement GDevelop est magnifique ! il est très utile notamment pour créer des modèles de jeux 2D complets, puis plus tard pour ajouter des fonctionnalités plus avancées via GDScript. Cela rendra Godot Game Engine beaucoup plus attrayant, populaire et répandu !

J'aime sincèrement Godot Engine mais créer des jeux 2D pour appareils mobiles n'est pas la solution la plus simple et la plus immédiate. Il pourrait offrir beaucoup plus avec un système simplifié / système événementiel). Godot a un excellent éditeur d'animation, c'est vraiment sympa et fonctionnel, il n'a besoin que d'un système plus convivial si je veux créer un jeu de plateforme 2D sans avoir à écrire des milliers de lignes de code (que je trouve inutile pour créer un super basique modèle de style mario bros pour NES).

Je trouve que l'idée de @blurymind est fantastique! la communauté Godot a énormément grandi et j'en suis content. Je n'ai aucun doute que le système d'événement est mis en œuvre avec les prochaines versions. Visual Scripting (je le répète) est absolument inutile à l'heure actuelle (je ne trouve même pas de tutoriels, et personne ne l'utilise d'après ce que je peux voir sur le web).

Salutations et merci pour votre travail fantastique!

@XenonCoder Vous faites un point intéressant à la fin

Visual Scripting (je le répète) est absolument inutile à l'heure actuelle (je ne trouve même pas de tutoriels, et personne ne l'utilise d'après ce que je peux voir sur le web).

C'est un bon exemple de cas où quelque chose est difficile à utiliser par nature, puis sera utilisé plus tard comme une prophétie auto-réalisatrice pour expliquer pourquoi cela ne devrait pas être fait (par exemple : "VOIR ! Personne ne veut de scripts visuels !"), plutôt que d'admettre que cela n'a tout simplement pas été fait d'une manière attrayante ou conviviale pour les débutants.

C'est comme un demi-cadeau, car sans suite, c'est effectivement inutile.

Il en sera de même pour tout ajout au moteur qui n'est pas bien documenté ou fourni avec des exemples.

@bigelod Absolument d'accord avec toi. Je suis heureux que vous n'ayez pas mal compris mes intentions et que vous ayez parfaitement compris ce que je voulais dire.

Godot Game Engine est tout simplement fantastique ! Il a un potentiel incroyable. Faire des jeux en 2D, c'est le numéro 1 ! Pendant des années, j'ai expérimenté tous les moteurs de jeu et frameworks existants et je peux dire avec une certitude absolue que Godot est un projet qui promet de grandes choses.

Par exemple, le nouveau Visual Shader est très beau et promet de belles choses pour l'avenir. J'ai fait quelques tests et j'aime beaucoup ça comme idée. Mais pour comprendre la logique d'un jeu vidéo, le Visual Scripting est un piège.

Nous avons besoin de tutoriels, de documentation en général, et surtout d'un système simplifié dans le style de Build 3, GDevelop, Game Maker Studio 2. Initialement comme addon pour réaliser des jeux principalement 2D, à l'avenir il s'améliore et est officiellement implémenté. Je me rends compte que ce n'est pas une tâche facile, c'est juste une idée pour faire de Godot Game Engine la solution idéale pour les passionnés, les étudiants et les professionnels du jeu vidéo.

Merci à tous.

Autour du jeu, les moteurs se sont formés en magasins. C'est devenu normal - d'écrire des add-ons sur une base commerciale. Pour construire y compris. Tous les derniers plug-ins C2 significatifs sont commerciaux. Cela est dû non seulement à la formation du marché, mais aussi à la complication des produits, une grande dépense de temps pour tester et corriger les erreurs de compatibilité.
Je pense que... Godot est dans un autre créneau, et si Juan n'écrit pas et ne supporte pas l'application de la programmation simplifiée, il est peu probable que quelqu'un d'autre achève ce travail.

J'ai grandi avec Klik 'n Play, The Games Factory et Multimedia Fusion, et j'utilise Construct 2 ces jours-ci. Les scripts visuels avec des feuilles d'événements sont totalement différents de l'utilisation de nœuds de machine à états de style blueprint connectés les uns aux autres, et pour les personnes habituées aux feuilles d'événements, c'est le moyen de programmation le plus simple et le plus efficace. J'accueillerais volontiers un moyen de scripter dans GoDot avec des feuilles d'événements.

J'ai rencontré certaines limitations dans gdscript, la documentation et l'API du plugin qui m'empêchent d'exécuter pleinement ma vision de cela en tant qu'addon. Même si je l'obtiens à un état fonctionnel, il aura probablement des limites.

Une chose qui m'aidera énormément à y arriver est le gdscript tapé en option - c'est pourquoi j'ai arrêté de travailler dessus jusqu'à ce que ce soit dans godot. Maintenant que c'est fusionné, je vais recommencer à travailler sur ce module complémentaire de preuve de concept chaque fois que j'en aurai le temps.

L'idée est que le gdscript généré de la feuille d'événement sera tapé. Les données saisies donneront alors à la feuille d'événement gui des données contextuelles supplémentaires sur le type de paramètres attendus.

S'il y a un intérêt pour cela en tant que module c++ approprié ou comme addon gdnative - tout le monde est libre d'essayer de l'implémenter.

Vu le nombre de personnes qui le souhaitent, rien ne me rendra plus heureux que de faire en sorte que cela fasse partie de godot - ou du moins de travailler comme partie de godot.

Malheureusement, j'ai un travail à temps plein qui prend la majorité de mon temps en ce moment :(
Désolé pour la lenteur des mises à jour

Pour ajouter à cette discussion, je voudrais présenter à tout le monde ici un exemple fantastique d'un moteur de script visuel utilisant une approche de programmation visuelle basée sur les connexions de nœuds qui échoue actuellement dans sa cible démographique.
https://youtu.be/b8GZ21YCh50?t=4m12s
C'est un peu similaire à https://www.reddit.com/r/unrealengine/comments/4nt0up/need_help_debugging_this_blueprint/

Notez les alternatives que Gamesfromscratch présente

Une chose que je veux éviter ici dans cette proposition de conception est de prédéfinir un comportement qui est en dehors de ce que les nœuds font déjà dans godot - créant également beaucoup d'onglets et d'interface graphique.
Une feuille d'événement godot devrait fonctionner exactement comme le code gdscript, uniquement d'une manière plus tactile/visuelle
Il ne devrait pas essayer de créer un moteur de jeu facile à utiliser sur godot, mais plutôt de rendre ce que godot a plus accessible et plus rapide à assembler

peut-être qu'avec un script visuel, cela pourrait être accessible même sur des écrans tactiles ?

En effet, le script visuel de style feuille d'événement est très bien adapté au toucher
écrans

Le mer. 1 août 2018 06:46 Elmapul, [email protected] a écrit :

peut-être qu'avec un script visuel, cela pourrait être accessible même sur des écrans tactiles ?

-
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/17795#issuecomment-409456475 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AGMbVdqoa3AdMNfiM986iwIpNeqzqjVLks5uMUCvgaJpZM4S8wyr
.

@blurymind si le système de plugin a besoin d'améliorations pour cela, ouvrez un problème, il a déjà été modifié car d'autres plugins avaient besoin de quelque chose en particulier.

C'est une excellente idée ! Je n'ai jamais vraiment compris ces plans, mais l'approche basée sur les événements est bien connue, en particulier dans les communautés de modding, telles que Warcraft III World Editor.

Exemples d'écrans :


Les catégories et la liste claire des déclencheurs ont fière allure, du moins pour moi. Il est plus facile de les percevoir que les écrans du premier post.

C'est essentiellement la même chose que vous l'avez dit, mais avec la possibilité d'ajouter des conditions en tant qu'actions et d'y imbriquer d'autres actions.

@Wiadomy
cette image est trop petite pour voir/lire quoi que ce soit

@Elmapul
Désolé, quelque chose n'allait pas. Mis à jour.

@Elmapul alors que mon

@blurymind a finalement commencé à travailler sur la mise en œuvre de la feuille d'événement, connaissez-vous des ressources qui discutent de sa mise en œuvre en détail, comme un document de recherche ou un article sur son fonctionnement et sa mise en œuvre ?
Ce sera d'une grande aide. Pour me lancer dans la conception du système de feuille d'événement pour Godot.
Parce qu'il ne serait pas précis d'utiliser la méthode Construct ou GDevelop car le fonctionnement de Godot est assez différent et nous avons des choses appelées signaux qui doivent également être intégrées et encore plus.

il y a quelques informations sur la feuille d'événement de construct ici si vous avez besoin d'informations générales : https://www.scirra.com/manual/74/events
différentes entreprises implémentent leurs feuilles d'événements un peu différemment les unes des autres, et elles ont donc chacune leurs propres bizarreries.
Peut-être que je peux créer une vidéo qui résume les différentes parties de la méthode de construction (puisque c'est probablement la meilleure façon actuellement). Je ne connais aucun document de recherche, bien que ce soit intéressant à trouver.

@prominentdetail Merci pour le lien, il me semble que je
Ma première idée était d'avoir quelque chose de similaire à l'addon de @blurymind mais maintenant il est plus probable que nous ayons une API différente pour Event Sheet qui facilite le codage et n'est pas une version de GDScript sous forme visuelle.

Alors, qu'en pensez-vous si le système d'événements doit avoir une API différente à ajouter à la facilité d'utilisation ou simplement être un wrapper pour GDScript.

@swarnimarun vraiment la meilleure chose à faire est d'utiliser les moteurs pendant un moment et de réfléchir à la façon dont cela peut être fait d'une manière plus efficace. Construct classic et gdevelop sont d'excellents exemples imo.

De mon point de vue, les signaux dans godot sont comme des événements de fonction intégrés. La connexion des signaux est déjà visuelle dans godot :)

Définir un signal à partir d'une feuille d'événement n'est qu'une action disponible dans le menu d'aide - sous le capot, ce n'est qu'une méthode de passeur. Ce serait donc la même chose qu'avec gdscript.

Si un nœud contient des méthodes intégrées, celles-ci devraient être disponibles dans le menu que vous obtiendrez en cliquant sur « Ajouter une fonction intégrée »

Je pense fortement que nous devrions garder les choses simples et être un wrapper pour gdscript typé , mais si ce n'est pas possible ou pratique, cela pourrait être une API différente. Il vaudrait la peine d'étudier comment le script visuel actuel implémenté dans godot fonctionne comme une abstraction.

Si vous vous demandez comment les fonctions personnalisées sont créées dans construct, voici un lien vers leur doc
https://www.scirra.com/tutorials/823/creating-function
:)

@blurymind C'est en fait beaucoup plus facile et beaucoup moins de travail de le garder en tant que wrapper pour GDScript, mais le fait est que de nombreuses fonctionnalités de Event Sheet deviendront plus fastidieuses de cette façon, du moins c'est ainsi que je le comprends.
Je pense donc que je vais garder la même chose pour les débutants et ajouter des choses plus tard si besoin est.

@swarnimarun merci d'avoir pris le temps d'essayer

Je pense que le plus gros problème est que VisualScript, comme tous les autres langages que vous pouvez utiliser pour scripter Godot, essaie d'être aussi proche que possible des fonctionnalités de GDscript, avec des fonctions, des variables, des signaux et tout le reste. Vous ne pourriez pas y parvenir avec un système de feuille d'événements, car vous perdriez beaucoup de fonctionnalités. (Je sais que c'est possible, mais ça gonflerait vite)

@Jummit sauf que vous le pouvez tout à fait, essayez Construct 2. Il n'est pas plus gonflé que le code standard.

Et il pourrait avoir toutes les fonctionnalités de GDscript ? Alors qu'est-ce qu'on attend ? Permet d'obtenir des feuilles d'événements à Godot!

@Jummit godot a toutes les fonctionnalités que vous souhaitez sous la forme de « nœuds »

Les « nœuds » dans godot sont comme les « comportements » dans la construction2
Le comportement du platformer dans construct2 est comme un nœud kintematicbody2d moins puissant :)
Vous n'êtes pas obligé de tout scripter à partir de zéro.

Ce qui est encore plus cool, c'est que vous pouvez imbriquer ces nœuds dans une relation parent-enfant, tandis que les comportements sont limités pour être attachés comme des modules à un seul objet de jeu.

Je crois fermement qu'un godot avec une capacité de feuille d'événement intégrée et quelques plugins supplémentaires de la communauté peut devenir un moteur de prototypage plus rapide que construct2 ou 3.
Il a beaucoup de potentiel qui n'est pas exploité.

La rapidité du prototypage dans C2 est largement déterminée par l'interactivité des cellules - elles peuvent être glissées, copiées et modifiées avec des raccourcis clavier, y compris des objets de condition, tandis que les listes déroulantes éliminent presque complètement l'erreur.

@swarnimarun , j'ai créé un aperçu générique de divers éléments de construction : https://www.youtube.com/watch?v=ioz3gHtA-Lg
C'est essentiellement pour quiconque n'est pas trop familier avec la construction d'en avoir une idée. J'ai probablement oublié diverses choses car je n'ai pas tout planifié, mais cela pourrait fournir une compréhension de base. Je devrais probablement faire des vidéos dans lesquelles je développe davantage, pour montrer le côté flux de travail au lieu de divaguer sur diverses choses. Faites-moi savoir si vous souhaitez quelque chose couvert ou exploré.

C'est moche comme f ** k pour moi. Je veux dire, les scripts dans la vidéo.

@Wiadomy c'est bien mieux utilisé que dans cette vidéo. Au final, les feuilles d'événements ont toujours l'air plus propres et plus lisibles que n'importe quel système basé sur des nœuds

@Wiadomy , en raison de l'enregistrement d'écran, j'ai dû utiliser un seul moniteur et également conserver la taille du texte relativement grande. Construct formate le texte de sorte que certaines choses peuvent se regrouper en raison de l'espace à l'écran si vous tapez une longue expression continue.
Pour résoudre certains de ces problèmes, vous pouvez effectuer un zoom arrière sur le texte et également utiliser un autre moniteur pour libérer de l'espace afin de mieux répertorier les événements.
Je pourrais aussi diviser un peu les expressions pour les rendre plus nettes aussi, mais c'est un de mes projets plus anciens et aussi un peu plus expérimental.
De plus, vous vous familiarisez avec les repères visuels et le modèle dans la structure des feuilles d'événements, il devient donc plus facile de retracer toutes les différentes parties des événements. Avoir une structure standard comme celle-ci est très utile pour pouvoir s'adapter à n'importe quel projet et rend le flux de travail très rapide.

Ce projet est-il mort maintenant ?

@ Amr512 Je ne pense pas qu'il soit mort. Il y a certainement beaucoup de désir d'apporter cette fonctionnalité à godot.
@reduz s'est même intéressé récemment à gdevelop sur twitter
https://twitter.com/reduzio/status/1085206844275081218

Bien que je n'aie pas travaillé sur l'addon depuis un certain temps, j'ai décidé de commencer à contribuer à gdevelop lui-même - afin d'en savoir plus sur la façon dont sa feuille d'événement est programmée - ainsi que d'aider à en faire une meilleure alternative au payant option.
https://github.com/4ian/GDevelop/

Certaines universités ont commencé à choisir gdevelop pour enseigner des cours de programmation
https://github.com/4ian/GDevelop/issues/882

Mon addon buggy godot est actuellement uniquement à des fins de présentation et a besoin de beaucoup de travail avant de pouvoir être fonctionnel. N'importe qui est libre de le forker et d'essayer de le pousser plus loin bien sûr.
Une grande chose qui manque actuellement à mon module complémentaire est un élément d'interface graphique triable pour les lignes d'événement. Il n'y a pas non plus de fonctionnalité pour restituer réellement les feuilles d'événements en gdscript, ni d'éditeur de texte d'expression approprié avec la saisie semi-automatique et la coloration de la syntaxe (l'idée est d'utiliser le gdscript standard pour la syntaxe). Il manque beaucoup d'éléments clés qui feraient une feuille d'événement, mais l'objectif principal est de présenter comment une feuille d'événement peut être utilisée en combinaison avec gdscript pour la syntaxe d'expression. Je pense que les deux feraient une combinaison très puissante pour le prototypage de jeux - même pour les développeurs expérimentés

@blurymind J'ai laissé un ticket sur votre projet (erreurs sur Godot 3.1beta3).
J'aime totalement l'idée.

Je suis tombé sur ce problème par accident, j'ignorais totalement que ce truc était déjà couramment utilisé dans d'autres moteurs/frameworks, donc j'ai dû écrire le mien, ça ressemble beaucoup, vous ne trouvez pas ? ??

Règle = Événement
Feuille d'événement = schéma

L'implémentation précédente utilisait des contrôles de propriétés assez "bas niveau" et des actions respectives, mais j'ai pensé que ce type de système est en fait plus utile pour définir des "blocs de construction" de gameplay en étendant les scripts de base de conditions/actions qui sont plus "élevés". niveau" en abstraction. C'est donc en fait la raison pour laquelle j'ai choisi la terminologie "Règle" en premier lieu.

Vous devez avoir le gameplay et le cadre de jeu déjà établis pour en tirer pleinement parti, de sorte qu'il ne sert pas l'expérience prête à l'emploi pour écrire un jeu sans codage, mais le complète en fait d'une manière qui permet Vous pouvez combiner les fonctionnalités existantes de diverses manières et les organiser efficacement, composez simplement de nouvelles règles avec différentes conditions et actions à l'aide de vos simples GDScripts.

Et oui, permettre aux joueurs de créer leurs propres modes de jeu/missions/défis via le modding est une autre raison d'utiliser un tel système.

@Xrayez pouvez-vous partager git repo ? Je pense que vous avez raison de dire que mon implémentation est trop granulaire, mais cela correspond au fonctionnement de gdscript et de l'API de godot.
Aussi, juste en regardant la capture d'écran, je pense que vous manquez le point - il ne devrait y avoir que deux colonnes, pas trois. Gauche= conditions, droite= actions. Vous devriez également pouvoir faire glisser et déposer des événements entre les cellules, ainsi que faire glisser et déposer des lignes et les imbriquer. Pour construire cela, nous devons utiliser un arbre triable. Amusez-vous avec gdevelop et construct, vous aurez une meilleure idée de ce qui rend ces feuilles d'événements si agréables

Peut-être que ma mise en œuvre pourrait être considérée comme quelque chose qui s'apparente à DSL , c'est donc de là que peuvent venir les différences. De nombreuses règles ne sont que des implémentations en bac à sable de fonctions adaptées à des exigences de jeu spécifiques. Essentiellement, les conditions et les actions héritent simplement de ces petits scripts avec les méthodes qui doivent être implémentées dans les classes enfants :

class_name SchemeCondition extends Node

func is_met(object): # override
    return true

class_name SchemeAction extends Node

func perform(object): # override
    pass

Les règles ne sont qu'une collection de ces conditions et actions et sont exécutées selon que toutes ou certaines conditions sont remplies, rien d'extraordinaire en fait.

Je comprends que les gens qui contribuent et implémentent des choses aiment coder et ne voient pas tous l'intérêt de la programmation sans codage, mais beaucoup d'autres sont en fait intéressés par cela.

Construct, Gdevelop, Stencyl, Game Maker, Playmaker, Bolt, Fungus for Unity, Blueprints dans Unreal, Flow Graph et Schematyc dans CryEngine, etc...

De nombreux outils pour les non-codeurs sont fabriqués et utilisés. Beaucoup de bons jeux sont créés grâce à ceux-ci.
Hollow Knight a été fait avec le meneur de jeu par exemple.

Vous avez même des trucs comme Dreams qui font pas mal de bruit.

Ce genre d'outil apporterait beaucoup d'attractivité et d'accessibilité, et donc de nouvelles personnes à Godot.

J'ai récemment implémenté un moyen dans gdevelop d'ajouter de nouvelles instructions à sa feuille d'événement via une liste déroulante comme celle-ci

C'est un peu ce que je pense qui pourrait bien fonctionner pour godot.

Vous utilisez le richtextlabel pour rendre chaque cellule, ces cellules sont imbriquées dans les colonnes de gauche et de droite, qui sont alors un enfant d'une ligne. Les lignes sont gérées par une arborescence triable. Chaque ligne contient le gdscript réel qu'un interpréteur restitue en de courtes descriptions simples avec des vignettes et des zones cliquables pour saisir des expressions.
C'est en fait ce que fait le créateur de jeux. Leurs données de programmation visuelle sont stockées en tant que gml réel.

La partie délicate que j'ai trouvée lorsque j'ai commencé à le faire en tant qu'extension gdscript était de faire les champs d'expression. Comment pouvons-nous mettre un éditeur de code dans un champ de saisie et le laisser faire l'auto-complétion pour nous ? Comment lui donner un contexte de complétion et de validation ? Sans champs d'expression auto-complétés validés, c'est mort dans l'eau.

Nous avons toutes les parties de l'interface utilisateur pour construire cela dans godot, mais nous n'avons littéralement pas un seul développeur expérimenté qui fait quoi que ce soit dessus. Je n'ai vu aucun travail effectué jusqu'à présent

Quoi qu'il en soit, si mes connaissances en c++ étaient meilleures, j'aurais essayé :) Mais je connais le javascript, donc mes contributions vont plutôt à gdevelop

J'adorerais voir une solution basée sur les événements dans godot. J'ai essayé godot dans le passé, mais je ne pouvais pas me sentir à l'aise avec son flux de travail. Mon esprit est plus adapté aux feuilles d'événements si je veux développer un jeu.

Je suis programmeur maintenant, et je commence même à me lancer dans le développement de moteurs. Mais je peux toujours me porter garant des feuilles d'événements avec assez de confiance.

Construct 2 était en fait ma toute première exposition à de nombreux concepts fondamentaux de la programmation, à travers un cours que j'ai repris au lycée. Je pense que cela a considérablement simplifié et accéléré le processus d'apprentissage pour moi - à la fois le moteur en particulier et la programmation en général - tout en traduisant suffisamment le code réel pour que je ne me sente pas totalement perdu dans la transition des feuilles d'événements aux anciens scripts de texte normaux. Bien que je ne puisse pas être sûr à 100% de cela, je ne pense vraiment pas que j'aurais pu obtenir l'un ou l'autre de ces avantages dans la même mesure, s'il s'agissait plutôt du type spaghetti de script visuel.

Mais je suis d'accord que le maintien de deux systèmes de script visuel différents est probablement une mauvaise idée. Cela dit, je ne pense pas que nous devrions nous en tenir au système actuel simplement parce que c'est ce que nous avons déjà. Je pense que nous devrions vraiment envisager de passer à l'autre système, si les données le justifient. C'est-à-dire que je pense que nous devrions essayer d'avoir une meilleure idée de combien le système de feuille d'événement est plus accessible par rapport à notre système actuel. L'objectif des scripts visuels devrait être de rendre le moteur plus convivial pour les personnes peu familiarisées ou pas à l'aise avec les scripts réguliers. Un système de script visuel solide pourrait faire une énorme différence dans l'accessibilité de Godot et pourrait signifier obtenir le soutien et l'adoption de beaucoup plus de personnes, qui autrement n'auraient pas envisagé Godot.

En fait, la principale raison pour laquelle je me suis éloigné de Construct 2 était simplement parce que je voulais déjà me lancer dans la 3D. J'ai fini par essayer Unity, Unreal, Godot et Amazon Lumberyard, et j'ai fini par utiliser Godot à peu près simplement parce que l'ouverture et l'utilisation étaient plus rapides et que le processus d'importation était meilleur. Mais si Godot avait le système de style feuille d'événement, j'aurais probablement immédiatement opté par défaut pour Godot. Certes, cela ne fait vraiment aucune différence pour moi maintenant personnellement, mais encore une fois, il s'agit de rendre Godot aussi convivial que possible pour les non-programmeurs (c'est-à-dire une partie importante des développeurs de jeux nouveaux/aspirants).

Je n'ai pas lu les 112 messages qui sont maintenant masqués, alors je m'excuse si j'ai répété ou manqué quelque chose, mais je serais totalement intéressé par le prototypage de l'idée, ou d'aider à la tester et à l'examiner.

Je pense que nous devrions vraiment envisager de passer à l'autre système, si les données le justifient. C'est-à-dire que je pense que nous devrions essayer d'avoir une meilleure idée de combien le système de feuille d'événement est plus accessible par rapport à notre système actuel.

Nous avons déjà très peu de mainteneurs pour le système de script visuel actuel. Je ne pense pas qu'un changement complet serait jamais terminé de notre vivant :slightly_smiliing_face:

Nous avons déjà très peu de mainteneurs pour le système de script visuel actuel. Je ne pense pas qu'un changement complet serait jamais terminé de notre vivant

Eh bien, en supposant que nous obtenions d'abord un prototype fonctionnel de la feuille d'événement, le code serait déjà en grande partie terminé, et la question serait simplement de savoir si nous voulons plutôt passer à ce système, n'est-ce pas ?

J'ai également commencé avec Construct 2 et j'ai trouvé que les feuilles d'événements sont idéales pour résoudre 2
problèmes:

• Comme tout script visuel, vous exposez toutes les possibilités de n'importe quel
  module/plugin/add-on/function, c'est très utile pour apprendre du nouveau code.
  Les nœuds visuels se transforment assez rapidement en code spaghetti (je suis un mélangeur,
  Je connais les spaghettis dans le compositeur et les shaders).
• La feuille d'événement est comme swagger pour l'API Rest, vous commencez avec bien documenté
  code qui remplit le menu déroulant de la feuille d'événement et vous obtenez une interface graphique propre
  façon de consommer votre code, vous pouvez prolonger le désordre, et vous pouvez
  générer du code à partir de celui-ci (JS de Construct2), d'où ma question : pourrions-nous
  générer du code à partir de celui-ci ?

Si oui, je pense que la fiche d'événement devrait devenir une priorité, pour une facilité d'utilisation pour
tout le monde et une génération de code de bas niveau optimisée.
Si Godot pouvait être utilisé pour transformer une API python/C#/... en un ensemble propre de
événements, puis les événements de génération de l'utilisateur, puis Godot génère du code à partir de celui-ci, vous êtes
résoudre un problème d'utilisateur très très difficile : apprendre à coder à partir d'une simple interface utilisateur.

Je sais que la feuille d'événement ne résout pas tous les problèmes mais au moins vous pouvez coder 500
événements comme vous le faites dans une feuille de calcul sans être perdu dans le visuel
des liens partout.

Le mercredi 8 avril 2020 à 19 h 44, Jay [email protected] a écrit :

Nous avons déjà très peu de mainteneurs pour le script visuel actuel
système. Je ne pense pas qu'un changement complet serait jamais réalisé dans notre
à vie

Eh bien, en supposant que nous obtenions un prototype fonctionnel de la feuille d'événement, alors le code
serait déjà en grande partie fait, il s'agirait simplement de savoir si nous
vous voulez passer à cela à la place, n'est-ce pas ?

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/godotengine/godot/issues/17795#issuecomment-611096608 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAAP6LM4PU6RYLO5NK5IL23RLSZWHANCNFSM4EXTBSVQ
.

J'ai commencé à utiliser Construct 2 et je suis finalement passé au développement de plugins à l'aide de JavaScript, les feuilles d'événements ont donc une place dans mon cœur. Ils étaient faciles et intuitifs pour les non-initiés, avec la plupart de la magie de la visualisation facile des méthodes disponibles (actions et conditions) pour chaque classe (plugin). Honnêtement, GDScript dans VSCode est tout aussi bon maintenant, avec un intellisense complet et l'auto-complétion rendant la vie un jeu d'enfant. Bien que j'étais un grand fan de cette idée il y a 2 ans, j'ai maintenant changé d'avis. Je préférerais que les héros de développement de Godot concentrent leur temps et leurs efforts sur l'ajout d'autres améliorations du moteur.

Pourrions-nous générer du code à partir de celui-ci ?

Il faudrait que je me penche davantage sur la question, mais je pense honnêtement que ce serait assez trivial de le faire, et en fait, c'est probablement la meilleure façon de le faire. C'est-à-dire que je pense que la meilleure façon de gérer un élément de style de feuille d'événement est de le faire agir comme une interface graphique pour un fichier gdscript normal. Les actions entreprises dans l'éditeur de feuille d'événements modifieraient simplement le fichier gdscript. Par exemple, déplacer un bloc d'un endroit à un autre dans l'éditeur de feuille d'événements reviendrait essentiellement sous le capot à un copier-coller virtuel dans le fichier gdscript. Et tout fichier gdscript peut être visualisé et modifié soit dans l'éditeur de script, soit dans l'éditeur de feuille d'événements. Cela semble être la meilleure façon de le faire, à la fois du point de vue de la convivialité et du point de vue de l'implémentation. Cela dit, je ne connais pas encore très bien le développement des moteurs, donc je peux me tromper.

Je préférerais que les héros de développement de Godot concentrent leur temps et leurs efforts sur l'ajout d'autres améliorations du moteur.

Je suis assez d'accord. Je pense que la façon idéale de procéder serait que toute personne intéressée essaie de créer un prototype fonctionnel, puis à partir de là, la communauté peut essayer de déterminer si cela vaut la peine de passer à cela comme système de script visuel principal ou non. Je ne demanderais pas de temps de développement principal sur cette idée jusqu'à ce qu'une décision soit prise ou du moins proche.

Je ne suis pas assez dans Gdscript ou Godot aussi.
Mais ce que j'ai développé en tant qu'extension VS Code va aussi dans cette voie large
(https://github.com/j2l/blocklight).
Comprendre visuellement le code en jouant avec une partie de celui-ci et visuellement
reliant les variables et les résultats (nœuds dans la plupart des scripts visuels, ou couleurs
dans mon extension) est la pierre angulaire manquante pour beaucoup.
En fait, nous comprenons le code lorsque nous avons fini de l'apprendre, alors que nous devrions
voir les variables et les liens des morceaux avant d'obtenir tous les
code.
Concevoir avant de coder :)

Le mercredi 8 avril 2020 à 20 h 08, Jay [email protected] a écrit :

Pourrions-nous générer du code à partir de celui-ci ?

Il faudrait que j'y réfléchisse plus, mais je pense honnêtement que ce serait joli
trivial de le faire, et en fait c'est probablement la meilleure façon de le faire. C'est-à-dire,
Je pense que la meilleure façon de gérer une chose de style de feuille d'événement est essentiellement de
le faire agir comme une interface graphique pour un fichier gdscript normal. Actions
pris dans l'éditeur de feuille d'événement modifierait simplement le fichier gdscript. En mouvement
un bloc d'un endroit à un autre dans l'éditeur de feuille d'événement serait essentiellement
sous le capot, faites comme un copier-coller virtuel dans le fichier gdscript. Et
tout fichier gdscript peut être visualisé et édité soit dans l'éditeur de script, soit dans
éditeur de feuille d'événement. Cela semble être la meilleure façon de le faire, à la fois d'un
du point de vue de la convivialité et du point de vue de la mise en œuvre. Cela dit je suis
pas encore très bien informé sur le développement du moteur, donc je peux me tromper.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/godotengine/godot/issues/17795#issuecomment-611108712 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAAP6LN7GFGSBDZ537XXA6DRLS4Q5ANCNFSM4EXTBSVQ
.

J'aime l'idée que cela génère un fichier Gdscript normal. Ce serait vraiment bien pour apprendre

Quand j'ai commencé à créer des jeux, le système d'événements de Klik & Play était un très bon moyen pour moi de comprendre la logique de programmation, et j'aime toujours y revenir.

J'aime l'idée que cela génère un fichier Gdscript normal. Ce serait vraiment bien pour apprendre

Quand j'ai commencé à créer des jeux, le système d'événements de Klik & Play était un très bon moyen pour moi de comprendre la logique de programmation, et j'aime toujours y revenir.

Je pense que c'est potentiellement l'un de ses plus grands avantages par rapport au système spaghetti actuel - en raison de sa conception, il facilitera l'apprentissage de la programmation et de l'API de gdscript/godot.

Certaines personnes ici ont commenté - mais pourquoi s'embêter à le faire - c'est trop similaire au script dans la présentation.
Ma réponse à cela est - précisément. Vous apprenez les spaghettis, vous vous retrouvez avec des spaghettis. Vous apprenez la feuille d'événement, vous connaîtrez gdscript en voyant ce qu'il génère et en utilisant ces champs d'expression.

Il vous apprendra l'ordre d'exécution et comment lire le code.

Voir ce que fait la conversion en GML dans le créateur de jeux
https://docs2.yoyogames.com/source/_build/3_scripting/1_drag_and_drop_overview/changing_dnd.html

Flou vraiment intéressant ! J'ai eu la même idée et je la soutiens complètement.
Je fais toujours des extensions pour Clickteam Fusion 2.5 mais tout ce que je veux ajouter dans Fusion est dans Godot.
Tout ce dont j'ai besoin est de mettre une couche d'abstraction supplémentaire (feuille d'événements) dans Godot pour faciliter le développement.
Je n'ai pas lu tout le fil, mais la principale différence de mon point de vue entre le script visuel dans Godot et les feuilles d'événements dans d'autres moteurs de jeu est que le script visuel est "juste" une vue visuelle du code et les feuilles d'événements sont une abstraction de le code avec une vue simplifiée. Il est plus lisible par l'homme, factorise des choses qui nécessitent plusieurs lignes de code sur une seule ligne et la liaison signal/slots se fait automatiquement.
En fait, ajouter des modèles (scènes prédéfinies) à un objet intégré CF2.5 abstrait tout en utilisant GDScript ferait l'essentiel du travail pour moi, mais la feuille d'événement me rendra certainement plus efficace dans Godot que ce que je fais dans CF2.5 à présent.

Flou vraiment intéressant ! J'ai eu la même idée et je la soutiens complètement.
Je fais toujours des extensions pour Clickteam Fusion 2.5 mais tout ce que je veux ajouter dans Fusion est dans Godot.
Tout ce dont j'ai besoin est de mettre une couche d'abstraction supplémentaire (feuille d'événements) dans Godot pour faciliter le développement.
Je n'ai pas lu tout le fil, mais la principale différence de mon point de vue entre le script visuel dans Godot et les feuilles d'événements dans d'autres moteurs de jeu est que le script visuel est "juste" une vue visuelle du code et les feuilles d'événements sont une abstraction de le code avec une vue simplifiée. Il est plus lisible par l'homme, factorise des choses qui nécessitent plusieurs lignes de code sur une seule ligne et la liaison signal/slots se fait automatiquement.
En fait, ajouter des modèles (scènes prédéfinies) à un objet intégré CF2.5 abstrait tout en utilisant GDScript ferait l'essentiel du travail pour moi, mais la feuille d'événement me rendra certainement plus efficace dans Godot que ce que je fais dans CF2.5 à présent.

J'avais l'habitude d'utiliser CF à l'époque où cela s'appelait la fusion multimédia, c'était assez facile à apprendre en tant qu'enfant qui ne parlait pas anglais, et après l'avoir pratiqué, vous pouvez être très rapide, selon ce que vous faites, cela peut être plus rapide que de taper.
construct et CF sont la référence de ce à quoi ressemble un bon script visuel (gdevelop y arrive)

Merci
je soutiens cette merveilleuse idée
Ils disent que la construction 2 prendra sa retraite !
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

Je me demande s'il est possible de négocier avec le développeur de construct 2 afin d'ouvrir le système d'événements en opensource, et de l'utiliser dans godot, unity etc.
C'est une perte que le système d'événement de construction 2 est négligé sur les étagères inutilisées

Merci
je soutiens cette merveilleuse idée
Ils disent que la construction 2 prendra sa retraite !
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

Je me demande s'il est possible de négocier avec le développeur de construct 2 afin d'ouvrir le système d'événements en opensource, et de l'utiliser dans godot, unity etc.
C'est une perte que le système d'événement de construction 2 est négligé sur les étagères inutilisées

Je doute que nous puissions utiliser n'importe quel code de construct2 sur godot - ils sont une base de code complètement différente.

Votre meilleur pari pour une alternative open source est de passer à gdevelop
https://github.com/4ian/GDevelop

Ce ticket de problème sera probablement fermé bientôt, donc s'il y a un intérêt pour cette fiche d'événement dans godot - nous devrons peut-être bientôt la déplacer ailleurs :) (ou pour gdevelop)

Ce ticket d'émission sera probablement fermé bientôt, donc s'il y a un intérêt pour cette feuille d'événement dans godot - nous devrons peut-être bientôt la déplacer ailleurs :)

Quoi? Pourquoi?

@TheGoklayeh Il peut être fermé car nous migrons les propositions de fonctionnalités vers les propositions

Cela dit, @blurymind pourrait modifier le premier message pour qu'il corresponde au modèle de proposition . Nous pourrions ensuite déplacer ce problème vers le référentiel de propositions.

Nous avons vraiment besoin d'un moteur 3D utilisant des feuilles d'événements.

Merci
je soutiens cette merveilleuse idée
Ils disent que la construction 2 prendra sa retraite !
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

Je me demande s'il est possible de négocier avec le développeur de construct 2 afin d'ouvrir le système d'événements en opensource, et de l'utiliser dans godot, unity etc.
C'est une perte que le système d'événement de construction 2 est négligé sur les étagères inutilisées

Cela pourrait ruiner leur entreprise. et clickteam en plus.

Merci
je soutiens cette merveilleuse idée
Ils disent que la construction 2 prendra sa retraite !
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505
Je me demande s'il est possible de négocier avec le développeur de construct 2 afin d'ouvrir le système d'événements en opensource, et de l'utiliser dans godot, unity etc.
C'est une perte que le système d'événement de construction 2 est négligé sur les étagères inutilisées

Cela pourrait ruiner leur entreprise. et clickteam en plus.

Si quelque chose les tue - clickteam serait dû au manque de mises à jour de leur logiciel (la dernière étant en 2019), Scirra serait pour obliger leurs utilisateurs à passer à une licence de location de logiciel qui les oblige à payer chaque année ou à obtenir enfermé dehors. Les deux sociétés ont des défauts et leur communauté n'a aucun contrôle sur ce qui arrive au logiciel. C'est là que l'open source brille

@TheGoklayeh Il peut être fermé car nous migrons les propositions de fonctionnalités vers les propositions

Cela dit, @blurymind pourrait modifier le premier message pour qu'il corresponde au modèle de proposition . Nous pourrions ensuite déplacer ce problème vers le référentiel de propositions.

Quelqu'un peut-il faire ça à ma place ? :)
J'ai en quelque sorte perdu l'espoir que cette fonctionnalité atteigne jamais godot nativement (pas une extension). L'approche spaghetti a conquis les utilisateurs et les développeurs de godot

@blurymind Si vous ne soutenez plus cette proposition, alors je pense qu'il vaut mieux la fermer. Quelqu'un d'autre intéressé à travailler sur une approche de feuille d'événement pourrait alors ouvrir une nouvelle proposition sur godot-proposals . (En raison de la quantité de travail requise, je ne pense pas qu'il serait logique d'ouvrir une proposition si personne n'est techniquement capable de la remplir.)

Pourtant, ce fil contient beaucoup de discussions précieuses, alors merci quand même :slightly_smiliing_face:

Je pense que cette proposition est très idiote :)
Mais peut-on créer le système d'événement avec le moteur de construction 3 ?!
Je pense que le jeu peut générer des codes et les envoyer dans un fichier texte au moteur godot via node.js

C'est ridicule .. mais je pense que la construction 3 est assez forte pour faire un système d'événement
C'est mieux que rien pour le moment

Oui, j'espère au moins que nous avons réussi à nous faire une idée d'un tel système dans godot, de ses avantages par rapport au système de codage visuel actuel et des opinions sur les autres moteurs qui l'utilisent

Honnêtement, j'aime la façon dont GDevelop le fait, mais Godot fait un script d'événement n'est pas quelque chose que je suis en faveur maintenant (de nos jours).
J'ai essayé de l'implémenter une fois et j'ai réalisé que Godot avait une API extrêmement granulaire/de bas niveau pour qu'elle soit exposée directement à partir d'un système de script visuel.
Le système de script visuel actuel inclus et pourquoi je préférerais qu'il ait une couche d'abstraction personnalisée tout en restant robuste.
Une telle implémentation est incroyablement difficile à écrire pour un script d'événement, à moins que vous n'utilisiez plusieurs langages DSL comme des sous-scripts d'événement, où chacun est utilisé pour une partie spécifique du moteur.

Un système de script visuel généralisé qui est simple et facile à utiliser serait assez difficile à réaliser et c'est ce que je considère comme un "Projet Licorne".
Car l'augmentation de la généralisation conduirait très vraisemblablement à une augmentation beaucoup plus importante de la complexité dudit système.

Je prévois d'amener progressivement Visual Scripting vers une direction où il peut avoir des interfaces spécialisées pour toutes les parties du moteur.
Imaginez une manière différente d'éditer pour chaque type de nœud complexe primitif, comme dans les Blueprints, ayant un nœud d'expression.
https://docs.unrealengine.com/en-US/Engine/Blueprints/UserGuide/MathNode/index.html

Mais juste pour être clair, je ne suis pas contre Event Scripting, j'aimerais que quelqu'un fasse une proposition qui puisse couvrir certains systèmes spécifiques du Godot, et pourquoi et comment cela peut être utile. Personnellement, je trouve ça plutôt sympa pour programmer les Comportements, comment GDevelop le fait.
http://wiki.compilgames.net/doku.php/gdevelop5/behaviors
http://wiki.compilgames.net/doku.php/gdevelop5/behaviors/events-based-behaviors

Je ne l'utiliserai pas pour écrire un vrai jeu, mais si nous avons des comportements simples avec lesquels nous pouvons jouer et jouer, je le vois comme un moyen assez amusant d'optimiser le projet pour les enfants qui apprennent à créer des jeux.
Ou quelqu'un qui n'a pas l'habitude de programmer en l'utilisant pour les game jams.

Bien que l'on puisse en dire autant de VisualScript et de la modularité, il sera probablement beaucoup plus facile à réaliser avec. Le problème serait l'unification et la cohérence (Visual Shader et VisualScript utilisent des bases de code complètement différentes, la seule similitude étant les nœuds d'interface utilisateur utilisés).
Pourtant, nous pouvons sûrement essayer d'avoir un système de script d'événement en tant que plugin (Plugin C++, espérons-le, cela deviendra facile à faire après 4.0) qui peut être maintenu par la communauté et ajouté à Godot si nécessaire. (Je suis en quelque sorte orienté vers un moteur de jeu modulaire)

Quoi qu'il en soit, ce ne sont que mes 2 cents.

Pourquoi mon commentaire a-t-il été marqué comme hors sujet ? Est-ce que quelqu'un censure la communauté, et qui ? Cela ne présage rien de bon. Il y a d'autres commentaires que le mien qui sont plus hors sujet.

@prominentdetail Voici mon message de notification anti-bosse, j'ai oublié de le coller :slightly_smiling_face:

Veuillez ne pas résoudre les problèmes sans apporter de nouvelles informations importantes. Utilisez plutôt le bouton de réaction :+1: sur le premier message.

(Je souhaite que GitHub ait un moyen d'envoyer des messages privés, ou au moins de spécifier une raison personnalisée pour se cacher, donc je n'aurais pas à salir le fil de commentaire avec ça.)

PS : C'est l'étiquette typique sur GitHub ; ce n'est pas spécifique à ce référentiel.

Je soutiens cette proposition, mais je pense que personne ne mettrait le temps à la mettre en œuvre.
Il n'a pas suffisamment de soutien de la part des développeurs qui peuvent réellement y arriver.

Cela valait le coup d'essayer et la discussion était intéressante à coup sûr :)

@blurymind si vous soutenez toujours la proposition et êtes prêt à prendre le temps de la rédiger dans le format requis pour les GIP. Cela vaut la peine de faire l'OMI.

La façon dont les choses sont ajoutées dans Godot est lorsqu'une personne intéressée par une fonctionnalité prend le temps de la mettre en œuvre. C'est très aléatoire et sporadique. Mais nous comptons presque entièrement sur les contributeurs qui décident au hasard d'ajouter des fonctionnalités.

Donc, ce n'est pas parce que l'ensemble actuel de développeurs actifs ne s'est pas intéressé à votre proposition que quelqu'un ne viendra pas la mettre en œuvre.