Godot: Concepteur de jeux facile à utiliser pour les non-programmeurs

le script visuel est prévu à un moment donné

Le mercredi 14 janvier 2015 à 6h20, RyanBram [email protected] a écrit :

Bonjour, Développeurs Godot.

Tout d'abord, je tiens à vous remercier tous d'avoir créé un excellent moteur de jeu
avec une licence très permissive. Vos efforts aideront de nombreux développeurs et
étudiants avec un budget serré pour réaliser leur rêve.

Avec l'état actuel de Godot, le jeu open source aura un avenir meilleur.
Malheureusement, la plupart des moteurs de jeu open source sont conçus avec des
utilisateur à l'esprit avec peu de connaissances en programmation. Il ne peut toujours pas atteindre
un créateur de jeux débutant.

Ma suggestion est de fournir un concepteur/éditeur de jeu facile à utiliser avec
interface graphique intuitive et classe prédéfinie pour faciliter la tâche du nouveau programmeur. Suite
programmeur signifie plus d'utilisateurs (parce que l'utilisateur de Godot est un programmeur de jeux).

Je connais un moteur de jeu qui fait bien ce travail. Il est écrit à partir de Ruby,
originaire du Japon et traduit en anglais dans le monde entier. Il s'appelle RPG
Fabricant VX Ace
http://www.rpgmakerweb.com/products/programs/rpg-maker-vx-ace. En dépit
le mot RPG devant son nom, il est assez capable de créer des non-RPG
jeu avec son système de script de jeu Ruby (RGSS) intégré.

https://camo.githubusercontent.com/72746b38bc6f990eb5f1b9bb242bdce347af3c72/687474703a2f2f67616d65736172656576696c2e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031332f30312f7270676d616b6572322e6a7067

La liste suivante est un exemple de jeux créés avec le moteur RPG Maker :

1. Aleph (RPG Aventure) http://www.pioneervalleygames.com/
2. Pas de lamantins promis (Arcade) http://rpgmaker.net/games/5102/
3. Ragarokk - Bestiarium (jeu de cartes) http://rpgmaker.net/games/5808/
4. Terre sous attaque ! (Tireur) http://rpgmaker.net/games/6561/
5. Terra (VisualNovel) http://rpgmaker.net/games/3956/
6. Souvenirs de Mana (Action RPG)
   http://www.atelier-rgss.com/Project/Mana/Project_Mana_Story.html
7. Myhos - Le début (Horreur) http://rpgmaker.net/games/6493/

Je souhaite que le moteur Godot devienne aussi populaire que RPG Maker, car il a beaucoup
plus de fonctionnalités que RPG Maker. Le programmeur débutant a juste besoin d'un outil facile à utiliser
interface. Si c'était un succès, le studio Okam pourrait devenir le prochain GOG ou Steam
qui publient des milliers de jeux créés par des développeurs inde.

Cordialement, Ryan

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220.

@RyanBram - N'essayez pas du tout de rejeter l'idée ici - cela pourrait probablement être utile à l'avenir, mais je ne suis pas certain que les scripts visuels soient un moyen efficace de script. Je ne peux pas le dire avec certitude, mais j'imagine que les jeux les plus complexes que vous avez publiés étaient probablement écrits en texte, pas visuellement. Il semble que les scripts visuels soient quelque chose que les nouveaux utilisateurs utilisent, sûrement, mais cela les retarde dans l'apprentissage des outils réels dont ils auront besoin pour mener à bien leurs projets. Mais cela pourrait rendre le moteur plus accessible, donc je ne sais pas.

Il devrait également être possible pour les utilisateurs de créer un système de programmation visuelle entièrement en Godot avec GDScript, par opposition à quelque chose qui doit être intégré au moteur, n'est-ce pas ? Je n'en suis pas sûr.

Le fabricant de RPG semble adopter davantage une approche "Modding", et si Godot ressemblera davantage à un fabricant de RPG - les personnes qui ont l'intention de créer différents types de jeux se détourneront. Donc, ce que vous suggérez essentiellement, c'est de faire en sorte que godot ressemble davantage à GameMaker (ce qui est compréhensible, beaucoup de gens veulent créer des jeux mais ne connaissent pas la programmation) mais il y a des limites :)
Ce qui se passera probablement, c'est que Godot obtiendra l'éditeur Nodal Behavior Graph, similaire à ce que Leadwerks et BGE ont. Cela fonctionne très bien avec les éléments de l'interface graphique, le reste nécessiterait des recherches et des tonnes de commentaires de la communauté, pour le rendre aussi simple et aussi puissant que possible.

@SolarLune , il est possible de construire un jeu dans Godot et d'ajouter un éditeur en plus qui permet de modder le jeu dans les moindres détails (en utilisant GraphNodes et le reste de l'interface utilisateur, très amusant à jouer), et permettrait même d'en écrire code GDscript supplémentaire en plus, je pense que c'est la meilleure approche, pour expédier un jeu complet (RPG, FPS, RTS) séparément et permettre d'en peaufiner tous les aspects. Constructeurs made in Godot.

@SolarLune : Les scripts visuels sont utiles lorsque vous travaillez avec un
programmeur, qui peut créer un bloc pour que vous puissiez jouer avec. Cette
approche dans Unreal est utile. Je ne pense pas qu'il soit possible de remplacer
programmation entièrement (sauf si vous êtes masochiste), mais cela pourrait fonctionner pour
certaines personnes créent également des blocs de modèles pour les non-programmeurs.

Le mercredi 14 janvier 2015 à 16h23, TheoXD [email protected] a écrit :

Le fabricant de RPG semble adopter davantage une approche "Modding", et si Godot veut
ressemble plus à un fabricant de RPG - des gens qui ont l'intention de faire différent
genre de jeux va se détourner. Donc, ce que vous suggérez essentiellement, c'est de
faire ressembler godot à GameMaker (ce qui est compréhensible, beaucoup de gens
je veux faire des jeux mais je ne connais pas la programmation) mais il y a une limite :)
Ce qui se passera probablement, c'est que Godot obtiendra Nodal Behavior Graph
éditeur, similaire à ce que Leadwerks et BGE ont. Cela fonctionne très bien avec
Éléments d'interface graphique, le reste nécessiterait des recherches et des tonnes de communauté
commentaires, pour le rendre aussi facile et aussi puissant que possible.

@SolarLune https://github.com/SolarLune , il est possible de créer un jeu
dans Godot et ajoutez un éditeur en haut qui permet de modder le jeu à chaque
petit détail (en utilisant GraphNodes et le reste de l'interface utilisateur), et permettrait même de
écrivez du code GDscript supplémentaire en haut, je pense que c'est la meilleure approche,
pour expédier un jeu complet (RPG, FPS, RTS) séparément et permettre des ajustements
chaque aspect de celui-ci.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -69974733.

Eh bien, d'après ce que je sais, Godot a déjà un code d'interface utilisateur basé sur des nœuds (pour l'arbre d'animation et maintenant l'éditeur de shader visuel) qui peut, à l'avenir, être utilisé pour créer un type d'arbre "logique".

Cependant, il faudra noter que GDscript restera la voie à suivre si vous voulez une flexibilité maximale et rendre les nœuds logiques utiles nécessiterait un nœud de script pour l'exécution de GDscript (pour des choses plus complexes et plus avancées).

À l'heure actuelle, UE4 ne peut pas tout faire dans Blueprints sans une complexité insensée, GameMaker s'attend à ce que vous utilisiez GML pour une flexibilité maximale (grâce à l'utilisation de blocs de code), et le BGE nécessite des scripts en Python pour une puissance maximale (grâce à l'utilisation de briques de code). On ne peut pas ignorer l'utilité de l'édition visuelle pour un prototypage rapide et des situations logiques moins complexes, mais elle ne peut souvent pas faire tout ce que l'on peut faire dans le code.

le script visuel est prévu à un moment donné

Merci pour la réponse simple et positive.

Tout le monde, merci d'avoir commenté cette suggestion. Je crois qu'un éditeur simple et visuel n'est jamais assez capable de remplacer le codage à la main. Je suggère cette fonctionnalité comme complément pour le codage régulier et non pour remplacer sa position.

Dans RPG Maker VX Ace, la plupart des fonctionnalités avancées sont codées à la main. Un programmeur avancé fournit généralement un script de modding avancé dont la valeur peut être modifiée dans l'éditeur GUI par un utilisateur occasionnel (nom du personnage, compétence, portrait, sprite, etc.). Le système de script de jeu Ruby rend possible l'application de correctifs de singe. C'est pourquoi la plupart des scripts fournis par les utilisateurs avancés ne remplaceront pas la classe prédéfinie d'origine par les développeurs RPG Maker pour éviter les problèmes de compatibilité.

En comparaison:
Les projets KDE et GNOME n'ont jamais l'intention de remplacer les puissantes commandes Shell de Linux, mais les projets essaient simplement de combler le fossé entre la facilité d'utilisation et la puissance de Linux.

J'ai souri à l'idée que le studio Okam soit comme Steam... :))

Le 14/01/2015 à 17h20, RyanBram a écrit :

Bonjour, Développeurs Godot.

Tout d'abord, je tiens à vous remercier tous d'avoir créé un excellent jeu
moteur avec permis très permissif. Votre effort aidera beaucoup
développeurs et étudiants avec un budget serré pour réaliser leur rêve.

Avec l'état actuel de Godot, le jeu open source sera plus brillant
futur. Malheureusement, la plupart des moteurs de jeu open source sont conçus
avec un utilisateur avancé à l'esprit avec peu de connaissances sur la programmation. Ce
ne peut toujours pas atteindre un fabricant de jeux débutant.

Ma suggestion est de fournir un concepteur/éditeur de jeu facile à utiliser avec
interface graphique intuitive et classe prédéfinie pour faciliter la tâche du nouveau programmeur.
Plus de programmeur signifie plus d'utilisateurs (car les utilisateurs de Godot sont des programmeurs de jeux).

Je connais un moteur de jeu qui fait bien ce travail. Il est écrit à partir de Ruby,
originaire du Japon et traduit en anglais dans le monde entier. Il est
appelé RPG Maker VX Ace
http://www.rpgmakerweb.com/products/programs/rpg-maker-vx-ace.
Malgré le mot RPG devant son nom, il est assez capable de
créer un jeu non-RPG avec son système de script de jeu Ruby (RGSS) intégré.

https://camo.githubusercontent.com/72746b38bc6f990eb5f1b9bb242bdce347af3c72/687474703a2f2f67616d65736172656576696c2e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031332f30312f7270676d616b6572322e6a7067

La liste suivante est un exemple de jeux créés avec le moteur RPG Maker :

1. Aleph (RPG Aventure) http://www.pioneervalleygames.com/
2. Pas de lamantins promis (Arcade) http://rpgmaker.net/games/5102/
3. Ragarokk - Bestiarium (jeu de cartes) http://rpgmaker.net/games/5808/
4. Terre sous attaque ! (Tireur) http://rpgmaker.net/games/6561/
5. Terra (VisualNovel) http://rpgmaker.net/games/3956/
6. Souvenirs de Mana (Action RPG)
   http://www.atelier-rgss.com/Project/Mana/Project_Mana_Story.html
7. Myhos - Le début (Horreur) http://rpgmaker.net/games/6493/

Je souhaite que le moteur Godot devienne aussi populaire que RPG Maker, car il a
beaucoup plus de fonctionnalités que RPG Maker. Le programmeur débutant a juste besoin d'un
interface facile à utiliser. Si c'était un succès, le studio Okam pourrait devenir le prochain
GOG ou Steam qui publient des milliers de jeux créés par des développeurs indépendants.

Cordialement, Ryan

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220.

Unreal a en fait des modèles pour les projets, que vous souhaitiez faire un
script visuel ou un flux de travail de type script complet... et même le
des blocs de code pour l'édition visuelle sont accessibles via visual studio et être
personnalisé... :)

Le 15/01/2015 à 03h44, Juan Linietsky a écrit :

@SolarLune : Les scripts visuels sont utiles lorsque vous travaillez avec un
programmeur, qui peut créer un bloc pour que vous puissiez jouer avec.
Cette
approche dans Unreal est utile. Je ne pense pas qu'il soit possible de remplacer
programmation entièrement (sauf si vous êtes masochiste), mais cela pourrait fonctionner pour
certaines personnes créent également des blocs de modèles pour les non-programmeurs.

Le mercredi 14 janvier 2015 à 16h23, TheoXD [email protected] a écrit :

Le fabricant de RPG semble adopter davantage une approche "Modding", et si Godot veut
ressemble plus à un fabricant de RPG - des gens qui ont l'intention de faire différent
genre de jeux va se détourner. Donc, ce que vous suggérez essentiellement, c'est de
faire ressembler godot à GameMaker (ce qui est compréhensible, beaucoup
gens
je veux faire des jeux mais je ne connais pas la programmation) mais il y a une limite :)
Ce qui se passera probablement, c'est que Godot obtiendra Nodal Behavior Graph
éditeur, similaire à ce que Leadwerks et BGE ont. Cela fonctionne très bien
avec
Éléments d'interface graphique, le reste nécessiterait des recherches et des tonnes de
communauté
commentaires, pour le rendre aussi facile et aussi puissant que possible.

@SolarLune https://github.com/SolarLune , il est possible de créer un jeu
dans Godot et ajoutez un éditeur en haut qui permet de modder le jeu à chaque
peu de détails (en utilisant GraphNodes et le reste de l'interface utilisateur), et même
permettre à
écrivez du code GDscript supplémentaire en haut, je pense que c'est le meilleur
approcher,
pour expédier un jeu complet (RPG, FPS, RTS) séparément et permettre
ajustement
chaque aspect de celui-ci.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -69974733.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -69978224.

J'ai souri à l'idée que le studio Okam soit comme Steam... :))

J'ai aussi souri de manière positive.
Parce que ce serait formidable pour moi en tant que joueur s'il y avait une entreprise aussi grande que Steam avec des tonnes de catalogues de jeux, ouverts et sans DRM, créés par des milliers de grands développeurs de jeux.

Unreal a en fait des modèles pour les projets, que vous souhaitiez faire un
script visuel ou un flux de travail de type script complet... et même le
des blocs de code pour l'édition visuelle sont accessibles via visual studio et être
personnalisé... :)

Super s'il sera disponible à Godot.

Salutations,
Ryan

Salut Ryan

Avez-vous vérifié Construct 2? C'est l'un de mes concepteurs de jeux visuels préférés et extrêmement simple à utiliser.

La programmation visuelle dans Godot, je pense que ce sera un peu difficile à faire (comme Godot fait à la fois 2d et 3d, donc la portée est beaucoup plus grande.)
De plus, il sera probablement intégré beaucoup plus tard, lorsque tous les blocs sous-jacents du moteur seront en place.

Je sais que reduz a sa propre feuille de route pour cela, mais j'espère qu'il ne donne pas la priorité à cela par rapport aux autres mises à jour de l'éditeur/du moteur. Je préférerais que Godot soit utilisé par des programmeurs débutants ou semi-compétents plutôt que par des non-programmeurs. Mais ce n'est que moi.

Salut Ryan

Avez-vous vérifié Construct 2? C'est l'un de mes concepteurs de jeux visuels préférés et extrêmement simple à utiliser.

J'ai essayé Construct 2. C'est sympa et génial. Les jeux résultants sont également multiplateformes, c'est donc un gros plus. Malheureusement, je ne trouve toujours aucun tutoriel pour créer facilement des jeux RPG. Pour l'instant, je peux rester avec RPG Maker VX Ace et essayer de porter mon jeu sur de nombreuses plateformes (y compris Android) avec l'aide de MKXP Project .

Merci d'avoir partagé. J'attends avec impatience la programmation visuelle en Godot.

Meilleures salutations,
Ryan

Pour l'approche de script visuel - vous pouvez prendre des notes à partir de gdevelop, de la fusion multimédia et de la construction 2. Ces moteurs reposent à 100 % sur les scripts visuels. Vous avez encore besoin d'apprendre une syntaxe là où des expressions sont nécessaires, mais l'éditeur d'expressions permet de trouver extrêmement facilement les bonnes commandes. Ces trois moteurs vous donnent la liberté de créer n'importe quel type de jeu avec des scripts visuels - par opposition au créateur de jeux et au créateur de rpg.

Rpg maker n'est pas vraiment un bon exemple, car il est extrêmement limité.
Les scripts basés sur les nœuds sont très inefficaces en termes d'utilisation de l'espace - vous vous déplacerez et effectuerez un zoom avant et arrière à travers un graphique de nœuds géant. Comparez cela à la construction 2, où tout est présenté de manière claire et c'est serré et facile à lire - et vous avez un gagnant.

BGE est probablement le pire exemple ici, car il essaie de combiner une approche basée sur les nœuds avec des blocs logiques. J'ai écrit pourquoi c'est mauvais:
http://blenderartists.org/forum/showthread.php?323905-comparing-BGE-logic-bricks-with-Scirra-Construct-event-sheet-for-prototyping

Si vous faites des scripts visuels, s'il vous plaît, ne vous en faites pas avec un éditeur générique basé sur des nœuds. Si vous voulez que plus de non-programmeurs utilisent votre moteur, faites quelque chose avec une meilleure conception - comme construct2 ou multimédia fusion.

J'aimerais voir quelque chose comme ça implémenté _only_ comme un moyen secondaire de programmation. Les scripts visuels, par opposition au code, ralentissent la productivité d'un ordre de grandeur assez important. Cela a également tendance à rendre le débogage et la refactorisation beaucoup plus difficiles. Le seul avantage majeur auquel je peux penser (en plus d'être attrayant pour les non-programmeurs) est que le script visuel a tendance à être un excellent outil pédagogique s'il est capable de générer, ou du moins d'afficher, du code GDScript réel (IE. code. org). Je ne pense pas qu'il aurait besoin d'aller dans l'autre sens (IE. GDScript à Visual). Je pense que ce serait un excellent moyen pour les écoles d'adopter Godot dans leurs classes.

Voici deux différences majeures entre le code et les scripts visuels qui, à mon avis, sont les plus importantes en termes d'accessibilité. Cela vient de quelqu'un qui ne touchera pas au script visuel avec un poteau de dix pieds, mais je comprends que cela plaise à certaines personnes :)

Code : Le code a tendance à avoir des règles de syntaxe spécifiques qui doivent être suivies. Je suppose que cela a tendance à être la principale chose qui décourage les non-programmeurs. C'EST À DIRE. dans GDScript, vous devez avoir deux-points à la fin d'une déclaration de fonction, des boucles if, for, while, etc. Vous devez indenter correctement. Vous devez utiliser le mot clé var lors de la déclaration d'une variable telle que "var myInteger = 1". Pour la plupart des langages, il y a environ 3 ou 4 règles de syntaxe primaires qui ont tendance à être suivies et, à mon avis, ne sont pas si difficiles à apprendre. Après avoir écrit une poignée de petits scripts, même un artiste peut les apprendre. Je dis cela parce que je travaille avec deux artistes très talentueux qui ont travaillé sur les trois jeux Age of Empires avec Ensemble Studios. L'un a écrit pas mal de code en UnityScript et l'autre a maintenant écrit une tonne de code en C#.

Visuel : Vous avez tendance à obtenir un menu déroulant pour la méthode, la variable, l'instruction, etc. Cependant, vous devez toujours savoir quelles fonctions, propriétés, etc. vous recherchez et ce qu'elles font et même parfois comment elles fonctionnent. Vous devez encore résoudre le problème. Vous devez toujours utiliser des variables et garder une trace de ce qu'elles font tout au long de votre script. Vous pouvez toujours avoir des erreurs logiques aussi facilement que d'écrire du code.

Je pense que pouvoir écrire le code est finalement une façon bien supérieure d'aller du point de vue de la productivité. Cependant, aucun des deux ne fera de vous un programmeur meilleur/pire. Je pense que les scripts visuels sont un très bon outil pédagogique, mais si vous ne savez pas (ou ne voulez pas apprendre) comment structurer correctement les choses et surtout comment résoudre les problèmes, les scripts visuels ne vous aideront pas du tout.

J'adopterais une approche légèrement différente. Étant donné que l'éditeur godot est piloté par lui-même, il est facile de recréer une interface d'éditeur similaire en pur GDscript.

Ma proposition serait donc de créer un constructeur entièrement scripté en godot et de l'expédier séparément. Cela permettrait aux programmeurs et aux non-programmeurs de travailler sur le même projet tout en utilisant des outils différents. Le seul problème est que les non-programmeurs devront parfois gérer les deux outils en même temps, mais bon, j'ai vu pire xD Gridmap editor, shader editor, animation editor, code editor - peuvent être recréés, tandis que collada importer, convexe producteur, exportateurs - pas si facilement. On a toujours l'impression de réinventer la roue, mais cela peut simplifier beaucoup de choses.

Le noyau du constructeur pourrait être adopté pour n'importe quel genre de jeu (FPS, RTS, GPS ....) avec du contenu téléchargeable et d'autres choses, et s'il est maintenu par la communauté - il sera plus facile de contribuer, car tout est GDscript
Il est peu probable qu'il y ait bientôt des scripts visuels dans godot, mais cela n'empêche pas les autres de créer un constructeur par-dessus. J'ai vu quelqu'un prendre Blender 2.5 et créer un outil de conception d'intérieur.

Je pense qu'avoir plusieurs éditeurs pourrait fragmenter le développement de Godot. Il doit y avoir un projet central bien conçu pour un outil de script visuel qui s'appuie sur gdscript.

Ne soyez pas paresseux et faites vos recherches. Regardez d'autres moteurs de script purement visuels. Comparez leur base d'utilisateurs (leur popularité), comparez leur flexibilité - les types de jeux qui ont été créés avec eux - que ce soit sur kickstarter, steam ou d'autres plateformes.
Examinez leur approche de conception.

Dessinez-le ensuite sur papier. Ne vous contentez pas de copier l'approche des nœuds. Utiliser des nœuds pour les shaders est correct, mais quand il s'agit de logique, vous vous retrouvez avec un sacré bordel à parcourir et à essayer de comprendre.

croyez-moi, j'ai tout essayé. Meneur de jeu d'Unity, Kismet d'Unreal, créateur de rpg, stencyl, etc etc..
Construct2 vient en tête, avec la fusion multimédia. Ce sont les plus populaires, avec l'approche la plus flexible. Et ils ont tous les deux un magasin de marché d'actifs.
Ils sont extrêmement flexibles et si vous regardez les jeux créés avec eux, il existe une grande variété de genres.

Si vous devenez encore plus intelligent à ce sujet, vous pouvez vous associer à Gdevelop, un autre projet open source qui dispose déjà d'un éditeur de script visuel qui crée des jeux html5.
Examinez sa conception et son code source.

Si nous devions voter sur ce fil, je suis sûr que ce serait le mauvais endroit, car ce sont principalement des programmeurs qui se présenteraient pour le vote.

Un système de script visuel doit être conçu pour les artistes, pas pour les programmeurs. Autant que je pourrais me plaindre de mon aversion totale pour des choses comme PlayMaker sur Unity, la vérité est que les artistes l'adorent. C'est pourquoi il a près de 2000 avis et 5 étoiles. Si le vote est d'avoir quelque chose de plus comme le script de Construct 2, alors mon vote est de ne pas avoir de script visuel du tout car je ne pense pas que cela sera d'un réel avantage puisque A) Les programmeurs peuvent programmer directement en GDScript et B) Beaucoup d'artistes sera instantanément désactivé par lui et il suffit d'aller ailleurs. Je le sais, parce que mes deux amis artistes, qui savent tous les deux coder, regardaient Construct 2 et se moquaient de l'interface de programmation dont il dispose puisque c'est presque la même chose que d'écrire du code.

Un langage de script visuel doit être très visuel, pas beaucoup de mots. Cela ne devrait pas ressembler à du code à première vue. Il devrait être adapté aux "personnes visuelles", sinon cela ne sert à rien de le faire en premier lieu. Les artistes sont habitués et ont tendance à aimer les graphiques de nœuds car ils vous donnent une idée visuelle de ce que fait votre programme. Encore une fois, je n'aime pas moi-même les graphes de nœuds car je ne les supporte pas, mais je suis un programmeur et mon vote ne devrait vraiment pas compter dans ce domaine.

Je suis d'accord avec vous qu'il devrait être conçu pour les artistes/designers.
Mais en désaccord sur la logique selon laquelle mots = complexité.

Si vous faites asseoir quelqu'un pour lui apprendre à utiliser l'un des deux, construct2 apparaîtra comme le plus facile des deux. Pourquoi?
Parce que c'est plus clair que les nœuds. Beaucoup plus clair. Vous avez des conditions et des actions. Vous mettez le premier sur le côté gauche et l'autre sur le côté droit.
Pour ajouter l'un des deux, vous n'avez pas besoin de connaître les commandes. Ils y sont tous répertoriés pour que vous puissiez les ajouter - clair comme un jour. Chacun est accompagné d'une icône - qui est un indice visuel.

Playmaker et d'autres systèmes basés sur des nœuds nécessitent beaucoup plus d'apprentissage, car accrocher un nœud à un autre nœud vous oblige à comprendre d'abord si vous pouvez connecter les deux. Ce n'est pas simplement condition--> action. Les nœuds sont beaucoup plus complexes et manquent d'indices visuels. Où avez-vous vu des icônes dans le meneur de jeu ? ?
Il est beaucoup plus facile de se tromper. Il est beaucoup plus difficile d'y lire la logique.
https://www.scirra.com/tutorials/top
Je dirais également que, parce que C2 est un outil de programmation visuelle mieux conçu, il a une communauté d'utilisateurs actifs beaucoup plus grande que le meneur de jeu - même s'il est limité aux jeux 2D pour le moment. Beaucoup plus de tutoriels vidéo sur le Web (plus de gens comprennent comment l'utiliser que de meneurs de jeu), beaucoup plus de projets terminés, un marché et un forum sains et actifs, et surtout une communication active entre les développeurs et les utilisateurs. Ainsi, les développeurs savent ce que veulent les utilisateurs artistes.

Les utilisateurs de Construct peuvent simplement prendre une capture d'écran de leur feuille d'événement et savoir comment ils l'ont fait est clair comme un jour. Allez sur les forums voyez par vous-même. Je dirais qu'il a beaucoup plus d'utilisateurs que de meneur de jeu.

Je dirais qu'il faut moins de travail pour y configurer la logique que dans n'importe quel système basé sur des nœuds.

Je peux voir que vous les aimez, mais s'il vous plaît, essayez au moins construct2 avant de déclarer qu'il s'agit d'un moteur de programmeur.
Regardez leur forum et leur base d'utilisateurs. Il a autant sinon plus de bonnes réputations que le meneur de jeu. Il a réussi à obtenir cette bonne réputation en étant bien conçu - par lui-même - et non en étant un plugin pour un moteur déjà réussi. C'est un pur outil de programmation visuelle que tout artiste peut utiliser. Je suis un artiste et j'ai essayé playmaker - c'est plus difficile que construct2. Allez sur le forum de C2 et essayez de les convaincre que le meneur de jeu est plus facile à utiliser - juste pour rire. :RÉ
N'es-tu pas programmeur toi-même ? Vous avez contribué aux projets github plus que moi. Cela ne signifie-t-il pas que vous ne devriez pas faire la déclaration qui est plus facile à apprendre ?

Je comprends vos points du point de vue d'un programmeur. Si je devais choisir entre les deux, j'opterais également pour le modèle Construct. Cependant, comme je l'ai dit, c'est le pire endroit pour prendre cette décision car probablement la plupart sinon toutes les personnes qui lisent les listes de diffusion GitHub sont des programmeurs.

J'ai passé plus de ma carrière avec des artistes qu'avec des programmeurs. Bien que j'aie régulièrement fait les deux au cours des 18 dernières années (et que j'aie été passionné par les deux), j'étais professionnellement artiste avant d'être professionnellement programmeur. Peu m'importe d'avoir un diplôme, mon diplôme est en animation numérique et en effets visuels. Au meilleur de ma connaissance, les publicités sur lesquelles j'ai travaillé sont toujours diffusées après plusieurs années à Kansas City. J'ai travaillé sur des plans pour Hallmark, Sprint, Radio Shack, Honda et quelques autres que j'oublie probablement. J'ai aussi eu beaucoup de plaisir à travailler sur pas mal de plans dans "World Builder" avec Bruce Branit.

https://www.youtube.com/watch?v=QP3YywgRx5A
Nathan Warden au générique c'est moi

Je ne dis pas ça pour me vanter, je dis ça pour marquer un point. Je peux me tromper, mais en tant qu'artiste qui a passé beaucoup de temps avec des artistes, je pense savoir ce que les artistes aiment. Ils n'aiment pas beaucoup les choses comme Constructor. Ils ont tendance à se sentir intimidés et à choisir une application entièrement différente. Les artistes en général ont un état d'esprit très différent de celui des programmeurs. C'est comme quand je parle à mon ami Erik de choses techniques que j'essaie de lui apprendre, ces mots sortent assez souvent de sa bouche : « Nate, je suis quelqu'un de très visuel, si tu ne peux pas me le montrer visuellement, autant parler au mur".

Il y a une raison pour laquelle les artistes apprécient des choses comme les graphiques de shader basés sur des nœuds par opposition aux systèmes de shader linéaires. Ils peuvent visualiser ce qui se passe. Je ne pense pas avoir déjà entendu un artiste se plaindre de ne pas avoir de système de shader linéaire dans son application 3D préférée, mais il se plaint régulièrement de ne pas avoir de système de shader basé sur des nœuds.

Il y a une raison pour laquelle les artistes préfèrent des applications comme Fusion à After Effects. Dans presque tous les cas, ils choisiront quelque chose basé sur un nœud plutôt que sur linéaire, car c'est plus visuel.

Donc, 2 raisons supplémentaires pour lesquelles un système basé sur des nœuds plaira aux artistes :

1) Ils sont visuellement beaucoup plus attrayants.
2) Cela s'inscrit dans le paradigme de conception auquel ils sont déjà habitués. Ombrage et composition IE

C'est vraiment de cela qu'il s'agit. Si l'artiste va jeter un coup d'œil et passer au moteur de jeu suivant parce que l'autre a une programmation basée sur des nœuds, alors Godot ne devrait pas du tout avoir de script visuel, car il n'y aura probablement pas plus qu'une petite poignée de personnes qui l'utilisera et cela signifie simplement plus de maintenance du code à partir de ce moment-là.

Êtes-vous sûr d'avoir une idée de ce qu'est Construct2 ? Vous n'épelez même pas correctement son nom.
Il ne s'appelle pas "Constructeur" .

Je ne suis pas du tout d'accord avec le fait que nous devrions utiliser des nœuds car "cela ne devrait pas ressembler à du code à première vue".

Il est plus important de savoir à quel point c'est clair que ce à quoi ça ressemble. La clarté de ce que fait la logique est plus importante que l'apparence de l'éditeur à première vue. Construct2 ne ressemble pas à du code - le texte est écrit en anglais simple et il est évident que fait une action ou une condition. Les personnes qui utilisent C2 ont également tendance à être principalement des personnes visuelles.

Une feuille d'événement gagnera toujours contre les nœuds, quelle que soit la façon dont vous essayez de la faire paraître. Il peut emballer plus d'informations sur l'écran avec moins de panoramique - c'est plus évident ce que fait la logique. Et les repères visuels (icônes) sont beaucoup plus faciles à trouver par l'œil de l'artiste.
Les nœuds n'ont pas d'icônes et une énorme limitation de texte.
Ainsi, dans de nombreux cas, un nœud ne décrit même pas clairement ce qu'il fait, en raison de sa taille limitée, ce qui oblige la conception à utiliser une terminologie obscure au lieu d'un anglais simple.

Autre remarque :
Une feuille d'événement est lue et exécutée de haut en bas. C'est évident et prévisible.
Avec un réseau de nœuds, vos yeux vont voyager partout, ils se divisent en branches. Cela devient beaucoup plus compliqué.

Les histoires d'opinion à la troisième personne sur les premiers aperçus et non sur l'expérience utilisateur réelle ne devraient pas avoir de poids ici. Je suis aussi une personne très visuelle, mais qui a déjà utilisé de nombreux moteurs de script visuel. C'est une douleur absolue dans le cou de voir des gens se disputer sans utiliser les moteurs réels pendant un moment - avec un petit projet par exemple.

J'exhorte les concepteurs/développeurs/visuels de Godot à essayer ces moteurs sur un projet à petite échelle, puis à tirer des conclusions. Assez de ces histoires de tiers. Nous avons besoin d'une recherche pratique et d'un cas énoncé logiquement pour expliquer pourquoi l'un est meilleur que l'autre. Croyez-le ou non, les visuels ont aussi du bon sens.

Hors sujet:
Sur l'exemple de Fusion vs Aftereffects - les gens préfèrent une approche basée sur les nœuds pour la composition, car l'utilisation de calques peut devenir très fastidieuse sur une scène compliquée où le même effet peut être dupliqué sur plusieurs calques. Avec les nœuds, vous pouvez avoir plus de flexibilité en termes de composition et simplement accrocher un effet à plusieurs couches. Mais les nœuds sont plus compliqués que les couches.

Je suis d'accord avec vous sur à peu près tous les points, mais ces points sont toujours du point de vue d'un programmeur. Si je devais utiliser un système de script visuel toute la journée, je choisirais celui qui ressemble le plus à du code normal. C'est pourquoi je suis un grand fan d'enseigner aux enfants qui veulent apprendre à programmer en utilisant code.org. Je suis vraiment fan du style. C'est bon pour apprendre aux gens qui "veulent" programmer comment programmer.

Et oui, j'ai mal dit Construct, désolé. Non, je ne l'ai pas utilisé personnellement. Mais, cela n'a pas d'importance parce que le paradigme de script qu'il utilise n'est pas un nouveau concept par aucun effort d'imagination, donc mon argumentation ne concerne même pas Construct lui-même. Il s'agit de ce style de script en ce qui concerne les artistes, pas les programmeurs.

Dans un système basé sur des nœuds, vous pouvez avoir plusieurs conditions, événements et fonctions contenus dans chaque nœud. Vous pouvez ensuite nommer le nœud quelque chose comme Input, par exemple. À l'intérieur, il contiendra toutes les entrées du joystick et l'utilisateur lui dira quel événement utiliser. C'EST À DIRE. ils spécifieraient un événement comme "Fire". Cet événement provoquerait une transition vers le nœud auquel ils l'auraient connecté.

Voici un exemple simple que vous pourriez avoir sur une arme qui gérerait simplement le tir. Notez que même si c'est simple, c'est aussi puissant et ça ne ressemble en rien à du code :

Sur une note finale, vous pouvez faire en sorte que les scripts basés sur des blocs ou les scripts basés sur des nœuds aient l'air plutôt bien du point de vue de l'interface, donc je ne perdrai pas mon temps à discuter de ce point.

Cependant, quand j'ai dit "Cela ne devrait pas ressembler à du code à première vue." De nombreux artistes se soucient de ce qu'ils vont regarder toute la journée, tous les jours, pendant une durée indéterminée. Ils rejetteront une application entière si elle ne semble pas attrayante ou si elle semble intimidante. Je dirais que le bloc semble intimidant et déroutant pour un artiste typique. Cela ressemble à quelque chose pour les programmeurs, et ça l'est.

@blurymind ,

Les nœuds de graphe sont en fait issus de l'UML conceptuel. Vous faites une représentation graphique du code d'une manière que le public non programmeur (chefs de projet, consommateurs, artistes) peut comprendre. C'est ce qu'utilise UE4/Unity. C'est quelque chose dont tout le monde dans l'industrie est conscient. Les constructeurs adoptent généralement une approche différente, et la qualité de cette approche n'est pas définie par le nombre d'utilisateurs qui l'utilisent.

Il y a toujours une courbe d'apprentissage partout, et Construct2 ne fait pas exception. Mais ne forçons pas des trucs C2 dans Godot sans soutenir les arguments. La feuille d'événement deviendra plus longue avec des jeux plus complexes et finira par perdre plus d'espace que les nœuds de graphique. Seul le bouton "Ajouter une action" a sa propre ligne. C'est essentiellement la façon dont un programmeur interpréterait un bloc de code. Donc ce n'est pas si mal.

Personnellement, je ne vois pas pourquoi nous ne pouvons pas avoir les deux, mais les développeurs ont déjà assez à faire, donc cela n'arrivera pas de si tôt. C'est pourquoi j'ai proposé une approche différente qui évoluera plus rapidement, plutôt conduite par des non-programmeurs en coopération avec des programmeurs.

Voici un meilleur exemple pour montrer que vous pouvez avoir plus d'un événement par nœud. Notez également que chaque nœud (ou état) est non bloquant, il permettra donc à d'autres graphes de nœuds de s'exécuter simultanément :

Mais voyez, rien qu'en regardant votre capture d'écran, je n'ai aucune idée de ce que fait cette logique. C'est quoi "firePrimary" et "fireSecondary" ??
Faites maintenant défiler jusqu'à la capture d'écran que j'ai publiée de construct2.
Sur construct2, la condition à gauche indiquera "sur "R" enfoncé" ou quelque chose qui est en anglais simple - avec une icône de clavier à côté!

Montrez-les tous les deux à un artiste et demandez-lui lequel est le plus clair.

Montrez-nous également une configuration de nœud plus élaborée :) La capture d'écran C2 montre toute la logique du jeu. Le vôtre n'est qu'un événement. Pouvez-vous intégrer la même logique dans une capture d'écran avec des nœuds ? Je ne pense pas.

Voir l'exemple de nœud qui masque les informations.
Vous devez sélectionner un nœud pour voir ce qu'il contient.
Il utilise une terminologie obscure de programmeur plutôt qu'un langage humain ("Envoyer l'événement", "Stocker les résultats" qu'est-ce que c'est ?).
Construct2 montre tout en un seul endroit et c'est compréhensible pour les non-programmeurs. Le but de la programmation visuelle est de se débarrasser de la nécessité d'apprendre la terminologie.

Je ne suis pas programmeur. Je n'ai aucune expérience dans l'écriture de code réel. Pourtant, je peux facilement créer un jeu avec construct2 et pour moi, l'utilisation de nœuds est beaucoup plus difficile - lorsqu'il s'agit d'un jeu complet.

Je comprends que tout le monde votera toujours pour ce qu'il sait déjà bien faire. Mais comme vous l'avez admis, vous êtes un programmeur et n'avez pas réellement utilisé C2. Et je garde la déclaration que je suis un artiste sans expérience de codage - qui a utilisé à la fois les nœuds et l'approche C2.

Je vous donne de bons arguments logiques sur pourquoi utiliser l'un plutôt que l'autre.
Vous me donnez des déclarations telles que "les nœuds sont plus visuels" et "les nœuds d'utilisation irréels". Ce sont des déclarations d'opinion. Et vous admettez tous les deux être des programmeurs.

Me dire que je ne soutiens pas mes arguments est juste une confirmation que vous n'avez aucune envie d'examiner construct2 ou de considérer sa conception comme une alternative aux nœuds. C'est malheureusement une perte de temps pour vous convaincre du contraire.

@ThéoXD
Je suis assez d'accord avec toi si je te lis bien. Ce serait bien d'avoir les deux en tant que plugin/module séparé. Donc, en dessous se trouverait le GDScript réel, mais vous pouvez le visualiser en utilisant ce que vous voulez. Je pense que c'est possible. L'approche basée sur les nœuds peut nécessiter des drapeaux comme des commentaires spéciaux pour séparer les nœuds (IE. #node name="Input" et #endnode), mais ce n'est pas si grave car ce serait automatique si vous commenciez avec le graphe de nœuds. Je pense que l'approche par bloc serait simple.

C'est quelque chose comme ça que tu voulais dire ?

Comme je l'ai dit plus haut, j'aime beaucoup la méthode block/Construct/code.org car elle fonctionne très bien pour enseigner la programmation. Je ne pense tout simplement pas que ce soit un bon choix pour les gens qui voient la programmation comme un mal nécessaire.

@blurymind
La raison pour laquelle cela n'a pas de sens est que vous ne le connaissez pas. Quand je regarde l'image Construct ci-dessus, je n'ai également aucune idée de ce qui se passe, non pas parce que c'est mauvais, mais parce que je ne le connais pas.

En ce qui concerne le fait de ne pas pouvoir voir ce qui se trouve sous un nœud tant que vous n'avez pas cliqué dessus, une fois que vous avez configuré un nœud, il n'y a aucun intérêt à passer au crible ce que vous savez déjà. Je sais déjà que j'ai un clic gauche et droit et qu'ils tirent des munitions primaires et secondaires. Je sais déjà ce que font les nœuds de tir primaires et secondaires. Il n'a pas changé depuis que je l'ai fait, pourquoi dois-je voir les détails à chaque fois que je le regarde ? Donc, maintenant, la logique sous-jacente est juste un fouillis. C'est une autre raison pour laquelle les nœuds sont plus conviviaux pour les artistes et les non-programmeurs. Ils peuvent décomposer leur logique spécifique en morceaux plus généraux. Cela leur permet d'avoir une vue d'ensemble et de ne se soucier des détails que lorsqu'ils en ont absolument besoin.

Je regarde un projet réel pour un jeu mobile publié réel en ce moment et presque chaque graphique de nœuds est de 2 à 4 nœuds au maximum, il est donc difficile de vous montrer une configuration plus élaborée lorsque vous n'avez généralement pas besoin d'une configuration élaborée.

Si vous voulez élaborer, cela provient de la même application qui a été écrite par une personne qui est à peu près aussi non programmeuse qu'elle vient. C'est l'un des graphiques les plus complexes du jeu. Il contrôle le mouvement du joueur principal :

(C'est une autre chose que vous ne pouvez pas faire avec des blocs, c'est de les faire ressembler au vaisseau de Samus, haha)

Sans aucune invite, j'ai juste mis votre image Construct2 sur un écran et mis le graphique de nœud ci-dessus sur l'autre et j'ai demandé à ma femme (qui n'est certainement pas une programmeuse), "Lequel voudriez-vous utiliser si vous deviez l'utiliser tous les jours ?", et elle a pointé le graphique des nœuds et a dit : "Celui-ci". Je sais que ce n'est pas définitif, mais le fait que ce soit moins intimidant signifie que j'ai beaucoup plus de chances de commencer à lui faire apprendre. Si cela semble intimidant, elle peut fermer son cerveau avant même que je la fasse s'asseoir pour apprendre les bases.

Sans le pousser vers l'un ou l'autre, j'ai aussi demandé hier à mon ami artiste (le même qui a travaillé sur les trois jeux Age of Empires), qui est dans l'industrie du jeu depuis près de 20 ans maintenant, (et qui a utilisé Construct2) ce qu'il pense que d'autres artistes préféreraient et il a également dit le graphe de nœuds.

Quoi qu'il en soit, j'apprécie vraiment la discussion, mais cela ne sert à rien de battre un cheval mort, haha ​​:)

Ouais je l'apprécie aussi. Pas de mauvais sentiments :)

Impressionnant Samus Ship btw. Plus vous publiez de photos, plus vous soutenez ma thèse selon laquelle les nœuds sont visuellement plus difficiles à suivre car ils peuvent se diviser en branches et aller dans des directions folles.
Pour moi, la complexité supplémentaire de devoir suivre les lignes et les flèches entre les blocs a toujours été ressentie comme un travail supplémentaire. Je suppose que je devrais essayer à nouveau les nœuds un de ces jours. Si c'est là que godot se dirigera.

Encore une fois, vous nous donnez des histoires à la troisième personne qui ne sont pas vraiment étayées par des preuves. Amenez le mec ici et demandez-lui de nous dire POURQUOI il préfère l'un à l'autre :)
Ensuite, vous aurez un cas plus fort. Je n'obtiens aucun point logiquement sensé soutenant la thèse selon laquelle les nœuds sont plus simples jusqu'à présent.

oui, il semble moins intimidant à première vue car il cache beaucoup d'informations. Vos exemples sont beaucoup plus simples que ce qui est montré dans la capture d'écran que j'ai publiée. C'est trompeur.
Voici une vidéo qui montre à chaud comment configurer la logique d'un jeu de plateforme en C2.
https://www.youtube.com/watch?v=5RlSmkSbleI
sauter la première minute :P

Ne comparons pas les pommes aux oranges.
Code.org est une approche radicalement différente de Construct2 - il ressemble plus à Stencyl et présente l'un des inconvénients des nœuds : vos conditions et vos actions ne sont pas clairement séparées - il est donc plus difficile de comprendre ce que vous pouvez attacher à quoi. Des outils de programmation visuels bien conçus (fusion multimédia, construct2, gamedevelop) séparent clairement les conditions des actions pour l'utilisateur. Cela facilite grandement la construction de la logique car ils sont organisés pour vous par le logiciel qui devine ce dont vous pourriez avoir besoin et vous le montre au bon moment. cela vous évite également de faire des erreurs stupides.

Avec nodes/stencyl/code.org, vous devez déterminer quelle pièce est une condition, laquelle est une action. Il faut plus de réflexion pour configurer vos conditions de la bonne façon. Quel type d'information sort d'un nœud ? Il faut parfois plus de nœuds pour configurer une condition, plus apprendre à les connecter.
Allez, faites vos recherches et utilisez un peu les autres outils. Voir tous ceux qui ne sont pas des nœuds comme étant identiques n'aide pas.

@blurymind , votre cas est jusqu'à présent soutenu par le nombre d'utilisateurs utilisant Construct2, qui est généralement le résultat du modèle commercial du logiciel et de sa qualité en marketing. La préférence personnelle (vos arguments logiques) ne suffit pas pour forcer le flux de travail C2 dans Godot. Mais c'est quand même une bonne référence.

Si vous montriez à quelqu'un comment vous aimeriez construire votre jeu (relation objet-objet) sur papier ou sur un tableau noir, comment le montreriez-vous ? En écrivant un arbre d'événements ? Non. Vous dessineriez une vue conceptuelle avec des nœuds et des lignes, puis les considéreriez comme des classes, ajouteriez des fonctions, des membres...
Je conviens que la table d'événements ressemble plus à du code, uniquement interprété par un programmeur, et qu'elle peut donner envie aux utilisateurs d'apprendre la programmation réelle au fur et à mesure qu'ils progressent. J'ai remarqué qu'il y a aussi une terminologie et une courbe d'apprentissage, vous ne pouvez pas le nier. Mais la reconnaissance de forme et le regroupement d'objets sont en réalité une réalité. J'étudie un cours sur la visualisation de données, et outre à quel point cela peut devenir ennuyeux, cela fait en fait de bons points.

Même si j'aimerais voir ce numéro recevoir plus de 100 commentaires, les développeurs ne les liront pas tous, la meilleure chose que chacun de nous puisse faire est de créer un PDF avec des propositions et de les partager sur la liste de diffusion. Je ne vois pas pourquoi nous ne pouvons pas avoir différents niveaux d'abstraction, les nœuds Graph comme niveau supérieur, qui peuvent être représentés sous la forme d'un arbre d'événements. Si cela fonctionne, il n'y aura pas besoin de faire de compromis.

" @blurymind -- || -- Et vous admettez tous les deux être des programmeurs." - Je ne me considère pas seulement comme un programmeur, fais de l'art aussi tu sais. J'utilise mon expérience pour voir les choses d'un point de vue objectif.

Je ne sais pas s'il a été manqué, mais je ne suis pas seulement un programmeur non plus, mais aussi un artiste professionnel. Je pense que la plupart des programmeurs gagneraient vraiment à se lancer dans l'art pendant un certain temps. Cela rend la programmation de certaines choses beaucoup plus logique et cela aide également à combler la rivalité programmeur/artiste, haha ​​:) Je sais que c'est plus idéal, et pas tellement pratique pour la plupart des gens.

Voici quelques liens vers certains de mes travaux (recherchez Nathan Warden dans les crédits)

World Builder (impliqué dans environ la moitié des plans)
https://www.youtube.com/watch?v=VzFpg271sm8

Teddy Scares (a été impliqué dans la plupart des plans)
https://www.youtube.com/watch?v=qCXIzS_iY0k

Hallmark Crown Center (Le troisième coup avec le Père Noël)
https://www.youtube.com/watch?v=biqBq3_Whqk

Voici un rendu de l'immeuble de mon Louie. Si vous regardez World Builder, vous verrez certaines des illustrations que j'en ai extraites et que j'ai intégrées au film.

Et voici un rendu inachevé d'un char HK de style Terminator 1 écrasant Christine de Stephen King. Ces deux modèles sont faits par moi, mais je ne pense pas que quoi que ce soit d'autre dans le plan l'ait été.

Et bien d'autres que je pourrais nommer, mais je pense que le point est fait. :)

Eh bien, ce sont des images fixes incroyables, mais encore une fois, vous faites cela pour vous donner plus d'autorité. Cela n'aide pas à soutenir logiquement l'idée que les nœuds sont meilleurs que la feuille d'événement :)

Si vous optez pour des nœuds, vous serez comme n'importe quel autre moteur de jeu 3D qui utilise la programmation visuelle.

Je pense que ce n'est pas une bonne idée pour plusieurs raisons.

-Récemment, Unreal a rendu son moteur gratuit - c'est aussi multiplateforme. C'est un moteur beaucoup plus mature que BGE/Godot. Vous êtes donc en concurrence directe avec eux lorsque vous copiez leur approche de la programmation visuelle.

-Les nœuds sont beaucoup moins efficaces à l'écran qu'une feuille logique. Ils sont plus difficiles à lire/suivre.

-Scirra a annoncé que construct3 sera multiplateforme - l'éditeur fonctionnera sur windows, linux et mac.
Cependant, ils ne sont pas open source.
https://www.construct3.com/

Cela a créé une vague de commentaires au sein de la communauté scirra. Beaucoup d'utilisateurs veulent un certain nombre de choses que godot peut offrir sans la programmation visuelle :
-Fichiers exe natifs au lieu de conteneurs html5 - pour de meilleures performances
-prise en charge du développement de jeux 3d, en utilisant le style feuille d'événement dans construct pour le programmer :
https://www.scirra.com/forum/construct-3_t90881

s'ils font un éditeur 3D simple et compréhensible comme l'outil 2D à l'intérieur de C2, je l'utiliserais totalement

j'ai essayé unity, blender, torque 3D, UDK, parce qu'ils sont les plus annoncés et ceux que la plupart des soi-disant développeurs célèbres utilisent... et ils partagent les mêmes problèmes : ils ne sont pas conviviaux (du tout) et si vous Je n'ai jamais utilisé d'API de création de jeux 3D auparavant... eh bien, vous êtes 3Doomed (mauvaise blague ikno)

le fait est que la construction est très intuitive une fois que vous couvrez la base et vous donne la liberté de faire des jeux 2D complexes, cela vous donne différents chemins pour faire le même résultat (sans oublier que le système d'événements MAKE SENSE pour moi); quel est le détail que la plupart de ces autres outils ne couvrent pas ou le rendent mal

s'ils créent un moteur 3D avec le même flux et la même sensation que j'ai en utilisant C2 ; alors pourquoi ne pas essayer?

Ils ont une énorme base d'utilisateurs en ce moment (qui aime le style de feuille d'événement pour la programmation visuelle, mais veut ces fonctionnalités) et certains d'entre eux sont prêts à passer à un autre moteur. Il y a ici un grand potentiel pour que Godot intègre de nombreux nouveaux développeurs indépendants - ceux qui préfèrent cela aux nœuds - ceux qui n'utilisent pas le moteur Unreal - qui est maintenant gratuit et bien plus mature que godot.

Si vous optez pour cela au lieu de nœuds, vous serez le premier moteur à prendre en charge le développement complet de jeux en 3D avec cette conception de programmation vis. Vous allez puiser dans une nouvelle base d'utilisateurs, au lieu de rivaliser avec Unreal (gratuit), Unity (version gratuite disponible)

Eh bien, ce sont des images fixes incroyables, mais encore une fois, vous faites cela pour vous donner plus d'autorité.

Les images fixes et les liens ne sont pas une preuve de mon autorité mais des personnes avec qui j'ai travaillé et que je n'invente pas seulement :) Cela inclut certains de mes bons amis qui ont travaillé sur des films dont vous avez peut-être entendu parler comme Avatar, King Kong, Serenity, et des émissions comme Lost, Revolution, etc... Et certains de mes autres amis qui travaillent dans l'industrie du jeu vidéo depuis plus de 15 ans. Tous préfèrent un flux de travail basé sur des nœuds à un flux de travail linéaire basé sur des feuilles. Je pourrais probablement obtenir une citation de 3 ou 4 d'entre eux vous disant qu'ils préfèrent les graphiques de nœuds aux feuilles logiques si vous le souhaitez ?

Récemment, Unreal a rendu son moteur gratuit - il est également multiplateforme. C'est un moteur beaucoup plus mature que BGE/Godot. Vous êtes donc en concurrence directe avec eux lorsque vous copiez leur approche de la programmation visuelle.

Le flux de travail de script visuel est la dernière chose que les gens vont regarder lorsqu'ils comparent Godot à ces moteurs. La première chose qu'ils remarqueront est qu'Unreal prend en charge DirectX 12 et OpenGL 4 et que leurs démos et exemples sont époustouflants, puis ils commenceront à regarder les autres choses. La principale chose que Godot a sur ces entreprises est qu'il s'agit d'un logiciel FLOSS et que quiconque l'utilise est également propriétaire à part entière du logiciel.

Les nœuds sont beaucoup moins efficaces à l'écran qu'une feuille logique. Ils sont plus difficiles à lire/suivre.

Bien qu'il soit évident par votre déclaration que vous n'avez pas utilisé une bonne configuration basée sur un nœud, si vous vous inquiétez de choses comme l'efficacité de l'écran, vous ne devriez de toute façon pas utiliser de script visuel, vous devriez utiliser le vrai script qui est déjà disponible :) Je vous garantis que tout ce que les scripts visuels peuvent vous offrir en termes d'espace d'écran, les scripts réguliers peuvent également le faire, comme l'effondrement des régions de code.

Si vous optez pour cela au lieu de nœuds, vous serez le premier moteur à prendre en charge le développement complet de jeux en 3D avec cette conception de programmation vis.

Il y a une raison pour laquelle des moteurs comme Unreal, qui consacrent beaucoup de temps, d'argent et de recherche aux besoins de leurs clients, n'utilisent pas cette forme de script visuel et choisissent plutôt des nœuds.

Mon point de vue à ce sujet est que tout dépend de l'approche que l'on souhaite
résolu.

Les blocs d'action comme Game Maker sont intéressants, mais je pense que c'est plus
conçu vers un remplacement de la programmation.

L'approche d'Unreal ressemble plus à un complément à la programmation donc
les concepteurs peuvent travailler eux-mêmes dans le jeu et retirer du travail au
programmeur. C'est beaucoup plus utile en équipe (Artistes et Game designers
peut l'utiliser très bien) et est certainement l'approche que je voudrais ajouter à
Godot à cause de ça.

En raison de l'architecture Godot, il serait également très facile d'ajouter donc je vais donner
c'est un coup en 1.2

Le mardi 3 mars 2015 à 16h37, Nathan [email protected] a écrit :

Eh bien, ce sont des images fixes incroyables, mais encore une fois, vous faites cela pour donner
vous-même plus d'autorité.

Les photos et les liens ne sont pas la preuve de mon autorité mais des personnes que j'ai
travaillé avec et que je ne fais pas que l'inventer :) Cela inclut certains de mes
de bons amis qui ont travaillé sur des films dont vous avez peut-être entendu parler, comme
Avatar, King Kong, Serenity, et des séries comme Lost, Revolution, etc... Et
certains de mes autres amis qui ont travaillé dans l'industrie du jeu pendant plus de 15
ans. Qui préfèrent tous un flux de travail basé sur des nœuds plutôt qu'un flux de travail linéaire basé sur des feuilles
flux de travail. Je pourrais probablement obtenir une citation de 3-4 d'entre eux vous disant que
ils préfèrent les graphiques de nœuds aux feuilles logiques si vous le souhaitez ?

Récemment, Unreal a rendu son moteur gratuit - il est également multiplateforme. C'est un
moteur beaucoup plus mature que BGE/Godot. Donc tu es en concurrence avec eux
directement lors de la copie de leur approche de la programmation visuelle.

Le flux de travail de script visuel est la dernière chose que les gens vont être
regarder en comparant Godot à ces moteurs. La première chose qu'ils feront
remarque est qu'Unreal supporte DirectX 12 et OpenGL 4 et que leurs démos
et les exemples semblent époustouflants, puis ils commenceront à regarder les autres choses.
La principale chose que Godot a sur ces entreprises est que c'est FLOSS
logiciel et que toute personne qui l'utilise est également propriétaire à part entière du
Logiciel.

Les nœuds sont beaucoup moins efficaces à l'écran qu'une feuille logique. Ils sont plus difficiles à
lire/suivre.

Bien qu'il soit évident par votre déclaration que vous n'avez pas utilisé un bon nœud
configuration basée, si vous vous inquiétez de choses comme l'efficacité de l'écran, vous
de toute façon, vous ne devriez pas utiliser de script visuel, vous devriez utiliser le vrai
script qui est déjà disponible :) Je vous garantis que tout
les scripts visuels peuvent vous offrir en termes d'espace d'écran des scripts réguliers
peut le faire aussi, comme réduire les régions de code.

Si vous optez pour cela au lieu de nœuds, vous serez le premier moteur qui
prend en charge le développement complet de jeux 3D avec cette conception de programmation vis.

Il y a une raison pour laquelle des moteurs comme Unreal qui dépensent beaucoup de temps, d'argent
et la recherche sur les besoins de leurs clients ne va pas avec cette forme de
script visuel et a choisi des nœuds à la place.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -77017857.

J'ai bien essayé Playmaker et je dois dire que je l'ai aimé - plus que les kismet/plans d'irréel.

Dans les nœuds de meneur de jeu, c'est un peu comme des conteneurs dans lesquels vous placez des actions. Certaines des actions sont la vérification d'une condition qui peut conduire à un autre nœud.

Étant donné que vous créez vous-même les conteneurs de nœuds et que vous pouvez les nommer, les actions qu'ils contiennent sont exécutées de manière prévisible (de haut en bas) - c'est quelque chose avec lequel je peux vivre. :)

De plus, les actions que vous placez à l'intérieur d'un nœud sont en fait des scripts d'unité standard avec des entrées visuelles. Ainsi, les utilisateurs pourront écrire leurs propres scripts et les ajouter en tant qu'actions personnalisées.

Veuillez vous pencher sur le meneur de jeu et mettre en œuvre un système basé sur des nœuds qui lui ressemble davantage, plutôt qu'Unreal.
Son avantage est bien sûr que nous pouvons faire plus avec moins de nœuds, ils sont plus faciles à lire et à déboguer, et sont plus prévisibles.

Voici une introduction de la façon dont cela fonctionne :
https://www.youtube.com/watch?v=I9VwsVtbgFU&index=2&list=PLC759306A1E692A10

Il est très flexible et permet à l'utilisateur d'ajouter et de partager facilement des fonctionnalités de jeu - faciles à réutiliser.

Discussion passionnante. Je veux juste souligner un autre type/forme de script visuel autre que les nœuds et la feuille d'événement de C2, mais des blocs de script qui s'emboîtent comme des pièces de puzzle. Utilisé dans le moteur 2d Stencyl http://www.stencyl.com/

basé sur MIT Scratch http://wiki.scratch.mit.edu/wiki/Wait_Until_ ()_(block)

et dans Unity, j'utilise personnellement, Blox http://www.plyoung.com/blox/

Je ne suis personnellement pas convaincu par la programmation "visuelle" de type scratch. je
pense que c'est à peu près comme la programmation.
Je pense que la façon dont Unreal fait cela est conviviale pour les concepteurs de jeux/niveaux

Le samedi 21 mars 2015 à 23h57, todheil [email protected] a écrit :

Discussion passionnante. Je veux juste souligner un autre type/forme de visuel
des scripts autres que des nœuds mais des blocs de script qui s'emboîtent comme
Pièces de puzzle. Utilisé dans le moteur 2d Stencyl http://www.stencyl.com/
[image : stencyl_blocks]
https://cloud.githubusercontent.com/assets/8675463/6767767/d52e7b16-d013-11e4-878c-29002dc04f8e.PNG
basé sur MIT Scratch
http://wiki.scratch.mit.edu/wiki/Wait_Until_ ()_(bloc)
[image : scratch_example]
https://cloud.githubusercontent.com/assets/8675463/6767792/57f50e5c-d014-11e4-8015-9228bb6001d8.PNG
et dans Unity, j'utilise personnellement, Blox http://www.plyoung.com/blox/
[image : hello_blox]
https://cloud.githubusercontent.com/assets/8675463/6767796/7849f46a-d014-11e4-9244-9e45c601f883.PNG

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -84508001.

_OkamStudio_

Bon point. Pour moi, les blocs sont à mi-chemin entre les lignes de code et les organigrammes.

Je n'aime pas la manière scratch/stencyl de la programmation visuelle. Sa disposition est
visuellement plus difficile à suivre que les blocs construct2 et même les nœuds. Il est
assembler littéralement des pièces de puzzle et il souffre du problème de
déterminer quelle pièce va où. Ils ne sont pas simples à mettre
ensemble

Le dimanche 22 mars 2015 à 5h46, todheil [email protected] a écrit :

Bon point. Pour moi, les blocs sont la voie médiane entre les lignes de code et le flux
graphiques.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -84511415.

ok, je ne vais pas tout lire maintenant, mais juste mes 2 cents sur ce sujet.

des moteurs basés sur des événements sont créés pour créer des prototypes et des projets de petits jeux
des moteurs comme godot sont créés pour réaliser toutes sortes de projets

Ce sont donc deux choses différentes avec deux approches différentes, ce sont deux
différents péages

pour être honnête, je ne peux pas bien les utiliser. (péages événementiels)

Pour moi, la meilleure approche est deux péages parallèles.

2015-03-22 6:49 GMT-03:00 Todor Imreorov [email protected] :

Je n'aime pas la manière scratch/stencyl de la programmation visuelle. Sa disposition est
visuellement plus difficile à suivre que les blocs construct2 et même les nœuds. Il est
assembler littéralement des pièces de puzzle et il souffre du problème de
déterminer quelle pièce va où. Ils ne sont pas simples à mettre
ensemble

Le dimanche 22 mars 2015 à 5h46, todheil [email protected] a écrit :

Bon point. Pour moi, les blocs sont la voie médiane entre les lignes de code et le flux
graphiques.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -84511415.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -84575752.

David Aguiar de Aquino Paiva

la seule chose qui serait utile est le système d'unité "comportement",
fondamentalement, c'est un script qui fait quelque chose, donc ceci dans godot serait
traduire par la possibilité d'ajouter plus d'un script par nœud.
Bien sûr, je pourrais créer un nœud et le cloner, mais un script serait un
ressource, puis il suffit de la charger sur un nœud et d'ajouter un comportement (par exemple
exemple, un script de saut)
Dans l'éditeur, nous pouvions voir les exportations classées sous le nom du script.

2015-03-26 13:15 GMT-03:00 David Paiva [email protected] :

ok, je ne vais pas tout lire maintenant, mais juste mes 2 cents sur ce sujet.

des moteurs basés sur des événements sont créés pour créer des prototypes et des projets de petits jeux
des moteurs comme godot sont créés pour réaliser toutes sortes de projets

Ce sont donc deux choses différentes avec deux approches différentes, ce sont deux
différents péages

pour être honnête, je ne peux pas bien les utiliser.

Pour moi, la meilleure approche est deux péages parallèles.

2015-03-22 6:49 GMT-03:00 Todor Imreorov [email protected] :

Je n'aime pas la manière scratch/stencyl de la programmation visuelle. Sa disposition est

visuellement plus difficile à suivre que les blocs construct2 et même les nœuds. Il est
assembler littéralement des pièces de puzzle et il souffre du problème de
déterminer quelle pièce va où. Ils ne sont pas simples à mettre
ensemble

Le dimanche 22 mars 2015 à 5h46, todheil [email protected]
a écrit:

Bon point. Pour moi, les blocs sont la voie médiane entre les lignes de code et le flux
graphiques.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -84511415
.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -84575752.

David Aguiar de Aquino Paiva

David Aguiar de Aquino Paiva

Salut les gars! Belle discussion est ici :) Je voudrais ajouter quelque chose.

Première chose : je suis étudiant en art mais la programmation est mon hobby. Je connais Java, Python et (mon préféré) Golang. Mais avant d'apprendre à coder (il y a environ 3 ans), j'ai essayé presque tous les programmes qui prétendent permettre de "créer des jeux sans programmation". Toutes ces affirmations sont absurdes.

J'ai essayé (sans ordre particulier) : Click & Play, GameMaker, The Games Factory, Multimedia Fusion, Construct 1, RPG Maker, Stencyl, BGE et quelques autres dont je ne me souviens même pas. Et mon opinion est la suivante : vous pouvez créer un jeu sans _écrire_ de code, mais non sans _programmer_. Même si vous utilisez des feuilles d'événements ou des nœuds, vous devez toujours comprendre la _logique de la programmation_. Vous devez savoir ce qui est conditionnel, événement, variable, chaîne, etc. Il est donc impossible de créer un jeu sans programmation. Toutes ces méthodes visuelles de codage ne sont qu'une manière différente d'exprimer la logique qui se trouve dans les langages de programmation traditionnels. Tout cet argument peut sembler évident mais je vous assure, je n'étais pas évident pour moi au début de mon aventure avec la programmation.

De là découle ma considération suivante :

Le langage de programmation visuel le meilleur et le plus intuitif que j'avais trouvé avant d'apprendre à coder est Scrach/Stencyl puzzle/blocks way. Voici pourquoi:

• cette solution est la plus proche de la programmation traditionnelle. En fait, c'est juste quelque chose comme du sucre de syntaxe pour le code sous-jacent (en gros, c'est comme ça que Stencyl fonctionne) dans de belles structures comme des fonctions. Pour moi _c'est un gâchis
  N'oubliez pas que ce n'est que mon avis

* Je pense que les blocs Scrach/Stencyl sont les méthodes les plus visuelles et les plus faciles à suivre. Ils utilisent beaucoup la couleur (et les personnes visuelles aiment les couleurs). Il est facile de se rappeler que jaune = conditions et boucles, vert = mathématiques, bleu = variables, etc. Cela ressemble également à du vrai code (contrairement aux nœuds) mais plus convivial.

Enfin, je ne pense pas que la programmation visuelle devrait être la priorité de sitôt. Il y a beaucoup de choses plus importantes à faire (feuille de route complète + documentation) et je suppose que la mise en œuvre de l'un de ces systèmes ne serait pas rapide et facile. Godot est à mon humble avis vraiment facile à travailler tel qu'il est maintenant. Il contient de nombreux outils qui peuvent être utilisés par l'artiste en coopération avec les développeurs du jeu (éditeur visuel de shader, éditeur d'animation, nœud tilemap).

D'AILLEURS. J'aimerais saisir cette opportunité et remercier tous les créateurs et contributeurs de Godot. Tu as fait un excellent travail :+1:

BTW2. Je suis désolé pour mon anglais. Je fais de mon mieux mais je fais encore des bêtises :cry:

que ce soit construct2 ou blox - les deux sont plus agréables pour moi que ces graphes de nœuds.

Si le système utilise des nœuds uniquement comme conteneurs d'actions (en tant qu'états) - comme c'est le cas dans Playmaker, alors je serai d'accord avec ça.

La bonne chose à propos de blox et de construct2 est que l'éditeur vous montre toutes les conditions et actions disponibles. Il les sépare pour vous et les met en catégories. C'est un changement radical de présentation qui permet à un non-codeur de faire beaucoup de choses avec le moteur immédiatement - sans avoir besoin de connaître les noms des commandes pour faire les choses.

si vous utilisez des nœuds pour la programmation visuelle - le plus grand défi serait de communiquer à l'utilisateur dans quel ordre les événements sont exécutés. Dans Unity, le meneur de jeu et le blox le font très proprement.

Dans le meneur de jeu en empilant les actions à l'intérieur des conteneurs de nœuds (état - contient des actions). Dans blox - où vous avez des états qui contiennent des fonctions.

Ils donnent un accès complet à la plupart des fonctionnalités de l'unité. C'est vraiment sympa pour les non programmeurs.
blox a été développé en "plygame" - un autre addon d'unité qui a blox + des scripts personnalisés auxquels blox peut accéder afin de créer un jeu complet de style rpg hack and slash.

Blox dans l'unité est le même que les blocs Skrach/Stencyl. Il semble y avoir beaucoup de gens ici qui aiment ce style de programmation :)
https://www.youtube.com/watch?v=Nd6Qy5ZipSs&list=PLuaBtUXEKcdIAA7_yjFNcLXM5YOf3WE9k

J'espère que les développeurs de Godot essaieront.
Au fait, la technologie Skratch (https://scratch.mit.edu/) est open source ! Et d'autres l'ont adopté - pas seulement stencyl. Google s'y est également beaucoup intéressé :
https://developers.google.com/blockly/

proposition - Pourquoi ne pas essayer d'avoir le meilleur des deux mondes ! Nœuds pour une machine d'état - blox/skratch/stencyl pour les expressions.
Dans un monde idéal, vous auriez des nœuds utilisés comme conteneurs d'état - comme dans Playmaker. Mais le conteneur d'état aurait un système de type lego blox/stencyl/skratch qui permet à l'utilisateur de configurer facilement la logique - pas besoin d'apprendre à écrire des expressions de cette façon - ils sont juste prêts à être glissés et déposés.

http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code

L'un des développeurs d'iCanScript a déclaré ceci à propos de son actif VS :

L'avancement technique d'iCS2 le dissocie du fait qu'il ne s'agit que d'un produit Unity, ce qui augmente considérablement les opportunités de marché. La vision finale est qu'iCS2 sera une aide au développement qui peut être utilisée pour créer des scripts pour d'autres moteurs de jeu ainsi que des applications Windows/OSX/iOS/Android standard.
http://forum.unity3d.com/threads/icanscript-visual-script-modeling-engine-for-unity.280847/#post-2124402

quel gâchis de nœuds iCanScript est !

En tout cas ça vaut le coup d'essayer avant de juger. Peut-être que quelqu'un peut entrer
contact avec son développeur ?
Si godot avait une place de marché avec des opportunités de profit - comme celle
l'unité le fait - peut-être que cela inciterait les développeurs de l'unité à créer des actifs pour
godot aussi.

Le samedi 23 mai 2015 à 16h24, todheil [email protected] a écrit :

L'un des développeurs d'iCanScript a déclaré ceci à propos de son actif VS :

L'avancement technique d'iCS2 le dissocie du fait qu'il ne s'agit que d'Unity
produit considérablement> augmentant les opportunités de marché. La vision finale
est que iCS2 sera une aide au développement qui >peut être utilisée pour créer des scripts
pour d'autres moteurs de jeu ainsi que standard > Windows/OSX/iOS/Android
applications.

http://forum.unity3d.com/threads/icanscript-visual-script-modeling-engine-for-unity.280847/#post-2124402

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104895405.

Je pense que la feuille d'événement de Construct 2 est vraiment facile à comprendre et à programmer.

En tant qu'artiste qui passe la plupart de son temps à créer des graphiques pour gagner sa vie, apprendre une nouvelle langue est très difficile et prend du temps. Les gens disent que vous pouvez l'apprendre en quelques mois, mais lorsque vous n'avez que 2 heures par jour pour vous, vous pouvez choisir d'apprendre à partir de zéro ou de créer en utilisant un langage simple. De plus, être une personne visuelle, les scripts visuels ont plus de sens.

J'ai fait de la programmation à l'école et je peux lire et comprendre facilement le code, mais l'écrire prend du temps. J'essaie aussi d'apprendre python qui est plus facile mais il faudra encore des mois pour créer quelque chose avec.

L'approche de Construct 2 semble simple. Pour moi ça ressemble à :

1 Évènement : Action ;

2 Evénement : Action ;
: Action;

C'est essentiellement de la programmation mais d'une manière très facilement compréhensible. S'ils avaient utilisé juste un langage au lieu de bloquer, cela ne m'aurait pas dérangé. En utilisant ce modèle, il est facile de créer une logique pour moi.

L'utilisation de nœuds peut devenir incontrôlable très rapidement lorsque les choses commencent à se propager et que vous passez plus de temps à rechercher les nœuds qu'à coder réellement (d'après l'unité et le meneur de jeu).

Donc, si vous essayez d'implémenter un script visuel, réfléchissez très sérieusement au système d'événements de construction.

Vous pouvez également créer le système de script visuel en tant qu'extension téléchargeable pour des personnes comme nous afin que ceux qui préfèrent la programmation n'aient pas à télécharger cette charge utile supplémentaire.

Excellent travail avec Godot impatient de créer de grands jeux dessus.

Mon problème avec l'approche de Construct est que cela ressemble à de la programmation, c'est
ça n'a pas l'air si différent
Du point de vue de l'équipe, j'aime davantage l'approche blueprint d'Unreal parce que
c'est plus convivial pour les concepteurs qui n'ont aucune idée de la programmation

Le dimanche 24 mai 2015 à 03h58, whoisda [email protected] a écrit :

Je pense que la feuille d'événement de construct 2 est vraiment facile à comprendre et
programme dans.

En tant qu'artiste qui passe la plupart de son temps à créer des graphiques pour vivre,
apprendre une nouvelle langue est très difficile et prend du temps. Les gens disent que tu peux
l'apprendre en quelques mois mais quand on n'a que 2 heures par jour pour
vous-même, vous pouvez choisir d'apprendre à partir de zéro ou de créer à l'aide d'un
langage simple. De plus, être une personne visuelle, les scripts visuels rendent plus
sens.

J'ai fait de la programmation à l'école et je peux facilement lire et comprendre le code
mais l'écrire prend du temps. J'essaie aussi d'apprendre python qui est plus facile
mais il faudra encore des mois pour créer quelque chose avec.

L'approche de Construct 2 semble simple. Pour moi ça ressemble à :

1 Évènement : Action ;

2 Evénement : Action ;
: Action;

C'est essentiellement de la programmation mais d'une manière très facilement compréhensible. Si ils
avait utilisé juste un langage au lieu de bloquer, cela ne m'aurait pas dérangé. En utilisant ceci
pattern c'est facile de créer une logique pour moi.

L'utilisation de nœuds peut devenir incontrôlable très rapidement lorsque les choses commencent à se propager et
vous passez plus de temps à rechercher les nœuds qu'à coder réellement (comme je
entendu de l'unité et meneur de jeu).

Donc, si vous essayez d'implémenter un script visuel, veuillez donner un très
pensée sérieuse pour construire le système d'événement.

Vous pouvez également créer le système de script visuel sous forme de fichier téléchargeable
extension pour les gens comme nous afin que ceux qui préfèrent la programmation n'aient pas à le faire
télécharger cette charge utile supplémentaire.

Excellent travail avec Godot impatient de créer de grands jeux dessus.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159.

Mais vous êtes le point de vue d'un programmeur - quelqu'un qui sait déjà comment
programmer.
Il est préférable de regarder les statistiques dans ce cas - le nombre de
les utilisateurs non-programmeurs que construct2 a sur l'autre programmation visuelle
les éditeurs devraient parler pour eux-mêmes.

cela vaut également la peine d'examiner la variété des jeux créés dans un style de programmation visuelle plutôt qu'un autre.

Unreal a en effet un grand nombre de projets réalisés dans kismet - mais c'est un moteur beaucoup plus ancien que construct2 et beaucoup d'entre eux ne sont que des tireurs à la première personne

Le dimanche 24 mai 2015 à 10h15, Juan Linietsky [email protected]
a écrit:

Mon problème avec l'approche de Construct est que cela ressemble à de la programmation, c'est
ça n'a pas l'air si différent
Du point de vue de l'équipe, j'aime davantage l'approche blueprint d'Unreal parce que
c'est plus convivial pour les concepteurs qui n'ont aucune idée de la programmation

Le dimanche 24 mai 2015 à 03h58, whoisda [email protected] a écrit :

Je pense que la feuille d'événement de construct 2 est vraiment facile à comprendre et
programme dans.

En tant qu'artiste qui passe la plupart de son temps à créer des graphiques pour vivre,
apprendre une nouvelle langue est très difficile et prend du temps. Les gens disent que tu
pouvez
l'apprendre en quelques mois mais quand on n'a que 2 heures par jour pour
vous-même, vous pouvez choisir d'apprendre à partir de zéro ou de créer à l'aide d'un
langage simple. De plus, être une personne visuelle, les scripts visuels rendent plus
sens.

J'ai fait de la programmation à l'école et je peux facilement lire et comprendre le code
mais l'écrire prend du temps. J'essaie aussi d'apprendre python qui est
Plus facile
mais il faudra encore des mois pour créer quelque chose avec.

L'approche de Construct 2 semble simple. Pour moi ça ressemble à :

1 Évènement : Action ;

2 Evénement : Action ;
: Action;

C'est essentiellement de la programmation mais d'une manière très facilement compréhensible. Si
elles ou ils
avait utilisé juste un langage au lieu de bloquer, cela ne m'aurait pas dérangé. Utilisant
cette
pattern c'est facile de créer une logique pour moi.

L'utilisation de nœuds peut devenir incontrôlable très rapidement lorsque les choses commencent à se propager et
vous passez plus de temps à rechercher les nœuds qu'à coder réellement (comme je
entendu de l'unité et meneur de jeu).

Donc, si vous essayez d'implémenter un script visuel, veuillez donner un très
pensée sérieuse pour construire le système d'événement.

Vous pouvez également créer le système de script visuel sous forme de fichier téléchargeable
extension pour les gens comme nous afin que ceux qui préfèrent la programmation n'aient pas
à
télécharger cette charge utile supplémentaire.

Excellent travail avec Godot impatient de créer de grands jeux dessus.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159
.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104985669.

L'approche de programmation de Construct2 est très similaire à celle de
Clickteam fusion, qui compte également de nombreux utilisateurs. La facilité vient d'un
nombre de choses, même si cela s'apparente à la programmation :

• Avoir toutes les CONDITIONS possibles répertoriées et à la disposition de l'utilisateur pour sélectionner
  à ajouter en cliquant/glissant en langage clair - c'est inestimable
  parce qu'ils n'ont pas à apprendre les mots magiques. Ils peuvent simplement faire glisser et
  Laisse-les tomber.
• Avoir toutes les ACTIONS possibles répertoriées et disponibles pour l'utilisateur à sélectionner pour
  ajouter en cliquant/glissant dans un langage anglais simple - c'est inestimable
  parce qu'ils n'ont pas à apprendre les mots magiques. Ils peuvent simplement faire glisser et
  Laisse-les tomber.
• il en va de même lorsque vous faites n'importe quelle sorte d'expressions à la fois dans la configuration et
  une action ou une condition. Lorsque vous écrivez des expressions, l'éditeur vous aide
  avec une liste déroulante facile d'éléments à obtenir à partir d'objets existants dans le
  scène. Vous n'avez pas besoin d'apprendre comment accéder à ces propriétés car elles
  sont déjà disponibles en quelques clics.

Le meilleur aspect est peut-être qu'il enseigne aux non-programmeurs
théorie de la programmation sans la courbe d'apprentissage de l'apprentissage d'une nouvelle programmation
Langue.

Le dimanche 24 mai 2015 à 10h17, Todor Imreorov [email protected]
a écrit:

Mais vous êtes le point de vue d'un programmeur - quelqu'un qui sait déjà
comment coder.
Il est préférable de regarder les statistiques dans ce cas - le nombre de
les utilisateurs non-programmeurs que construct2 a sur l'autre programmation visuelle
les éditeurs devraient parler pour eux-mêmes.

Le dimanche 24 mai 2015 à 10h15, Juan Linietsky < [email protected]

a écrit:

Mon problème avec l'approche de Construct est que cela ressemble à de la programmation, c'est
ça n'a pas l'air si différent
Du point de vue de l'équipe, j'aime davantage l'approche blueprint d'Unreal parce que
c'est plus convivial pour les concepteurs qui n'ont aucune idée de la programmation

Le dimanche 24 mai 2015 à 03h58, whoisda [email protected]
a écrit:

Je pense que la feuille d'événement de construct 2 est vraiment facile à comprendre et
programme dans.

En tant qu'artiste qui passe la plupart de son temps à créer des graphiques pour vivre,
apprendre une nouvelle langue est très difficile et prend du temps. Les gens disent que tu
pouvez
l'apprendre en quelques mois mais quand on n'a que 2 heures par jour pour
vous-même, vous pouvez choisir d'apprendre à partir de zéro ou de créer à l'aide d'un
langage simple. De plus, être une personne visuelle, les scripts visuels rendent plus
sens.

J'ai fait de la programmation à l'école et je peux lire et comprendre le code
facilement
mais l'écrire prend du temps. J'essaie aussi d'apprendre python qui est
Plus facile
mais il faudra encore des mois pour créer quelque chose avec.

L'approche de Construct 2 semble simple. Pour moi ça ressemble à :

1 Évènement : Action ;

2 Evénement : Action ;
: Action;

C'est essentiellement de la programmation mais d'une manière très facilement compréhensible. Si
elles ou ils
avait utilisé juste un langage au lieu de bloquer, cela ne m'aurait pas dérangé. Utilisant
cette
pattern c'est facile de créer une logique pour moi.

L'utilisation de nœuds peut devenir incontrôlable très rapidement lorsque les choses commencent à se propager
et
vous passez plus de temps à rechercher les nœuds qu'à coder réellement (comme je
entendu de l'unité et meneur de jeu).

Donc, si vous essayez d'implémenter un script visuel, veuillez donner un très
pensée sérieuse pour construire le système d'événement.

Vous pouvez également créer le système de script visuel sous forme de fichier téléchargeable
extension pour les gens comme nous afin que ceux qui préfèrent la programmation n'aient pas
à
télécharger cette charge utile supplémentaire.

Excellent travail avec Godot impatient de créer de grands jeux dessus.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159
.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104985669.

Regardez-le également du point de vue d'un concepteur qui aimerait apprendre à coder une logique complexe et finalement devenir suffisamment confiant pour apprendre à coder. Je vois d'où vous venez car vous voyez que le système sera utilisé par une équipe de concepteurs et de programmeurs. Personnellement, j'aimerais utiliser Godot en tant qu'utilisateur unique et non en équipe avec un programmeur comme beaucoup de développeurs de jeux indépendants. Le système d'événements est indulgent et se sent plus organisé en utilisant des groupes lorsque vous avez plus de 1000 événements.

En dehors de cela, je n'ai aucun problème avec le système de nœuds et si Godot parvient à créer un système meilleur que l'actuel, je l'utiliserai à fond.

En outre, si possible, créez une fonction de recherche pour trouver facilement des blocs/nœuds de code.

Notez que les feuilles d'événement dans construct2/clickteam éliminent le besoin d'apprendre
syntaxe - pour que l'utilisateur n'ait pas à savoir où mettre les choses - c'est-à-dire
très évident. Conditions à gauche, actions à droite. L'ordre de
l'exécution des événements est également très évidente.
Les pièces Lego en scratch/stencyl/unity blox ne sont pas aussi évidentes, mais le sont quand même
bien mieux que le cauchemar des nœuds présenté dans "iCanScript". Avez-vous regardé
à leur tutoriel vidéo. C'est une conception de programmation visuelle super alambiquée
avec une courbe d'apprentissage assez raide. Je pense que même si vous le donnez à un
programmeur, ils auront du mal à comprendre

Le dimanche 24 mai 2015 à 10h33, whoisda [email protected] a écrit :

Regardez-le également du point de vue d'un designer qui aimerait apprendre
pour coder une logique complexe et finalement devenir suffisamment confiant pour apprendre à coder.
Je vois où vous voulez en venir car vous voyez que le système sera utilisé par un
équipe de concepteurs et de programmeurs. Personnellement, j'aimerais utiliser Godot comme
un seul utilisateur et non en équipe avec un programmeur comme beaucoup de jeux indépendants
développeurs. Le système d'événements est indulgent et se sent plus organisé en utilisant
groupes lorsque vous avez plus de 1000 événements.

En dehors de cela, je n'ai aucun problème avec le système de nœuds et si Godot parvient à
créer un système meilleur que l'actuel dont j'utiliserai la merde
ce.

Aussi, si possible, créez une fonction de recherche pour trouver des blocs/nœuds de code
facilement.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104988595.

Ils ne vendent même plus "icanscript" au magasin d'actifs Unity.
Regardez les chiffres de vente là-bas - lequel des programmes visuels disponibles
systèmes est le plus utilisé - et a des projets complets.

Je vous laisse juste avec cette vidéo :
https://www.youtube.com/watch?v=3Zq1yo0lxOU
Il a 167 jeux créés avec clickteam fusion - par des personnes qui n'ont pas
expérience en programmation.

Regardez aussi les jeux kickstarter à succès réalisés en fusion.
https://www.kickstarter.com/projects/alonsomartin/heart-forth-alicia/description
https://www.kickstarter.com/projects/galaxytrail/freedom-planet-high-speed-platform-game/description
https://www.kickstarter.com/projects/2064021040/tiny-trek

dois-je également mentionner Five Nights at Freddy's (réalisé en clickteam fusion):
http://en.wikipedia.org/wiki/Five_Nights_at_Freddy%27s_%28video_game%29
ce jeu est un best-seller. Voici quelques chiffres pour vous :
https://thinkgaming.com/app-sales-data/8779/five-nights-at-freddys/

L'idée d'un cadre de programmation visuelle devrait être de permettre à un artiste de créer un jeu sans avoir besoin d'un programmeur - dans le processus, apprenez un peu la programmation.

Si vous en créez un où le programmeur est toujours requis - alors vous n'avez pas vraiment créé de cadre de programmation visuel - vous venez de créer une machine d'état que les programmeurs peuvent configurer pour que les concepteurs l'utilisent - pour des choses simples dans le jeu - mais pas pour la logique de base du jeu. Vous n'allez donc pas vraiment créer quelque chose d'aussi bon et complet que les autres outils de programmation visuelle mentionnés ici. Vous ne donnez pas aux artistes les moyens de mettre en place une logique et de les inviter à apprendre les concepts de base de la programmation. Vous les gardez dépendants des programmeurs et dans l'obscurité de ces concepts.

Le dimanche 24 mai 2015 à 10h42, Todor Imreorov [email protected]
a écrit:

Notez que les feuilles d'événement dans construct2/clickteam éliminent le besoin d'apprendre
syntaxe - pour que l'utilisateur n'ait pas à savoir où mettre les choses - c'est-à-dire
très évident. Conditions à gauche, actions à droite. L'ordre de
l'exécution des événements est également très évidente.
Les pièces Lego en scratch/stencyl/unity blox ne sont pas aussi évidentes, mais sont
encore bien mieux que le cauchemar des nœuds présenté dans "iCanScript". Fait
vous regardez leur tutoriel vidéo. C'est un visuel super alambiqué
conception de programmation avec une courbe d'apprentissage assez raide. Je pense que même si
vous le donnez à un programmeur, il aura du mal à le comprendre

Le dimanche 24 mai 2015 à 10h33, whoisda [email protected]
a écrit:

Regardez-le aussi du point de vue d'un designer qui aimerait
apprendre à coder une logique complexe et finalement devenir suffisamment confiant pour apprendre à
code. Je vois où vous voulez en venir car vous voyez que le système sera utilisé par
une équipe de concepteurs et de programmeurs. Personnellement, j'aimerais utiliser Godot
en tant qu'utilisateur unique et non en équipe avec un programmeur comme beaucoup d'indie
développeurs de jeux. Le système d'événements est indulgent et se sent plus organisé
en utilisant des groupes lorsque vous avez plus de 1000 événements.

En dehors de cela, je n'ai aucun problème avec le système de nœuds et si Godot parvient à
créer un système meilleur que l'actuel dont j'utiliserai la merde
ce.

Aussi, si possible, créez une fonction de recherche pour trouver des blocs/nœuds de code
facilement.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104988595.

Je ne pense pas qu'il soit judicieux de vous pousser à utiliser un système qui fonctionne parfaitement pour un autre moteur de jeu si ce n'est pas la direction que vous voudriez prendre.

Sur la même note, j'aimerais voir une manière plus intuitive d'implémenter un script visuel. Ne pas utiliser les nœuds désordonnés ou les blocs qui prennent du temps (créateur d'applications Android) ou trop programmer le système d'événements (que je préfère à tout le reste). Quelque chose qui prend le meilleur de chacun d'eux.

Peut-être consulter un concepteur d'utilisabilité pour dégager certains chemins et examiner certains chiffres.

En fin de compte, ce serait formidable de voir une méthode unique à Godot qui fait de Godot un excellent moteur qui permet à la fois à un débutant de concevoir son premier jeu en une semaine et à une équipe de développement de collaborer pour créer un jeu AAA.

Je serais heureux de voir un système qui m'aiderait à créer des jeux merveilleux sans changer de moteur ni apprendre de langues très souvent.

Acclamations.

Cela ne me dérange pas les nœuds s'ils sont faits comme ceux de playmaker - comme
conteneurs d'action (états).
Les nœuds ne sont pas réellement utilisés pour définir des actions ou des conditions.

Si vous les faites cependant comme "iCanScript", vous avez un gâchis complet.

1. il est difficile de dire dans quel ordre les événements s'exécutent
2. Difficile de déterminer quel nœud peut être connecté à quel nœud
3. il faut beaucoup de nœuds et d'étapes pour configurer une seule action que pour
   faites-le glisser et déposez-le et configurez-y une expression (style construct2/clickteam
4. où vous êtes aidé avec la syntaxe - c'est un excellent moyen d'introduire
   quelqu'un à programmer sans l'obliger à lire des tonnes de
   documentation - tout est là pour eux dans le menu déroulant de la
   objet).

Le dimanche 24 mai 2015 à 11h20, whoisda [email protected] a écrit :

Je ne pense pas qu'il soit sage de vous pousser à utiliser un système qui fonctionne
parfaitement pour un autre moteur de jeu si ce n'est pas la direction que vous prendriez
vouloir prendre.

Sur la même note, j'aimerais voir une manière plus intuitive qu'un visuel
le script est implémenté. Ne pas utiliser les nœuds désordonnés ou prendre du temps
blocs (créateur d'applications Android) ou trop de programmation à la recherche d'un système d'événements (que je
préférer à tout le reste). Quelque chose qui prend le meilleur de chacun d'eux.

Peut-être consulter un concepteur d'utilisabilité pour dégager certains chemins et examiner certains
Nombres.

En fin de compte, ce serait formidable de voir une méthode unique à Godot qui rend
Godot un excellent moteur qui permet à la fois à un débutant de concevoir son
premier jeu en une semaine et une équipe de développement collaborant pour
créer un jeu AAA.

Je serais heureux de voir un système qui m'aiderait à créer des jeux merveilleux
sans changer de moteur ni apprendre de langues très souvent.

Acclamations.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104990083.

Je vote pour @whoisda en ce qui concerne quelque chose d'innové pour/dans Godot. Cependant, il semble y avoir trois écoles de Visual Scripting : 1) nœuds, 2) feuilles d'événements, 3) blocs. De ces trois nœuds semblent être en tête du peloton dans les environnements 3D. En parlant de cela, j'ai lu quelque part une idée suggérant que les scripts/programmations sortent d'un format linéaire (texte, blocs, feuille d'événement) ou horizontal (nœuds) et programment en 3D à l'aide de structures. Je ne sais pas comment cela fonctionnerait, mais cela semble fascinant.

Les écoles de script visuel mentionnées ont été testées dans la pratique et
ont déjà des utilisateurs. Je suggère de combiner les conceptions de Playmaker et
blox dans l'unité.

Nœuds pour créer une machine d'état.
Blocs ou feuilles d'événements pour créer les actions à l'intérieur de chaque nœud (état).

Le dimanche 24 mai 2015 à 13h56, todheil [email protected] a écrit :

Je vote pour @whoisda https://github.com/whoisda en ce qui concerne quelque chose
innover pour/dans Godot. Cependant, il semble y avoir trois visuels
Écoles de script : 1) nœuds, 2) feuilles d'événements, 3) blocs. De ces trois
les nœuds semblent être en tête du peloton dans les environnements 3D. En parlant de quoi
J'ai lu quelque part une idée suggérant que les scripts/programmation sortent d'un
format linéaire (texte, blocs, fiche événement), ou horizontal (nœuds) et
programme en 3D à l'aide de structures. Je ne sais pas comment cela fonctionnerait, mais ça sonne
fascinant.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105001411.

Ce serait formidable si nous pouvions utiliser des nœuds et des événements ensemble. Les nœuds peuvent les états qui, s'ils suivent une logique simple, peuvent être connectés à d'autres nœuds ou peuvent être des conteneurs pour des scripts/blocs/feuilles d'événements de cette façon, nous n'aurons pas de très grands nœuds et nous pourrons également collaborer en équipe. Mais cela pourrait être trop pour le développeur. Pourtant, l'idée semble être très soignée.

C'est un peu comme ça dans Playmaker - les gens semblent beaucoup l'aimer.
Beaucoup de gens ici semblent également aimer le stencyl - la technologie est
open source et disponible sur le site Web scratch github. Je l'ai partagé dans un
post précédent.

Personnellement, j'aimerais voir TOUS les premiers pas dans la programmation visuelle
direction. Même si le développeur crée une machine d'état qui fonctionne avec gd
scripts - ce serait un début incroyable que même les programmeurs avancés
j'apprécierais.

Ensuite, peut-être qu'après cela, nous pourrons avoir quelque chose de visuel comme stencyl ou
construct2 - c'est comme le code - mais beaucoup plus facile que le code - à l'intérieur du
États.

Donc, en fait, ce sont deux demandes de fonctionnalités !

• Un pour une machine d'état (nœuds)
• un autre pour un cadre de script visuel qui remplace l'apprentissage de gdscript
  avec codage par glisser-déposer. Mais c'est aussi une belle étape vers l'apprentissage
  gdscript.

En fin de compte, le développeur principal sait ce qui convient le mieux à la conception de Godot.

Le mardi 26 mai 2015 à 11h43, whoisda [email protected] a écrit :

Ce serait formidable si nous pouvions utiliser des nœuds et des événements ensemble. Les nœuds peuvent
états qui, s'ils suivent une logique simple, peuvent être connectés à d'autres nœuds ou
peuvent être des conteneurs pour les scripts/blocs/feuilles d'événements de cette façon nous n'aurons pas
de très grands nœuds et peuvent également collaborer en équipe. Mais c'est peut-être aussi
beaucoup pour le développeur. Pourtant, l'idée semble être très soignée.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105446984.

Je vais vérifier styencyl bientôt car je ne le connais pas.
à ce stade de tout ce que j'ai vu/lu, je peux comprendre que :

1) Blueprint : est idéal pour les concepteurs de jeux/niveaux, mais pas si bon pour
programmation visuelle
2) Stencyl : est bien meilleur pour la programmation visuelle, mais inutilisable pour
concepteurs de jeux/niveaux

Mon expérience dans la création de jeux a toujours été en équipe, donc je peux voir 1) comme étant
très utile, mais cela me rend également biaisé. Y a-t-il autant de monde
intéressé par la programmation visuelle comme dans Stencyl ?

Le mardi 26 mai 2015 à 6h10, Todor Imreorov [email protected]
a écrit:

C'est un peu comme ça dans Playmaker - les gens semblent beaucoup l'aimer.
Beaucoup de gens ici semblent également aimer le stencyl - la technologie est
open source et disponible sur le site Web scratch github. Je l'ai partagé dans un
post précédent.

Personnellement, j'aimerais voir TOUS les premiers pas dans la programmation visuelle
direction. Même si le développeur crée une machine d'état qui fonctionne avec gd
scripts - ce serait un début incroyable que même les programmeurs avancés
j'apprécierais.

Ensuite, peut-être qu'après cela, nous pourrons avoir quelque chose de visuel comme stencyl ou
construct2 - c'est comme le code - mais beaucoup plus facile que le code - à l'intérieur du
États.

Donc, en fait, ce sont deux demandes de fonctionnalités !

• Un pour une machine d'état (nœuds)
• un autre pour un cadre de script visuel qui remplace l'apprentissage de gdscript
  avec codage par glisser-déposer. Mais c'est aussi une belle étape vers l'apprentissage
  gdscript.

En fin de compte, le développeur principal sait ce qui convient le mieux à la conception de Godot.

Le mar. 26 mai 2015 à 11h43, whoisda [email protected]
a écrit:

Ce serait formidable si nous pouvions utiliser des nœuds et des événements ensemble. Les nœuds peuvent
états qui, s'ils suivent une logique simple, peuvent être connectés à d'autres nœuds
ou
peuvent être des conteneurs pour les scripts/blocs/feuilles d'événements de cette façon, nous ne le ferons pas
ont
de très grands nœuds et peuvent également collaborer en équipe. Mais cela pourrait être
trop
beaucoup pour le développeur. Pourtant, l'idée semble être très soignée.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105446984
.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105458142.

http://www.emanueleféronato.com/wp-content/uploads/2011/12/stencyl05.png

Est-ce un exemple canonique de ce à quoi ressemble le "code" stencyl ? Si oui, alors cela semble être une idée horrible : cela ressemble à un codage standard dans les emballages visuels pour la maternelle. Allez, python est déjà assez facile à lire pour ma femme, alors pourquoi ne pas faire un effort pour apprendre les bases ?

Si vous parlez de programmation visuelle, alors ce que Godot a déjà est bien meilleur - des graphiques de shader ou des graphiques d'animation : du code enveloppé dans des nœuds visuels.
https://frenchdog.files.wordpress.com/2009/09/specular_reflexion_vops.jpg - un autre exemple de programmation visuelle basée sur des nœuds (Sidefx Houdini, ou XSI). Il est mature et ne ressemble pas à un jouet pour enfants, me rappelle aussi les nœuds Godot.

J'ai aimé l'approche construct2, mais après avoir examiné de plus près, cela semble être un meilleur choix pour un certain nombre de raisons :

• La conception de la programmation semble être plus populaire que celle de construct2
• Il a déjà été établi comme un outil pour aider à enseigner aux gens un langage de programmation
• Il est open source et d'autres l'ont réutilisé pour leur moteur dans le passé

Les développeurs de Stencyl ont adopté la technologie open source "scratch". Ce n'est pas leur conception.
https://scratch.mit.edu/about/
http://en.wikipedia.org/wiki/Scratch_ (langage_de_programmation)
http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code

Exemples d'utilisation de Scratch par d'autres moteurs de jeu destinés aux non-programmeurs :

• Stencyl (le plus populaire) http://www.stencyl.com/
  
• Craftstudio ( http://craftstud.io/ )
  
• google en bloc ( https://developers.google.com/blockly/ )
• Le plus proche de Godot est l'atout de programmation visuelle "Blox" d'Unity :
  
  https://www.youtube.com/watch?v=Nd6Qy5ZipSs&list=PLuaBtUXEKcdIAA7_yjFNcLXM5YOf3WE9k
  Au lieu de Lua, il génère C#.
  sa documentation complète est ici:
  http://www.plyoung.com/blox/
  et est vendu ici : https://www.assetstore.unity3d.com/en/#!/content/12859

Cela peut sembler une idée horrible pour les programmeurs expérimentés, mais c'est la meilleure façon d'enseigner aux non-programmeurs comment écrire du code ou simplement de leur permettre de programmer sans connaître les mots magiques ou la syntaxe. Scratch les rend tous disponibles par glisser-déposer - forçant une structure correcte avec des indices visuels. Veuillez regarder la playlist de vidéos "Unity Blox" que j'ai postée pour la voir en action. Plus que toute autre chose, cela a été prouvé dans la pratique à maintes reprises. Cela ressemble au pari le plus sûr.

Je suis d'accord avec @reduz sur ses points selon lesquels l'un est bon en conception de niveau et l'autre en script visuel et je ne discute plus pour utiliser l'un plutôt que l'autre.

Utiliser les deux semble être la meilleure approche. Si ce n'est pas Unity blox, même si vous regardez Playmaker, vous verrez que les nœuds sont vraiment des conteneurs là-bas - où les actions peuvent être empilées - de manière très similaire à stencyl. Vous les faites glisser et les déposez à partir d'une liste !

"mais c'est le meilleur moyen d'enseigner aux non-programmeurs comment écrire du code ou simplement de leur permettre de programmer sans connaître les mots magiques"

Alors je ne comprends pas quel public est ce ciblage. Godot vise-t-il à concurrencer les grands du marché (Unreal Engine, Unity, etc.) ou à apprendre aux enfants à programmer/créer des jeux comme le fait Scratch (https://scratch.mit.edu/) ?

Je sais ce que sont les nœuds (entrée -> fonction avec paramètres -> sortie), je ne suis pas d'accord avec la présentation.

Stencyl et Playmaker sont peut-être géniaux pour apprendre aux enfants à coder, mais ils ont été utilisés avec succès par des non-programmeurs (studios et indépendants) pour créer des jeux à succès - vendus sur différentes plateformes.
Si vous classez Unity parmi les grands garçons, sachez que les grands garçons font aussi de la programmation visuelle.
http://www.hutonggames.com/showcase.html

Je pense que godot a beaucoup de fonctionnalités en place pour être utilisé par les grands garçons. Quelques fonctionnalités permettant aux petits / indépendants pourraient aider à une adoption plus rapide du moteur. Et la nature open source et les licences allégées sont très lucratives pour les débutants.

@blurymind
Je ne conteste _pas_ la programmation visuelle. Je dirais que Godot a déjà ce dont il a besoin (ShaderGraphs): la même approche visuelle pourrait être étendue à la programmation logique de la machine à états ou à la programmation générale. Ce à quoi je m'oppose, c'est contre l'adoption d'un autre paradigme visuel (~scratch) qui n'effraie pas les enfants.

comme indiqué précédemment, ce n'est pas seulement pour les enfants. Mais si même les enfants peuvent le comprendre et l'utiliser, je pense que c'est une bonne chose. Pas de quoi avoir honte.

Le point le plus important que je veux faire ici est que:

• l'ordre d'exécution des actions doit être clair ! Faire toute la logique avec les nœuds peut devenir très désordonné très rapidement. Les nœuds doivent donc être utilisés pour les états imo.
• Les développeurs de Playmaker ont très intelligemment anticipé ce problème et c'est pourquoi ils ont fait en sorte que les nœuds soient des conteneurs d'action dans lesquels - de manière très similaire à Stencyl - vous faites glisser et déposez les actions disponibles à partir d'une liste :
  
  et empiler les événements de cette façon

Vous obtenez une configuration de nœud très propre et efficace !

Je suggère aux développeurs de Godot d'essayer également le meneur de jeu.
Remplacer la pile d'événements par la logique Stencyl rendrait l'approche de Godot beaucoup plus flexible/puissante !.

Il n'est pas nécessaire que ce soit uniquement via une approche stencyl. Je pense que vous pouvez permettre aux programmeurs expérimentés d'attacher des scripts gd aux nœuds. Avoir la possibilité d'utiliser une approche stencyl pour créer des gdscripts serait inestimable imo. Il invitera de nombreux nouveaux utilisateurs dans la communauté godot.

@blurymind
D'accord, mais c'est quelque chose de différent. Facile à utiliser ne signifie pas qu'il doit ressembler à ce qu'il est destiné aux enfants.
L'ordre d'exécution et le filtrage assisté des entrées/sorties appropriées pour un nœud donné sont des problèmes courants pour les workflows basés sur des nœuds. Différents logiciels le résolvent différemment.

Vous devez vous demander - Voulez-vous que plus de non-programmeurs utilisent Godot ? Voulez-vous permettre aux personnes qui n'ont aucune expérience avec gdscript de faire quelque chose d'amusant ?

Si la réponse est oui, alors la meilleure façon de le faire est de leur donner une approche de script visuel.
Je ne suggère pas de faire ressembler les nœuds à quelque chose fait pour les enfants.
Ce que je suggère, c'est de diviser cela en deux projets !

• Nœuds utilisés comme machine d'état - comme dans Playmaker ! Les programmeurs peuvent nommer chaque nœud et y attacher des gdscripts - avec l'entrée et la sortie qu'ils configurent. Ce n'est donc pas du tout pour les enfants. En fait, il s'agit d'une approche beaucoup plus flexible pour les programmeurs qui est beaucoup moins salissante.
• Une feuille d'événements ou une interface de blocs par glisser-déposer comme alternative pour générer un GDscript. Ainsi, au lieu d'écrire un GdScript à attacher à un nœud, les non-programmeurs peuvent simplement empiler des actions à partir d'une liste de tous les événements disponibles dans godot - un peu comme Playmaker. Pour aller plus loin et innover - au lieu de simplement empiler des actions, il serait encore mieux d'utiliser Stencyl comme des blocs.

De cette façon, vous avez quelque chose qui est utile à la fois aux programmeurs et aux non-programmeurs. Ils peuvent tous deux utiliser la machine d'état (nœuds) et les non-programmeurs n'ont pas à apprendre gdscript tout de suite et utilisent gdBlocks à la place pour générer un gdscript pour un nœud (encore une fois - comme dans Playmaker).

@blurymind
J'aime mieux ça. De plus, il est cohérent avec Shader node-graph vs Shader-text qui est déjà dans Godot.

SideFX Houdini a quelque chose appelé VEX (https://goo.gl/TMWNKk) ("expression vectorielle" un langage de type c destiné à l'algèbre vectorielle). C'est un peu synonyme de gdScript. Il a également quelque chose appelé "VOPs" (http://goo.gl/Qpn2OE) (Vex Operators) - essentiellement des wrappers visuels d'un sous-ensemble de VEX, qui ressemble beaucoup à l'image de graphe de nœuds LeadWerks que vous avez référencée ci-dessus. En fait, les VOP peuvent être transformés en texte-script, si nécessaire (mais pas l'inverse).

La coexistence des 2 est assez naturelle et permet, même aux non-programmeurs, de créer du code très brouillon et inefficace ;)

Personnellement, j'aime l'approche Blueprint car c'est très game designer
comme, mais j'insiste sur le fait que je pourrais être partial.

J'ai téléchargé Stencyl il y a deux heures et j'ai joué avec. je pourrais être
erreur, mais je pense que Stencyl est un bon outil pour apprendre car non seulement le
la partie programmation est simplifiée mais la partie moteur aussi. La combinaison est
bien parce que c'est une approche de programmation simple pour un moteur de jeu simple.

Mais Godot n'est pas un simple moteur de jeu (du moins comparé à Stencyl) donc je
ne pense pas que la programmation simplifiée serait si utile. Stencyl s'appuie sur
beaucoup de choses logiques de jeu codées qui ne seront tout simplement pas disponibles dans
Godot, et essayer de le rendre disponible contredira l'objectif de Godot de
étant un moteur de jeu très polyvalent.

L'approche nœuds et graphes est plus intéressante à mon avis car c'est
un niveau inférieur et une manière plus flexible de faire les choses.

Le mar. 26 mai 2015 à 11h29, Vladimir Lopatin < [email protected]

a écrit:

@blurymind https://github.com/blurymind
J'aime mieux ça. Il est également cohérent avec Shader node-graph vs
Shader-text qui est déjà dans Godot.

SideFX Houdini a quelque chose de froid VEX (https://goo.gl/TMWNKk) ("vecteur
expression" un langage de type c destiné à l'algèbre vectorielle).
quelque peu synonyme de gdScript. Il a aussi quelque chose appelé "VOPs" (
http://goo.gl/Qpn2OE) (Opérateurs Vex) - essentiellement des emballages visuels d'un
sous-ensemble de VEX, qui ressemble beaucoup au graphe de nœuds LeadWerks que vous
référencé ci-dessus. En fait, les VOP peuvent être transformés en script, si nécessaire
(mais pas l'inverse).

La coexistence des 2 est assez naturelle et permet, même
non-programmeurs, pour créer du code très désordonné et inefficace ;)

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105543845.

Qu'en est-il de l'empilement d'action dans Playmaker et du blox dans Unity ? Unity n'est pas un moteur très simple.

Je pense que stencyl n'est pas un très bon exemple. Il est préférable de chercher des exemples dans le magasin d'actifs de l'unité.

J'ai essayé de comprendre le meneur de jeu mais j'ai échoué, comment est-il censé fonctionner ?

Le mar. 26 mai 2015 à 12h16, Todor Imreorov [email protected]
a écrit:

Qu'en est-il de l'empilement d'action dans Playmaker et du blox dans Unity ? L'unité n'est pas un
moteur très simple.

Je pense que stencyl n'est pas un très bon exemple. il vaut mieux chercher
exemples dans le magasin d'actifs Unity.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760.

vérifié le tutoriel du meneur de jeu, mais il semble être similaire à stencyl dans
le sens qu'il est livré avec un zillion de comportements prédéfinis

Le mar. 26 mai 2015 à 12h19, Juan Linietsky [email protected]
a écrit:

J'ai essayé de comprendre le meneur de jeu mais j'ai échoué, comment est-il censé fonctionner ?

Le mar. 26 mai 2015 à 12h16, Todor Imreorov < [email protected]

a écrit:

Qu'en est-il de l'empilement d'action dans Playmaker et du blox dans Unity ? L'unité n'est pas un
moteur très simple.

Je pense que stencyl n'est pas un très bon exemple. il vaut mieux chercher
exemples dans le magasin d'actifs Unity.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760
.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105563777.

_OkamStudio_

Le plus proche dans Unity des blueprints U4 est uScript :
https://www.assetstore.unity3d.com/en/#!/content/1808

Les gens semblent préférer Playmaker à uscript, car il est plus facile de comprendre la logique qui a été mise en place. Comme vous pouvez le voir sur les captures d'écran, cela devient très compliqué, même pour une logique simple.

@reduz @okamstudio voici une playlist sur playmaker :
https://www.youtube.com/watch?v=I9VwsVtbgFU&index=2&list=PLC759306A1E692A10
Je pense que vous devriez en fait l'utiliser un peu. Vous pouvez faire des comportements et des scripts prédéfinis, mais le meneur de jeu vous permet également d'accéder aux fonctionnalités de base du moteur et de créer vous-même de tels comportements à partir de zéro.

Oui, le meneur de jeu est une machine à états et l'unité s'accompagne de nombreux comportements prédéfinis.
Godot les a aussi - ils sont intégrés au moteur.
Je crois toujours que vous pouvez réellement créer un script/comportement à partir de zéro en utilisant le blox de clone stencyl d'Unity.

Je pense qu'enfin vous avez besoin d'un programmeur pour faire un bon jeu et cette idée
c'est super que les concepteurs de jeux créent le jeu eux-mêmes mais je pense que c'est beaucoup
de travail qui ne vient pas à portée de main dans de nombreux cas. mais si nous avons plus
fonctionnalité pour l'éditeur lui-même comme le concepteur de plate-forme que quelqu'un d'autre
mentionné dans un autre numéro ou d'autres choses utiles pour faciliter l'interface utilisateur
plus sympathique.
Le 26 mai 2015 à 19h52, "Okam Studio" [email protected] a écrit :

vérifié le tutoriel du meneur de jeu, mais il semble être similaire à stencyl dans
le sens qu'il est livré avec un zillion de comportements prédéfinis

Le mar. 26 mai 2015 à 12h19, Juan Linietsky < [email protected]

a écrit:

J'ai essayé de comprendre le meneur de jeu mais j'ai échoué, comment est-il censé fonctionner ?

Le mar. 26 mai 2015 à 12 h 16, Todor Imreorov <
[email protected]

a écrit:

Qu'en est-il de l'empilement d'action dans Playmaker et du blox dans Unity ? L'unité est
pas un
moteur très simple.

Je pense que stencyl n'est pas un très bon exemple. il vaut mieux chercher
exemples dans le magasin d'actifs Unity.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
<
https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760
.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105563777
.

_OkamStudio_

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105565084.

voici un avis sur Unity Asset Store pour uScript :

Bon outil, mais difficile à apprendre si un non-programmeur... les réponses aux demandes d'aide sur les forums sont très lentes ou n'existent pas du tout...

Quoi qu'il en soit dans Godot, je pense - si possible - que ce serait une bonne idée d'autoriser la conversion à sens unique vers GDScript. Cela permettrait de configurer rapidement les choses visuellement, par les concepteurs et les artistes, etc., puis de permettre aux codeurs de l'équipe de les peaufiner et de les retravailler davantage sans avoir à utiliser le pointy-clicky.

@adolson Ce serait une fonctionnalité très souhaitée :)

cela pourrait être fait, et pourrait également être fait avec l'éditeur visuel de shader
(qui, en fait, génère du code de shader)
mais je pense que le code de shader généré ne sera pas aussi lisible que vous pourriez
attendre :P

Le mardi 26 mai 2015 à 18h33, Nathan [email protected] a écrit :

@adolson https://github.com/adolson Ce serait très souhaité
caractéristique :)

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105670945.

@reduz Certaines métadonnées sont attendues.
Voici un exemple de conversion depuis VOPs -> conversion VEX, comme indiqué ci-dessus :
:
Et voici la liste complète du code , qui, sinon, en pur VEX ressemble à ceci :
@P += vecteur({0,1,0}); // prend Position et ajoute le vecteur (0,1,0)

Comme vous pouvez le constater, la quantité de métadonnées est importante, mais il n'est pas difficile de séparer les 2, éventuellement de les analyser de manière semi ou entièrement automatique.

@reduz C'est vrai. Je ne pensais pas vraiment à ça. Ce ne sera probablement pas le genre de code dans lequel la plupart des programmeurs voudraient passer leur temps. Je pourrais voir des étiquettes devenir des noms de variables et autres, mais je ne vois pas grand-chose d'autre pour atténuer le problème.

Bien que je ne puisse pas parler pour tout le monde, si je vois un gâchis de code, je peux en prendre quelques morceaux, mais je me sens généralement enclin à simplement le réécrire. Donc, si c'est le cas, cela n'en vaudrait pas la peine pour moi personnellement.

Vous avez vraiment parcouru toute la gamme des options. J'ai utilisé Construct 2 et bien qu'il soit soigné, vous ne pouvez jamais toucher à un code pour l'affiner et les options étaient plutôt limitées. La mise à jour du tilemap s'est essentiellement débarrassée des préfabriqués et donc de l'instanciation aussi. Celui que j'ai vraiment aimé était PlayMaker pour Unity.

Quelque chose à ce sujet était très facile à comprendre votre portée et ce que vous deviez faire. C'est un facteur vraiment attrayant, la raison pour laquelle j'aime utiliser des scripts visuels est précisément à cause de cela. Je perds de vue ce que je faisais ou ce que je devais faire dans le code textuel, mais voir comment tout "se connecte" a le plus grand avantage pour moi. NateWardog a publié un exemple dans une capture d'écran beaucoup plus tôt et blurrymind beaucoup plus récemment.

Je dis reduz, tu y vas. Pour l'instant, si vous voulez vous embêter, je tirerais pour la version 1.3 ou ultérieure et même alors je me concentrerais principalement sur le côté frontal. Ensuite, lorsqu'il sera prêt plus tard, concentrez-vous sur l'obtention d'un code lisible comme Blueprint, ce qui, j'imagine, serait très difficile. S'il vous plaît ne sous-estimez pas celui-ci!

Abonnement. ça m'intéresse beaucoup aussi ! Je connais certains scripts et cela ne me dérange pas vraiment de les utiliser ... mais je préfère tellement connecter des nœuds à cela lorsque cela est possible! Quelque chose comme les briques logiques de Blender Game Engine, qui agissent comme des raccourcis visuels pour les fonctions de script Godot comme une alternative à leur écriture à la main... ce serait une fonctionnalité intéressante et que j'attends activement.

les scripts visuels attirent vraiment beaucoup de créatifs ou de personnes qui ne veulent pas apprendre un nouveau langage de script comme gd script. Je regardais Game Maker est tellement populaire et la raison la plus donnée est le mécanisme de script visuel.

Les scripts visuels sont fastidieux, stupides et difficiles à utiliser.
Je ne vois jamais une bonne mise en œuvre. Les personnes visuelles doivent dessiner des graphiques. je
sais que beaucoup de gens ne savent tout simplement pas écrire,
mais cela ne leur fera aucun bien. Personne qui ne programme pas ne veut pas dire
personne analphabète.

Je ne connais aucun outil de construction de logique visuelle, qui était le système principal pour
logique de jeu dans n'importe quel moteur.
La manière visuelle aspire à bien des égards. Les visuels considèrent généralement
la programmation comme "truc technique"
ce qui signifie quelque chose de réel de plomberie et de travail acharné, et je veux être au-dessus
ce. Cette attitude
est généralement dû à des problèmes intellectuels. Je ne pense pas que ce peuple
peut être un public cible
fondamentalement, ils limitent leur créativité.

Le jeu 14 avril 2016 à 8h33, Rémi Verschelde [email protected]
a écrit:

Edit : je vois que tu as changé "RPG Maker" pour "Game Maker", maintenant ça fait plus
sens :p Suppression de mon message.

—
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment -209770726

Je ne veux pas, mais je dois le dire, mais c'est une vision très étroite des outils de script visuel, Sergey. En ce qui concerne les jeux qui ont été entièrement créés avec eux, certains moteurs les ont complètement désactivés, tels que Construct, vous ne verrez donc aucun jeu de ce moteur créé avec des scripts réguliers. D'autres moteurs (plus sains, imo) ont des plugins tels que Unity et UE4. Personnellement, j'ai vraiment aimé utiliser à la fois uscript et PlayMaker dans Unity avec mon code habituel, car si certaines choses sont plus faciles à coder, beaucoup sont plus faciles à scripter visuellement, en particulier les machines à états, car avec un script visuel comme PM, cela vous donne beaucoup de commentaires avec points d'arrêt, il est tellement plus facile de regarder le projet d'un point de vue plus étendu.

La vraie chose à propos des scripts visuels en général, c'est une vaine tentative de
rendre la programmation accessible aux non-programmeurs, ce qui est totalement faux
approcher.
La programmation visuelle est plus difficile que la programmation textuelle normale. Pour le faire
plus facile, vous devez écrire de nombreux blocs pour chaque cas dans la vie en traditionnel
chemin et
laissez ces gens les utiliser. Celles-ci se sont avérées moins efficaces que de demander à un
bon programmeur pour écrire du code. Le révélateur "la programmation n'est pas un métier,
tout le monde peut le faire" est faux. Toutes les tentatives de programmation sans
la programmation est un gâchis.

Quant à la machine d'état - je pensais à l'implémenter quelque temps
il y a, mais cela n'aidera pas le programme de haute qualité visuelle.
Cela peut être facilement fait pour votre jeu en utilisant le script d'outil et l'éditeur de nœuds,
qui est un outil puissant, beaucoup de gens l'utilisent pour des outils de jeu, comme
éditeurs de dialogue de jeu.

Le jeudi 14 avril 2016 à 9h09, Aaron M [email protected] a écrit :

Je ne veux pas avoir à le dire, mais c'est une vision très étroite du visuel
outils de script, Sergey. Quant aux jeux entièrement réalisés avec eux,
certains moteurs les ont complètement désactivés, tels que Construct, vous
ne verra aucun jeu de ce moteur créé avec des scripts réguliers. Autre
(plus sain d'esprit, imo) a des plugins tels que Unity et UE4. Personnellement, je
j'ai vraiment aimé utiliser à la fois usscript et PlayMaker dans Unity aux côtés de mes habitués
coder parce que si certaines choses sont plus faciles à coder, beaucoup sont plus faciles à
script visuellement, en particulier les machines d'état car avec un visuel
scripter comme PM, il vous donne beaucoup de commentaires avec des points d'arrêt, c'est juste
tellement plus facile de regarder le projet d'un point de vue plus étendu.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment -209776732

Clapin, tu as raison. Mais vous oubliez que la programmation visuelle ou les blocs de programmation ont un taux d'échec très faible. C'est à cause des limites.
C'est fondamentalement la même chose lorsque vous prenez un langage de script très limité. Vous ne pouvez pas faire beaucoup d'erreurs.

Je pense que cela devrait être l'objectif à atteindre, pas la question de savoir si Visual- ou Text-Scripting !

Si vous voulez améliorer la programmation, améliorez les outils. Codehighlighting, Codecompletion, Codevalidation, Codetemplates, etc. Améliorez le débogueur et améliorez la programmation en direct.
J'ai toujours cherché un environnement de programmation Live stable, mais jusqu'à présent je ne l'ai pas trouvé !

Si vous voulez vraiment créer des scripts visuels, faites-le comme le moteur Stingray. Vous pouvez créer des CodeBlocks dans Visual et générer du TextCode que vous pourrez modifier ultérieurement, ou écrire du TextCode que vous pourrez utiliser ultérieurement comme Visual Blocks.

Je ne dirais pas que c'est futile, mais je dirais qu'on parle de 2
des produits complètement différents.

Si vous dirigez un studio et que vous créez des jeux avec, disons, 20 à 80 personnes,
vous dépensez 6 chiffres en coûts de production chaque mois, et vous avez besoin d'un
moteur pour faire vos jeux, vous voulez un certain produit. Dans ce cas, vous
ne vous souciez pas du tout des outils de script visuel, vous vous souciez des autres
des choses, comme la productivité de votre équipe avec les outils du moteur
(puisque s'ils dépassent le calendrier pendant un mois, vous perdez environ 100 000 $). Celles
les équipes ont des programmeurs, et ils seront beaucoup plus productifs en écrivant du code
que d'utiliser un outil visuel (recherchez Vicious Engine pour un exemple de cela)

D'un autre côté, si vous avez une idée géniale et que vous ne savez pas vraiment comment
écrire du code, vous voulez un autre produit, quelque chose à faire un prototype rapide qui
vous pouvez montrer et éventuellement donner aux programmeurs pour faire le réel
Jeu.

C'est 2 produits différents, et si on se dispute pour savoir lequel vaut le plus
avoir, nous devons le reconnaître. Je dirais que le script visuel
l'outil ne s'adapte pas vraiment à plus d'une personne réalisant un prototype. Comme
dès que vous voulez faire un jeu complet, ou dès que votre équipe passe à 2-3
gens, vous avez déjà besoin d'un vrai langage de programmation. Alors j'aime bien le premier
exemple plus comme un objectif global (sauf si vous voulez un 3ème produit, qui est
"le moteur que vous pouvez utiliser pour créer un jeu indépendant complet qui rapporte des millions
sans écrire de code". Cela n'existe pas).

Mais nous pouvons avoir les deux, et je ne découragerais ni l'un ni l'autre. Un visuel
outil de script nous aiderait à long terme, en créant des utilisateurs débutants
qui finira par travailler sur l'industrie et sera en mesure de décider de
utiliser godot pour un vrai jeu, et c'est bien. Aussi, le CTO de Square Enix
nous a demandé si le moteur avait un langage de prototypage visuel, donc ça veut dire
il y a aussi un créneau dans les grandes entreprises pour ce genre de choses, probablement celles
qui valorisent la R&D et ont de longues étapes de
préproduction/prototypage/expérimentation de nouvelles idées, etc. (il a également dit
nous que nos jeux ressemblaient à des jeux de console et demandé (deux fois) quel pays
sommes-nous allés apprendre à les fabriquer :p ).

Le 14 avril 2016 à 03h26, Sergey Lapin [email protected] a écrit :

La vraie chose à propos des scripts visuels en général, c'est une vaine tentative de
rendre la programmation accessible aux non-programmeurs, ce qui est totalement faux
approcher.
La programmation visuelle est plus difficile que la programmation textuelle normale. Pour le faire
plus facile, vous devez écrire de nombreux blocs pour chaque cas dans la vie en traditionnel
chemin et
laissez ces gens les utiliser. Celles-ci se sont avérées moins efficaces que de demander à un
bon programmeur pour écrire du code. Le révélateur "la programmation n'est pas un métier,
tout le monde peut le faire" est faux. Toutes les tentatives de programmation sans
la programmation est un gâchis.

Quant à la machine d'état - je pensais à l'implémenter quelque temps
il y a, mais cela n'aidera pas le programme de haute qualité visuelle.
Cela peut être facilement fait pour votre jeu en utilisant le script d'outil et l'éditeur de nœuds,
qui est un outil puissant, beaucoup de gens l'utilisent pour des outils de jeu, comme
éditeurs de dialogue de jeu.

Le jeudi 14 avril 2016 à 9h09, Aaron M [email protected] a écrit :

Je ne veux pas avoir à le dire, mais c'est une vision très étroite du visuel
outils de script, Sergey. Quant aux jeux entièrement réalisés avec
eux,
certains moteurs les ont complètement désactivés, tels que Construct, vous
ne verra aucun jeu de ce moteur créé avec des scripts réguliers. Autre
(plus sain d'esprit, imo) a des plugins tels que Unity et UE4. Personnellement, je
j'ai vraiment aimé utiliser à la fois usscript et PlayMaker dans Unity aux côtés de mes habitués
coder parce que si certaines choses sont plus faciles à coder, beaucoup sont plus faciles à
script visuellement, en particulier les machines d'état car avec un visuel
scripter comme PM, il vous donne beaucoup de commentaires avec des points d'arrêt, c'est
juste
tellement plus facile de regarder le projet d'un point de vue plus étendu.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail ou consultez-le sur GitHub
< https://github.com/godotengine/godot/issues/1220#issuecomment -209776732

—
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment -209779422

Vous parlez juste devant moi punto slapin, je veux dire, je n'ai jamais rien dit sur les concepteurs ou la simplification, mais sur la facilité d'utilisation même pour les programmeurs, dont j'ai expérimenté l'utilité. Ce n'est pas comme si vous pouviez simplement me dire que c'est une perte de temps alors que j'ai une expérience anecdotique montrant exactement le contraire. Je préfère de loin que l'option soit disponible _alongside_ scripting, vous agissez comme si je ne pouvais choisir que l'un ou l'autre et je suis obligé de le confier à mon artiste. Pas du tout le cas.

Super fil, plein d'avis 😁

Le mien est simple. Vous allez bien !

Chacune de ces idées sera un excellent ajout à gdscript 😁

J'ai hâte de les essayer quand ils apparaîtront.

Je pense que gdscript aurait également besoin d'un peu d'amour pour être plus convivial.

Certains nœuds ne sont pas entièrement documentés. Beaucoup n'ont pas de descriptions.
Godot pourrait utiliser certaines fonctions d'assistance pour simplifier le développement. Gamemaker gml en est un bon exemple :
https://twitter.com/uheartbeast/status/724326557108461568

Je pense que la documentation est un PITA majeur ici, et c'est tout.
Le développement lui-même est assez simple. La documentation et les tutoriels
sont vraiment nécessaires. Il suffit donc de rendre votre compte youtube utile (ou votre blog, ou
il suffit de poster sur le forum),
cela fera beaucoup d'aide.

Le lundi 25 avril 2016 à 9h35, Todor Imreorov [email protected]
a écrit:

Je pense que gdscript aurait également besoin d'un peu d'amour pour être plus convivial.

Certains nœuds ne sont pas entièrement documentés. Beaucoup n'ont pas de descriptions.
Godot pourrait utiliser certaines fonctions d'assistance pour simplifier le développement.
Gamemaker gml en est un bon exemple :
https://twitter.com/uheartbeast/status/724326557108461568

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment -214163012

Eh bien, j'ai plusieurs idées à ce sujet.
Vous pouvez faciliter l'approche d'un moteur en incluant quelque chose comme des scripts visuels, et ce serait bien pour tous les artistes qui veulent se lancer dans la création de jeux mais n'ont simplement aucune expérience en programmation, mais cela invite un tout autre ensemble de personnes - à savoir , des gens sans aucune compétence. Les personnes pour qui le passage à la programmation dans un éditeur de texte ne sera jamais à l'ordre du jour, même si cela signifie que le jeu final en souffrira. Les gens qui pensent que la seule chose difficile dans la création d'un jeu est la programmation, et qu'avec les scripts visuels, du coup, cette restriction est levée. Ce n'est pas rare non plus. Regardez tous les moteurs populaires qui facilitent certaines choses pour les non-programmeurs - des tonnes de shovelware. Je ne dis pas que vous ne devriez pas inclure de scripts visuels parce que cela signifie que nous courons le risque d'obtenir des shovelwares, mais qu'ils devraient être implémentés de manière à décourager ces types de personnes de penser qu'ils peuvent simplement utiliser Godotengine pour créer lesdits shovelware.
Mon autre problème est que l'une des choses pour lesquelles Godotengine est bon, et beaucoup de gens aiment cette fonctionnalité, c'est qu'elle fonctionne très bien avec git. Le problème avec les scripts visuels est qu'ils sont souvent enregistrés dans un format binaire, et c'est un cauchemar à gérer si vous utilisez n'importe quel type de révision du code source. Si vous devez implémenter des scripts visuels, ils doivent être enregistrés de manière conviviale. Et si c'est impossible, bien dur. Je préfère avoir des fichiers de projet dans Godotengine dans un format compatible avec git plutôt que d'avoir des scripts visuels qui ne fonctionnent pas bien avec git.
Et à en juger par tout le travail requis pour implémenter un système de script visuel, et le fait que vous pouvez créer certains types de jeux dans Godotengine sans script visuel sans aucune perte de fonctionnalité, d'efficacité ou de performance, quel est le problème avec le simple fait de l'implémenter comme un plugin ? Je ne vois vraiment aucune raison pour laquelle cela doit être une partie essentielle du moteur.

Juste pour ajouter mes 2 cents sur les scripts visuels et pourquoi je n'aime pas l'idée :

Je pense que la possibilité de connecter des nœuds dans n'importe quel fichier gdscript est bien meilleure, en termes de gestion de code et de compétence.

Par exemple, avec des scripts visuels (ou en utilisant une feuille d'événement similaire à C2), que se passe-t-il si vous avez plus de 1 000 fonctions ? Cela rendra les choses bien pires, je crois, pour naviguer à travers tout. Je suis en train de porter mon jeu HTML 5 Action RPG en ce moment dans Godot (qui fait plus de 10k + lignes de code et bien plus de 500 fonctions). _(Il a pratiquement toutes les fonctionnalités de Path of Exile, à l'exception des animations et est multijoueur)_

Il n'y a aucun moyen que cela soit possible pour moi avec des scripts visuels. Je pense que nous, et les développeurs de godot ici, devrions nous concentrer davantage sur les fonctionnalités / l'élimination des bogues qu'une feuille d'événement de code visuel. Mais ce n'est que moi :)

Edit : Comme d'autres l'ont dit, peut-être pour des projets plus petits, je suppose... mais tout ce qui est gros, je ne le vois tout simplement pas utile

La feuille d'événement dans construct2 prend en charge les fonctions et elles fonctionnent de la même manière que les godots. Un simple filtre / champ de recherche résoudra tous les problèmes que vous avez répertoriés.

Mais les développeurs de Godot ne veulent pas faire une approche de feuille d'événement même si c'est populaire. J'ai l'impression que c'est plus susceptible d'obtenir quelque chose qui ressemble à l'approche irréelle du plan directeur. De cette façon, les programmeurs bénéficieront d'un éditeur de machine d'état ajouté à leur arsenal

Pour organiser le code de script visuel dans vonstruct2 , placez-le dans des groupes qui peuvent être réduits. C'est quelque chose que même gdscript ne peut pas faire - vous ne pouvez pas réduire des blocs de code. Donc, à certains égards, la feuille d'événement présente des avantages par rapport à l'éditeur gdscript de godots.

@reduz Je regardais Pure Data et la façon dont ils le font est très simple. Eh bien regarde ça

Comme vous pouvez le voir, taper "Bang" transforme l'objet générique en un objet Bang.

Et si les scripts visuels pouvaient simplement devenir une extension de GD Script. Placez simplement un nœud générique et tapez Vector2 pour ex et il deviendra un objet Vector2. Donc, essentiellement, chaque classe/objet est également un nœud.

Pour exécuter des fonctions, je pense que vous pouvez obtenir un autre nœud qui n'est pas un objet mais plutôt un nœud de processus et vous tapez quelque chose comme Vector2.dot et le nœud se transformera en nœud point avec 2 entrées et 1 sortie.

le script visuel est prévu à un moment donné

Tu n'as pas déçu :) <3

Puisqu'il existe déjà VisualScripting, ce problème doit-il être clos ?

Oui.

"J'ai aussi souri de manière positive.
Parce que ce serait formidable pour moi en tant que joueur s'il y avait une entreprise aussi grande que Steam avec des tonnes de catalogues de jeux, ouverts et sans DRM, créés par des milliers de grands développeurs de jeux."
il suffit de regarder gog, c'est un magasin qui vend des jeux gratuits drm.

Réponse hors sujet à une déclaration de 2015, allez :)