Godot: Einfach zu bedienender Spieledesigner für Nicht-Programmierer

Visual Scripting ist irgendwann geplant

Am Mittwoch, den 14. Januar 2015 um 6:20 Uhr schrieb RyanBram [email protected] :

Hallo, Godot-Entwickler.

Zunächst möchte ich mich bei Ihnen allen für die Erstellung einer großartigen Spiel-Engine bedanken
mit sehr freizügiger Lizenz. Ihre Bemühungen werden vielen Entwicklern helfen und
Studenten mit knappem Budget, um sich ihren Traum zu erfüllen.

Mit dem aktuellen Status von Godot wird Open-Source-Gaming eine bessere Zukunft haben.
Leider sind die meisten Open-Source-Spiele-Engines mit fortgeschrittenen Designs ausgestattet
Benutzer mit wenig Programmierkenntnissen. Es kann immer noch nicht erreichen
ein Spielemacher für Anfänger.

Mein Vorschlag ist, einen einfach zu bedienenden Spieledesigner/-editor bereitzustellen
intuitive GUI und vordefinierte Klasse, um die Aufgabe neuer Programmierer zu erleichtern. Mehr
Programmierer bedeutet mehr Benutzer (weil Godot-Benutzer Spieleprogrammierer sind).

Ich kenne eine Spiel-Engine, die diesen Job gut macht. Es ist von Ruby geschrieben,
ursprünglich aus Japan und weltweit ins Englische übersetzt. Es heißt Rollenspiel
Maker VX Ace
http://www.rpgmakerweb.com/products/programs/rpg-maker-vx-ace. Trotz
das RPG-Wort vor seinem Namen, ist es in der Lage, Nicht-RPG zu erstellen
Spiel mit seinem eingebauten Ruby Game Scripting System (RGSS).

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

Die folgende Liste ist ein Beispiel für Spiele, die mit der RPG Maker-Engine erstellt wurden:

1. Aleph (Rollenspiel-Abenteuer) http://www.pioneervalleygames.com/
2. Keine Seekühe versprochen (Arcade) http://rpgmaker.net/games/5102/
3. Ragarokk – Bestiarium (Kartenspiel) http://rpgmaker.net/games/5808/
4. Erde unter Beschuss! (Shooter) http://rpgmaker.net/games/6561/
5. Terra (VisualNovel) http://rpgmaker.net/games/3956/
6. Erinnerungen an Mana (Action-Rollenspiel)
   http://www.atelier-rgss.com/Project/Mana/Project_Mana_Story.html
7. Myhos – Der Anfang (Horror) http://rpgmaker.net/games/6493/

Ich wünsche mir, dass die Godot-Engine so beliebt wird wie RPG Maker, weil sie viel hat
mehr Funktionen als RPG Maker. Programmieranfänger brauchen nur eine einfach zu bedienende
Schnittstelle. Wenn es erfolgreich war, könnte Okam Studio das nächste GOG oder Steam werden
die Tausende von Spielen veröffentlichen, die von unabhängigen Entwicklern erstellt wurden.

Grüße, Ryan

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220.

@RyanBram - Ich versuche hier überhaupt nicht, die Idee abzulehnen - sie könnte in Zukunft wahrscheinlich nützlich sein, aber ich bin mir nicht sicher, ob visuelles Skripting ein effektives Mittel zum Skripten ist. Ich kann es nicht mit Sicherheit sagen, aber ich würde mir vorstellen, dass die komplexeren Spiele, die Sie gepostet haben, höchstwahrscheinlich in Text und nicht in visueller Form geschrieben wurden. Es scheint, als wäre Visual Scripting etwas, das neue Benutzer verwenden, aber das verzögert sie beim Erlernen der eigentlichen Tools, die sie benötigen, um ihre Projekte ordnungsgemäß abzuschließen. Aber es könnte den Motor zugänglicher machen, also weiß ich es nicht.

Es sollte Benutzern auch möglich sein, ein visuelles Programmiersystem in Godot mit GDScript zu erstellen, im Gegensatz zu etwas, das in die Engine eingebaut werden muss, oder? Da bin ich mir aber nicht sicher.

Der RPG-Hersteller scheint eher einen "Modding" -Ansatz zu verfolgen, und wenn Godot eher wie der RPG-Hersteller aussehen wird - Leute, die die Absicht haben, andere Arten von Spielen zu machen, werden sich abwenden. Was Sie also im Grunde vorschlagen, ist, Godot eher wie GameMaker aussehen zu lassen (was verständlich ist, viele Leute wollen Spiele machen, kennen sich aber nicht mit Programmieren aus), aber es gibt Einschränkungen :)
Was wahrscheinlich passieren wird, ist, dass Godot den Nodal Behavior Graph Editor bekommt, ähnlich wie Leadwerks und BGE. Dies funktioniert sehr gut mit GUI-Elementen, der Rest würde einige Recherchen und jede Menge Community-Feedback erfordern, um es so einfach und leistungsfähig wie möglich zu machen.

@SolarLune , es ist möglich, ein Spiel in Godot zu erstellen und einen Editor hinzuzufügen, der es ermöglicht, das Spiel bis ins kleinste Detail zu modifizieren (unter Verwendung von GraphNodes und dem Rest der Benutzeroberfläche, sehr lustig zu spielen) und sogar erlauben würde, einige zu schreiben zusätzlichen GDscript-Code oben drauf, ich denke, das ist der beste Ansatz, um ein komplettes Spiel (RPG, FPS, RTS) separat zu liefern und jeden Aspekt davon zu optimieren. Konstrukteure aus Godot.

@SolarLune : Visual Scripting ist nützlich, wenn Sie mit a zusammenarbeiten
Programmierer, der Blöcke erstellen kann, mit denen Sie spielen können. Dies
Ansatz in Unreal ist nützlich. Ich glaube nicht, dass ein Austausch möglich ist
vollständig programmieren (es sei denn, Sie sind ein Masochist), aber es könnte funktionieren
Einige Leute erstellen Vorlagenblöcke auch für Nicht-Programmierer.

Am Mittwoch, den 14. Januar 2015 um 16:23 Uhr schrieb TheoXD [email protected] :

Der RPG-Hersteller scheint eher einen "Modding" -Ansatz zu verfolgen, und wenn Godot es will
sehen eher aus wie RPG-Hersteller - Leute, die die Absicht haben, etwas anderes zu machen
Art von Spielen wird sich abwenden. Was Sie also im Grunde vorschlagen, ist
Godot eher wie GameMaker aussehen lassen (was verständlich ist, viele Leute
Ich möchte Spiele machen, kenne mich aber nicht mit Programmieren aus), aber es gibt eine Grenze :)
Was wahrscheinlich passieren wird, ist, dass Godot Nodal Behavior Graph erhält
Editor, ähnlich wie bei Leadwerks und BGE. Das funktioniert sehr gut mit
GUI-Elemente, der Rest würde einige Recherchen und jede Menge Community erfordern
Feedback, um es so einfach und wirkungsvoll wie möglich zu machen.

@SolarLune https://github.com/SolarLune , es ist möglich, ein Spiel zu bauen
in Godot und fügen Sie oben einen Editor hinzu, der das Modden des Spiels für jeden ermöglicht
wenig Detail (durch die Verwendung von GraphNodes und dem Rest der Benutzeroberfläche) und würde es sogar erlauben
schreiben Sie etwas zusätzlichen GDscript-Code oben drauf, ich denke, das ist der beste Ansatz,
um ein komplettes Spiel (RPG, FPS, RTS) separat zu versenden und Anpassungen zu ermöglichen
jeden Aspekt davon.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220#issuecomment -69974733.

Nun, soweit ich weiß, hat Godot bereits knotenbasierten UI-Code (für den Animationsbaum und jetzt den visuellen Shader-Editor), der in Zukunft verwendet werden kann, um einen "logischen" Baumtyp zu erstellen.

Man muss jedoch beachten, dass GDscript der richtige Weg bleibt, wenn Sie maximale Flexibilität wünschen, und um die Logikknoten nützlich zu machen, wäre ein Skriptknoten für die GDscript-Ausführung erforderlich (für komplexere und fortgeschrittenere Dinge).

UE4 kann derzeit nicht alles in Blueprints ohne wahnsinnige Komplexität erledigen, GameMaker erwartet, dass Sie GML für maximale Flexibilität verwenden (durch die Verwendung von Codeblöcken), und das BGE erfordert Skripting in Python für maximale Leistung (durch die Verwendung von Codebausteinen). Man kann die Nützlichkeit der visuellen Bearbeitung für schnelles Prototyping und weniger komplexe Logiksituationen nicht außer Acht lassen, aber sie kann oft nicht alles tun, was man im Code tun kann.

Visual Scripting ist irgendwann geplant

Vielen Dank für die einfache und positive Antwort.

Vielen Dank, dass Sie diesen Vorschlag kommentiert haben. Ich glaube, dass ein einfacher und visueller Editor niemals in der Lage ist, das Codieren von Hand zu ersetzen. Ich schlage diese Funktion als Ergänzung zur regulären Codierung vor, nicht um ihre Position zu ersetzen.

In RPG Maker VX Ace werden die meisten erweiterten Funktionen von Hand codiert. Ein fortgeschrittener Programmierer stellt normalerweise ein fortgeschrittenes Modding-Skript zur Verfügung, dessen Wert im GUI-Editor von gelegentlichen Benutzern bearbeitet werden kann (Charaktername, Fähigkeit, Porträt, Sprite usw.). Das Ruby Game Scripting System ermöglicht Monkey Patching. Aus diesem Grund ersetzen die meisten Skripte, die von fortgeschrittenen Benutzern bereitgestellt werden, nicht die ursprünglich vordefinierten Klassen von RPG Maker-Entwicklern, um Kompatibilitätsprobleme zu vermeiden.

Zum Vergleich:
KDE- und GNOME-Projekte beabsichtigen nie, die mächtigen Shell-Befehle in Linux zu ersetzen, stattdessen versuchen die Projekte nur, die Lücke zwischen Benutzerfreundlichkeit und der Leistungsfähigkeit von Linux zu schließen.

Ich habe über die Idee gelächelt, dass Okam Studio wie Steam ist ... :))

Am 14.01.2015 um 17:20 schrieb RyanBram:

Hallo, Godot-Entwickler.

Zunächst möchte ich mich bei Ihnen allen für die Erstellung eines großartigen Spiels bedanken
Motor mit sehr freizügiger Lizenz. Ihre Bemühungen werden vielen helfen
Entwickler und Studenten mit knappem Budget, um sich ihren Traum zu erfüllen.

Mit dem aktuellen Status von Godot wird Open-Source-Gaming heller
Zukunft. Leider sind die meisten Open-Source-Game-Engines konzipiert
für fortgeschrittene Benutzer mit wenig Programmierkenntnissen. Es
kann einen Anfänger-Spielemacher immer noch nicht erreichen.

Mein Vorschlag ist, einen einfach zu bedienenden Spieledesigner/-editor bereitzustellen
intuitive GUI und vordefinierte Klasse, um die Aufgabe neuer Programmierer zu erleichtern.
Mehr Programmierer bedeutet mehr Benutzer (weil Godot-Benutzer Spieleprogrammierer sind).

Ich kenne eine Spiel-Engine, die diesen Job gut macht. Es ist von Ruby geschrieben,
ursprünglich aus Japan und weltweit ins Englische übersetzt. es ist
namens RPG Maker VX Ace
http://www.rpgmakerweb.com/products/programs/rpg-maker-vx-ace.
Trotz des RPG-Wortes vor seinem Namen ist es dazu in der Lage
Erstellen Sie Nicht-RPG-Spiele mit dem integrierten Ruby Game Scripting System (RGSS).

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

Die folgende Liste ist ein Beispiel für Spiele, die mit der RPG Maker-Engine erstellt wurden:

1. Aleph (Rollenspiel-Abenteuer) http://www.pioneervalleygames.com/
2. Keine Seekühe versprochen (Arcade) http://rpgmaker.net/games/5102/
3. Ragarokk – Bestiarium (Kartenspiel) http://rpgmaker.net/games/5808/
4. Erde unter Beschuss! (Shooter) http://rpgmaker.net/games/6561/
5. Terra (VisualNovel) http://rpgmaker.net/games/3956/
6. Erinnerungen an Mana (Action-Rollenspiel)
   http://www.atelier-rgss.com/Project/Mana/Project_Mana_Story.html
7. Myhos – Der Anfang (Horror) http://rpgmaker.net/games/6493/

Ich wünsche mir, dass die Godot-Engine so beliebt wird wie RPG Maker, denn das hat sie
viel mehr Funktionen als RPG Maker. Programmieranfänger brauchen nur eine
einfach zu bedienende Oberfläche. Wenn es erfolgreich war, könnte Okam Studio das nächste werden
GOG oder Steam, die Tausende von Spielen veröffentlichen, die von unabhängigen Entwicklern erstellt wurden.

Grüße, Ryan

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220.

Unreal hat tatsächlich Vorlagen für Projekte, ob Sie eine tun möchten
visuelles Scripting oder ein vollständiger Scripting-Workflow ... und sogar das
Codeblöcke für die visuelle Bearbeitung sind über Visual Studio und be zugänglich
angepasst... :)

Am 15.01.2015 um 3:44 Uhr schrieb Juan Linietsky:

@SolarLune : Visual Scripting ist nützlich, wenn Sie mit a zusammenarbeiten
Programmierer, der Blöcke erstellen kann, mit denen Sie spielen können.
Dies
Ansatz in Unreal ist nützlich. Ich glaube nicht, dass ein Austausch möglich ist
vollständig programmieren (es sei denn, Sie sind ein Masochist), aber es könnte funktionieren
Einige Leute erstellen Vorlagenblöcke auch für Nicht-Programmierer.

Am Mittwoch, den 14. Januar 2015 um 16:23 Uhr schrieb TheoXD [email protected] :

Der RPG-Hersteller scheint eher einen "Modding" -Ansatz zu verfolgen, und wenn Godot es will
sehen eher aus wie RPG-Hersteller - Leute, die die Absicht haben, etwas anderes zu machen
Art von Spielen wird sich abwenden. Was Sie also im Grunde vorschlagen, ist
Godot eher wie GameMaker aussehen lassen (was verständlich ist, viele
Menschen
Ich möchte Spiele machen, kenne mich aber nicht mit Programmieren aus), aber es gibt eine Grenze :)
Was wahrscheinlich passieren wird, ist, dass Godot Nodal Behavior Graph erhält
Editor, ähnlich wie bei Leadwerks und BGE. Das funktioniert sehr gut
mit
GUI-Elemente, der Rest würde einige Recherche und jede Menge davon erfordern
Gemeinschaft
Feedback, um es so einfach und wirkungsvoll wie möglich zu machen.

@SolarLune https://github.com/SolarLune , es ist möglich, ein Spiel zu bauen
in Godot und fügen Sie oben einen Editor hinzu, der das Modden des Spiels für jeden ermöglicht
wenig Detail (unter Verwendung von GraphNodes und dem Rest der Benutzeroberfläche) und würde sogar
erlauben
Schreiben Sie etwas zusätzlichen GDscript-Code oben drauf, ich denke, das ist das Beste
sich nähern,
ein komplettes Spiel (RPG, FPS, RTS) separat zu versenden und zu ermöglichen
optimieren
jeden Aspekt davon.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220#issuecomment -69974733.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220#issuecomment -69978224.

Ich habe über die Idee gelächelt, dass Okam Studio wie Steam ist ... :))

Ich lächelte auch positiv.
Weil es für mich als Spieler großartig sein wird, wenn es ein Unternehmen gibt, das so groß wie Steam ist und einen Tonnen von Spielekatalogen hat, offen und DRM-frei, die von Tausenden großartiger Spieleentwickler erstellt wurden.

Unreal hat tatsächlich Vorlagen für Projekte, ob Sie eine tun möchten
visuelles Scripting oder ein vollständiger Scripting-Workflow ... und sogar das
Codeblöcke für die visuelle Bearbeitung sind über Visual Studio und be zugänglich
angepasst... :)

Großartig, wenn es in Godot verfügbar sein wird.

Grüße,
Ryan

Hallo Ryan

Hast du dir Construct 2 angesehen? Es ist einer meiner bevorzugten visuellen Spieledesigner und extrem einfach zu bedienen.

Visuelle Programmierung in Godot wird meiner Meinung nach etwas schwierig sein (da Godot sowohl 2D als auch 3D macht, ist der Umfang viel größer.)
Außerdem wird es wahrscheinlich viel später eingebaut, wenn alle zugrunde liegenden Blöcke für den Motor vorhanden sind.

Ich weiß, dass Reduz dafür seine eigene Roadmap hat, aber ich hoffe, dass er dies nicht gegenüber anderen Editor-/Engine-Updates priorisiert. Ich hätte lieber, dass Godot von Anfängern oder halbwegs erfahrenen Programmierern verwendet wird als von Nicht-Programmierern. Aber das bin nur ich.

Hallo Ryan

Hast du dir Construct 2 angesehen? Es ist einer meiner bevorzugten visuellen Spieledesigner und extrem einfach zu bedienen.

Ich habe Construct 2 ausprobiert. Es ist schön und großartig. Die resultierenden Spiele sind auch plattformübergreifend, also ein großes Plus. Leider kann ich immer noch kein Tutorial zum einfachen Erstellen von RPG-Spielen finden. Im Moment bleibe ich vielleicht bei RPG Maker VX Ace und versuche, mein Spiel mit Hilfe von MKXP Project auf viele Plattformen (einschließlich Android) zu portieren.

Danke für das Teilen. Ich freue mich auf die visuelle Programmierung in Godot.

Mit freundlichen Grüßen,
Ryan

Für den visuellen Skripting-Ansatz – Sie können sich Notizen von gdevelop, multimedia fusion und construct 2 machen. Diese Engines verlassen sich zu 100 % auf visuelles Skripting. Sie müssen noch etwas Syntax lernen, wo Ausdrücke benötigt werden, aber der Ausdruckseditor macht es extrem einfach, die richtigen Befehle zu finden. Diese drei Engines geben Ihnen die Freiheit, jede Art von Spiel mit visuellem Scripting zu erstellen – im Gegensatz zu Game Maker und RPG Maker.

Rpg Maker ist nicht wirklich ein gutes Beispiel, da es extrem begrenzt ist.
Knotenbasiertes Skripting ist sehr ineffizient in Bezug auf die Platznutzung – Sie werden in einem riesigen Knotendiagramm herumschwenken und hinein- und herauszoomen. Vergleichen Sie das mit Konstrukt 2, wo alles übersichtlich angeordnet und straff und leicht lesbar ist – und Sie haben gewonnen.

BGE ist hier wahrscheinlich das schlechteste Beispiel, da es versucht, einen knotenbasierten Ansatz mit Logikblöcken zu kombinieren. Ich habe darüber geschrieben, warum das schlecht ist:
http://blenderartists.org/forum/showthread.php?323905-comparing-BGE-logic-bricks-with-Scirra-Construct-event-sheet-for-prototyping

Wenn Sie visuelles Skripting betreiben, machen Sie es bitte nicht mit einem generischen, knotenbasierten Editor. Wenn Sie möchten, dass mehr Nicht-Programmierer Ihre Engine verwenden, machen Sie etwas mit einem besseren Design - wie construct2 oder Multimedia Fusion.

Ich würde gerne sehen, dass so etwas _nur_ als sekundäre Art der Programmierung implementiert wird. Visual Scripting verlangsamt im Gegensatz zu Code die Produktivität um eine ziemlich große Größenordnung. Es neigt auch dazu, das Debuggen und Refactoring erheblich zu erschweren. Der einzige große Vorteil, den ich mir vorstellen kann (abgesehen davon, dass es Nicht-Programmierer anspricht), ist, dass visuelles Skripting in der Regel ein großartiges Lehrmittel ist, wenn es in der Lage wäre, tatsächlichen GDScript-Code (IE. code. org). Ich glaube nicht, dass es umgekehrt gehen müsste (IE. GDScript zu Visual). Ich denke, dies wäre eine großartige Möglichkeit für Schulen, Godot in ihren Unterricht aufzunehmen.

Hier sind zwei Hauptunterschiede zwischen Code und visueller Skripterstellung, die meiner Meinung nach die wichtigsten in Bezug auf die Zugänglichkeit sind. Dies kommt von jemandem, der visuelles Skripting nicht mit einer drei Meter langen Stange anfasst, aber ich verstehe, dass es einige Leute anspricht :)

Code: Code hat in der Regel bestimmte Syntaxregeln, die befolgt werden müssen. Ich vermute, dass dies tendenziell die Hauptsache ist, die Nicht-Programmierer abschreckt. IE. In GDScript müssen Sie am Ende einer Funktionsdeklaration einen Doppelpunkt haben, wenn, for, while-Schleifen usw. Sie müssen richtig einrücken. Sie müssen das Schlüsselwort var verwenden, wenn Sie eine Variable wie "var myInteger = 1" deklarieren. Für die meisten Sprachen gibt es in der Regel etwa 3 oder 4 primäre Syntaxregeln, die befolgt werden müssen und meiner Meinung nach nicht so schwer zu lernen sind. Nach dem Schreiben einer Handvoll kleiner Skripte kann sogar ein Künstler sie lernen. Ich sage das, weil ich mit zwei sehr talentierten Künstlern zusammenarbeite, die mit Ensemble Studios an allen drei Age of Empires-Spielen gearbeitet haben. Einer hat ziemlich viel Code in UnityScript geschrieben und der andere hat jetzt eine Menge Code in C# geschrieben.

Visuell: Sie erhalten in der Regel ein Dropdown-Menü für die Methode, Variable, Anweisung usw. Sie müssen jedoch immer noch wissen, nach welchen Funktionen, Eigenschaften usw. Sie suchen und was sie tun und manchmal sogar wie sie funktionieren. Sie müssen das Problem noch lösen. Sie müssen immer noch Variablen verwenden und verfolgen, was sie in Ihrem Skript tun. Sie können immer noch logische Fehler haben, genauso einfach wie beim Schreiben von Code.

Ich denke, in der Lage zu sein, den Code tatsächlich zu schreiben, ist letztendlich aus Produktivitätssicht ein weitaus besserer Weg. Beides macht Sie jedoch nicht zu einem besseren/schlechteren Programmierer. Ich denke, dass Visual Scripting ein wirklich gutes Lehrmittel ist, aber wenn Sie nicht wissen (oder lernen möchten), wie man Dinge richtig strukturiert und insbesondere Probleme löst, hilft Ihnen Visual Scripting kein bisschen.

Ich würde einen etwas anderen Ansatz wählen. Da der Godot-Editor selbst gesteuert wird, ist es einfach, eine ähnliche Editor-Oberfläche in reinem GDscript nachzubilden.

Mein Vorschlag wäre also, einen Konstruktor zu erstellen, der vollständig in Godot geschrieben und separat versendet wird. Dies würde es Programmierern und Nicht-Programmierern ermöglichen, an demselben Projekt zu arbeiten und gleichzeitig unterschiedliche Tools zu verwenden. Das einzige Problem ist, dass Nicht-Programmierer manchmal mit beiden Tools gleichzeitig umgehen müssen, aber hey, ich habe schlechtere xD-Gridmap-Editoren, Shader-Editoren, Animations-Editoren, Code-Editoren gesehen - kann neu erstellt werden, während Collada-Importer, Convex Erzeuger, Exporteure - nicht so einfach. Fühlt sich immer noch an, als würde man das Rad neu erfinden, kann aber vieles vereinfachen.

Der Constructor-Kern könnte in jedes Spielgenre (FPS, RTS, GPS ...) mit herunterladbaren Inhalten und Sachen übernommen werden, und wenn er von der Community gepflegt wird, ist es einfacher, Beiträge zu leisten, da alles GDscript ist
Es ist unwahrscheinlich, dass es bald visuelles Skripting in Godot geben wird, aber es hindert andere nicht daran, einen Konstruktor darüber zu erstellen. Ich habe gesehen, wie jemand Blender 2.5 nahm und ein Werkzeug zum Gestalten von Innenräumen erstellte.

Ich denke, dass mehrere Redakteure Godots Entwicklung fragmentieren könnten. Es muss ein gut gestaltetes zentrales Projekt für ein visuelles Skripting-Tool geben, das auf gdscript aufbaut.

Seien Sie nicht faul und recherchieren Sie. Sehen Sie sich andere rein visuelle Scripting-Engines an. Vergleichen Sie ihre Benutzerbasis (wie beliebt sie sind), vergleichen Sie, wie flexibel sie sind - die Arten von Spielen, die mit ihnen erstellt wurden - sei es auf Kickstarter, Steam oder anderen Plattformen.
Schauen Sie sich ihren Designansatz an.

Dann gestalte es auf Papier. Kopieren Sie nicht einfach den Node-Ansatz. Die Verwendung von Nodes für Shader ist in Ordnung, aber wenn es zur Logik kommt, endet man mit einem höllischen Durcheinander, durch das man scrollen und versuchen muss, es herauszufinden.

Vertrauen Sie mir, ich habe alles versucht. Der Spielmacher von Unity, Kismet von Unreal, der RPG-Hersteller, Stencyl usw.
Construct2 kommt oben drauf, zusammen mit Multimedia Fusion. Dies sind die beliebtesten mit dem flexibelsten Ansatz. Und beide haben einen Asset Market Store.
Sie sind extrem flexibel und wenn man sich Spiele ansieht, die damit erstellt wurden, gibt es eine riesige Vielfalt an Genres.

Wenn Sie noch klüger werden, könnten Sie sich mit Gdevelop zusammenschließen – einem anderen Open-Source-Projekt, das bereits einen visuellen Skripteditor hat, der HTML5-Spiele erstellt.
Schauen Sie sich das Design und den Quellcode an.

Wenn wir über diesen Thread abstimmen würden, bin ich mir ziemlich sicher, dass es der völlig falsche Ort wäre, weil hauptsächlich Programmierer zur Abstimmung erscheinen würden.

Ein visuelles Skriptsystem sollte für Künstler entwickelt werden, nicht für Programmierer. So sehr ich mich über meine völlige Abneigung gegen Dinge wie PlayMaker auf Unity beschweren könnte, die Wahrheit ist, dass Künstler es lieben. Deshalb hat es fast 2000 Bewertungen und 5 Sterne. Wenn die Abstimmung etwas mehr wie das Skripting von Construct 2 sein soll, dann ist meine Stimme dafür, überhaupt kein visuelles Skripting zu haben, da ich nicht glaube, dass es von wirklichem Nutzen sein wird, da A) Programmierer direkt in GDScript programmieren können und B) viele Künstler wird davon sofort ausgeschaltet und geht einfach woanders hin. Ich weiß das, weil meine beiden befreundeten Künstler, die beide programmieren können, sich Construct 2 ansahen und sich über die Programmierschnittstelle lustig machten, die es hat, da es fast dasselbe ist, als würde man einfach nur Code schreiben.

Eine visuelle Skriptsprache sollte sehr visuell sein, nicht viele Worte. Es sollte auf den ersten Blick nicht wie Code aussehen. Es sollte auf "visuelle Menschen" zugeschnitten sein, sonst macht es keinen Sinn, es überhaupt zu machen. Künstler sind an Knotendiagramme gewöhnt und neigen dazu, sie zu mögen, da sie Ihnen einen visuellen Eindruck davon vermitteln, was Ihr Programm tut. Auch hier mag ich Knotendiagramme selbst nicht, da ich sie nicht ausstehen kann, aber ich bin Programmierer und meine Stimme sollte in diesem Bereich wirklich nicht zählen.

Ich stimme Ihnen zu, dass es für Künstler/Designer konzipiert sein sollte.
Aber stimmen Sie nicht der Logik zu, dass Wörter = Komplexität sind.

Wenn Sie jemanden hinsetzen, um ihm beizubringen, eines der beiden zu verwenden, wird Konstrukt2 als das einfachere der beiden erscheinen. Wieso den?
Weil es klarer ist als Knoten. Viel klarer. Sie haben Bedingungen und Aktionen. Den ersten legst du auf die linke Seite und den anderen auf die rechte Seite.
Um eines der beiden hinzuzufügen, müssen Sie keine Befehle kennen. Sie sind dort alle aufgelistet, damit Sie sie hinzufügen können - klar wie ein Tag. Jedes kommt mit einem Symbol – das ist ein visueller Hinweis.

Playmaker und andere knotenbasierte Systeme erfordern viel, viel mehr Lernen, denn das Verbinden eines Knotens mit einem anderen Knoten erfordert, dass Sie zuerst verstehen, ob Sie die beiden verbinden können. Es ist nicht einfach Bedingung -> Aktion. Knoten sind viel komplexer und es fehlen visuelle Hinweise. Wo hast du Symbole im Spielmacher gesehen??
Es ist viel einfacher, darin einen Fehler zu machen. Es ist viel schwieriger, die Logik darin zu lesen.
https://www.scirra.com/tutorials/top
Ich würde auch argumentieren, dass C2, weil es ein besser gestaltetes visuelles Programmiertool ist, eine viel größere Community aktiver Benutzer hat als Playmaker - obwohl es im Moment auf 2D-Spiele beschränkt ist. Eine viel größere Anzahl von Video-Tutorials im Web (mehr Leute verstehen, wie man es benutzt als Playmaker), viel mehr abgeschlossene Projekte, ein gesunder aktiver Marktplatz und ein Forum und vor allem eine aktive Kommunikation zwischen Entwicklern und Benutzern. Die Entwickler wissen also, was die Künstlernutzer wollen.

Konstruktbenutzer können einfach einen Screenshot ihres Ereignisblatts machen und es ist klar wie ein Tag, wie sie es gemacht haben. Gehen Sie zu den Foren und überzeugen Sie sich selbst. Ich würde argumentieren, dass es viel mehr Benutzer als Spielmacher hat.

Ich würde argumentieren, dass es weniger Arbeit erfordert, Logik darin einzurichten, als in jedem knotenbasierten System.

Ich kann sehen, dass Sie sie mögen, aber versuchen Sie es zumindest mit construct2, bevor Sie erklären, dass es sich um eine Programmier-Engine handelt.
Schauen Sie sich ihr Forum und ihre Benutzerbasis an. Es hat genauso viel, wenn nicht sogar mehr guten Ruf als Spielmacher. Es hat es geschafft, diesen guten Ruf zu bekommen, weil es gut entworfen wurde - für sich selbst - und nicht, weil es ein Plugin für eine bereits erfolgreiche Engine war. Es ist ein rein visuelles Programmierwerkzeug, das jeder Künstler verwenden kann. Ich bin ein Künstler und habe es mit Spielmachern versucht – es ist schwieriger als Konstrukt2. Gehen Sie ins C2-Forum und versuchen Sie, sie davon zu überzeugen, dass der Spielmacher einfacher zu verwenden ist - nur zum Spaß. :D
Bist du selbst kein Programmierer? Sie haben mehr zu GitHub-Projekten beigetragen als ich. Bedeutet das nicht, dass Sie die Aussage nicht machen sollten, die leichter zu lernen ist?

Ich verstehe Ihre Punkte aus der Perspektive eines Programmierers. Wenn ich mich zwischen den beiden entscheiden müsste, würde ich mich auch für das Construct-Modell entscheiden. Wie ich bereits sagte, ist dies jedoch der schlechteste Ort, um diese Entscheidung zu treffen, da wahrscheinlich die meisten, wenn nicht alle Leute, die GitHub-Mailinglisten lesen, Programmierer sind.

Ich habe mehr Zeit meiner Karriere mit Künstlern verbracht als mit Programmierern. Obwohl ich in den letzten 18 Jahren regelmäßig beides gemacht habe (und für beides leidenschaftlich war), war ich beruflich Künstler, bevor ich beruflich Programmierer wurde. Es ist mir egal, ob ich überhaupt einen Abschluss habe, mein Abschluss ist in Digitaler Animation und visuellen Effekten. Soweit ich weiß, werden Werbespots, an denen ich gearbeitet habe, auch nach mehreren Jahren in Kansas City immer noch gespielt. Ich habe an Aufnahmen für Hallmark, Sprint, Radio Shack, Honda und ein paar andere gearbeitet, die ich wahrscheinlich vergessen habe. Es hat mir auch viel Spaß gemacht, mit Bruce Branit an einigen Aufnahmen in „World Builder“ zu arbeiten.

https://www.youtube.com/watch?v=QP3YywgRx5A
Nathan Warden in den Credits bin ich

Ich sage das nicht, um anzugeben, ich sage das, um ein Zeichen zu setzen. Ich könnte mich irren, aber als Künstler, der viel Zeit mit Künstlern verbracht hat, weiß ich, was Künstler mögen. Sie neigen nicht dazu, Dinge wie Constructor sehr zu mögen. Sie neigen dazu, sich eingeschüchtert zu fühlen und wählen eine ganz andere App. Künstler haben im Allgemeinen eine ganz andere Denkweise als Programmierer. Es ist, als ob ich mit meinem Freund Erik über technische Dinge spreche, die ich ihm beizubringen versuche, diese Worte kommen ziemlich oft aus seinem Mund: „Nate, ich bin eine sehr visuelle Person, wenn du es mir nicht zeigen kannst optisch könnte man genauso gut mit der Wand sprechen".

Es gibt einen Grund, warum Künstler Dinge wie knotenbasierte Shader-Graphen im Gegensatz zu linearen Shader-Systemen mögen. Sie können sich vorstellen, was vor sich geht. Ich glaube, ich habe noch nie einen Künstler darüber klagen hören, dass er kein lineares Shader-System in seiner bevorzugten 3D-Anwendung hat, aber sie beschweren sich regelmäßig, wenn sie kein knotenbasiertes Shader-System haben.

Es gibt einen Grund, warum Künstler Apps wie Fusion gegenüber After Effects bevorzugen. In so ziemlich jedem Fall wählen sie etwas Knotenbasiertes gegenüber Linearem, weil es visueller ist.

Also, 2 weitere Gründe, warum ein knotenbasiertes System Künstler ansprechen wird:

1) Sie sehen optisch viel ansprechender aus.
2) Es passt in das Designparadigma, an das sie bereits gewöhnt sind. IE-Shading und Compositing

Darauf kommt es wirklich an. Wenn der Künstler einen Blick werfen und zur nächsten Spiel-Engine übergehen wird, weil die andere eine knotenbasierte Programmierung hat, dann sollte Godot überhaupt kein visuelles Skripting haben, weil es wahrscheinlich nicht mehr als eine winzige Handvoll Leute geben wird wer wird es verwenden und es bedeutet nur mehr Codepflege von diesem Punkt an.

Sind Sie sicher, dass Sie wissen, was Construct2 ist? Du buchstabierst nicht einmal den Namen richtig.
Es heißt nicht "Konstruktor".

Ich bin völlig anderer Meinung, dass wir uns für Nodes entscheiden sollten, weil „es auf den ersten Blick nicht wie Code aussehen sollte“.

Es ist wichtiger, wie klar es ist, als wie es aussieht. Die Klarheit dessen, was Logik tut, ist wichtiger als das Aussehen des Editors auf den ersten Blick. Construct2 sieht nicht wie Code aus - der Text ist in einfachem Englisch geschrieben und es ist offensichtlich, was eine Aktion oder eine Bedingung tut. Menschen, die C2 verwenden, neigen auch dazu, hauptsächlich visuelle Menschen zu sein.

Ein Ereignisblatt wird immer gegen Knoten gewinnen – wie auch immer Sie versuchen, es aussehen zu lassen. Es kann mit weniger Schwenken mehr Informationen auf den Bildschirm packen - es ist offensichtlicher, was die Logik tut. Und die visuellen Hinweise (Symbole) sind für das Auge des Künstlers viel einfacher zu finden.
Knoten haben keine Symbole und eine große Textbeschränkung.
In vielen Fällen beschreibt ein Knoten aufgrund seiner begrenzten Größe nicht einmal klar, was er tut, was das Design dazu zwingt, obskure Terminologie anstelle von einfachem Englisch zu verwenden.

Ein weiterer Punkt:
Ein Ereignisblatt wird von oben nach unten gelesen und ausgeführt. Das ist offensichtlich und vorhersehbar.
Mit einem Knotennetzwerk reisen Ihre Augen überall hin, sie teilen sich in Zweige auf. Es wird viel komplizierter.

Meinungsgeschichten aus dritter Person über erste Einblicke und nicht über tatsächliche Benutzererfahrungen sollten hier kein Gewicht haben. Ich bin auch ein sehr visueller Mensch, aber einer, der bereits viele Visual Scripting Engines verwendet hat. Es ist ein absoluter Schmerz im Nacken zu sehen, wie Leute einen Streit führen, ohne die eigentlichen Engines für eine Weile zu benutzen - zum Beispiel bei einem kleinen Projekt.

Ich fordere die Designer/Entwickler/Visual People von Godot auf, diese Engines tatsächlich in einem kleinen Projekt auszuprobieren und dann zu Schlussfolgerungen zu kommen. Genug dieser Geschichten von Drittanbietern. Wir brauchen praktische Forschung und einen logisch erklärten Fall, warum das eine besser ist als das andere. Ob Sie es glauben oder nicht, visuelle Menschen haben auch einen gesunden Menschenverstand.

Offtopic:
Am Beispiel von Fusion vs. After Effects bevorzugen die Leute einen knotenbasierten Ansatz für das Compositing, da die Verwendung von Ebenen in einer komplizierten Szene, in der derselbe Effekt auf vielen Ebenen dupliziert werden kann, sehr umständlich werden kann. Mit Knoten haben Sie mehr Flexibilität in Bezug auf das Compositing und können einfach einen Effekt mit vielen Ebenen verknüpfen. Aber Knoten sind komplizierter als Schichten.

Ich stimme Ihnen in so ziemlich allen Punkten zu, aber diese Punkte sind immer noch aus der Perspektive eines Programmierers. Wenn ich den ganzen Tag ein visuelles Skriptsystem verwenden müsste, würde ich das auswählen, das am ehesten wie normaler Code aussieht. Deshalb bin ich ein großer Fan davon, Kindern, die lernen möchten, wie man mit code.org programmiert, beizubringen. Ich bin wirklich ein großer Fan des Stils. Es eignet sich gut, um Leuten, die programmieren "wollen", das Programmieren beizubringen.

Und ja, ich sagte Construct falsch, sorry. Nein, ich habe es nicht persönlich benutzt. Aber es spielt keine Rolle, weil das Scripting-Paradigma, das es verwendet, bei weitem nicht ein neues Konzept ist, also bezieht sich meine Argumentation nicht einmal auf Construct selbst. Es geht um diesen Scripting-Stil, da er sich auf Künstler bezieht, nicht auf Programmierer.

In einem knotenbasierten System können mehrere Bedingungen und Ereignisse und Funktionen in jedem Knoten enthalten sein. Sie können den Knoten dann beispielsweise so benennen wie Input. Darin enthält es alle Joystick-Eingaben und der Benutzer würde ihm mitteilen, welches Ereignis verwendet werden soll. IE. Sie würden ein Ereignis wie "Feuer" angeben. Dieses Ereignis würde einen Übergang zu dem Knoten verursachen, an den sie es angeschlossen haben.

Hier ist ein einfaches Beispiel, das Sie für eine Waffe haben könnten, die einfach das Schießen übernimmt. Beachten Sie, dass es zwar einfach, aber auch leistungsstark ist und nicht wie Code aussieht:

Abschließend sei gesagt, dass Sie sowohl blockbasiertes Skripting als auch knotenbasiertes Skripting vom Standpunkt der Benutzeroberfläche aus ziemlich gut aussehen lassen könnten, also werde ich meine Zeit nicht damit verschwenden, diesen Punkt zu argumentieren.

Als ich jedoch sagte: "Es sollte auf den ersten Blick nicht wie Code aussehen." Vielen Künstlern ist es wichtig, was sie jeden Tag auf unbestimmte Zeit den ganzen Tag anschauen werden. Sie lehnen eine ganze App ab, wenn sie nicht ansprechend oder einschüchternd aussieht. Ich würde sagen, dass das blockbasierte Aussehen für einen typischen Künstler einschüchternd und verwirrend aussieht. Es sieht aus wie etwas für Programmierer, und das ist es auch.

@blurymind ,

Graph-Knoten stammen eigentlich aus der konzeptionellen UML. Sie erstellen eine grafische Darstellung des Codes auf eine Weise, die ein Nicht-Programmierpublikum (Projektmanager, Verbraucher, Künstler) verstehen kann. Dies wird von UE4/Unity verwendet. Das ist jedem in der Branche bewusst. Konstrukteure verfolgen normalerweise einen anderen Ansatz, und wie gut dieser Ansatz ist, wird nicht durch die Anzahl der Benutzer definiert, die ihn verwenden.

Es gibt immer und überall eine Lernkurve, und Construct2 ist da keine Ausnahme. Aber lassen Sie uns nicht C2-Zeug in Godot zwingen, ohne die Argumente zu unterstützen. Das Ereignisblatt wird bei komplexeren Spielen länger und verschwendet am Ende mehr Platz als Diagrammknoten. Nur die Schaltfläche "Aktion hinzufügen" hat eine eigene Zeile für sich. Im Grunde genommen würde ein Programmierer einen Codeblock so interpretieren. Also so schlimm ist es nicht.

Ich persönlich verstehe nicht, warum wir nicht beides haben können, aber die Entwickler haben bereits genug zu tun, also wird es in absehbarer Zeit nicht passieren. Aus diesem Grund habe ich einen anderen Ansatz vorgeschlagen, der sich schneller entwickeln wird und im Wesentlichen von Nicht-Programmierern in Zusammenarbeit mit Programmierern vorangetrieben wird.

Hier ist ein besseres Beispiel, um zu zeigen, dass Sie mehr als ein Ereignis pro Knoten haben können. Beachten Sie auch, dass jeder Knoten (oder Zustand) nicht blockiert, sodass andere Knotendiagramme gleichzeitig ausgeführt werden können:

Aber sehen Sie, nur wenn ich mir Ihren Screenshot ansehe, habe ich keine Ahnung, was diese Logik tut. Was zum Teufel ist "firePrimary" und "fireSecondary"??
Scrollen Sie nun nach oben zu dem Screenshot, den ich von construct2 gepostet habe.
Auf construct2 lautet die Bedingung auf der linken Seite "on "R" pressed" oder etwas, das in Kurzform Englisch ist - mit einem Tastatursymbol daneben!

Zeigen Sie beide einem Künstler und fragen Sie ihn, was klarer ist.

Zeigen Sie uns auch ein ausgefeilteres Node-Setup :) Der C2-Screenshot zeigt die gesamte Spiellogik. Ihr ist nur ein Ereignis. Können Sie dieselbe Logik in einem Screenshot mit Knoten unterbringen? Ich glaube nicht.

Siehe das Knotenbeispiel verschleiert Informationen.
Sie müssen einen Knoten auswählen, um zu sehen, was darin festgelegt ist.
Es verwendet eher obskure Programmiererterminologie als menschliche Sprache ("Ereignis senden", "Ergebnisse speichern", was zum Teufel?).
Construct2 zeigt alles an einem Ort und ist auch für Nicht-Programmierer verständlich. Der Sinn der visuellen Programmierung besteht darin, die Notwendigkeit des Erlernens von Terminologie zu beseitigen.

Ich bin kein Programmierer. Ich habe keine Erfahrung im Schreiben von eigentlichem Code. Dennoch kann ich mit construct2 leicht ein Spiel erstellen und für mich ist die Verwendung von Knoten viel schwieriger - wenn es um ein vollständiges Spiel geht.

Ich verstehe, dass jeder immer für das stimmen wird, was er bereits gut kann. Aber wie Sie zugegeben haben, sind Sie Programmierer und haben C2 noch nicht verwendet. Und ich bleibe bei der Aussage, dass ich ein Künstler ohne Programmiererfahrung bin, der sowohl Nodes als auch C2-Ansätze verwendet hat.

Ich gebe Ihnen gute logische Argumente, warum Sie eines über dem anderen verwenden sollten.
Sie geben mir Aussagen wie "Knoten sind visueller" und "Unreal verwendet Knoten". Das sind eigensinnige Aussagen. Und Sie geben beide zu, Programmierer zu sein.

Mir zu sagen, dass ich meine Argumente nicht unterstütze, ist nur eine Bestätigung dafür, dass Sie sich nicht mit construct2 befassen oder sein Design als Alternative zu Nodes betrachten möchten. Es ist leider Zeitverschwendung, Sie vom Gegenteil zu überzeugen.

@TheoXD
Ich stimme dir vollkommen zu, wenn ich dich richtig verstehe. Es wäre schön, beides als separates Plugin/Modul zu haben. Darunter wäre also das eigentliche GDScript, aber Sie könnten es mit allem, was Sie wollen, visualisieren. Ich denke, das ist möglich. Der knotenbasierte Ansatz benötigt möglicherweise einige Flags wie spezielle Kommentare, um Knoten zu trennen (z. B. #node name="Input" und #endnode), aber keine große Sache, da es automatisch wäre, wenn Sie mit dem Knotendiagramm beginnen würden. Ich denke, der Blockansatz wäre einfach.

Ist sowas in der Art gemeint?

Wie ich oben sagte, mag ich die block/Construct/code.org-Methode sehr, da sie wirklich gut für den Programmierunterricht geeignet ist. Ich glaube einfach nicht, dass es für Leute geeignet ist, die Programmieren als notwendiges Übel ansehen.

@blurymind
Der Grund, warum es keinen Sinn macht, ist, weil Sie damit nicht vertraut sind. Wenn ich mir das Construct-Bild oben anschaue, habe ich ebenfalls keine Ahnung, was los ist, nicht weil es schlecht ist, sondern weil ich damit nicht vertraut bin.

Soweit Sie nicht sehen können, was sich unter einem Knoten befindet, bis Sie darauf klicken, macht es keinen wirklichen Sinn, nach dem Einrichten eines Knotens das zu sichten, was Sie bereits wissen. Ich weiß bereits, dass ich Links- und Rechtsklick habe und dass sie primäre und sekundäre Munition abfeuern. Ich weiß bereits, was die primären und sekundären Feuerknoten tun. Es hat sich nicht geändert, seit ich es gemacht habe, warum muss ich jedes Mal die Details sehen, wenn ich es ansehe? Also, jetzt ist die zugrunde liegende Logik nur noch Unordnung. Dies ist ein weiterer Grund, warum Knoten künstler- und nicht-programmiererfreundlicher sind. Sie können ihre spezifische Logik in allgemeinere Stücke aufteilen. Dadurch können sie sich einen Gesamtüberblick verschaffen und sich nur dann um die Details kümmern, wenn sie es unbedingt müssen.

Ich schaue mir gerade ein aktuelles Projekt für ein tatsächlich veröffentlichtes Handyspiel an, und fast jeder Knotengraph besteht aus höchstens 2 bis 4 Knoten, daher ist es schwierig, Ihnen ein aufwändigeres Setup zu zeigen, wenn Sie normalerweise kein aufwändiges Setup benötigen.

Wenn Sie es ausführlicher wollen, ist dies von derselben App, die von einer Person geschrieben wurde, die ungefähr so ​​​​Nicht-Programmierer ist, wie sie kommen. Dies ist eine der komplexesten Grafiken im Spiel. Es steuert die Bewegung des Hauptspielers:

(Das ist eine andere Sache, die Sie mit Blöcken nicht tun können, ist, sie wie Samus 'Schiff aussehen zu lassen, haha)

Ohne Aufforderung habe ich einfach Ihr Construct2-Bild auf einen Bildschirm und das obige Knotendiagramm auf den anderen Bildschirm gestellt und meine Frau (die definitiv keine Programmiererin ist) gefragt: „Welchen würden Sie verwenden wollen, wenn Sie ihn verwenden müssten? jeden Tag?", und sie zeigte auf das Knotendiagramm und sagte: "Dieses". Ich weiß, das ist nicht endgültig, aber die Tatsache, dass es weniger einschüchternd ist, bedeutet, dass ich viel mehr Chancen habe, sie überhaupt dazu zu bringen, es zu lernen. Wenn es einschüchternd aussieht, schaltet sie vielleicht ihr Gehirn ab, bevor ich sie überhaupt dazu bringe, sich hinzusetzen, um die Grundlagen zu lernen.

Ohne ihn zu dem einen oder anderen zu drängen, fragte ich gestern auch meinen Künstlerfreund (derselbe, der an allen drei Age of Empires-Spielen gearbeitet hat), der seit fast 20 Jahren in der Spieleindustrie ist (und Construct2 verwendet) was seiner Meinung nach andere Künstler bevorzugen würden und er sagte auch den Knotengraphen.

Wie auch immer, ich genieße die Diskussion wirklich, aber es macht keinen Sinn, ein totes Pferd zu schlagen, haha ​​:)

Ja, ich genieße es auch. Keine schlechten Gefühle :)

Tolles Samus-Schiff übrigens. Je mehr Bilder Sie posten, desto mehr unterstützen Sie meinen Standpunkt, dass Knoten visuell schwerer zu verfolgen sind, da sie sich in Äste teilen und in verrückte Richtungen gehen können.
Für mich hat sich die zusätzliche Komplexität, Linien und Pfeilen zwischen Blöcken folgen zu müssen, immer wie zusätzliche Arbeit angefühlt. Ich denke, ich sollte Nodes eines Tages noch einmal versuchen. Wenn das ist, wo Godot hingeht.

Wieder geben Sie uns Geschichten aus der dritten Person, die nicht wirklich durch Beweise gestützt werden. Holen Sie den Typen her und lassen Sie ihn uns sagen, WARUM er das eine dem anderen vorzieht :)
Dann hast du einen stärkeren Fall. Ich bekomme bisher keine logisch vernünftigen Punkte, die die These stützen, dass Knoten einfacher sind.

Ja, es sieht auf den ersten Blick weniger einschüchternd aus, weil es viele Informationen verbirgt. Ihre Beispiele sind viel einfacher als das, was in dem von mir geposteten Screenshot gezeigt wird. Das ist irreführend.
Hier ist ein Video, das zeigt, wie man Logik für einen Plattformer in C2 einrichtet.
https://www.youtube.com/watch?v=5RlSmkSbleI
Überspringen Sie die erste Minute :P

Vergleichen wir nicht Äpfel mit Birnen.
Code.org ist ein radikal anderer Ansatz als Construct2 - es sieht eher aus wie Stencyl und hat einen der Nachteile von Knoten: Ihre Bedingungen und Aktionen sind nicht klar getrennt - daher ist es schwieriger herauszufinden, was Sie woran anhängen können. Gut gestaltete visuelle Programmierwerkzeuge (Multimedia Fusion, construct2, gamedevelop) trennen Bedingungen und Aktionen deutlich für den Benutzer. Dies macht es viel einfacher, Logik zu erstellen, da sie von der Software für Sie organisiert wird, die errät, was Sie möglicherweise benötigen, und es Ihnen zur richtigen Zeit zeigt. Es verhindert auch, dass Sie dumme Fehler machen.

Bei nodes/stencyl/code.org müssen Sie herausfinden, welches Stück eine Bedingung ist, welches eine Aktion ist. Es erfordert mehr herauszufinden, um Ihre Bedingungen richtig einzurichten. Welche Art von Informationen kommt aus einem Knoten? Es braucht manchmal mehr Knoten, um eine Bedingung einzurichten – mehr zu lernen, wie man sie verbindet.
Kommen Sie, recherchieren Sie und verwenden Sie die anderen Tools tatsächlich für eine Weile. Es hilft nicht, alle Nicht-Knoten als mehr vom Gleichen zu sehen.

@blurymind , Ihr Fall wird bisher durch die Anzahl der Benutzer gestützt, die Construct2 verwenden, was normalerweise auf das Geschäftsmodell der Software zurückzuführen ist und wie gut sie im Marketing sind. Persönliche Vorlieben (Ihre logischen Argumente) reichen nicht aus, um den C2-Workflow in Godot zu erzwingen. Aber es ist trotzdem eine gute Referenz.

Wenn Sie jemandem zeigen würden, wie Sie Ihr Spiel (Objekt-Objekt-Beziehung) auf Papier oder einer Tafel aufbauen möchten, wie würden Sie es zeigen? Indem Sie einen Ereignisbaum schreiben? Nein. Sie würden eine konzeptionelle Ansicht mit Knoten und Linien zeichnen, sie dann als Klassen betrachten, Funktionen und Mitglieder hinzufügen.
Ich würde zustimmen, dass die Ereignistabelle eher wie Code aussieht, der nur von einem Programmierer interpretiert wird, und Benutzer dazu bringen kann, die eigentliche Programmierung zu lernen, wenn sie vorankommen. Mir ist aufgefallen, dass es auch eine gewisse Terminologie und Lernkurve gibt, das können Sie nicht leugnen. Aber die Formerkennung und Objektgruppierung ist tatsächlich eine echte Sache. Ich studiere einen Kurs über Datenvisualisierung, und abgesehen davon, wie langweilig es werden könnte – es macht tatsächlich gute Punkte.

So sehr ich es auch begrüßen würde, wenn diese Ausgabe über 100 Kommentare erhalten würde, Entwickler werden sie nicht alle lesen. Das Beste, was jeder von uns tun kann, ist, ein PDF mit Vorschlägen zu erstellen und sie auf der Mailingliste zu teilen. Ich verstehe nicht, warum wir nicht verschiedene Abstraktionsebenen haben können, Graphknoten als oberste Ebene, die in Form eines Ereignisbaums dargestellt werden können. Wenn dies funktioniert, müssen Sie keine Kompromisse eingehen.

" @blurymind -- || -- Und Sie geben beide zu, Programmierer zu sein." - Ich sehe mich nicht nur als Programmierer, sondern mache auch Kunst. Ich nutze meine Erfahrung, um Dinge objektiv zu betrachten.

Ich bin mir nicht sicher, ob es übersehen wurde, aber ich bin auch nicht nur ein Programmierer, sondern auch ein professioneller Künstler. Ich denke, die meisten Programmierer würden wirklich davon profitieren, wenn sie sich für eine Weile in die Kunst stürzen würden. Es macht das Programmieren bestimmter Dinge viel sinnvoller und es hilft auch, die Rivalität zwischen Programmierern und Künstlern zu überbrücken, haha ​​:) Ich weiß, dass dies idealer und für die meisten Leute nicht so praktisch ist.

Hier sind einige Links zu einigen meiner Arbeiten (suchen Sie nach Nathan Warden in den Credits)

World Builder (an etwa der Hälfte der Aufnahmen beteiligt)
https://www.youtube.com/watch?v=VzFpg271sm8

Teddy Scares (war an den meisten Aufnahmen beteiligt)
https://www.youtube.com/watch?v=qCXIzS_iY0k

Hallmark Crown Center (Der dritte Schuss mit dem Weihnachtsmann)
https://www.youtube.com/watch?v=biqBq3_Whqk

Hier ist ein Rendering von meinem Louie-Gebäude. Wenn Sie sich World Builder ansehen, werden Sie einige der Kunstwerke sehen, die ich daraus kopiert und in den Film eingefügt habe.

Und hier ist eine unfertige Darstellung eines HK-Panzers im Stil von Terminator 1, der Stephen Kings Christine zerschmettert. Beide Modelle sind von mir gemacht, aber ich glaube nicht, dass irgendetwas anderes in der Aufnahme war.

Und viele mehr, die ich nennen könnte, aber ich denke, der Punkt ist getroffen. :)

Nun, das sind erstaunliche Standbilder – aber Sie tun dies wiederum, um sich selbst mehr Autorität zu verleihen. Dies trägt nicht dazu bei, die Idee logisch zu unterstützen, dass Knoten besser sind als Ereignisblätter :)

Wenn Sie sich für Nodes entscheiden, werden Sie wie jede andere gottverdammte 3D-Game-Engine da draußen sein, die visuelle Programmierung verwendet.

Ich denke, dass dies aus mehreren Gründen keine gute Idee ist.

- Kürzlich hat Unreal seine Engine kostenlos gemacht - es ist auch plattformübergreifend. Es ist eine viel ausgereiftere Engine als BGE/Godot. Sie konkurrieren also direkt mit ihnen, wenn Sie ihren Ansatz zur visuellen Programmierung kopieren.

-Knoten sind viel weniger bildschirmeffizient als ein Logikblatt. Sie sind schwerer zu lesen/folgen.

- Scirra kündigte an, dass construct3 plattformübergreifend sein wird - der Editor wird unter Windows, Linux und Mac funktionieren.
Sie sind jedoch nicht Open Source.
https://www.construct3.com/

Dies löste eine Welle von Kommentaren in der Scirra-Community aus. Viele Benutzer wünschen sich eine Reihe von Dingen, die Godot ohne die visuelle Programmierung bieten kann:
-Native exe-Dateien anstelle von HTML5-Containern - für eine bessere Leistung
-Unterstützung für die Entwicklung von 3D-Spielen unter Verwendung des Ereignisblattstils in Konstrukt, um es zu programmieren:
https://www.scirra.com/forum/construct-3_t90881

Wenn sie einen einfachen und verständlichen 3D-Editor wie das 2D-Tool in C2 machen, würde ich es total verwenden

Ich habe Unity, Blender, Torque 3D, UDK ausprobiert, weil sie am meisten beworben werden und die meisten der sogenannten berühmten Entwickler verwenden ... und sie haben die gleichen Probleme: Sie sind (überhaupt) nicht benutzerfreundlich und wenn Sie Ich habe noch nie eine API zur Erstellung von 3D-Spielen verwendet ... nun, Sie sind 3Doomed (schlechter Witz, ikno)

Die Sache ist, dass Konstrukt sehr intuitiv ist, sobald Sie die Grundlagen abgedeckt haben, und Ihnen die Freiheit gibt, komplexe 2D-Spiele zu erstellen. Es gibt Ihnen verschiedene Wege, um dasselbe Ergebnis zu erzielen (ganz zu schweigen davon, dass das Ereignissystem für mich SINN ergibt); Welches Detail können die meisten dieser anderen Tools nicht abdecken oder machen es schlecht

wenn sie eine 3D-Engine mit dem gleichen Fluss und Gefühl machen, das ich mit C2 habe; warum probierst du es dann nicht aus?

Sie haben im Moment eine riesige Benutzerbasis (die den Event-Sheet-Stil für die visuelle Programmierung liebt, aber diese Funktionen will) und einige davon sind bereit, zu einer anderen Engine zu springen. Hier besteht ein großes Potenzial für Godot, viele neue Indie-Entwickler an Bord zu holen – diejenigen, die dies den Nodes vorziehen – diejenigen, die die Unreal-Engine nicht verwenden – die jetzt kostenlos und viel ausgereifter als Godot ist.

Wenn Sie sich dafür anstelle von Knoten entscheiden, werden Sie die erste Engine sein, die die vollständige 3D-Spieleentwicklung mit diesem visuellen Programmierdesign unterstützt. Sie werden eine neue Benutzerbasis erschließen, anstatt mit Unreal (kostenlos), Unity (kostenlose Version verfügbar) zu konkurrieren.

Nun, das sind erstaunliche Standbilder – aber Sie tun dies wiederum, um sich selbst mehr Autorität zu verleihen.

Die Standbilder und Links sind kein Beweis für meine Autorität, sondern für die Leute, mit denen ich gearbeitet habe, und dass ich mir das nicht nur ausgedacht habe :) Dazu gehören einige meiner guten Freunde, die an einigen Filmen mitgearbeitet haben, von denen Sie vielleicht gehört haben Avatar, King Kong, Serenity und Shows wie Lost, Revolution usw. Und einige meiner anderen Freunde, die seit über 15 Jahren in der Spielebranche arbeiten. Alle bevorzugen einen knotenbasierten Workflow gegenüber einem linearen, blattbasierten Workflow. Ich könnte wahrscheinlich ein Zitat von 3-4 von ihnen erhalten, die Ihnen sagen, dass sie Knotendiagramme gegenüber Logikblättern bevorzugen, wenn Sie möchten?

Kürzlich hat Unreal seine Engine kostenlos gemacht - es ist auch plattformübergreifend. Es ist eine viel ausgereiftere Engine als BGE/Godot. Sie konkurrieren also direkt mit ihnen, wenn Sie ihren Ansatz zur visuellen Programmierung kopieren.

Der visuelle Skript-Workflow ist das Letzte, worauf die Leute achten werden, wenn sie Godot mit diesen Engines vergleichen. Das erste, was ihnen auffallen wird, ist, dass Unreal DirectX 12 und OpenGL 4 unterstützt und dass ihre Demos und Beispiele umwerfend aussehen, dann werden sie anfangen, sich die anderen Dinge anzusehen. Das Wichtigste, was Godot gegenüber diesen Unternehmen hat, ist, dass es sich um FLOSS-Software handelt und dass jeder, der sie verwendet, gleichermaßen ein vollständiger Eigentümer der Software ist.

Knoten sind viel weniger bildschirmeffizient als ein Logikblatt. Sie sind schwerer zu lesen/folgen.

Während Ihre Aussage offensichtlich ist, dass Sie kein gutes knotenbasiertes Setup verwendet haben, sollten Sie, wenn Sie sich Sorgen um Dinge wie die Bildschirmeffizienz machen, ohnehin kein visuelles Skript verwenden, sondern das bereits verfügbare echte Skript :) Ich garantiere Ihnen, dass alles, was visuelles Skripting Ihnen in Bezug auf den Bildschirmplatz bieten kann, auch normales Skripting tun kann, wie z. B. das Einklappen von Coderegionen.

Wenn Sie sich dafür anstelle von Knoten entscheiden, werden Sie die erste Engine sein, die die vollständige 3D-Spieleentwicklung mit diesem visuellen Programmierdesign unterstützt.

Es gibt einen Grund, warum Engines wie Unreal, die viel Zeit, Geld und Forschung in die Bedürfnisse ihrer Kunden investieren, diese Form des visuellen Skriptings nicht verwenden und stattdessen Nodes wählen.

Meine Ansicht dazu ist, dass alles von der beabsichtigten Herangehensweise abhängt
gelöst.

Aktionsblöcke wie Game Maker sind interessant, aber ich denke, es ist mehr
auf eine Ablösung der Programmierung ausgelegt.

Der Ansatz von Unreal ist also eher eine Ergänzung zur Programmierung
Designer können selbst im Spiel arbeiten und dem Spiel Arbeit abnehmen
Programmierer. Dies ist viel nützlicher in Teams (Künstler und Spieledesigner
kann es gut verwenden) und ist definitiv der Ansatz, den ich ergänzen möchte
Godot, weil dafür.

Aufgrund der Godot-Architektur wäre es auch sehr einfach hinzuzufügen, also werde ich geben
es ein Schuss in 1.2

Am Dienstag, 3. März 2015 um 16:37 Uhr schrieb Nathan [email protected] :

Nun, das sind erstaunliche Standbilder – aber Sie tun dies noch einmal, um etwas zu geben
selbst mehr Autorität.

Die Standbilder und Links sind kein Beweis meiner Autorität, sondern der Leute, die ich habe
gearbeitet hat und dass ich mir das nicht nur ausdenke :) Dazu gehören einige meiner
gute Freunde, die an einigen Filmen gearbeitet haben, von denen Sie vielleicht gehört haben
Avatar, King Kong, Serenity und Shows wie Lost, Revolution, etc... Und
einige meiner anderen Freunde, die seit über 15 Jahren in der Spieleindustrie arbeiten
Jahre. Alle bevorzugen einen knotenbasierten Workflow gegenüber einem linearen, blattbasierten
Arbeitsablauf. Ich könnte wahrscheinlich ein Zitat von 3-4 von ihnen bekommen, die Ihnen das sagen
Sie bevorzugen Knotendiagramme gegenüber Logikblättern, wenn Sie möchten?

Kürzlich hat Unreal seine Engine kostenlos gemacht - es ist auch plattformübergreifend. Es ist ein
wesentlich reiferer Motor als BGE/Godot. Sie konkurrieren also mit ihnen
direkt beim Kopieren ihrer Herangehensweise an die visuelle Programmierung.

Der visuelle Scripting-Workflow ist das Letzte, was die Leute sein werden
wenn man Godot mit diesen Motoren vergleicht. Das erste, was sie tun
Beachten Sie, dass Unreal DirectX 12 und OpenGL 4 und deren Demos unterstützt
und Beispiele umwerfend aussehen, dann fangen sie an, sich die anderen Dinge anzusehen.
Das Wichtigste, was Godot gegenüber diesen Unternehmen hat, ist, dass es FLOSS ist
Software und dass jeder, der sie verwendet, gleichermaßen ein vollständiger Eigentümer der ist
Software.

Knoten sind viel weniger bildschirmeffizient als ein Logikblatt. Sie sind schwerer zu
lesen/folgen.

Während es durch Ihre Aussage offensichtlich ist, dass Sie keinen guten Knoten verwendet haben
basierte Einrichtung, wenn Sie sich Sorgen um Dinge wie die Bildschirmeffizienz machen, dann Sie
sollten sowieso kein visuelles Scripting verwenden, Sie sollten das echte verwenden
Skripting, das bereits verfügbar ist :) Ich garantiere Ihnen, dass alles möglich ist
Visual Scripting kann Ihnen in Bezug auf den Bildschirmplatz normales Scripting bieten
kann es auch, wie das Einklappen von Coderegionen.

Wenn Sie es anstelle von Knoten versuchen, werden Sie die erste Engine sein, die dies tut
unterstützt die vollständige 3D-Spieleentwicklung mit diesem Vis-Programmierdesign.

Es gibt einen Grund, warum Engines wie Unreal viel Zeit und Geld ausgeben
und die Erforschung der Bedürfnisse ihrer Kunden gehen nicht mit dieser Form von
visuelles Skripting und wählte stattdessen Knoten.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220#issuecomment -77017857.

Ich habe Playmaker ausgiebig ausprobiert und muss sagen, dass es mir gefallen hat – mehr als Kismet/Blueprints von Unreal.

In Playmaker sind Knoten so etwas wie Container, in denen Sie Aktionen platzieren. Einige der Aktionen sind das Prüfen einer Bedingung, die zu einem anderen Knoten führen kann.

Da Sie die Node-Container selbst erstellen und benennen können, werden die darin enthaltenen Aktionen auf vorhersehbare Weise ausgeführt (von oben nach unten) - damit kann ich leben. :)

Auch Aktionen, die Sie in einem Knoten platzieren, sind eigentlich Standard-Unity-Skripte mit visuellen Eingaben. So können Benutzer ihre eigenen Skripte schreiben und sie als benutzerdefinierte Aktionen hinzufügen.

Bitte schauen Sie sich den Spielmacher an und implementieren Sie ein knotenbasiertes System, das ihm ähnlicher ist als Unreal.
Der Vorteil ist natürlich, dass wir mit weniger Knoten mehr erreichen können, sie einfacher zu lesen und zu debuggen und vorhersehbarer sind.

Hier ist eine Einführung, wie es funktioniert:
https://www.youtube.com/watch?v=I9VwsVtbgFU&index=2&list=PLC759306A1E692A10

Es ist sehr flexibel und ermöglicht es dem Benutzer, Spielfunktionen einfach hinzuzufügen und zu teilen – einfach umzufunktionieren.

Spannende Diskussion. Ich möchte nur auf eine andere Art/Form des visuellen Skriptings hinweisen als auf Knoten und das Ereignisblatt von C2, aber auf Skriptblöcke, die wie Puzzleteile zusammenpassen. Verwendet in 2D-Engine Stencyl http://www.stencyl.com/

basierend auf MIT Scratch http://wiki.scratch.mit.edu/wiki/Wait_Until_ ()_(block)

und in Unity verwende ich persönlich Blox http://www.plyoung.com/blox/

Mich persönlich überzeugt die scratchartige "visuelle" Programmierung nicht. ich
denke, es ist so ziemlich wie Programmieren.
Die Art und Weise, wie Unreal dies tut, ist meiner Meinung nach freundlich zu Spiel-/Level-Designern

Am Samstag, 21. März 2015 um 23:57 Uhr schrieb todheil [email protected] :

Spannende Diskussion. Ich möchte nur auf eine andere Art / Form von Visuals hinweisen
Scripting andere als Knoten, sondern Skriptblöcke, die gerne zusammenpassen
Puzzle Stücke. Verwendet in 2D-Engine Stencyl http://www.stencyl.com/
[Bild: stencyl_blocks]
https://cloud.githubusercontent.com/assets/8675463/6767767/d52e7b16-d013-11e4-878c-29002dc04f8e.PNG
basierend auf MIT Scratch
http://wiki.scratch.mit.edu/wiki/Wait_Until_ ()_(block)
[Bild: scratch_example]
https://cloud.githubusercontent.com/assets/8675463/6767792/57f50e5c-d014-11e4-8015-9228bb6001d8.PNG
und in Unity verwende ich persönlich Blox http://www.plyoung.com/blox/
[Bild: hallo_blox]
https://cloud.githubusercontent.com/assets/8675463/6767796/7849f46a-d014-11e4-9244-9e45c601f883.PNG

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220#issuecomment -84508001.

_OkamStudio_

Guter Punkt. Blöcke sind für mich der Mittelweg zwischen Codezeilen und Flussdiagrammen.

Ich mag die Scratch/Stencyl-Art der visuellen Programmierung nicht. Sein Layout ist
visuell schwieriger zu verfolgen als construct2-Blöcke und sogar Knoten. es ist
buchstäblich Puzzleteile zusammensetzen und es leidet unter dem Problem
herauszufinden, welches Teil wo hinpasst. Sie sind nicht einfach zu setzen
zusammen

Am Sonntag, den 22. März 2015 um 5:46 Uhr schrieb todheil [email protected] :

Guter Punkt. Für mich sind Blöcke der Mittelweg zwischen Codezeilen und Flow
Diagramme.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220#issuecomment -84511415.

ok, ich werde jetzt nicht alles lesen, aber nur meine 2 cent zu diesem thema.

Ereignisbasierte Engines werden erstellt, um Prototypen und kleine Spielprojekte zu erstellen
Engines wie Godot werden erstellt, um alle Arten von Projekten zu realisieren

Sie sind also zwei verschiedene Dinge mit zwei verschiedenen Ansätzen, sie sind zwei
verschiedene Mautgebühren

Ehrlich gesagt kann ich sie nicht gut gebrauchen. (eventbasierte Maut)

Für mich ist der bessere Ansatz zwei parallele Mautstellen.

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

Ich mag die Scratch/Stencyl-Art der visuellen Programmierung nicht. Sein Layout ist
visuell schwieriger zu verfolgen als construct2-Blöcke und sogar Knoten. es ist
buchstäblich Puzzleteile zusammensetzen und es leidet unter dem Problem
herauszufinden, welches Teil wo hinpasst. Sie sind nicht einfach zu setzen
zusammen

Am Sonntag, den 22. März 2015 um 5:46 Uhr schrieb todheil [email protected] :

Guter Punkt. Für mich sind Blöcke der Mittelweg zwischen Codezeilen und Flow
Diagramme.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220#issuecomment -84511415.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220#issuecomment -84575752.

David Aguiar de Aquino Paiva

Das einzige, was nützlich wäre, ist das "Verhaltens" -System der Einheit,
Im Grunde ist es ein Skript, das etwas macht, also würde dies in Godot
übersetzen als die Möglichkeit, mehr als ein Skript pro Knoten hinzuzufügen.
Natürlich könnte ich einen Knoten erstellen und ihn einfach klonen, aber ein Skript wäre a
Ressource und würde sie dann einfach in einen Knoten laden und ein Verhalten hinzufügen (z
Beispiel ein Sprungskript)
Im Editor konnten wir die unter dem Skriptnamen kategorisierten Exporte sehen.

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

ok, ich werde jetzt nicht alles lesen, aber nur meine 2 cent zu diesem thema.

Ereignisbasierte Engines werden erstellt, um Prototypen und kleine Spielprojekte zu erstellen
Engines wie Godot werden erstellt, um alle Arten von Projekten zu realisieren

Sie sind also zwei verschiedene Dinge mit zwei verschiedenen Ansätzen, sie sind zwei
verschiedene Mautgebühren

Ehrlich gesagt kann ich sie nicht gut gebrauchen.

Für mich ist der bessere Ansatz zwei parallele Mautstellen.

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

Ich mag die Scratch/Stencyl-Art der visuellen Programmierung nicht. Sein Layout ist

visuell schwieriger zu verfolgen als construct2-Blöcke und sogar Knoten. es ist
buchstäblich Puzzleteile zusammensetzen und es leidet unter dem Problem
herauszufinden, welches Teil wo hinpasst. Sie sind nicht einfach zu setzen
zusammen

Am Sonntag, 22. März 2015 um 5:46 Uhr, todheil [email protected]
schrieb:

Guter Punkt. Für mich sind Blöcke der Mittelweg zwischen Codezeilen und Fluss
Diagramme.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
< https://github.com/okamstudio/godot/issues/1220#issuecomment -84511415
.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220#issuecomment -84575752.

David Aguiar de Aquino Paiva

David Aguiar de Aquino Paiva

Hallo Leute! Nette Diskussion ist hier :) Ich möchte etwas hinzufügen.

Als erstes: Ich bin Kunststudent, aber Programmieren ist mein Hobby. Ich kenne Java, Python und (mein Favorit) Golang. Aber bevor ich das Programmieren lerne (vor etwa 3 Jahren), habe ich fast jedes einzelne Programm ausprobiert, das behauptet, es erlaube "Spiele ohne Programmierung zu erstellen". All diese Behauptungen sind Unsinn.

Ich habe versucht (in keiner bestimmten Reihenfolge): Click & Play, GameMaker, The Games Factory, Multimedia Fusion, Construct 1, RPG Maker, Stencyl, BGE und einige andere, an die ich mich nicht einmal erinnere. Und meine Meinung ist: Man kann ein Spiel machen, ohne Code zu _schreiben_, aber nicht ohne _Programmierung_. Selbst wenn Sie Ereignisblätter oder Knoten verwenden, müssen Sie immer noch die _Logik der Programmierung_ verstehen. Sie müssen wissen, was Bedingungen, Ereignisse, Variablen, Zeichenfolgen usw. sind. Es ist also unmöglich, ein Spiel ohne Programmierung zu erstellen. All diese visuellen Kodierungsmethoden sind nur eine andere Art, Logik auszudrücken, die in traditionellen Programmiersprachen enthalten ist. Dieses ganze Argument mag offensichtlich erscheinen, aber ich versichere Ihnen, ich war zu Beginn meines Abenteuers mit dem Programmieren für mich nicht offensichtlich.

Daraus folgt meine nächste Überlegung:

Die beste und intuitivste visuelle Programmiersprache, die ich gefunden habe, bevor ich das Programmieren gelernt habe, ist Scrach/Stencyl Puzzle/Blocks Way. Hier ist der Grund:

• diese Lösung kommt der traditionellen Programmierung am nächsten. Tatsächlich ist es nur so etwas wie Syntaxzucker für den zugrunde liegenden Code (im Grunde funktioniert Stencyl so). Für mich ist es sauberer und einfacher, etwas zu verfolgen oder zu erstellen, das wie bunter, ausgefallener Code aussieht, als Diagramme von Knoten oder überladene Ereignisblätter, die Sie nicht einfügen können in nette Strukturen wie Funktionen. Für mich ist _das_ ein Durcheinander
  Denken Sie daran, dass dies nur meine Meinung ist

*Ich denke, Scrach/Stencyl-Blöcke sind die visuellste und am einfachsten zu befolgende Methode. Sie verwenden ausgiebig Farbe (und visuell denkende Menschen mögen Farben). Es ist leicht, sich daran zu erinnern, dass Gelb = Bedingungen und Schleifen, Grün = Mathematik, Blau = Variablen usw. Außerdem sieht es aus wie echter Code (im Gegensatz zu Knoten), aber freundlicher.

Schließlich glaube ich nicht, dass die visuelle Programmierung in naher Zukunft Priorität haben sollte. Es gibt viele wichtigere Dinge zu tun (vollständige Roadmap + Dokumentation) und ich nehme an, dass die Implementierung eines dieser Systeme nicht schnell und einfach wäre. Godot ist IMHO wirklich einfach zu bearbeiten, wie es jetzt ist. Es enthält viele Tools, die vom Künstler in Zusammenarbeit mit den Spieleentwicklern verwendet werden können (visueller Shader-Editor, Animationseditor, Tilemap-Knoten).

Übrigens. Ich möchte diese Gelegenheit nutzen und danke allen Godot-Erstellern und Mitwirkenden. Das hast du super gemacht :+1:

Übrigens2. Es tut mir leid für mein Englisch. Ich gebe mein Bestes, aber ich mache immer noch dumme Fehler :cry:

sei es construct2 oder blox - beide sind für mich schöner als diese Knotendiagramme.

Wenn das System Knoten nur als Container für Aktionen (als Zustände) verwendet – so wie es in Playmaker ist, dann bin ich damit einverstanden.

Das Schöne an blox und construct2 ist, dass der Editor Ihnen alle verfügbaren Bedingungen und Aktionen anzeigt. Es trennt sie für Sie und ordnet sie Kategorien zu. Das ist eine dramatische Änderung in der Präsentation, die es einem Nicht-Programmierer ermöglicht, sofort viel mit der Engine zu tun - ohne die Namen der Befehle kennen zu müssen, um Dinge zu tun.

Wenn Sie Knoten für die visuelle Programmierung verwenden, besteht die größte Herausforderung darin, dem Benutzer mitzuteilen, in welcher Reihenfolge Ereignisse ausgeführt werden. In Unity machen das sowohl Playmaker als auch Blox sehr sauber.

Im Spielmacher durch Stapeln von Aktionen in Knotencontainern (Status - enthält Aktionen). In blox - wo Sie Zustände haben, die Funktionen enthalten.

Sie bieten vollständigen Zugriff auf die meisten Funktionen von Unity. Das ist wirklich schön für Nicht-Programmierer.
blox wurde zu „plygame“ weiterentwickelt – ein weiteres Unity-Addon, das blox+ einige benutzerdefinierte Skripte enthält, auf die blox zugreifen kann, um ein komplettes RPG-Spiel im Hack- und Slash-Stil zu erstellen.

Blox in Einheit ist dasselbe wie Skrach/Stencyl-Blöcke. Es scheint hier viele Leute zu geben, die diesen Programmierstil mögen :)
https://www.youtube.com/watch?v=Nd6Qy5ZipSs&list=PLuaBtUXEKcdIAA7_yjFNcLXM5YOf3WE9k

Hoffe, Godot-Entwickler versuchen es.
Übrigens ist die Skratch (https://scratch.mit.edu/) Technologie Open Source! Und andere haben es übernommen – nicht nur Stencyl. Google hat sich auch sehr dafür interessiert:
https://developers.google.com/blockly/

Vorschlag - Warum nicht versuchen, das Beste aus beiden Welten zu haben! Knoten für eine Zustandsmaschine - blox/skratch/stencyl für Ausdrücke.
In einer idealen Welt würden Knoten als Zustandscontainer verwendet werden – wie in Playmaker. Aber die State-Container hätten ein Blox/Stencyl/Scratch-ähnliches Lego-System, das es dem Benutzer ermöglicht, die Logik einfach einzurichten – es ist nicht erforderlich, zu lernen, wie man Ausdrücke auf diese Weise schreibt – sie können einfach per Drag & Drop verschoben werden.

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

Einer der Entwickler von iCanScript sagte dies über sein VS-Asset:

Der technische Fortschritt von iCS2 entkoppelt es von einem reinen Unity-Produkt und erhöht die Marktchancen erheblich. Die Endvision ist, dass iCS2 eine Entwicklungshilfe sein wird, die verwendet werden kann, um Skripte für andere Spiele-Engines sowie Standardanwendungen für Windows/OSX/iOS/Android zu erstellen.
http://forum.unity3d.com/threads/icanscript-visual-script-modeling-engine-for-unity.280847/#post-2124402

was für ein Knotenchaos iCanScript ist!

Es ist auf jeden Fall einen Versuch wert, bevor ich darüber urteile. Vielleicht kommt jemand rein
Kontakt mit seinem Entwickler?
Wenn Godot einen Marktplatz mit Gewinnmöglichkeiten hätte - wie den hier
Unity tut - vielleicht würde das Unity-Entwickler anziehen, um Assets dafür zu erstellen
Godot auch.

Am Samstag, den 23. Mai 2015 um 16:24 Uhr schrieb todheil [email protected] :

Einer der Entwickler von iCanScript sagte dies über sein VS-Asset:

Die technische Weiterentwicklung von iCS2 entkoppelt es davon, nur eine Unity zu sein
Produkt deutlich >Steigerung der Marktchancen. Die Endvision
ist, dass iCS2 eine Entwicklungshilfe sein wird, die zum Erstellen von Skripten verwendet werden kann
für andere Game-Engines sowie Standard >Windows/OSX/iOS/Android
Anwendungen.

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

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220#issuecomment -104895405.

Ich denke, das Ereignisblatt von Konstrukt 2 ist wirklich einfach zu verstehen und einzuprogrammieren.

Als Künstler, der die meiste Zeit damit verbringt, Grafiken für seinen Lebensunterhalt zu erstellen, ist das Erlernen einer neuen Sprache sehr schwierig und zeitaufwändig. Die Leute sagen, dass Sie es in ein paar Monaten lernen können, aber wenn Sie nur 2 Stunden pro Tag für sich selbst haben, können Sie entweder von Grund auf neu lernen oder mit einer einfachen Sprache erstellen. Außerdem macht visuelles Scripting als visueller Mensch mehr Sinn.

Ich habe in der Schule programmiert und kann Code leicht lesen und verstehen, aber das Schreiben braucht Zeit. Ich versuche auch, Python zu lernen, was einfacher ist, aber es wird noch Monate dauern, etwas damit zu erstellen.

Der Ansatz von Konstrukt 2 scheint einfach. Bei mir sieht es so aus:

1 Ereignis: Aktion;

2 Ereignis: Aktion;
: Aktion;

Es ist im Grunde Programmierung, aber auf sehr leicht verständliche Weise. Wenn sie nur Sprache statt Block verwendet hätten, hätte ich nichts dagegen gehabt. Mit diesem Muster ist es einfach, eine Logik für mich zu erstellen.

Die Verwendung von Nodes kann sehr schnell außer Kontrolle geraten, wenn sich die Dinge ausbreiten und Sie mehr Zeit damit verbringen, nach den Nodes zu suchen, als tatsächlich zu codieren (wie ich von Unity und Playmaker verstanden habe).

Wenn Sie also versuchen, ein visuelles Skripting zu implementieren, denken Sie bitte sehr ernsthaft darüber nach, ein Ereignissystem zu konstruieren.

Sie können das visuelle Skriptsystem auch als herunterladbare Erweiterung für Leute wie uns erstellen, damit diejenigen, die lieber programmieren, diese zusätzliche Payload nicht herunterladen müssen.

Großartige Arbeit mit Godot, der sich darauf freut, großartige Spiele darauf zu entwickeln.

Mein Problem mit dem Ansatz von Construct ist, dass es sich wie Programmieren anfühlt
scheint nicht viel anders zu sein
Aus Teamsicht gefällt mir der Blueprint-Ansatz von Unreal besser, weil
es ist freundlicher für Designer, die keine Ahnung vom Programmieren haben

Am Sonntag, den 24. Mai 2015 um 3:58 Uhr schrieb whoisda [email protected] :

Ich denke, das Ereignisblatt von Konstrukt 2 ist wirklich einfach zu verstehen und
Programm ein.

Als Künstler, der die meiste Zeit damit verbringt, Grafiken für meinen Lebensunterhalt zu erstellen,
Das Erlernen einer neuen Sprache ist sehr schwierig und zeitaufwändig. Die Leute sagen, Sie können
lernen Sie es in ein paar Monaten, aber wenn Sie nur 2 Stunden am Tag dafür haben
selbst können Sie entweder von Grund auf neu lernen oder mit a erstellen
einfache Sprache. Außerdem macht visuelles Scripting mehr aus, wenn man eine visuelle Person ist
Sinn.

Ich habe in der Schule programmiert und kann Code leicht lesen und verstehen
aber das Schreiben braucht Zeit. Ich versuche auch, Python zu lernen, was einfacher ist
aber es wird noch Monate dauern, etwas damit zu schaffen.

Der Ansatz von Konstrukt 2 scheint einfach. Bei mir sieht es so aus:

1 Ereignis: Aktion;

2 Ereignis: Aktion;
: Aktion;

Es ist im Grunde Programmierung, aber auf sehr leicht verständliche Weise. Wenn sie
Hätte ich nur Sprache statt Block verwendet, hätte ich nichts dagegen gehabt. Mit diesem
Muster ist es einfach, eine Logik für mich zu erstellen.

Die Verwendung von Knoten kann sehr schnell außer Kontrolle geraten, wenn sich die Dinge ausbreiten und
Sie verbringen mehr Zeit damit, nach den Knoten zu suchen, als tatsächlich zu codieren (wie I
verstanden von Einheit und Spielmacher).

Wenn Sie also versuchen, ein visuelles Skript zu implementieren, geben Sie bitte ein sehr
ernsthafter Gedanke, ein Ereignissystem zu konstruieren.

Sie können das visuelle Skriptsystem auch als Download erstellen
Erweiterung für Leute wie uns, damit diejenigen, die lieber programmieren, dies nicht tun müssen
Laden Sie diese zusätzliche Nutzlast herunter.

Großartige Arbeit mit Godot, der sich darauf freut, großartige Spiele darauf zu entwickeln.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159.

Aber Sie haben die Perspektive eines Programmierers - jemand, der bereits weiß, wie
zu codieren.
In diesem Fall ist es besser, sich Statistiken anzusehen - die Anzahl der
Benutzer, die keine Programmierer sind, haben Konstrukt2 gegenüber der anderen visuellen Programmierung
Redakteure sollten für sich selbst sprechen.

Es lohnt sich auch, sich die Vielfalt der Spiele anzusehen, die in einem Stil der visuellen Programmierung gegenüber einem anderen erstellt wurden.

Unreal hat in der Tat eine große Anzahl von Projekten in Kismet durchgeführt - aber es ist eine viel ältere Engine als construct2 und viele davon sind nur Ego-Shooter

Am Sonntag, den 24. Mai 2015 um 10:15 Uhr, Juan Linietsky [email protected]
schrieb:

Mein Problem mit dem Ansatz von Construct ist, dass es sich wie Programmieren anfühlt
scheint nicht viel anders zu sein
Aus Teamsicht gefällt mir der Blueprint-Ansatz von Unreal besser, weil
es ist freundlicher für Designer, die keine Ahnung vom Programmieren haben

Am Sonntag, den 24. Mai 2015 um 3:58 Uhr schrieb whoisda [email protected] :

Ich denke, das Ereignisblatt von Konstrukt 2 ist wirklich einfach zu verstehen und
Programm ein.

Als Künstler, der die meiste Zeit damit verbringt, Grafiken für meinen Lebensunterhalt zu erstellen,
Das Erlernen einer neuen Sprache ist sehr schwierig und zeitaufwändig. Die Leute sagen Sie
kann
lernen Sie es in ein paar Monaten, aber wenn Sie nur 2 Stunden am Tag dafür haben
selbst können Sie entweder von Grund auf neu lernen oder mit a erstellen
einfache Sprache. Außerdem macht visuelles Scripting mehr aus, wenn man eine visuelle Person ist
Sinn.

Ich habe in der Schule programmiert und kann Code leicht lesen und verstehen
aber das Schreiben braucht Zeit. Ich versuche auch, Python zu lernen, was ist
Einfacher
aber es wird noch Monate dauern, etwas damit zu schaffen.

Der Ansatz von Konstrukt 2 scheint einfach. Bei mir sieht es so aus:

1 Ereignis: Aktion;

2 Ereignis: Aktion;
: Aktion;

Es ist im Grunde Programmierung, aber auf sehr leicht verständliche Weise. Wenn
Sie
Hätte ich nur Sprache statt Block verwendet, hätte ich nichts dagegen gehabt. Verwenden
Dies
Muster ist es einfach, eine Logik für mich zu erstellen.

Die Verwendung von Knoten kann sehr schnell außer Kontrolle geraten, wenn sich die Dinge ausbreiten und
Sie verbringen mehr Zeit damit, nach den Knoten zu suchen, als tatsächlich zu codieren (wie I
verstanden von Einheit und Spielmacher).

Wenn Sie also versuchen, ein visuelles Skript zu implementieren, geben Sie bitte ein sehr
ernsthafter Gedanke, ein Ereignissystem zu konstruieren.

Sie können das visuelle Skriptsystem auch als Download erstellen
Erweiterung für Leute wie uns, damit diejenigen, die lieber programmieren, keine haben
zu
Laden Sie diese zusätzliche Nutzlast herunter.

Großartige Arbeit mit Godot, der sich darauf freut, großartige Spiele darauf zu entwickeln.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
< https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159
.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220#issuecomment -104985669.

Der Programmieransatz von Construct2 ist dem in sehr ähnlich
Clickteam Fusion, das ebenfalls viele Benutzer hat. Die Leichtigkeit dazu kommt von a
eine Reihe von Dingen, obwohl es ähnlich wie beim Programmieren ist:

• Alle möglichen BEDINGUNGEN sind aufgelistet und stehen dem Benutzer zur Auswahl zur Verfügung
  durch Klicken/Ziehen in einfacher englischer Sprache hinzufügen - das ist von unschätzbarem Wert
  weil sie die Zauberwörter nicht lernen müssen. Sie können einfach ziehen und
  Lass sie fallen.
• Alle möglichen AKTIONEN sind aufgelistet und stehen dem Benutzer zur Auswahl zur Verfügung
  Hinzufügen durch Klicken/Ziehen in einfacher englischer Sprache - das ist von unschätzbarem Wert
  weil sie die Zauberwörter nicht lernen müssen. Sie können einfach ziehen und
  Lass sie fallen.
• Dasselbe gilt für alle Arten von Ausdrücken sowohl beim Einrichten als auch
  Aktion oder eine Bedingung. Beim Schreiben von Ausdrücken unterstützt Sie der Editor
  mit einer einfachen Dropdown-Liste von Dingen, die von vorhandenen Objekten in der abgerufen werden können
  Szene. Sie müssen nicht lernen, wie Sie zu diesen Eigenschaften gelangen, da sie
  sind bereits mit wenigen Klicks verfügbar.

Der vielleicht beste Aspekt daran ist, dass es Nicht-Programmierern etwas beibringt
Programmiertheorie ohne die Lernkurve des Erlernens einer neuen Programmierung
Sprache.

Am Sonntag, 24. Mai 2015 um 10:17 Uhr, Todor Imreorov [email protected]
schrieb:

Aber Sie haben die Perspektive eines Programmierers - jemand, der es bereits weiß
wie man codiert.
In diesem Fall ist es besser, sich Statistiken anzusehen - die Anzahl der
Benutzer, die keine Programmierer sind, haben Konstrukt2 gegenüber der anderen visuellen Programmierung
Redakteure sollten für sich selbst sprechen.

Am Sonntag, 24. Mai 2015 um 10:15 Uhr, Juan Linietsky < [email protected]

schrieb:

Mein Problem mit dem Ansatz von Construct ist, dass es sich wie Programmieren anfühlt
scheint nicht viel anders zu sein
Aus Teamsicht gefällt mir der Blueprint-Ansatz von Unreal besser, weil
es ist freundlicher für Designer, die keine Ahnung vom Programmieren haben

Am Sonntag, 24. Mai 2015 um 3:58 Uhr, whoisda [email protected]
schrieb:

Ich denke, das Ereignisblatt von Konstrukt 2 ist wirklich einfach zu verstehen und
Programm ein.

Als Künstler, der die meiste Zeit damit verbringt, Grafiken für meinen Lebensunterhalt zu erstellen,
Das Erlernen einer neuen Sprache ist sehr schwierig und zeitaufwändig. Die Leute sagen Sie
kann
lernen Sie es in ein paar Monaten, aber wenn Sie nur 2 Stunden am Tag dafür haben
selbst können Sie entweder von Grund auf neu lernen oder mit a erstellen
einfache Sprache. Außerdem macht visuelles Scripting mehr aus, wenn man eine visuelle Person ist
Sinn.

Ich habe Programmieren in der Schule gemacht und kann Code lesen und verstehen
leicht
aber das Schreiben braucht Zeit. Ich versuche auch, Python zu lernen, was ist
Einfacher
aber es wird noch Monate dauern, etwas damit zu schaffen.

Der Ansatz von Konstrukt 2 scheint einfach. Bei mir sieht es so aus:

1 Ereignis: Aktion;

2 Ereignis: Aktion;
: Aktion;

Es ist im Grunde Programmierung, aber auf sehr leicht verständliche Weise. Wenn
Sie
Hätte ich nur Sprache statt Block verwendet, hätte ich nichts dagegen gehabt. Verwenden
Dies
Muster ist es einfach, eine Logik für mich zu erstellen.

Die Verwendung von Nodes kann sehr schnell außer Kontrolle geraten, wenn sich die Dinge ausbreiten
und
Sie verbringen mehr Zeit damit, nach den Knoten zu suchen, als tatsächlich zu codieren (wie I
verstanden von Einheit und Spielmacher).

Wenn Sie also versuchen, ein visuelles Skript zu implementieren, geben Sie bitte ein sehr
ernsthafter Gedanke, ein Ereignissystem zu konstruieren.

Sie können das visuelle Skriptsystem auch als Download erstellen
Erweiterung für Leute wie uns, damit diejenigen, die lieber programmieren, keine haben
zu
Laden Sie diese zusätzliche Nutzlast herunter.

Großartige Arbeit mit Godot, der sich darauf freut, großartige Spiele darauf zu entwickeln.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
< https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159
.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220#issuecomment -104985669.

Betrachten Sie es auch aus der Perspektive eines Designers, der lernen möchte, komplexe Logik zu programmieren, und schließlich selbstbewusst genug wird, um das Programmieren zu lernen. Ich sehe, woher Sie kommen, wenn Sie sehen, dass das System von einem Team von Designern und Programmierern verwendet wird. Ich persönlich würde Godot gerne als Einzelnutzer nutzen und nicht im Team mit einem Programmierer wie viele Indie-Game-Entwickler. Das Event-System verzeiht Fehler und fühlt sich besser organisiert an, wenn man Gruppen verwendet, wenn man mehr als 1000 Events hat.

Abgesehen davon habe ich kein Problem mit Knotensystemen und wenn es Godot gelingt, ein System zu erstellen, das besser ist als das aktuelle, werde ich die Scheiße daraus verwenden.

Erstellen Sie außerdem, wenn möglich, eine Suchfunktion, um Codeblöcke/Knoten einfach zu finden.

Beachten Sie, dass Ereignisblätter in construct2/clickteam das Erlernen überflüssig machen
Syntax - damit der Benutzer nicht wissen muss, wo er Dinge ablegen soll - das heißt
sehr offensichtlich. Bedingungen links, Aktionen rechts. Die Reihenfolge von
Die Ausführung von Ereignissen ist ebenfalls sehr offensichtlich.
Lego-Teile in Scratch/Stencyl/Unity Blox sind nicht so offensichtlich, aber immer noch
viel besser als der in "iCanScript" vorgestellte Node-Albtraum. Hast du geschaut
in ihrem Video-Tutorial. Es ist ein super kompliziertes visuelles Programmierdesign
mit einer ziemlich steilen Lernkurve. Ich denke, dass selbst wenn Sie es zu einem geben
Programmierer werden sie Schwierigkeiten haben, es herauszufinden

Am Sonntag, den 24. Mai 2015 um 10:33 Uhr schrieb whoisda [email protected] :

Betrachten Sie es auch aus der Perspektive eines Designers, der lernen möchte
komplexe Logik zu codieren und schließlich genug Selbstvertrauen zu entwickeln, um das Codieren zu lernen.
Ich sehe, woher Sie kommen, wenn Sie sehen, dass das System von a verwendet wird
Team von Designern und Programmierern. Ich persönlich würde gerne Godot als verwenden
ein einzelner Benutzer und nicht in einem Team mit einem Programmierer wie viele Indie-Spiele
Entwickler. Das Ereignissystem verzeiht und fühlt sich besser organisiert an
Gruppen, wenn Sie über 1000 Ereignisse haben.

Abgesehen davon habe ich kein Problem mit dem Knotensystem und wenn Godot es schafft
ein System schaffen, das besser ist als das aktuelle, aus dem ich die Scheiße verbrauchen werde
es.

Erstellen Sie außerdem, wenn möglich, eine Suchfunktion, um Codeblöcke/Knoten zu finden
leicht.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220#issuecomment -104988595.

Sie verkaufen "icanscript" nicht einmal mehr im Unity Asset Store.
Schauen Sie sich dort die Verkaufszahlen an - welche der verfügbaren visuellen Programmierungen
systems ist am häufigsten im Einsatz - und hat komplette Projekte.

Ich lasse Sie nur mit diesem Video:
https://www.youtube.com/watch?v=3Zq1yo0lxOU
Es hat 167 Spiele, die mit Clickteam Fusion erstellt wurden – von Leuten, die keine haben
Programmiererfahrung.

Schauen Sie sich auch erfolgreiche Kickstarter-Spiele an, die in Fusion erstellt wurden.
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

Muss ich auch Five Nights at Freddy's erwähnen (made in clickteam fusion):
http://en.wikipedia.org/wiki/Five_Nights_at_Freddy%27s_%28video_game%29
das spiel ist ein bestseller. Hier sind einige Zahlen für Sie:
https://thinkgaming.com/app-sales-data/8779/five-nights-at-freddys/

Die Idee eines visuellen Programmierrahmens sollte es sein, einen Künstler in die Lage zu versetzen, ein Spiel zu erstellen, ohne einen Programmierer zu benötigen – und dabei ein wenig über das Programmieren zu lernen.

Wenn Sie einen erstellen, bei dem der Programmierer immer noch benötigt wird – dann haben Sie nicht wirklich ein visuelles Programmier-Framework erstellt – Sie haben nur eine Zustandsmaschine erstellt, die Programmierer für Designer einrichten können – für einfache Dinge im Spiel – aber nicht für die Kernlogik des Spiels. Sie werden also nicht wirklich etwas schaffen, das so gut und vollständig ist wie die anderen hier erwähnten visuellen Programmierwerkzeuge. Sie ermächtigen die Künstler nicht, Logik aufzubauen, und laden sie nicht ein, grundlegende Konzepte der Programmierung zu lernen. Sie halten sie von Programmierern abhängig und im Dunkeln dieser Konzepte.

Am Sonntag, 24. Mai 2015 um 10:42 Uhr, Todor Imreorov [email protected]
schrieb:

Beachten Sie, dass Ereignisblätter in construct2/clickteam das Erlernen überflüssig machen
Syntax - damit der Benutzer nicht wissen muss, wo er Dinge ablegen soll - das heißt
sehr offensichtlich. Bedingungen links, Aktionen rechts. Die Reihenfolge von
Die Ausführung von Ereignissen ist ebenfalls sehr offensichtlich.
Lego-Stücke in Scratch / Stencyl / Unity Blox sind nicht so offensichtlich, aber sind es
immer noch viel besser als der in "iCanScript" vorgestellte Node-Albtraum. Tat
Sie sehen sich ihr Video-Tutorial an. Es ist ein super kompliziertes Bild
Programmierdesign mit einer ziemlich steilen Lernkurve. Ich denke, auch wenn
Sie geben es einem Programmierer, der Schwierigkeiten haben wird, es herauszufinden

Am Sonntag, 24. Mai 2015 um 10:33 Uhr, whoisda [email protected]
schrieb:

Betrachten Sie es auch aus der Perspektive eines Designers, der möchte
Lernen Sie, komplexe Logik zu programmieren, und werden Sie schließlich selbstbewusst genug, um es zu lernen
Code. Ich sehe, woher Sie kommen, wenn Sie sehen, dass das System verwendet wird
ein Team von Designern und Programmierern. Ich persönlich würde gerne Godot verwenden
als Einzelnutzer und nicht im Team mit einem Programmierer wie viele Indie
Spieleentwickler. Das Ereignissystem verzeiht und fühlt sich organisierter an
Verwenden von Gruppen bei mehr als 1000 Ereignissen.

Abgesehen davon habe ich kein Problem mit dem Knotensystem und wenn Godot es schafft
ein System schaffen, das besser ist als das aktuelle, aus dem ich die Scheiße verbrauchen werde
es.

Erstellen Sie außerdem, wenn möglich, eine Suchfunktion, um Codeblöcke/Knoten zu finden
leicht.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220#issuecomment -104988595.

Ich denke nicht, dass es klug ist, Sie dazu zu drängen, ein System zu verwenden, das für eine andere Spiel-Engine hervorragend funktioniert, wenn dies nicht die Richtung ist, die Sie einschlagen möchten.

Gleichzeitig würde ich gerne eine intuitivere Art und Weise sehen, wie ein visuelles Skripting implementiert wird. Nicht die unordentlichen Knoten oder zeitraubenden Blöcke (Android-App-Ersteller) oder zu programmierähnliches Ereignissystem (das ich allem anderen vorziehe) verwenden. Etwas, das das Beste von allen nimmt.

Wenden Sie sich vielleicht an einen Usability-Designer, um einige Wege freizumachen und sich einige Zahlen anzusehen.

Am Ende wäre es großartig, eine einzigartige Methode von Godot zu sehen, die Godot zu einer großartigen Engine macht, die es sowohl einem Ein-Personen-Anfänger ermöglicht, sein erstes Spiel in einer Woche zu entwerfen, als auch einem Entwicklungsteam, das zusammenarbeitet, um ein AAA-Spiel zu erstellen.

Ich wäre froh, ein System zu sehen, das mir helfen würde, wunderbare Spiele zu erstellen, ohne die Engines zu wechseln und ständig Sprachen zu lernen.

Beifall.

Ich habe nichts gegen die Knoten, wenn sie wie die in Playmaker gemacht sind - als
Aktionscontainer (Zustände).
Knoten dort werden nicht wirklich verwendet, um Aktionen oder Bedingungen festzulegen.

Wenn Sie sie jedoch wie "iCanScript" machen, haben Sie ein komplettes Durcheinander.

1. Es ist schwer zu sagen, in welcher Reihenfolge Ereignisse ausgeführt werden
2. Es ist schwer herauszufinden, welcher Knoten mit welchem ​​Knoten verbunden werden kann
3. Es sind viele Knoten und Schritte erforderlich, um eine einzelne Aktion einzurichten, als dies erforderlich ist
   Ziehen Sie es per Drag-and-Drop und richten Sie einen Ausdruck darin ein (construct2/clickteam style
4. wo Sie mit der Syntax unterstützt werden - das ist eine großartige Möglichkeit, sich vorzustellen
   jemanden zum Programmieren, ohne dass er Unmengen davon lesen muss
   Dokumentation - im Drop-down-Menü der ist alles für sie da
   Objekt).

Am Sonntag, den 24. Mai 2015 um 11:20 Uhr schrieb whoisda [email protected] :

Ich halte es nicht für klug, Sie dazu zu drängen, ein System zu verwenden, das funktioniert
hervorragend für eine andere Spiel-Engine, wenn das nicht die Richtung ist, in die Sie gehen würden
nehmen wollen.

Gleichzeitig würde ich gerne einen intuitiveren Weg als einen visuellen sehen
Scripting ist implementiert. Keine unordentlichen Knoten verwenden oder Zeit in Anspruch nehmen
Blöcke (Android-App-Ersteller) oder ein zu programmierähnliches Ereignissystem (was ich
lieber als alles andere). Etwas, das das Beste von allen nimmt.

Wenden Sie sich vielleicht an einen Usability-Designer, um einige Wege freizumachen und sich einige anzusehen
Zahlen.

Am Ende wäre es großartig, eine Methode zu sehen, die einzigartig für Godot ist
Godot ist ein großartiger Motor, der sowohl einem Ein-Personen-Anfänger als auch seinem Design ermöglicht
erstes Spiel seit einer Woche und ein Entwicklungsteam, das zusammenarbeitet
Erstellen Sie ein AAA-Spiel.

Ich wäre froh, ein System zu sehen, das mir helfen würde, wunderbare Spiele zu erstellen
ohne die Motoren zu wechseln und Sprachen zu lernen.

Beifall.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220#issuecomment -104990083.

Ich stimme für @whoisda in Bezug auf etwas, das für/in Godot innoviert wird. Es scheint jedoch drei Visual Scripting-Schulen zu geben: 1) Knoten, 2) Ereignisblätter, 3) Blöcke. Von diesen scheinen drei Knoten das Feld in 3D-Umgebungen anzuführen. Apropos, ich habe irgendwo eine Idee gelesen, die vorschlägt, Scripting/Programmierung aus einem linearen (Text, Blöcke, Ereignisblatt) oder horizontalen (Knoten) Format auszubrechen und mithilfe von Strukturen in 3D zu programmieren. Ich bin mir nicht sicher, wie das funktionieren würde, aber es klingt faszinierend.

Die genannten Visual Scripting Schulen sind praxiserprobt und
haben bereits Benutzer. Ich schlage vor, die Designs von Playmaker und zu kombinieren
blox in Einheit.

Knoten zum Erstellen einer Zustandsmaschine.
Blöcke oder Ereignisblätter zum Erstellen der Aktionen innerhalb jedes Knotens (Zustand).

Am Sonntag, den 24. Mai 2015 um 13:56 Uhr schrieb todheil [email protected] :

Ich stimme für @whoisda https://github.com/whoisda in Bezug auf etwas
für/in Godot innoviert werden. Allerdings scheint es drei Visual zu geben
Skriptschulen: 1) Knoten, 2) Ereignisblätter, 3) Blöcke. Von diesen drei
Nodes scheinen das Feld in 3D-Umgebungen anzuführen. Apropos
Ich habe irgendwo eine Idee gelesen, die darauf hindeutet, Scripting/Programmierung auszubrechen
lineares (Text, Blöcke, Ereignisblatt) oder horizontales (Knoten) Format und
Programmieren in 3D mit Strukturen. Nicht sicher, wie das funktionieren würde, aber klingt
faszinierend.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220#issuecomment -105001411.

Es wäre toll, wenn wir Nodes und Events gemeinsam nutzen könnten. Knoten können die Zustände sein, die, wenn sie einer einfachen Logik folgen, in andere Knoten gesteckt werden können oder Container für Skripte/Blöcke/Ereignisblätter sein können, auf diese Weise haben wir keine sehr großen Knoten und können auch als Team zusammenarbeiten. Aber das könnte für den Entwickler zu viel sein. Trotzdem scheint die Idee sehr nett zu sein.

So ist es bei Playmaker - die Leute scheinen es sehr zu mögen.
Viele Leute hier scheinen auch Stencyl zu mögen - die Technologie schon
Open Source und auf der Scratch-Github-Website verfügbar. Ich teilte es in a
vorherigen Post.

Ich persönlich würde gerne ALLE ersten Schritte in der visuellen Programmierung sehen
Richtung. Selbst wenn der Entwickler eine Zustandsmaschine erstellt, die mit gd funktioniert
Skripte - das wäre ein erstaunlicher Anfang, den selbst fortgeschrittene Programmierer kennen
würde es zu schätzen wissen.

Danach können wir vielleicht etwas Visuelles wie Stencyl oder
construct2 - das ist wie Code - aber viel einfacher als Code - innerhalb der
Zustände.

Also eigentlich sind das zwei Feature Requests!

• Einer für eine Zustandsmaschine (Knoten)
• ein weiteres für ein visuelles Scripting-Framework, das das Erlernen von gdscript ersetzt
  mit Drag-and-Drop-Codierung. Aber auch ein schöner Schritt in Richtung Lernen
  gdscript.

Am Ende weiß der Hauptentwickler, was das Beste für Godots Design ist.

Am Dienstag, den 26. Mai 2015 um 11:43 Uhr schrieb whoisda [email protected] :

Es wäre toll, wenn wir Nodes und Events gemeinsam nutzen könnten. Knoten können die
Zustände, die, wenn sie einer einfachen Logik folgen, in andere Knoten gesteckt werden können oder
können Container für Skripte/Blöcke/Ereignisblätter sein, die wir so nicht haben werden
sehr große Knoten und können auch als Team zusammenarbeiten. Aber das könnte auch sein
viel für den Entwickler. Trotzdem scheint die Idee sehr nett zu sein.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220#issuecomment -105446984.

Ich werde Styencyl bald überprüfen, weil ich damit nicht vertraut bin.
An dieser Stelle kann ich aus allem, was ich gesehen / gelesen habe, Folgendes entnehmen:

1) Blueprint: Eignet sich hervorragend für Spiel-/Level-Designer, aber nicht so gut für
visuelle Programmierung
2) Stencyl: Ist viel besser für die visuelle Programmierung, aber unbrauchbar für
Spiel-/Level-Designer

Meine Erfahrung beim Erstellen von Spielen lag immer in Teams, also kann ich 1) so sehen
sehr nützlich, aber das macht mich auch voreingenommen. Sind da so viele Leute
Interesse an visueller Programmierung wie in Stencyl?

Am Dienstag, 26. Mai 2015 um 6:10 Uhr, Todor Imreorov [email protected]
schrieb:

So ist es bei Playmaker - die Leute scheinen es sehr zu mögen.
Viele Leute hier scheinen auch Stencyl zu mögen - die Technologie schon
Open Source und auf der Scratch-Github-Website verfügbar. Ich teilte es in a
vorherigen Post.

Ich persönlich würde gerne ALLE ersten Schritte in der visuellen Programmierung sehen
Richtung. Selbst wenn der Entwickler eine Zustandsmaschine erstellt, die mit gd funktioniert
Skripte - das wäre ein erstaunlicher Anfang, den selbst fortgeschrittene Programmierer kennen
würde es zu schätzen wissen.

Danach können wir vielleicht etwas Visuelles wie Stencyl oder
construct2 - das ist wie Code - aber viel einfacher als Code - innerhalb der
Zustände.

Also eigentlich sind das zwei Feature Requests!

• Einer für eine Zustandsmaschine (Knoten)
• ein weiteres für ein visuelles Scripting-Framework, das das Erlernen von gdscript ersetzt
  mit Drag-and-Drop-Codierung. Aber auch ein schöner Schritt in Richtung Lernen
  gdscript.

Am Ende weiß der Hauptentwickler, was das Beste für Godots Design ist.

Am Dienstag, 26. Mai 2015 um 11:43 Uhr, whoisda [email protected]
schrieb:

Es wäre toll, wenn wir Nodes und Events gemeinsam nutzen könnten. Knoten können die
Zustände, die, wenn sie einer einfachen Logik folgen, in andere Knoten gesteckt werden können
oder
können Container für Skripte/Blöcke/Ereignisblätter sein, auf diese Weise werden wir es nicht tun
verfügen über
sehr große Knoten und können auch als Team zusammenarbeiten. Aber das könnte sein
auch
viel für den Entwickler. Trotzdem scheint die Idee sehr nett zu sein.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105446984
.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220#issuecomment -105458142.

http://www.emanueleferonato.com/wp-content/uploads/2011/12/stencyl05.png

Ist dies ein kanonisches Beispiel dafür, wie Stencyl "Code" aussieht? Wenn ja, dann scheint es eine schreckliche Idee zu sein: Es sieht aus wie eine Standardcodierung in visuellen Verpackungen für den Kindergarten. Komm schon, Python ist für meine Frau bereits leicht genug, um es zu lesen, also warum nicht die Mühe machen, die Grundlagen zu lernen?

Wenn Sie von visueller Programmierung sprechen, dann ist das, was Godot bereits hat, viel besser - Shader-Graphen oder Animationsgraphen: Code, der in visuelle Knoten verpackt ist.
https://frenchdog.files.wordpress.com/2009/09/specular_reflexion_vops.jpg - ein weiteres Beispiel für visuelle knotenbasierte Programmierung (Sidefx Houdini oder XSI). Es ist ausgereift und sieht nicht aus wie ein Kinderspielzeug, erinnert mich auch an Godot-Knoten.

Mir gefiel der construct2-Ansatz, aber nachdem ich mich mehr mit Scratch befasst habe, scheint er aus mehreren Gründen die bessere Wahl zu sein:

• Das Programmierdesign scheint beliebter zu sein als das von construct2
• Es hat sich bereits als Werkzeug etabliert, um Menschen eine Programmiersprache beizubringen
• Es ist Open Source und andere haben es in der Vergangenheit für ihre Engine umfunktioniert

Stencyl-Entwickler haben die Open-Source-„Scratch“-Technologie übernommen. Es ist nicht ihr Design.
https://scratch.mit.edu/about/
http://en.wikipedia.org/wiki/Scratch_ (Programmiersprache)
http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code

Beispiele dafür, dass Scratch von anderen Spiele-Engines verwendet wird, die auf Nicht-Programmierer abzielen:

• Stencyl (am beliebtesten) http://www.stencyl.com/
  
• Craftstudio ( http://craftstud.io/ )
  
• Google Blockly ( https://developers.google.com/blockly/ )
• Am nächsten an Godot ist das visuelle Programmierobjekt „Blox“ von Unity:
  
  https://www.youtube.com/watch?v=Nd6Qy5ZipSs&list=PLuaBtUXEKcdIAA7_yjFNcLXM5YOf3WE9k
  Anstelle von Lua generiert es C#.
  Die vollständige Dokumentation ist hier:
  http://www.plyoung.com/blox/
  und wird hier verkauft: https://www.assetstore.unity3d.com/en/#!/content/12859

Für erfahrene Programmierer mag es wie eine schreckliche Idee erscheinen, aber es ist der beste Weg, Nicht-Programmierern das Schreiben von Code beizubringen oder sie einfach zum Programmieren zu befähigen, ohne die Zauberwörter oder die Syntax zu kennen. Scratch macht sie alle per Drag-and-Drop verfügbar und erzwingt eine korrekte Struktur mit visuellen Hinweisen. Bitte sehen Sie sich die Video-Playlist „Unity Blox“ an, die ich gepostet habe, um sie in Aktion zu sehen. Vor allem hat es sich in der Praxis immer wieder bewährt. Es sieht aus wie die sicherste Wette.

Ich stimme @reduz in seinen Punkten zu, dass der eine gut im Level-Design und der andere im visuellen Scripting ist und ich nicht länger argumentiere, einen über dem anderen zu verwenden.

Die Verwendung beider scheint der beste Ansatz zu sein. Wenn nicht Unity blox, selbst wenn Sie sich Playmaker ansehen, werden Sie feststellen, dass Knoten dort wirklich Container sind – wo Aktionen gestapelt werden können – sehr ähnlich wie bei Stencyl. Sie ziehen sie per Drag-and-Drop aus einer Liste!

"Aber es ist der beste Weg, Nicht-Programmierern das Schreiben von Code beizubringen oder sie einfach zum Programmieren zu befähigen, ohne die Zauberworte zu kennen."

Dann verstehe ich nicht, auf welche Zielgruppe diese Zielgruppe ausgerichtet ist. Hat Godot das Ziel, mit den großen Jungs auf dem Markt (Unreal Engine, Unity usw.) zu konkurrieren oder Kindern das Programmieren/Erstellen von Spielen beizubringen, wie es Scratch tut (https://scratch.mit.edu/)?

Ich weiß, was Knoten sind (Eingabe -> Funktion mit Parametern -> Ausgabe), ich bin mit der Darstellung nicht einverstanden.

Stencyl und Playmaker mögen großartig darin sein, Kindern das Programmieren beizubringen, aber sie wurden erfolgreich von Nicht-Programmierern (sowohl Studios als auch Indie) verwendet, um erfolgreiche Spiele zu entwickeln, die auf verschiedenen Plattformen verkauft werden.
Wenn Sie Unity als die großen Jungs einstufen, dann sollten Sie wissen, dass große Jungs auch visuelle Programmierung machen.
http://www.hutonggames.com/showcase.html

Ich denke, Godot hat viele Funktionen, die von den großen Jungs genutzt werden können. Ein paar Funktionen, die kleinere/Indies ermöglichen, könnten bei der schnelleren Einführung der Engine helfen. Und die Open-Source-Natur und die schlanke Lizenzierung sind für den Anfang sehr lukrativ.

@blurymind
Ich argumentiere _nicht_ gegen visuelle Programmierung. Ich würde sagen, Godot hat bereits, was es braucht (ShaderGraphs): Derselbe visuelle Ansatz könnte auf die Logikprogrammierung von Zustandsmaschinen oder die allgemeine Programmierung erweitert werden. Wogegen ich argumentiere, ist dagegen, ein weiteres visuelles Paradigma (~scratch) zu übernehmen, das Kinder nicht abschreckt.

Wie bereits erwähnt, ist es nicht nur für Kinder. Aber wenn es auch Kinder verstehen und anwenden können – dann finde ich das gut. Nichts wofür man sich schämen muss.

Der wichtigste Punkt, den ich hier machen möchte, ist folgender:

• Die Reihenfolge der Aktionen sollte klar sein! Die gesamte Logik mit Knoten auszuführen, kann sehr schnell sehr chaotisch werden. Knoten sollten also für Zustände imo verwendet werden.
• Die Playmaker-Entwickler haben dieses Problem sehr clever antizipiert und deshalb Nodes als Aktionscontainer konzipiert, in denen Sie – ganz ähnlich wie bei Stencyl – verfügbare Aktionen per Drag-and-Drop aus einer Liste ziehen:
  
  und Ereignisse auf diese Weise stapeln

Was Sie am Ende erhalten, ist ein sehr sauberer und effizienter Knotenaufbau!

Ich schlage vor, dass Godot-Entwickler auch Playmaker ausprobieren.
Das Ersetzen des Event-Stacks durch Stencyl-Logik würde Godots Herangehensweise viel flexibler/leistungsstärker machen!.

Es muss nicht nur über einen Stencyl-Ansatz erfolgen. Ich denke, Sie können erfahrenen Programmierern ermöglichen, gd-Skripte an Knoten anzuhängen. Die Möglichkeit zu haben, einen Stencyl-Ansatz zum Erstellen von Gdscripts zu verwenden, wäre imo von unschätzbarem Wert. Es wird viele neue Benutzer in die Godot-Community einladen.

@blurymind
Okay, aber das ist etwas anderes. Einfach zu bedienen bedeutet nicht, dass es so aussehen sollte, als wäre es für Kinder gedacht.
Die Reihenfolge der Ausführung und das unterstützte Filtern geeigneter Eingaben/Ausgaben für einen bestimmten Knoten sind häufige Probleme für knotenbasierte Arbeitsabläufe. Unterschiedliche Software löst es unterschiedlich.

Sie müssen sich fragen: Wollen Sie, dass mehr Nicht-Programmierer Godot verwenden? Wollen Sie es Leuten ermöglichen, die keine Erfahrung mit gdscript haben, etwas Spaß zu machen?

Wenn die Antwort ja lautet, dann ist der beste Weg, ihnen einen visuellen Skripting-Ansatz zu geben.
Ich schlage nicht vor, Knoten wie etwas für Kinder aussehen zu lassen.
Was ich vorschlage, ist, dies in zwei Projekte aufzuteilen!

• Knoten, die als Zustandsmaschine verwendet werden - wie in Playmaker! Programmierer können jeden Knoten benennen und gdscripts daran anhängen – mit Ein- und Ausgabe, die sie einrichten. Das ist also überhaupt nichts für Kinder. Tatsächlich ist dies ein viel flexiblerer Ansatz für Programmierer, der viel weniger chaotisch ist.
• Ein Drag-and-Drop-Ereignisblatt oder eine Blockschnittstelle als alternative Möglichkeit zum Generieren eines GDscripts. Anstatt ein GdScript zu schreiben, das an einen Knoten angehängt wird, können Nicht-Programmierer einfach Aktionen aus einer Liste aller verfügbaren Ereignisse in Godot stapeln - ähnlich wie Playmaker. Um noch einen Schritt weiter zu gehen und innovativ zu sein - anstatt einfach Aktionen zu stapeln, wäre es noch besser, Stencyl-ähnliche Blöcke zu verwenden.

Auf diese Weise haben Sie etwas, das sowohl für Programmierer als auch für Nicht-Programmierer nützlich ist. Sie können beide die Zustandsmaschine (Knoten) verwenden und Nicht-Programmierer müssen gdscript nicht sofort lernen und stattdessen gdBlocks verwenden, um ein gdscript für einen Knoten zu generieren (wieder - wie in Playmaker).

@blurymind
Ich mag das lieber. Es stimmt auch mit Shader Node-Graph vs. Shader-Text überein, der bereits in Godot vorhanden ist.

SideFX Houdini hat etwas namens VEX (https://goo.gl/TMWNKk) ("Vektorausdruck" eine c-ähnliche Sprache, die für Vektoralgebra gedacht ist). Es ist etwas synonym zu gdScript. Es hat auch etwas namens "VOPs" (http://goo.gl/Qpn2OE) (Vex Operators) - im Wesentlichen visuelle Wrapper einer Teilmenge von VEX, die dem LeadWerks-Node-Graph-Bild, auf das Sie oben verwiesen haben, sehr ähnlich sehen. Tatsächlich können VOPs bei Bedarf in das Textskript umgewandelt werden (aber nicht umgekehrt).

Die Koexistenz der 2 ist ganz natürlich und ermöglicht es sogar Nicht-Programmierern, sehr chaotischen und ineffizienten Code zu erstellen;)

Ich persönlich mag den Blueprint-Ansatz, weil er sehr spieldesignerisch ist
wie, aber ich bestehe darauf, dass ich voreingenommen sein könnte.

Ich habe Stencyl vor zwei Stunden heruntergeladen und damit gespielt. ich könnte
irre, aber ich denke Stencyl ist ein gutes Werkzeug um da nicht nur das zu lernen
Der Programmierteil ist vereinfacht, aber auch der Motorteil. Die Kombination ist
gut, weil es ein einfacher Programmieransatz für eine einfache Spiel-Engine ist.

Aber Godot ist keine einfache Spiel-Engine (zumindest im Vergleich zu Stencyl), also ich
glaube nicht, dass eine vereinfachte Programmierung so nützlich wäre. Stencyl setzt auf
eine Menge hartcodierter Spiellogik-Sachen, die einfach nicht verfügbar sein werden
Godot, und der Versuch, es verfügbar zu machen, widerspricht dem Godot-Ziel
eine sehr universelle Spiel-Engine zu sein.

Der Node-and-Graph-Ansatz ist meiner Meinung nach interessanter, weil er es ist
eine niedrigere Ebene und eine flexiblere Art, Dinge zu tun.

Am Dienstag, 26. Mai 2015 um 11:29 Uhr, Vladimir Lopatin < [email protected]

schrieb:

@blurymind https://github.com/blurymind
Ich mag das lieber. Es ist auch konsistent mit Shader Node-Graph vs
Shader-Text, der bereits in Godot ist.

SideFX Houdini hat etwas kaltes VEX (https://goo.gl/TMWNKk) ("vector
expression" eine c-ähnliche Sprache, die für die Vektoralgebra gedacht ist). Das ist es
etwas auch zu gdScript. Außerdem hat es etwas namens "VOPs" (
http://goo.gl/Qpn2OE) (Vex Operators) – im Wesentlichen visuelle Wrapper von a
Teilmenge von VEX, die dem Knotendiagramm von LeadWerks, das Sie verwenden, sehr ähnlich sehen
oben verwiesen. Tatsächlich können VOPs bei Bedarf in das Skript umgewandelt werden
(aber nicht umgekehrt).

Die Koexistenz der 2 ist ganz natürlich und erlaubt es sogar
Nicht-Programmierer, um sehr chaotischen und ineffizienten Code zu erstellen;)

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220#issuecomment -105543845.

Was ist mit Action Stacking in Playmaker und Blox in Unity? Unity ist keine sehr einfache Engine.

Ich denke, Stencyl ist kein sehr gutes Beispiel. Es ist besser, im Unity Asset Store nach Beispielen zu suchen.

Ich habe versucht, Playmaker zu verstehen, bin aber gescheitert, wie soll es funktionieren?

Am Dienstag, 26. Mai 2015 um 12:16 Uhr, Todor Imreorov [email protected]
schrieb:

Was ist mit Action Stacking in Playmaker und Blox in Unity? Einheit ist keine
sehr einfacher Motor.

Ich denke, Stencyl ist kein sehr gutes Beispiel. Es ist besser zu suchen
Beispiele im Unity Asset Store.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760.

habe das Tutorial von Playmaker überprüft, aber es scheint ähnlich zu sein wie stencyl in
das Gefühl, dass es mit einer Million vordefinierter Verhaltensweisen einhergeht

Am Dienstag, 26. Mai 2015 um 12:19 Uhr, Juan Linietsky [email protected]
schrieb:

Ich habe versucht, Playmaker zu verstehen, bin aber gescheitert, wie soll es funktionieren?

Am Dienstag, 26. Mai 2015 um 12:16 Uhr, Todor Imreorov < [email protected]

schrieb:

Was ist mit Action Stacking in Playmaker und Blox in Unity? Einheit ist keine
sehr einfacher Motor.

Ich denke, Stencyl ist kein sehr gutes Beispiel. Es ist besser zu suchen
Beispiele im Unity Asset Store.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760
.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220#issuecomment -105563777.

_OkamStudio_

Der U4-Blaupausen in Unity am nächsten kommt uScript:
https://www.assetstore.unity3d.com/en/#!/content/1808

Die Leute scheinen Playmaker gegenüber uscript zu bevorzugen, da es einfacher ist, die eingerichtete Logik zu verstehen. Wie Sie auf den Screenshots sehen können, wird es selbst bei einfacher Logik sehr chaotisch.

@reduz @okamstudio hier ist eine Playlist auf Playmaker:
https://www.youtube.com/watch?v=I9VwsVtbgFU&index=2&list=PLC759306A1E692A10
Ich denke, Sie sollten es tatsächlich für eine Weile verwenden. Sie können vordefinierte Verhaltensweisen und Skripte erstellen, aber mit Playmaker können Sie auch auf die Kernfunktionen der Engine zugreifen und solche Verhaltensweisen von Grund auf selbst erstellen.

Ja, Playmaker ist eine Zustandsmaschine und Unity bringt viele vordefinierte Verhaltensweisen mit sich.
Godot hat sie auch - sie sind in den Motor eingebaut.
Ich glaube immer noch, dass Sie ein Skript/Verhalten von Grund auf neu erstellen können, indem Sie den Stencyl-Klon-Blox von Unity verwenden.

Ich denke, man braucht endlich einen Programmierer, um ein richtiges Spiel und diese Idee zu machen
Es ist großartig, dass Spieledesigner das Spiel selbst machen, aber ich denke, es sind viele
Arbeit, die in vielen Fällen nicht praktisch ist. aber wenn wir mehr haben
Funktion für den Editor selbst wie den Platformer-Designer oder jemand anderen
in einer anderen Ausgabe erwähnt oder andere nützliche Dinge, um die Benutzeroberfläche zu vereinfachen
freundlicher.
Am 26. Mai 2015 um 19:52 Uhr schrieb „Okam Studio“ [email protected] :

habe das Tutorial von Playmaker überprüft, aber es scheint ähnlich zu sein wie stencyl in
das Gefühl, dass es mit einer Million vordefinierter Verhaltensweisen einhergeht

Am Dienstag, 26. Mai 2015 um 12:19 Uhr, Juan Linietsky < [email protected]

schrieb:

Ich habe versucht, Playmaker zu verstehen, bin aber gescheitert, wie soll es funktionieren?

Am Di, 26. Mai 2015 um 12:16 Uhr, Todor Imreorov <
[email protected]

schrieb:

Was ist mit Action Stacking in Playmaker und Blox in Unity? Einheit ist
kein
sehr einfacher Motor.

Ich denke, Stencyl ist kein sehr gutes Beispiel. Es ist besser zu suchen
Beispiele im Unity Asset Store.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
<
https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760
.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105563777
.

_OkamStudio_

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220#issuecomment -105565084.

Hier ist eine Bewertung im Unity Asset Store für uScript:

Gutes Tool, aber für Nicht-Programmierer schwer zu erlernen... Antworten auf Hilfeanfragen in den Foren sind sehr langsam oder gar nicht vorhanden..

Was auch immer in Godot landet, ich denke - wenn möglich - wäre es eine gute Idee, eine Einweg-Konvertierung in GDScript zuzulassen. Dies würde es ermöglichen, Dinge schnell visuell einzurichten, von Designern und Künstlern und dergleichen, und es den Programmierern im Team dann zu ermöglichen, sie weiter zu optimieren und zu überarbeiten, ohne das Pointy-Clicky verwenden zu müssen.

@adolson Das wäre ein sehr erwünschtes Feature :)

Dies könnte und auch mit dem visuellen Shader-Editor erfolgen
(was tatsächlich Shader-Code generiert)
aber ich denke, der generierte Shader-Code wird nicht so lesbar sein wie Sie vielleicht
erwarte :P

Am Dienstag, den 26. Mai 2015 um 18:33 Uhr schrieb Nathan [email protected] :

@adolson https://github.com/adolson Das wäre sehr erwünscht
Merkmal :)

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/okamstudio/godot/issues/1220#issuecomment -105670945.

@reduz Einige Metadaten werden erwartet.
Hier ist ein Beispiel für die Konvertierung von VOPs -> VEX-Konvertierung, wie oben angegeben:
:
Und hier ist die vollständige Auflistung des Codes , der ansonsten in reinem VEX so aussieht:
@P += Vektor({0,1,0}); // Position einnehmen und Vektor hinzufügen (0,1,0)

Wie Sie sehen können, ist die Menge an Metadaten erheblich, aber es ist nicht schwierig, die 2 zu trennen, möglicherweise halb- oder vollautomatisch zu analysieren.

@reduz Das stimmt. Daran habe ich nicht wirklich gedacht. Es wird wahrscheinlich nicht die Art von Code sein, mit der die meisten Programmierer ihre Zeit verbringen möchten. Ich könnte mir vorstellen, dass Labels zu Variablennamen werden und so, aber ich kann nicht viel anderes sehen, um das Problem zu entschärfen.

Ich kann zwar nicht für alle sprechen, aber wenn ich ein Durcheinander von Code sehe, nehme ich vielleicht ein paar Bits und Stücke daraus, aber normalerweise fühle ich mich geneigt, ihn einfach neu zu schreiben. Also, wenn dem so wäre, würde sich das für mich persönlich nicht lohnen.

Ihr habt wirklich die ganze Bandbreite an Möglichkeiten durchgespielt. Ich habe Construct 2 verwendet, und obwohl es ordentlich ist, können Sie niemals einen Code berühren, um ihn zu verfeinern, und die Optionen waren ziemlich begrenzt. Das Tilemap-Update hat im Grunde Prefabs und damit auch die Instanziierung beseitigt. Was mir wirklich gut gefallen hat, war PlayMaker for Unity.

Irgendwie war es sehr einfach, den Überblick über Ihren Umfang und das, was Sie tun mussten, zu behalten. Das ist ein wirklich ansprechender Faktor, der ganze Grund, warum ich visuelle Skriptoren verwende, ist genau das. Ich verliere den Überblick darüber, was ich getan habe oder was ich in Textcode tun muss, aber zu sehen, wie alles „zusammenhängt“, hat den absolut größten Nutzen für mich. NateWardog hat viel früher ein Beispiel in einem Screenshot gepostet und blurrymind erst kürzlich.

Ich sage reduz, du machst es. Wenn Sie sich jetzt die Mühe machen, würde ich für 1.3 oder höher schießen und mich selbst dann hauptsächlich auf die Frontend-Seite konzentrieren. Wenn es dann später fertig ist, konzentrieren Sie sich darauf, es dazu zu bringen, lesbaren Code wie Blueprint auszugeben, was meiner Meinung nach sehr schwierig wäre. Bitte unterschätzen Sie diese nicht!

Abonnieren. Das interessiert mich auch sehr! Ich kenne einige Skripte und habe nichts dagegen, sie zu verwenden ... aber ich bevorzuge das Verbinden von Knoten, wenn dies möglich ist! So etwas wie die Logikbausteine ​​in der Blender Game Engine, die als visuelle Abkürzungen für Godot-Skriptfunktionen dienen, anstatt sie von Hand zu schreiben ... das wäre ein nettes Feature, auf das ich aktiv warte.

Visual Scripting zieht wirklich viele kreative Leute an oder Leute, die keine neue Skriptsprache wie gd script lernen wollen. Ich habe mir angesehen, dass Game Maker so verdammt beliebt ist, und der einzige Grund dafür ist die visuelle Skriptmechanik.

Visual Scripting ist mühsam, dumm und schwer zu verwenden.
Ich sehe nie eine gute Umsetzung. Visuelle Menschen sollten Grafiken zeichnen. ich
weiß, dass viele Leute einfach nicht schreiben können,
aber das wird ihnen nichts nützen. Nicht programmierende Person bedeutet nicht
Analphabeten.

Ich kenne kein Tool zum Erstellen visueller Logik, für das das Hauptsystem war
Spiellogik in jeder Engine.
Der visuelle Weg saugt in vielen Aspekten. Visuelle Menschen denken normalerweise darüber nach
Programmieren als "Tech-Zeug"
was wirklich etwas von Klempnerarbeit und harter Arbeit bedeutet und oben sein möchte
es. Diese Haltung
liegt normalerweise an einigen intellektuellen Problemen. Ich glaube nicht, dass diese Leute
Zielgruppe sein können
im Grunde schränken sie ihre Kreativität ein.

Am Do, 14. April 2016 um 8:33 Uhr, Rémi Verschelde [email protected]
schrieb:

Bearbeiten: Ich sehe, Sie haben "RPG Maker" in "Game Maker" geändert, jetzt macht es mehr
Sinn :p Meinen Beitrag entfernen.

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/godotengine/godot/issues/1220#issuecomment -209770726

Ich möchte nicht, aber ich muss es sagen, aber das ist eine sehr enge Sicht auf visuelle Skripting-Tools, Sergey. Bei Spielen, die vollständig mit ihnen erstellt wurden, haben sich einige Engines vollständig dagegen entschieden, wie z. B. Construct, sodass Sie kein Spiel außerhalb dieser Engine sehen werden, das mit regulärem Skripting erstellt wurde. Andere (vernünftigere, imo) Engines haben Plugins wie Unity und UE4. Ich persönlich habe es sehr gemocht, neben meinem regulären Code sowohl uscript als auch PlayMaker in Unity zu verwenden, denn während einige Dinge einfacher zu codieren sind, lassen sich viele einfacher visuell skripten, insbesondere Zustandsmaschinen, da Sie mit einem visuellen Skripter wie PM viel Feedback erhalten Breakpointsw ist es einfach so viel einfacher, das Projekt aus einer umfassenderen Perspektive zu betrachten.

Das eigentliche an Visual Scripting im Allgemeinen ist ein vergeblicher Versuch
Programmieren für Nicht-Programmierer zugänglich machen, was völlig falsch ist
sich nähern.
Die visuelle Programmierung ist schwieriger als die normale Textprogrammierung. Um es zu schaffen
einfacher müssen Sie viele Blöcke für jeden Fall im Leben auf traditionelle Weise schreiben
Weg und
lass diese Leute sie benutzen. Diese erwiesen sich als weniger effektiv als die Frage nach a
guter Programmierer, um Code zu schreiben. Der Spruch „Programmieren ist kein Beruf,
Jeder kann es" ist falsch. Alle Versuche, ohne zu programmieren
Programmieren ist eine Verschwendung.

Was die Zustandsmaschine betrifft - ich habe darüber nachgedacht, dies einige Zeit zu implementieren
her, aber das wird dem High-Visuals-Programm nicht helfen.
Dies kann für Ihr Spiel einfach mit dem Werkzeugskript und dem Knoteneditor durchgeführt werden.
Dies ist ein leistungsstarkes Tool, das viele Leute für Spieltools verwenden, z
Editoren für Spieldialoge.

Am Donnerstag, den 14. April 2016 um 9:09 Uhr schrieb Aaron M [email protected] :

Ich möchte es nicht sagen müssen, aber das ist eine sehr enge Sicht auf das Visuelle
Scripting-Tools, Sergey. Was Spiele betrifft, die vollständig damit erstellt wurden,
Einige Engines haben sich vollständig für sie entschieden, wie z. B. Construct, also Sie
wird kein Spiel aus dieser Engine sehen, das mit normalem Skripting erstellt wurde. Andere
(vernünftiger, imo) Engine haben Plugins wie Unity und UE4. Ich, persönlich
Ich mochte es sehr, sowohl uscript als auch PlayMaker in Unity neben meinem regulären zu verwenden
Code, denn während einige Dinge einfacher zu programmieren sind, sind viele einfacher zu programmieren
visuell ausschreiben, insbesondere Zustandsautomaten, weil mit einem visuellen Skript
Skripter wie PM geben dir viel Feedback mit Breakpointsw, es ist nur so
Es ist so viel einfacher, das Projekt aus einer umfassenderen Perspektive zu betrachten.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/godotengine/godot/issues/1220#issuecomment -209776732

Slappin, du hast Recht. Dabei vergisst man aber, dass visuelles Programmieren bzw. Programmierbausteine ​​eine sehr geringe Ausfallrate haben. Das liegt an den Einschränkungen.
Es ist im Grunde dasselbe, wenn Sie eine sehr begrenzte Skriptsprache verwenden. Viele Fehler kann man nicht machen.

Ich denke, das sollte das Ziel sein, nicht die Frage ob Visual- oder Text-Scripting!

Wenn Sie die Programmierung verbessern wollen, machen Sie die Tools besser. Codehighlighting, Codecompletion, Codevalidation, Codetemplates, etc. Verbessern Sie den Debugger und machen Sie Liveprogramming.
Ich habe immer nach einer stabilen Liveprogrammierumgebung gesucht, aber bis jetzt habe ich sie nicht gefunden!

Wenn Sie wirklich Visual Scripting machen wollen, machen Sie es wie die Stingray Engine. Sie können CodeBlocks in Visual erstellen und TextCode generieren, den Sie später ändern können, oder TextCode schreiben, den Sie später als Visual Blocks verwenden können.

Ich würde nicht sagen, dass es sinnlos ist, aber ich würde sagen, dass wir über 2 sprechen
ganz andere Produkte.

Wenn Sie ein Studio betreiben und Spiele mit sagen wir 20-80 Leuten machen,
Sie geben jeden Monat 6-stellige Produktionskosten aus, und Sie brauchen eine
Engine, um Ihre Spiele zu erstellen, möchten Sie ein bestimmtes Produkt. In diesem Fall Sie
Kümmern Sie sich überhaupt nicht um die visuellen Skriptwerkzeuge, Sie kümmern sich um andere
Dinge, wie z. B. wie produktiv Ihr Team mit den Werkzeugen der Engine sein wird
(denn wenn sie den Zeitplan für einen Monat überschreiten, sind Sie ~ $ 100.000). Jene
Teams haben Programmierer, und sie werden beim Schreiben von Code viel produktiver sein
als ein visuelles Tool zu verwenden (siehe Vicious Engine für ein Beispiel dafür)

Andererseits, wenn du eine coole Idee hast und nicht so richtig weißt wie
Schreiben Sie Code, Sie wollen ein anderes Produkt, etwas, um einen schnellen Prototypen zu machen
Sie können herumzeigen und schließlich Programmierern geben, um das Tatsächliche zu machen
Spiel.

Es sind 2 verschiedene Produkte, und wenn wir darüber streiten, welches mehr wert ist
haben, das müssen wir anerkennen. Ich würde sagen, dass das visuelle Skripting
Das Tool lässt sich nicht wirklich auf mehr als 1 Person skalieren, die einen Prototyp erstellt. Wie
sobald Sie ein komplettes Spiel machen möchten oder sobald Ihr Team auf 2-3 anwächst
Leute, ihr braucht schon eine richtige Programmiersprache. Also ich mag das erste
Beispiel eher als Gesamtziel (es sei denn, Sie möchten ein drittes Produkt, das ist
„Die Engine, mit der Sie ein komplettes Indie-Spiel erstellen können, das Millionen einbringt
ohne Code zu schreiben". Das gibt es nicht).

Aber wir können beides haben, und ich würde keines davon entmutigen. Ein visuelles
Scripting-Tool würde uns langfristig helfen, indem es Anfängerbenutzer erstellt
das wird schließlich in der Branche funktionieren und in Positionen sein, um sich dafür zu entscheiden
Verwenden Sie Godot für ein echtes Spiel, und das ist gut. Auch der CTO von Square Enix
hat uns gefragt, ob die Engine eine visuelle Prototyping-Sprache hat, also das heißt
Es gibt auch eine Nische in großen Unternehmen für solche Dinge, wahrscheinlich solche
die Wert auf F&E legen und lange Entwicklungsstadien haben
Vorproduktion/Prototyping/Experimentieren mit neuen Ideen usw. (er erzählte auch
uns, dass unsere Spiele wie Konsolenspiele aussahen und fragten (zweimal) welches Land
sind wir gegangen, um zu lernen, wie man sie macht: p).

Am 14. April 2016 um 03:26 schrieb Sergey Lapin [email protected] :

Das eigentliche an Visual Scripting im Allgemeinen ist ein vergeblicher Versuch
Programmieren für Nicht-Programmierer zugänglich machen, was völlig falsch ist
sich nähern.
Die visuelle Programmierung ist schwieriger als die normale Textprogrammierung. Um es zu schaffen
einfacher müssen Sie viele Blöcke für jeden Fall im Leben auf traditionelle Weise schreiben
Weg und
lass diese Leute sie benutzen. Diese erwiesen sich als weniger effektiv als die Frage nach a
guter Programmierer, um Code zu schreiben. Der Spruch „Programmieren ist kein Beruf,
Jeder kann es" ist falsch. Alle Versuche, ohne zu programmieren
Programmieren ist eine Verschwendung.

Was die Zustandsmaschine betrifft - ich habe darüber nachgedacht, dies einige Zeit zu implementieren
her, aber das wird dem High-Visuals-Programm nicht helfen.
Dies kann für Ihr Spiel einfach mit dem Werkzeugskript und dem Knoteneditor durchgeführt werden.
Dies ist ein leistungsstarkes Tool, das viele Leute für Spieltools verwenden, z
Editoren für Spieldialoge.

Am Donnerstag, den 14. April 2016 um 9:09 Uhr schrieb Aaron M [email protected] :

Ich möchte es nicht sagen müssen, aber das ist eine sehr enge Sicht auf das Visuelle
Scripting-Tools, Sergey. Wie für Spiele, die vollständig mit gemacht wurden
Ihnen,
Einige Engines haben sich vollständig für sie entschieden, wie z. B. Construct, also Sie
wird kein Spiel aus dieser Engine sehen, das mit normalem Skripting erstellt wurde. Andere
(vernünftiger, imo) Engine haben Plugins wie Unity und UE4. Ich, persönlich
Ich mochte es sehr, sowohl uscript als auch PlayMaker in Unity neben meinem regulären zu verwenden
Code, denn während einige Dinge einfacher zu programmieren sind, sind viele einfacher zu programmieren
visuell ausschreiben, insbesondere Zustandsautomaten, weil mit einem visuellen Skript
Skripter wie PM geben Ihnen viel Feedback mit Haltepunkten
einfach
Es ist so viel einfacher, das Projekt aus einer umfassenderen Perspektive zu betrachten.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
< https://github.com/godotengine/godot/issues/1220#issuecomment -209776732

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/godotengine/godot/issues/1220#issuecomment -209779422

Sie reden einfach an mir vorbei, punto slapin, ich meine, ich habe nie etwas von Designern oder Vereinfachung gesagt, sondern von Benutzerfreundlichkeit, selbst für Programmierer, deren Nützlichkeit ich erfahren habe. Es ist nicht so, dass Sie mir einfach sagen können, dass es Zeitverschwendung ist, wenn ich die anekdotische Erfahrung gemacht habe, die genau das Gegenteil zeigt. Ich ziehe es vor, dass die Option _neben_ Scripting verfügbar ist, Sie tun so, als ob ich nur das eine oder andere auswählen könnte und ich gezwungen wäre, es meinem Künstler zu überlassen. Überhaupt nicht der Fall.

Toller Thread, viele Meinungen 😁

Meine ist einfach. Du bist okay!

Jede dieser Ideen wird eine großartige Ergänzung zu gdscript sein 😁

Ich freue mich darauf, sie auszuprobieren, wenn sie erscheinen.

Ich denke, gdscript könnte auch etwas Liebe gebrauchen, um benutzerfreundlicher zu sein.

Einige Knoten sind nicht vollständig dokumentiert. Viele haben keine Beschreibung.
Godot könnte einige Hilfsfunktionen verwenden, um die Entwicklung zu vereinfachen. Gamemaker gml ist ein gutes Beispiel:
https://twitter.com/uheartbeast/status/724326557108461568

Ich denke, das Dokumentationszeug ist hier ein großes PITA, und das war's.
Die Entwicklung selbst ist einfach genug. Die Dokumentation und Tutorials
sind wirklich nötig. Machen Sie also einfach Ihr YouTube-Konto nützlich (oder bloggen Sie, oder
einfach im Forum posten),
das wird viel helfen.

Am Montag, 25. April 2016 um 9:35 Uhr, Todor Imreorov [email protected]
schrieb:

Ich denke, gdscript könnte auch etwas Liebe gebrauchen, um benutzerfreundlicher zu sein.

Einige Knoten sind nicht vollständig dokumentiert. Viele haben keine Beschreibung.
Godot könnte einige Hilfsfunktionen verwenden, um die Entwicklung zu vereinfachen.
Gamemaker gml ist ein gutes Beispiel:
https://twitter.com/uheartbeast/status/724326557108461568

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/godotengine/godot/issues/1220#issuecomment -214163012

Nun, ich habe mehrere Gedanken dazu.
Sie können den Zugang zu einer Engine erleichtern, indem Sie so etwas wie visuelles Skripting einbauen, und das wäre gut für alle Künstler, die mit der Entwicklung von Spielen beginnen wollten, aber keine Programmiererfahrung haben, aber das lädt eine ganze andere Gruppe von Leuten ein - nämlich , Menschen ohne jegliche Fähigkeiten. Menschen, für die der Wechsel zur Programmierung in einem Texteditor niemals auf ihrer Tagesordnung stehen wird, selbst wenn das bedeutet, dass das endgültige Spiel darunter leiden wird. Leute, die denken, dass das einzige, was schwer daran ist, ein Spiel zu machen, die Programmierung ist, und dass mit visuellem Scripting diese Einschränkung plötzlich aufgehoben wird. Das ist auch keine Seltenheit. Schauen Sie sich nur all die populären Engines an, die bestimmte Dinge für Nicht-Programmierer einfacher machen – tonnenweise Schaufelware. Ich sage nicht, dass Sie kein visuelles Skripting einbeziehen sollten, weil es bedeutet, dass wir das Risiko eingehen, Schaufelware zu bekommen, aber dass es so implementiert werden sollte, dass diese Art von Leuten davon abgehalten wird zu glauben, dass sie Godotengine verwenden können, um besagte Schaufelware herzustellen.
Mein anderes Problem ist, dass eines der Dinge, in denen Godotengine gut ist und viele Leute diese Funktion mögen, darin besteht, dass sie sehr gut mit Git funktioniert. Das Problem mit Visual Scripting ist, dass es oft in einem binären Format gespeichert wird und es ein Albtraum ist, es zu verwalten, wenn Sie irgendeine Art von Quellcode-Revision verwenden. Wenn Sie visuelles Skripting implementieren müssen, sollte es textfreundlich gespeichert werden. Und wenn das unmöglich ist, dann auch hart. Ich hätte lieber Projektdateien in Godotengine in einem Format, das mit Git kompatibel ist, als visuelles Skripting zu haben, das mit Git nicht gut funktioniert.
Und nach all der Arbeit zu urteilen, die erforderlich ist, um ein visuelles Skriptsystem zu implementieren, und der Tatsache, dass Sie bestimmte Arten von Spielen in Godotengine ohne visuelles Skripting ohne Verlust von Funktionalität, Effizienz oder Leistung erstellen können, was ist falsch daran, es einfach so zu implementieren ein Plugin? Ich sehe keinen Grund, warum es ein Kernstück des Motors sein muss.

Nur um meine 2 Cent über visuelles Skripting hinzuzufügen und warum ich die Idee nicht mag:

Ich denke, dass die Möglichkeit, Knoten in jeder gdscript-Datei zu verbinden, in Bezug auf die Codeverwaltung und die Kenntnisse weitaus besser ist.

Was passiert zum Beispiel mit visuellem Skripting (oder mit einem Ereignisblatt ähnlich C2), wenn Sie über 1000 Funktionen haben? Es wird es viel schlimmer machen, glaube ich, durch alles zu navigieren. Ich portiere gerade mein HTML-5-Action-RPG-Spiel in Godot (das mehr als 10.000 Codezeilen und weit mehr als 500 Funktionen umfasst). _(Es hat im Grunde jedes einzelne Feature, das Path of Exile hat, außer Animationen und ist Multiplayer)_

Mit Visual Scripting wäre das für mich nicht möglich. Ich denke, wir und die Godot-Entwickler hier sollten uns mehr auf Features / Bug Squishing konzentrieren als auf ein visuelles Code-Event-Sheet. Aber das bin nur ich :)

Bearbeiten: Wie einige andere gesagt haben, vielleicht für kleinere Projekte, denke ich ... aber etwas Großes kann ich einfach nicht als nützlich erachten

Das Ereignisblatt in construct2 unterstützt Funktionen und sie funktionieren genauso wie Godots. Ein einfaches Filter-/Suchfeld löst alle Probleme, die Sie aufgelistet haben.

Aber Godot-Entwickler wollen keinen Event-Sheet-Ansatz machen, auch wenn es beliebt ist. Ich habe den Eindruck, dass es wahrscheinlicher ist, so etwas wie den unwirklichen Ansatz der Blaupause zu erhalten. Auf diese Weise profitieren Programmierer von einem State-Machine-Editor, der ihrem Arsenal hinzugefügt wird

Um visuellen Skriptcode in vonstruct2 zu organisieren, ordnen Sie ihn in Gruppen ein, die reduziert werden können. Das ist etwas, was selbst gdscript nicht kann – Sie können keine Codeblöcke zusammenklappen. In gewisser Weise hat das Ereignisblatt also Vorteile gegenüber dem gdscript-Editor von Godots.

@reduz Ich habe mir Pure Data angesehen und die Art und Weise, wie sie es tun, ist sehr einfach. Sehen Sie sich das an

Wie Sie sehen können, verwandelt die Eingabe von "Bang" das generische Objekt in ein Bang-Objekt.

Was wäre, wenn Visual Scripting einfach eine Erweiterung von GD Script werden könnte? Platzieren Sie einfach einen generischen Knoten und geben Sie zum Beispiel Vector2 ein, und es wird zu einem Vector2-Objekt. Im Wesentlichen ist also jede Klasse/jedes Objekt auch ein Knoten.

Um Funktionen auszuführen, denke ich, dass Sie einen anderen Knoten erhalten können, der kein Objekt, sondern ein Prozessknoten ist, und Sie würden so etwas wie Vector2.dot eingeben, und der Knoten wird zu einem Punktknoten mit 2 Eingängen und 1 Ausgang.

Visual Scripting ist irgendwann geplant

Du hast nicht enttäuscht :) <3

Da es bereits VisualScripting gibt, sollte dieses Problem geschlossen werden?

Ja.

„Ich habe auch positiv gelächelt.
Weil es für mich als Spieler großartig sein wird, wenn es ein Unternehmen gibt, das so groß wie Steam ist und einen Tonnen von Spielekatalogen hat, offen und DRM-frei, die von Tausenden großartiger Spieleentwickler erstellt wurden."
schau dir einfach gog an, das ist ein geschäft, das drm-freie spiele verkauft.

Off-Topic-Antwort auf eine Aussage von 2015, komm schon :)