Godot: Visuelles Skripting im Event Sheet-Stil

Könnte nicht vieles davon abgemildert werden, indem das aktuelle Visual Scripting mit mehr und besseren Funktionen ausgestattet wird?

Viele der Beispiele sind in der Blaupause von UE4 trivial. "Bewege diesen Akteur bei Tastendruck W nach vorne".
Die meisten davon könnten Sie auf sehr ähnliche Weise in Blaupausen bauen und sogar die visuellen Unterschiede (die die einzigen wären) wären minimal.

Wir sollten uns darauf konzentrieren, das Visual Script, das wir haben, nutzbar zu machen und auf intuitive und reibungslose Weise zu arbeiten, IMO. So wie es ist, fühlt sich das Visual Script, das wir bereits haben , ein wenig vergessen an und scheint nicht viel Liebe zu finden. Wie würden zwei Visual Scripting-Systeme diese Situation überhaupt verbessern?

Eine gute Idee für ein Plugin. Aber die offizielle Aufrechterhaltung von zwei visuellen Skriptsystemen wäre mühsam und mit geringem Gewinn.

@mhilbrunner leider nein, Blueprints sind ein ganz anderer Ansatz für visuelles Scripting. Für Sie sind sie trivial, aber ich wage es, das im Clickteam-Forum oder im Konstrukt-Forum zu sagen. Diese Jungs bleiben bei den Engines, die sie verwenden, weil sie diesen Ansatz lieben und glauben Sie mir - viele von ihnen haben Blaupausen in Unity , unreal und anderen Engines ausprobiert - einschließlich Godot. Sie bleiben immer noch bei der construct2 oder clickteam Fusion, weil sie Event Sheets Blueprints vorziehen. Sie fordern immer noch einen Ansatz für das Ereignisblatt im Forum von Unity.
Godots Visual Scripting wurde in ihren Foren erwähnt und die Benutzer dort bevorzugen immer noch Ereignisblätter. Ich persönlich bin auf gdscript umgestiegen und bevorzuge es, gdscript anstelle von Blueprints zu verwenden - weil gdscript in seinen Vorteilen näher an den Ereignisblättern ist als Blueprints.

Es ist, als würde man jemandem, der Bananen mag, sagen, er soll stattdessen Tomaten essen - das ist Geschmackssache :)

@groud Ich dachte eine Weile dasselbe, aber ich bin mir nicht einmal sicher, wo ich anfangen soll - und selbst als Plugin muss jemand das Plugin pflegen.

@reduz schien der Idee auf Facebook wärmer zu sein, aber ich verstehe, dass er mit wichtigeren Dingen alle Hände voll zu

Auf jeden Fall poste ich dies hier zur Dokumentation - um das Ereignisblattsystem zu skizzieren - was es tut und wie es sich von Blaupausen unterscheidet. Wenn jemand Interesse hat, es in Godot oder als Addon zu implementieren, lassen Sie es uns bitte wissen. Ich würde auf jeden Fall die Ärmel hochkrempeln und mithelfen, die Neuigkeiten verbreiten und Feedback von clickteam/construct-Nutzern einholen.

Bisher weiß ich nicht einmal, wie ich seine Schnittstelle mit der GUI-Klasse von Godot richtig implementieren soll. Sie müssen in der Lage sein, Logikblöcke zwischen Zellen derselben Spalte zu ziehen. Blöcke/Reihen auch kopieren/einfügen - Reihen verschachteln und
andere einzigartige Dinge. Ich denke, es ist keine kleine Aufgabe

@blurymind Ja, und danke definitiv für den Hinweis und die Zeit für die detaillierte Beschreibung. Denke immer noch, dass dies als Plugin vielleicht besser wäre.

devs: Was ist der beste Weg, dies mit minimaler Komplexität hinzuzufügen? Vielleicht finde ich etwas Zeit, um zu sehen, wie das aktuelle Visual Scripting funktioniert. Ich frage mich, ob es möglich ist, die Visual Scripting-Benutzeroberfläche meistens einfach zu ersetzen oder GDScript zu generieren oder auf andere Weise dynamisch dies zu tun.

Habe mich aber noch nicht damit befasst, also Hinweise willkommen. :) Bitte keine Null-Zeiger!

@mhilbrunner wir können vielleicht ein weiteres Problem auf dem Tracker mit einer Liste von Dingen öffnen, die das Blueprint-System in Godot benötigt, um intuitiver zu sein. Bitte verlinke es, wenn du es schaffst

Mein Beitrag hier ist ein Vorschlag für einen alternativen Ansatz, nicht für eine Änderung des derzeit implementierten. Veranstaltungsblätter sind sowieso viel zu unterschiedlich

Ich glaube, dass ein solches Ereignisblatt über Nativescript implementiert werden könnte, aber ich sehe keinen Grund, warum es sich auf dieselbe Codebasis wie Visualscripting verlassen muss.

@groud das ist eigentlich ein guter Punkt. Wie viel von der aktuellen Visualscripting-Codebasis kann wiederverwendet werden? Wie spezifisch ist es für die Nodegraph-Schnittstelle?

@blurymind Ja, ich habe dich dazu gebracht, an einer solchen Liste für VS zu arbeiten und wird es tun, aber es wird einige Zeit dauern.

Muss NativeScript untersuchen :)

Wir haben jetzt mehrere Auswahlmöglichkeiten für Skriptsprachen (C++, C#, sogar Python). Warum nicht auch mehr als eine Wahl für Visual Scripting haben :)

Ich denke, dies könnte auch davon abhängen, wie flexibel die API von Godot zum Erstellen von visuellen Skriptschnittstellen ist.
Soll die Visualscripting-Codebase wiederverwendet werden - oder sollte eine komplett alternative mit Nativescript (c++) geschrieben werden?
Kann dies einfach als gdscript-Addon implementiert werden?

Warum nicht auch mehr als eine Wahl für Visual Scripting haben :)

Weil wir bereits zu viele Sprachen als eingebaut unterstützen. Die meisten Anwendungsfälle sind bereits abgedeckt, daher gibt es nicht viele Gründe, eine neue Sprache hinzuzufügen, die gepflegt werden muss. Wir haben eine Sprache für die grundlegende Programmierung (GDscript), zwei für Performances (C# und C/C++) und eine für Künstler/Spieledesigner (visuelle Skripte). Es gibt keinen Grund, eine weitere Sprache als integrierte Sprache hinzuzufügen, nur weil einige Leute nicht damit umgehen können, eine neue Sprache zu lernen.

Ehrlich gesagt denke ich definitiv nicht, dass dies zum Kern hinzugefügt werden sollte. Es wäre besser wie jede andere Sprachbindung über ein Plugin hinzuzufügen. Wir haben bereits genug Arbeit an der Pflege der aktuellen Sprachen.

Und nein, ich glaube nicht, dass wir den Code des Visualscripting wiederverwenden können.

@groud Das ist ein guter Punkt, aber bedenken Sie das Verhältnis von Programmierern zu Künstlern in Gamedev. Einige der großartigsten und schönsten Retro-2D-Spiele wurden mit Fusion 2 von Künstlern entwickelt, die Spiele auf eine intuitive Weise entwickeln wollten, die ihrer Denkweise entspricht. Hier ist ein etwas veraltetes Showreel von Fusion-Spielen:
https://www.youtube.com/watch?v=3Zq1yo0lxOU

Sie haben viele viele erfolgreiche Kickstarter-Projekte und Spiele auf Steam - Spiele auf vielen Plattformen. Dieser Ansatz wird gerne in der visuellen Programmierung verwendet - sogar in professionellen Teams. Ich würde es hier nicht präsentieren, wenn ich nicht Potenzial zur Erweiterung der Userbase sehen würde

Nun, vielleicht, aber wie viele von ihnen sind in der Lage, Ereignisblätter zu verstehen, aber kein VisualScripting? Sie sagen, dass "diese Jungs bei den Engines feststecken, die sie verwenden, weil sie diesen Ansatz lieben und glauben Sie mir - viele von ihnen haben Blaupausen in Unity, unreal und anderen Engines ausprobiert - einschließlich Godot", aber Sie sind es tatsächlich der erste, der das fragt.

Wenn dies eine beliebte Forderung ist, könnten wir sie zum Kern hinzufügen. Aber bis jetzt ist es das nicht.

Für mich decken wir bereits alle Anwendungsfälle ab. Zumindest für eine hochmoderne und professionelle Game-Engine. Und da wir uns nicht an Kinder oder Bastler, sondern an Unternehmen wenden, lohnt es sich nicht, Zeit damit zu verbringen. Fusion 2, Construct oder sogar RPGmaker fokussieren sich auf ein anderes Publikum, auch wenn schöne Spiele mit ihnen gemacht wurden, nur ein kleiner Teil davon sind professionelle Projekte.

@groud diese Statistiken sind schwer zu bekommen. Wie viele verwenden das aktuelle visuelle Skript?

Ich weise auch darauf hin, warum der Event-Sheet-Ansatz Vorteile gegenüber Blueprints hat - wie weniger Klicks, um Dinge zum Laufen zu bringen, klarere Präsentation und besserer Lernübergang zu gdscript.

Die RPG-Maker-Engine ist wirklich ein Level-Editor, wenn Sie mich fragen. Es hat nicht das gleiche Maß an Flexibilität wie Fusion und construct2

Es ist einfacher, jemandem zu erklären, wie ein Ereignisblatt funktioniert, als dasselbe Beispiel in einer Blaupause zu erklären - sie müssen viel weniger Konzepte lernen - sie müssen nicht die Art der Verbindungen zwischen Knoten, Arten von Ein- und Ausgängen lernen - wie man den Durchfluss einstellt.
Stattdessen fließen die Ereignisse von oben nach unten, links ist die Bedingung und rechts ist die Aktion. Sie müssen nichts anschließen.

Macht dies

Sieht so schwer verständlich aus?

Sicher, Godot würde mehr Ereignisblöcke verwenden, um dies zu erreichen, aber es wäre immer noch klarer als ein Knotendiagramm.
Sogar gdscript sieht für mich klarer aus. Unser aktuelles visuelles Skriptsystem sieht auf den ersten Blick kompliziert aus

Ich spreche als jemand, der beide Systeme verwendet hat und sie jetzt vergleicht - beide sind gleich leistungsstark, eines ist eindeutig einfacher zu erlernen und zu erlernen
Probieren Sie es bitte aus. Sie können construct3 hier kostenlos in Ihrem Webbrowser ausprobieren:
https://www.scirra.com/
Wenn Sie einen Sohn oder ein jüngeres Geschwisterkind haben, bitten Sie sie, es auszuprobieren, dann versuchen Sie es mit Godots - sehen Sie, was sie tun können und wie lange es dauert, ohne Anweisungen zu tun - es gibt einen potenziellen Markt für mehr Schulen, um Godot hier zu übernehmen - Visual Scripting zum Erlernen von Programmierkonzepten verbessern und wir werden eine jüngere Bevölkerungsgruppe mit der Engine erreichen

Wie viele verwenden das aktuelle visuelle Skript?

Ich habe keine Ahnung, aber ich glaube im Moment nicht viel. Die meisten Leute scheinen derzeit GDScript zu verwenden, da ich nicht viele Fragen/Inhalte zu VisualScripting auf Facebook oder Youtube sehe. Das Hinzufügen von Ereignisblättern, bevor Sie sicher sind, dass VisualScripting nicht alle Anwendungsfälle beantwortet, wäre eine kühne Wette. Mal sehen, ob VisualScripting ausreicht und wenn die Leute massiv nach einem anderen System fragen, können wir es später hinzufügen.

@groud wäre großartig, wenn wir das visuelle Skript von Godot in einer Schulumgebung testen könnten - mit Kindern, die grundlegende Codierungskonzepte lernen.
Eines der größten Verkaufsargumente von construct2 ist es, Kindern das Programmieren beizubringen, und sie verkaufen seit Jahren eine spezielle Bildungslizenz.

Mein Argument ist, dass visuelles Skript in Godot im Moment für Nicht-Programmierer nicht sehr einladend ist und den Leuten nicht wirklich hilft, das Programmieren zu lernen - weil sein Ansatz rein zustandsmaschinenzentriert ist und grundlegende Programmierkonzepte mit zusätzlichem Nodegraph noch komplizierter werden zentrische Regeln an der Spitze.

Erfahrene Programmierer sind wirklich nicht das beste Publikum, um dies zu verkaufen - denn sie würden das Ereignisblatt als eine Vereinfachung dessen sehen, was wir bereits haben - gdscript und Blaupausen als neues Werkzeug sehen, das von Designern als Zustandsmaschine verwendet werden könnte.

Ich würde gerne versuchen, ein grundlegendes Ereignisblatt-Addon in gdscript zu schreiben, ich bin wirklich nicht erfahren genug, um ein natives Skript-Addon zu erstellen. Wenn das möglich ist und Sie einige Hinweise haben, wo Sie anfangen sollen - ich würde sie gerne hören
Vielleicht macht es jemand in nativescript, wenn genug Interesse besteht

weil sein Ansatz rein zustandsmaschinenzentriert ist

Was ? Ich habe keine Ahnung, warum du das denkst. VisualScripting hat nichts mit Zustandsautomaten zu tun.

Was ist im Moment einfacher zu verwenden - Blueprints oder Gdscript? Was das Ziel von Visual Scripting ist und wer der Zielbenutzer ist

VisualScripting sollte für Künstler/Spieleentwickler einfacher sein als GDscript. Ich muss zugeben, dass es im Moment nicht wirklich so ist, wahrscheinlich könnten ein paar Knoten vereinfacht / ansprechender gemacht werden. Aber ehrlich gesagt liegen Sie falsch, wenn Sie denken, dass Ereignisblätter einfacher zu verstehen sind als VisualScript, für mich sind sie es nicht.

Das einzige, was den Unterschied in den gezeigten Beispielen ausmacht, sind der Text und die Symbole, die die Dinge viel verständlicher machen. Es sind der Text und die Symbole, die die Dinge klarer und einfacher machen, nicht die vertikale Organisation. VisualScripting wäre genauso verständlich, wenn wir solche Icons hinzufügen, eine bessere GUI für die gängigsten Aktionen erstellen und die Funktionen in relevante Kategorien gruppieren würden.

@groud ist auch die Ausführungsreihenfolge und die Verbindungstypen. Es gibt viel mehr Konzepte, auf die Sie im Nodegraph achten müssen als im Ereignisblatt. Auch wenn Sie den Knoten Icons hinzufügen, müssen Sie immer noch erklären, dass die Reihenfolge der Ereignisse durch die weißen Linien bestimmt wird, auch was die anderen Farben bedeuten. Am Ende hast du immer noch eine Spaghetti-Grafik, die schwerer zu lesen ist – deine Augen müssen überall herumreisen, um herauszufinden, was in der Grafik eines anderen vor sich geht

Sie sind nicht die richtige Zielgruppe - Sie sind ein erfahrener C++-Programmierer. Bitte testen Sie dies mit Leuten, die keine Programmierer sind, und Sie werden verstehen, was ich meine.

Komm schon, das ist nicht so schwer zu verstehen, wir zielen wieder nicht auf Kinder ab.
Und was die Code-Organisation betrifft, ist das Problem bei Ereignisblättern das gleiche. Wenn Sie sich nicht die Mühe machen, Knoten zu gruppieren und Ihren Code zu organisieren, erhalten Sie unlesbaren Code, sei es aufgrund von langen Ereignisblättern oder riesigen Knotendiagrammen.

@groud können wir Visualscript-Knoten sogar wie in Blender gruppieren? Ich kann mich nicht erinnern, das gesehen zu haben. Vielleicht sollte @mhilbrunner es seiner Liste hinzufügen
https://github.com/godotengine/godot/issues/12418
Ein weiterer wichtiger Punkt ist, dass die Möglichkeit, über gdscript wiederverwendbare Aktions-/Bedingungslogikblöcke auf höherer Ebene zu erstellen, für ein Ereignisblattsystem oder das Blaupausensystem sehr vorteilhaft wäre. Das Blueprint-System hat es bereits - aber ich sehe keine Plugins dafür.

Nochmals - construct2 ist uns weit voraus. Ihre Community hat viele, viele, einfach zu installierende Plugins erstellt, die benutzerdefinierte Bedingungen und Aktionen hinzufügen - und ihre API zum Registrieren einer Aktion und einer Bedingung ist super einfach
https://www.scirra.com/forum/completed-addons_f153
https://www.scirra.com/manual/19/actions-conditions-and-expressions

Ganz im Sinne von blurymind
Für mich ist es viel einfacher, das Construct- und Fusion-Event-System zu verstehen, das auch eine viel schnellere Entwicklung jedes Spiels bietet als ein System voller Zeilen

lol wie ist das einfacher zu lesen als gdscript

@groud können wir Visualscript-Knoten sogar wie in Blender gruppieren? Ich kann mich nicht erinnern, das gesehen zu haben

Ich weiß nicht. Aber wenn es nicht implementiert ist, denke ich, dass es so sein sollte.

lol wie ist das einfacher zu lesen als gdscript

Dies ist hier nicht der Punkt.

@groud ja das ist es. Warum sollte ein Spieleentwickler Ereignisblätter verwenden, wenn es viel unorganisierter / verwirrender ist als einfacher gdscript-Code? Das ist der ganze Kern dieses Feature-Vorschlags, nicht wahr

@groud ja das ist es. Warum sollte ein Spieleentwickler Ereignisblätter verwenden, wenn diese weitaus unorganisierter sind als einfacher gdscript-Code?

Nein, ist es nicht, VisualScripting (oder Event Sheets) und GDscript richten sich nicht an dieselben Personen. VisualScripting (oder Ereignisblätter) sind für Künstler oder Spiele-/Level-Designer gedacht, während gdscript Programmiererfahrung erfordert.

Ein Vergleich von Event Sheets und GDscript macht keinen Sinn.

Es macht keinen Sinn, Event Sheets und GDscript zu vergleichen.

naja, da unterscheiden wir uns :P weil ich denke, dass es mehr als vernünftig ist, sie zu vergleichen. zumal gdscript alles, was sie tun, auf einer viel einfacheren Ebene macht.

Außerdem bin ich nicht der Meinung, dass "Programmiererfahrung erforderlich ist". Wenn ein Leveldesigner Aktionsblöcke erstellt _bereits in einem Ereignisblatt oder visuellen Skripten_, hat er _bereits die grundlegenden Bausteine_, um gdscript zu verwenden.

Abgesehen davon: JIT-kompiliertes gdscript ist auf der Roadmap und wäre weitaus vorteilhafter als Event Sheets oder visuelle Skriptergänzungen (da die Mehrheit der Godot-Entwickler bereits stark davon profitieren könnte). und die potenziellen Anwendungsfälle von VS/Event Sheets sind derzeit ziemlich gering. Also alles, worum ich bitte, bitte sei vorsichtig mit der Lead-Dev-Zeit, da dein letzter Beitrag bereits darauf hingewiesen hat

@girng an welchem ​​Punkt hast du entschieden, dass ich versuche, anderen wichtigen Funktionen auf der Roadmap die Priorität zu stehlen? In diesem Beitrag werden die Vorteile von Visual Scripting mithilfe einer alternativen Methode zu der derzeitigen untersucht.
Es ist nicht einmal auf der Straßenkarte, aber Sie springen darauf, als ob es hier ist, um Ihr Frühstück zu essen. :P
Eine Idee zu erforschen ist nicht gleichbedeutend mit Zeitaufwand.

Konstrukt oder Clickteam-Fusion haben Sie offensichtlich noch nie angerührt, wenn Sie darüber diskutieren wollen - verwenden Sie zumindest das Ereignisblatt für eine Weile - machen Sie einen Plattformer damit.
Ich habe auf eine Online-Demo von construct3 verlinkt, bei der Sie kein Konto registrieren oder sich anmelden müssen.
https://www.scirra.com/
es ist buchstäblich drei Klicks entfernt

Probieren Sie das Ereignisblatt aus, machen Sie etwas damit. Dann verwenden Sie die Visualscript-Blaupausen, die Godot hat

Gdscript ist einfach - ja, ich stimme zu und liebe es auch. Ein Jit-kompiliertes gdscript wäre toll! Stimmt, es ist auch wichtiger.
Aber um diese Dinge geht es in dieser Diskussion überhaupt nicht

naja, da unterscheiden wir uns :P weil ich denke, dass es mehr als vernünftig ist, sie zu vergleichen. zumal gdscript alles, was sie tun, auf einer viel einfacheren Ebene macht.

Was Sie nicht verstehen, ist, dass es für viele Leute eine geistige Barriere zwischen Codieren und Nicht-Codieren gibt. Ich muss zugeben, dass der Einstieg in VS im Moment etwas schwierig ist, aber in Zukunft sollte es einfacher sein als GDScript, da möglicherweise viel Lernmaterial erstellt wurde und mehrere VS-Verbesserungen vorgenommen werden sollten.

Außerdem bin ich nicht der Meinung, dass "Programmiererfahrung erforderlich ist". Wenn ein Leveldesigner bereits Aktionsblöcke in einem Ereignisblatt erstellt oder visuelle Skripte erstellt, verfügt er bereits über die grundlegenden Bausteine ​​für die Verwendung von gdscript.

Ja, da stimme ich auch als Programmierer voll und ganz zu, aber das ist nicht das, was die Erfahrung zeigt.
Unreal ist das perfekte Beispiel: Viele Leute verwenden Blaupausen mit Unreal, insbesondere im professionellen Bereich, da sie es Nicht-Programmierern ermöglichen, Code einladender zu schreiben. Auch wenn es sich nicht so sehr vom tatsächlichen Code unterscheidet (meiner Meinung nach), macht es die Unterschiede in den Köpfen der Menschen aus. Wenn Profis es verwenden, bedeutet dies, dass es ein echtes Bedürfnis ist und kein Gadget, das wir weglassen sollten, weil wir denken, dass sie dasselbe sind. Daher macht ein Vergleich keinen Sinn, beides sollte vorhanden sein und korrekt funktionieren.

Jedenfalls werde ich diese Diskussion hier beenden. Der Fahrradschuppen über VS oder nicht VS wurde bereits behandelt.

@blurymind ich bewundere deine Energie und du machst gute Punkte. Ich habe schon einmal Event Sheets in Construct ausprobiert und sie waren anfangs cool, aber je fortgeschrittener mein Spiel wurde, wollte ich sofort wieder zum Code zurückkehren. Also ja, ich habe sie in der Vergangenheit ausprobiert.

@groud macht ein gutes Argument dafür, da Marvel Heroes ein AAA-aRPG war und sie Blaupausen mit Unreal verwendeten .

Ich bin nicht anderer Meinung, dass sie ihre Anwendungsfälle haben, ich denke nur, dass es schwierig sein wird, dies anhand der folgenden Kriterien zu rechtfertigen:

• begrenzte Entwickler-Manpower
• bereits viele aktuelle Themen
• Desorganisation / schwer zu lesen (siehe hier )
• Ich glaube, die meisten Godot-Entwickler würden lieber gdscript verwenden
• gdscript verbindet sich schon so gut mit Godot
• wenn es zu core hinzugefügt wird , könnten neue Probleme rund um die Ereignisblätter auftreten, die gdscript-Probleme beeinträchtigen könnten
• nicht fair gegenüber den aktuellen 90% der Godot-Entwickler, die bereits gdscript verwenden (wenn die Entwicklerzeit für Jit-kompiliertes gdscript verwendet werden könnte, das aktive Anwendungsfälle erfüllt)

Als Plugin könnte ich es vollständig unterstützen, aber mein Herz sagt, dass es vielleicht keine gute Idee ist, wenn es offiziell unterstützt wird

@girng danke. Noch einmal - dies ist keine Aufforderung, gdscript oder visuelles Skript zu ersetzen.
Es ist eher eine Beobachtung zu Visual Scripting im Allgemeinen und dass das Visual Scripting von Godot im Moment wirklich nicht benutzerfreundlich für Nicht-Programmierer ist.

Gdscript kann sich wunderbar in jedes visuelle Skriptsystem einfügen - Ereignisblätter oder Blaupausen.
Wie in meinem ersten Post erwähnt, verwendet der Event-Sheet-Ansatz auch Ausdrücke, für die gdscript bereits verwendet werden kann. Über gdscript und das Plugin-System von Godot könnten auch höhere Logikblöcke erstellt werden - es fügt sich wunderbar in ein visuelles Skriptsystem ein.

Tatsächlich kann ein Ereignisblattsystem viel besser mit gdscript verbunden werden als das aktuelle Blaupausensystem, bei dem Ausdrücke mit einer Milliarde Knotengraphen anstelle einer einfachen Textfeldeingabe erstellt werden. Wenn Sie 1+1 tun möchten, verwenden Sie einen Knoten. Wenn Sie eine einfache Variable in einem Ausdruck ansprechen möchten, verwenden Sie einen anderen Knoten. Am Ende steht ein Spaghetti-Durcheinander von einer Milliarde Basisknoten für einen einfachen Ausdruck, der mit viel weniger Aufwand und Ausführlichkeit genauso einfach und viel klarer in ein winziges Textfeld geschrieben werden könnte.

Das aktuelle visuelle Skript, das wir haben, erfordert viel zu viele Klicks, Knoten und Ausführlichkeit, um die einfachsten Dinge zu tun. Das ist ein weiterer Grund, warum gdscript imo einfacher ist - eine Codezeile anstelle von 10 Knoten und 100 Verbindungen.

Das ist im Grunde der andere Vorteil eines Ereignisblattsystems - Sie können Ihre Ausdrücke einfach in Codeblock-Eingabefelder schreiben. Sowohl construct2 als auch fusion verfügen sogar über Autovervollständigungs- und Ausdruckseditoren mit einfachem Zugriff auf alle Methoden, die ein Knoten hat, mit einer Liste aller Knoten, auf die das Blatt im Geltungsbereich Zugriff hat.

Godot könnte ganz einfach gdscript für Ausdrücke verwenden, wenn er dasselbe tut - aber diese Ausdrücke sind in einer einfachen Tabellenkalkulationsstruktur abgelegt.

Stellen Sie sich eine Methode in Godot- als Logikblock vor. Genau wie seine Methode nimmt dieser Block die gleichen Parameter an, aber Sie müssen ihn nicht mit Knoten verbinden. Sie können einfach ein gdscript in das Eingabefeld eingeben.
Knoten in Godot können als Verhalten in construct2 fungieren und ein Ereignisblatt in Godot wäre viel flexibler und leistungsfähiger als das von construct2. Es wird keinen der Nachteile haben, die ihr Motor hat

Der Ansatz von Construct, Objekte zu paaren, ist unter anderem schrecklich, aber das hat nichts mit dem Design des Ereignisblatts zu tun

Das aktuelle visuelle Skript, das wir haben, erfordert viel zu viele Klicks, Knoten und Ausführlichkeit, um die einfachsten Dinge zu tun.

Das ist kein inhärenter Fehler von VS, sondern liegt an seiner derzeit begrenzten Implementierung. Dies sollte behoben werden und nicht als Argument für die Implementierung einer anderen visuellen Skriptmethode daneben verwendet werden. Andernfalls sollte die aktuelle VS verschrottet werden.

Auch die Diskussion von JIT für GDscript ist kein Thema. Der Wert eines Merkmals kann nur gemessen werden durch:

• seine Nützlichkeit im Vergleich zu anderen, ähnlichen Funktionen, die für denselben Anwendungsfall nützlich sein können
• seine Nützlichkeit im Vergleich zu der Komplexität, die es mit sich bringt, die zusätzliche technische Schuld und der Wartungsaufwand für Godot

Ob dies getan werden sollte oder nicht, hat also nichts damit zu tun, ob wir JIT für GDScript implementieren oder nicht. Andernfalls sollten wir 99% aller Funktionsanfragen schließen, bis alle größeren Fehler behoben sind, dh für immer. Diese sind für GDScript noch wichtiger als JIT.

@mhilbrunner JIT für GDScript wird jedoch tatsächlich passieren, es ist bereits auf der offiziellen Roadmap :P. Ich sagte nur, dass dies die Entwicklungszeit verkürzen könnte. und es ist schwer zu rechtfertigen, dass 90% der godot-Entwickler bereits gdscript verwenden (und viele Leute denken, dass es besser ist als Ereignisblätter und haben ihre eigenen Gefühle). sorry wenn ich mich nicht richtig ausgedrückt habe. Ja, ich weiß, dass dies nicht ersetzt wird, aber ich sage mehr über die Entwicklungszeit.

Trotzdem kann ich

Nachdem ich Action Game Maker und das Game Maker-Ereignisblatt zuvor selbst verwendet habe, stimme ich zu, dass es einfacher zu verwenden und zu verstehen ist als VisualScript (Sie lesen von oben nach unten, nicht nach Zeilen), braucht nicht so viel Platz auf dem Bildschirm und kann endlich implementiert werden Zustandsmaschine einfacher (durch Filtern, welche Ereignisse ausgelöst werden können, nachdem ein Ereignis beendet wurde).

Es wäre eine sehr schöne Ergänzung. Ich selbst werde es wahrscheinlich nicht verwenden, da mir GDScript ausreicht, aber ich kann mir vorstellen, es gut zu verwenden, wenn GDScript keine Option ist (was Anfänger und Nicht-Programmierer wahrscheinlich erleben).

Nun, ich bin seit ungefähr einem Jahr Godot-Benutzer. Ich liebe GDScript und seine einfache Syntax.
Aber ich benutze Construct seit mehr als 8 Jahren und kann sagen, dass ich noch nie ein einfacheres Visual Script als Event Sheets gesehen habe Ich verstehe nicht, wie die Leute sagen können, dass Blue Print einfacher ist als Event Sheets. Vielleicht liegt es daran, dass Künstler daran gewöhnt sind, Nodes zum Einrichten von Shadern und Grafiken zu verwenden, und sind an diese Ästhetik gewöhnt. Aber ich wette, wenn man ein Event-Sheet-System in eine Engine wie Unreal einbaut, würden die Leute Blueprints fallen lassen.

Ich arbeite an einer Schule, die Kindern und Jugendlichen Programmierlogik beibringt. Für Kinder verwenden wir Construct 2, weil es ihnen schmerzlich leicht fällt, mit Ereignisblättern etwas zu erstellen. Für Teenager verwenden wir GDScript und haben gute Ergebnisse damit erzielt. Als Godot 3.0 herauskam, haben wir die Idee untersucht, Construct 2 wegzulassen, um Godot VS zu verwenden, aber wir haben die Idee aufgegeben, weil VS im Moment schwieriger als GDScript ist, sehr kompliziert zu verstehen und zu verwenden. Wenn Godot so etwas wie Event Sheet hätte, würden wir unseren Kurs vollständig auf Godot aufbauen, da wir an der Schule Open Source-Lösungen bevorzugen.

Ein weiterer Vorteil, den Event Sheets mit sich bringen würden, würde die Godot-Benutzerbasis erhöhen, da wir in GDC gesehen haben, dass mittlere bis große Studios Godot bevorzugen, aber kleine Studios Unity und andere Lösungen bevorzugen. Ich denke, Benutzer von Construct, Fusion und Game Maker würden anfangen, zu Godot zu migrieren.

Nun, als Lehrer sehe ich einen großen Wert in Event Sheets, weil es sehr einfach zu verstehen ist und wenn die Schüler zu GDscript wechseln, haben sie bereits ein logisches Denken entwickelt und die Struktur der Events Sheets ist eher Code als Blue Prints.

Wie auch immer, ich liebe was Godot macht und liebe GDscript, ich wollte nur meine Erfahrung einbringen, da ich sowohl Event Sheet als auch GDscript zum Unterrichten verwende. Behalte die tolle Arbeit!

Als Godot 3.0 herauskam, haben wir die Idee untersucht, Construct 2 zu entfernen, um Godot VS zu verwenden, aber wir haben die Idee aufgegeben, weil VS im Moment schwieriger als GDScript ist, sehr kompliziert zu verstehen und zu verwenden

Das ist ein ganz interessantes Feedback. :)
Tatsache ist, dass Ereignisblätter in der Construct2-Form viel weniger niedrig sind als VS oder GDscript. Tatsächlich können sie Kindern helfen, in die Spieleprogrammierung einzusteigen, aber das ist nicht Godots Ziel. Meiner Meinung nach sollte ein solches System nicht als eingebautes System ausgeliefert werden, sondern über ein Plugin verfügbar sein. Ich denke, dieser Kommentar von reduz drückt dies auch aus.

@DrZanuff vielen Dank, dass Sie diesen wirklich wichtigen Punkt @NinkuX festgestellt - Veranstaltungsblätter sind großartig für eine Schulumgebung und ein großartiger Übergang zu so etwas wie gdscript. Blaupausen sind leider nicht

Vielleicht kann Godot dies auf die Art und Weise angehen, wie es Spielehersteller tun - ihr visueller Drag-and-Drop-Code wird direkt in gml-Code übersetzt, der sogar in Echtzeit als Vorschau angezeigt werden kann. Auf diese Weise können Nicht-Programmierer gml lernen, während sie das visuelle Skripting-System der Engine verwenden - genau dies ist die Strategie, die Yoyo-Spiele anwendet, um Nicht-Programmierer schrittweise an gml heranzuführen
https://docs2.yoyogames.com/source/_build/3_scripting/1_drag_and_drop_overview/changing_dnd.html

Sowohl bei der Verwendung von gml für Ausdrücke als auch bei der Vorschau dessen, was ihre visuelle Programmierung tut

Sogar als Addon - ich denke immer, dass die Ereignisblattobjekte von Godot am Ende in gdscript übersetzt werden sollten. Das Ereignisblatt kann ein Werkzeug sein, um Nicht-Programmierern die Verwendung von gdscript beizubringen, indem es ihnen eine einfache Schnittstelle bietet, die immer noch die Verwendung von gdscript für Ausdrücke ermöglicht und am Ende trotzdem gdscript generiert und eine Vorschau anzeigt.

Godots API verfügt über eine Methode zum Generieren von gdscript-Dateien und zum Anhängen an Knoten. So kann ein Ereignisblatt entweder beim Ausführen des Spiels in gdscript übersetzt werden oder sogar während der Bearbeitung des Ereignisblatts, wie es der Spielemacher tut.

Die zusätzliche Lernhilfe, die sowohl bei clickteam fusion als auch bei construct2 verwendet wird, ist eine klickbasierte Menüliste mit integrierten Knotenmethoden/Mitgliedern

Wenn der Schüler auf eines der Elemente in der Liste klickt, wird dem Eingabefeld die entsprechende Syntax hinzugefügt. Wenn sie anfangen zu lernen, klicken sie, aber während sie klicken, lernen sie die Syntax und die Methoden und merken sie sich. Anstatt zu klicken, tippen sie später mit Autovervollständigung und ohne es zu merken, haben sie die API gelernt

In diesem Sinne – Godots Implementierung eines Event-Sheet-Systems kann das Hauptziel haben, Nicht-Programmierer in gdscript und grundlegende Programmierkonzepte einzuführen, ohne sie mit jeglicher Syntax zu verzetteln – es wird Godot in mehr Schulen bringen, die Programmieren für Kinder im Teenageralter unterrichten. Im weiteren Verlauf lernen sie gdscript und die API von Godot, anstelle von construct2 oder Game Maker

Ich glaube, ich habe nicht gut erklärt ... :(

Wenn ich Linien sage, beziehe ich mich auf Visual Scripting, auf die Linien, die die Knoten verbinden

Das Konstrukt- und Fusionsereignissystem ist viel intuitiver, einfacher und schneller, um ein Spiel zu erstellen, als das visuelle Scripting von Godot

Es wäre gut, eine Alternative dieser Art zu prüfen

@groud Funktionen auf höherer Ebene in Godots Visual Script Blueprints können auch als Plugins geschrieben werden - aber Blueprints werden immer noch die zusätzliche Designkomplexität haben, die wir erkannt haben.
Es würde viel weniger Arbeit erfordern, höherstufige Funktionen für das aktuelle Blueprint-System zu erstellen und zu warten, als höherstufige Funktionen, Ereignisblattfunktionen UND ein völlig neues Ereignisblatt-Basissystem von Grund auf als Plugin zu schreiben.

Wenn wir eine Low-Level-Implementierung eines Event-Sheet-Systems hätten, wäre es viel einfacher, übergeordnete Aktionen/Bedingungen dafür zu erstellen und zu pflegen.
Ich denke, sogar als Addon - ich würde zuerst das Basis-Event Sheet-Addon mit nur niedrigem Zugriff und einer Schnittstelle erstellen -, das der Architektur von Godot folgt, ohne sie mit neuen Methoden aufzublähen. Dann können separate optionale Addons für höherwertige Dinge in anderen Plugins oben geschrieben werden.

Das Asset-Repository könnte einen speziellen Abschnitt für Add-ons für visuelle Skripte haben

Ich unterrichte Programmieren für Kinder zwischen 7 und 17 Jahren. Derzeit verwenden die jüngeren Schüler das Konstrukt und die älteren verwenden Godot, aber wenn alle meine Schüler das Godot verwenden könnten, wäre ich wirklich dankbar, dass die Kinder das Godot von Beginn ihrer Reise in dieser Welt der Spieleentwickler an verwenden.

Ist nicht nur das Ereignisblattsystem. So funktionieren auch die Plugins/Verhalten/Familien , die UIDs und die Objekteigenschaften.

Zum Beispiel kann ich in C2 in einem Objekt-Sprite die gesamte Spielgrafik haben, einschließlich statischer / Animationen von Dekoration, Spieler, Feinden usw und Verwenden einer Instanzvariablen für das Objekt namens "type=", um zu sagen, ob es sich um einen Feind, Spieler, Objekt, Zerbrechlichkeit usw. handelt, um sein Verhalten in Ereignissen festzulegen. Außerdem haben Sie für jedes Sprite einige grundlegende Zeichenprogramme, Animator-Eigenschaften usw.

In Godot habe ich das Pong-Beispiel in Visual Scripting ausprobiert und als ich sah, dass es ein Sprite für den Spieler und ein anderes Sprite-Objekt für die Kollision verwendet, und ich dachte: WAS!? . Auch C2 hat eine "Rate-Polygon-Form", die mit einem Klick die Kollision Ihres Sprites mit 8 Punkten bewirkt. Danach können Sie mehr Punkte hinzufügen und anpassen, um genauer zu sein, oder einige Plugins oder Tricks verwenden, um Pixelgenauigkeit zu erreichen.

Ich meine, wenn Godot das Event-Sheet-System wie in C2 anwendet, aber nicht der gleichen Philosophie folgt, um alles benutzerfreundlich zu machen, wird es Zeitverschwendung sein, weil es nicht funktioniert. Und nun, all dies in der tatsächlichen Godot-Engine zu tun, kann eine wirklich verrückte Arbeit sein.

Für den Fall, dass sie weitermachen, sollten sie vielleicht die großen Jungs von C2 wie RexRainbow, R0j0hound usw. fragen / einstellen ... . Aber wie gesagt, das bedeutet viel Arbeit und Geld.

@matriax Ich glaube nicht, dass du hier richtig
Godot hat eine viel flexiblere und unkompliziertere Architektur als Construct2.
Wie erwähnt, ist die Objektpaarung unter vielen anderen ein Problem im Konstrukt - wir könnten zum Beispiel eine klarere Ereignisreihenfolge haben als die von Konstrukten. Wir können Ereignisblätter an jeden Knoten anhängen - was eine bessere Organisation als bei construct'2 ermöglicht.
Für Typen/Familien - in Godot haben wir "Gruppen" - die Gruppenimplementierung von Godot ist tatsächlich besser als die von Konstrukt.
Zum Anhängen von Verhalten an Objekte - Sie können einfach untergeordnete Knoten anhängen und sie als Verhalten des übergeordneten Stammknotens verwenden, der das angehängte Ereignisblatt enthält. Das ist tatsächlich besser als wieder Construct.
In Godot müssen Sie einen Kollisionsformknoten zu einem untergeordneten Knoten des Knotens machen, der die Kollision aufweist. Es ist kein Hexenwerk und eigentlich besser, um Kindern das Programmieren beizubringen

Einige der Dinge, die Sie anfordern, sollten als Add-Ons ausgeführt werden und wurden bereits als Add-Ons erstellt (schätzen Sie zum Beispiel die Polygonform)

Die Implementierung eines Event-Sheet-Systems in Godot, das zur aktuellen Godot-Architektur passt, würde zu einem besseren Event-Sheet-System/Lernplattform führen als das von Konstrukten - weil Godot viel mehr Flexibilität bei Codierungsstilen ermöglicht und eine bessere Architektur hat. Das Erweitern dieses Systems mit höherwertigen Funktionen über Plugins würde es so benutzerfreundlich machen wie das von construct2

Godot so benutzerfreundlich wie Construct 2 zu machen, müsste eine gemeinsame Anstrengung imo sein - der beiden Kernentwickler von Godot und seiner Community. Die Community müsste die Funktionen auf höherer Ebene über Ereignisblatt-Addons erstellen. Bitte versuchen Sie jedoch nicht, Godot genau wie construct2 zu machen. Es ist in vielerlei Hinsicht besser.

@blurymind Ich sage nicht, dass ich dieselbe Architektur wie in C2 sinnlos, ich kenne auch nicht alles, was Godot bereits hat, wie die Gruppen, untergeordneten Knoten usw., die Sie gesagt haben.

Was ich meine ist, dass es Zeitverschwendung ist, ein Ereignisblattsystem auf Godot hinzuzufügen, ohne der gleichen Philosophie zu folgen, um alle Arbeiten auf einfache Weise zu erledigen, wie in C2/C3. Wie gesagt, ein Objekt für Sprites/Kollisionen oder alle Gamearts anstelle eines Objekts für jedes Ding.

Vielleicht sollten sie die Community fragen, wie viele Leute das eigentliche Visual Scripting verwenden und wie viele Leute das Ereignisblattsystem bevorzugen, und dann eine Entscheidung treffen.

@matriax Sie müssen Godot lernen, bevor Sie solche Behauptungen

Der Vorschlag hier gilt für ein Ereignisblatt, nicht für eine vollständige Engine-Kopie von construct2.

Da ich beide Engines kenne, glaube ich fest daran, dass ein Ereignisblatt auf Godot-zentrierte Weise erstellt werden kann und Godot zu einem guten, wenn nicht sogar besseren Werkzeug für das Unterrichten jüngerer Kinder über das Programmieren würde.

In diesem Sinne wäre eine Ereignisblattentität gleich einer Skriptdatei - ähnlich wie bei DND in Game Maker, muss nichts an der Engine oder ihrer Funktionsweise geändert werden. Wenn Sie andere Funktionen von construct2 wünschen, können Sie einige Addons erstellen

Auch als Addon-Implementierung sollte ein Ereignisblatt in Godot nichts anderes tun, als nur eine weitere Schnittstelle zum Generieren von gdscript-Dateien zu erstellen imo

@blurymind Und wieder mit dem gleichen, ok, vergessen.

@matriax das Feedback ist eine gute Idee. Da hast du Recht.
Es wäre gut, eine Zielgruppe von Menschen zu befragen – nicht nur irgendjemanden im Internet. Eine Zielgruppe könnten junge Schüler und Lehrer sein – das wäre eigentlich die perfekte Zielgruppe für ein Event-Blatt-System.
Lehrer wüssten sehr gut, womit ihre Schüler zu kämpfen haben, und kennen gleichzeitig Godot und Construct. Schüler und Nicht-Programmierer könnten gutes Feedback geben

Wenn Sie hier einfach nach dem Godot-Tracker fragen, werden Sie hauptsächlich erfahrene Programmierer werden, die bereits gdscript, die API der Engine und sogar c++ kennen und lieben
Sie werden schützend reagieren - wie Sie am Anfang des Posts sehen können - denken, dass das, was Sie vorschlagen, nicht das ist, was sie und die Engine brauchen - natürlich, weil wir bereits wissen, wie man Code in gdscript schreibt und wichtigere Ziele für die Motor als dieser. Es stimmt, dass es wichtigere Ziele gibt.
Wenn Sie Glück haben, haben einige von ihnen mit der Fusion von Construct/Game Maker/Clickteam begonnen, bevor sie zu Godot kamen, und wissen, wo ihr Wert für Leute liegt, die noch keine Programmiersprachen kennen.

Jemand hat darauf hingewiesen, dass 3D-Künstler Blaupausen mögen, weil sie bereits wissen, wie man Shader erstellt. Das ist ein sehr guter Punkt – ein 3D-Künstler ist kein Programmierer – aber immer noch eine technische Person, die die Konzepte eines Node-Graph-Systems gelernt hat.

Um auf den Wert zurückzukommen - wäre es nicht wunderbar, wenn Godot , vielleicht eines Tages in der Zukunft der erste Motor für mehr Kinder wird?
Warum nicht versuchen, Construct in Schulen zu ersetzen :) Scirra-Entwickler haben es im Moment zu einfach. Sehen Sie sich an, wie sie damit prahlen, mit Schulen zusammenzuarbeiten
https://www.construct.net/gb/blogs/construct-official-blog-1/construct-3-a-year-in-review-947?utm_campaign=blog1postemailsub&utm_medium=email&utm_source=947&utm_term=txt4-read-laura_d% 2527s-post&utm_campaign=marketing&utm_source=sendgrid&utm_medium=email

Um die Idee als Addon auszuprobieren, habe ich eine WIP-Proof-of-Concept-Benutzeroberfläche erstellt. Es tut im Moment nichts - es geht nur darum, herauszufinden, wie die Schnittstelle funktionieren und mit der Architektur von Godot in Einklang stehen könnte. Ich bin mir noch nicht sicher, wie Sie Elemente innerhalb der Zellen verschieben und einrücken sollen

Es wäre cool, wenn der Richtextlabel-Knoten in Godot interne Godot-Editor-Symbole verwenden könnte

Ich werde ein weiteres Modell für einen Bedingungs-/Aktionseditor erstellen, wenn ich die Zeit habe :)
Der Aktionen/Bedingungs-Editor wäre das Werkzeug zum Bearbeiten von Zellen/Logikblöcken. Ich denke an etwas, das dem Ansatz von Construct2 mit dem internen Code-Editor von Godot als Ausdruckseditor ähnelt.
Vielleicht könnten später noch ein paar Hilfshilfen hinzugefügt werden - wie die in construct2 oder fusion

Sobald eine Schnittstelle erstellt wurde, besteht der Rest darin, die Daten in der Szene zu speichern / zu speichern und ein sauberes gdscript zu generieren - aber vielleicht fehlt mir etwas

@blurymind Schön, das Konzept hat
Vielleicht sollten die Schaltflächen zum Hinzufügen von Aktionen und Bedingungen ohne die Hintergrundschaltfläche sein, wie in Konstrukt 2

Und ich denke, es wäre schön eine Linie, um die Bedingung von der Aktion zu trennen

Ich mag die Art und Weise, wie sich das entwickelt.

Das ist ein wirklich schönes Modell. Zuerst habe ich nicht ganz verstanden, worauf du hinaus wolltest. Jetzt ist es wirklich klar... eine Art Zwischenschritt zwischen Programmierung und der Art von Visual Scripting, die wir bereits haben?

@DrZanuff Danke für das Feedback
@Zireael07 Danke :)
Ja genau - ein Tool, das uns helfen würde, Construct2 in Schulen, die beide Engines verwenden, um Programmieren zu unterrichten, vollständig durch Godot zu ersetzen.
Darunter befindet sich nur eine visuelle Schnittstelle zum Generieren von gdscript-Dateien - ähnlich wie DnD in Game Maker 2 verwendet wird. Ich fordere keine Änderungen an der hervorragenden Architektur von Godot.
Ereignisblätter können eine visuelle Skriptoption in Godot sein, die für Nicht-Programmierer (Blaupausen sind es nicht) und kleine Kinder, die Programmierkonzepte lernen, benutzerfreundlich ist - um sie in gdscript zu integrieren

Godot verfügt übrigens bereits über viele Elemente, um dies zu ermöglichen, aber es kann nicht genau dasselbe sein wie in Construct2. Auf die Art von Godot wird es in vielerlei Hinsicht besser sein, wenn es passiert. Das Ereignisblatt von Construct2 lässt einige wirklich schlechte Code-Organisationspraktiken zu und weist einige schreckliche Einschränkungen/Macken auf. Wir können tatsächlich ein besseres Ereignisblatt als ihres erstellen, das genauso benutzerfreundlich ist und das Programmieren besser lehrt - ohne Macken.

Aus meiner Sicht besteht ein Großteil der Arbeit darin, die Benutzeroberfläche zum Bearbeiten von Ereignisblättern zu erstellen das erklärt es. Manchmal ist ein Bild mehr wert als Worte. Ein Addon - mehr als ein Bild

Liebe deine Arbeit dazu. Wären Sie bereit, es während der Arbeit in einem Repo zur Verfügung zu stellen (falls Sie dies tun)? Würde gerne mal reinschauen, reinschnuppern und herumspielen.

@mhilbrunner Natürlich kannst du das - und ich werde es wirklich lieben, wenn ihr damit

Ich bin dabei, die GUI als gdscript-Plugin in den Editor von Godot zu integrieren - sie ist noch nicht interaktiv genug :)

Werde es auf github veröffentlichen, wenn die grundlegende GUI interaktiv funktioniert, um die Designideen zu kommunizieren :) Heute habe ich die Ereignisblatt-GUI zum Laden als Registerkarte bekommen - inspiriert vom Sketchfab-Plugin:

Vielleicht sollte das Ereignisblatt von woanders aufgerufen werden?

Werde weitere Update-Screenshots und eventuell einen Link zum Github posten – mein erster Post wurde mit einigen Planungshinweisen und Links zu Online-Demos anderer Event-Sheet-Engines aktualisiert

• Kennen Sie eine einfache Möglichkeit, Godot-Knotensymbole innerhalb des Rich-Text-Label-Knotens über bbcode anzuzeigen?
  In meinem vorherigen Mockup habe ich die [img]-Tags verwendet - aber das ist ein ziemlich schlechter Ansatz, da ich alle Node-Symbole herunterladen muss, die der Godot-Editor verwendet, und sie mit dem Add-On speichert

• Ich habe auch Probleme herauszufinden, wie ich eine neue Ressource vom Typ Ereignisblattskript über die Addon-API registrieren kann

@blurymind sehr gut! Jetzt ist es besser lesbar. Wir müssen uns überlegen, wie die Aktionsliste dem Benutzer angezeigt wird.

Eine Sache, die mir am alten Construct Classic gefallen hat, war die Option, die Werte aus dem Ereignisblatt zu bearbeiten, ohne die Aktion oder die Bedingung zu öffnen, sondern doppelklicken Sie auf den Wert, um ihn zu bearbeiten:

Wenn jemand dies hinzufügen möchte (allein über ein Plugin, Addon, gdnative usw.), dann kein Schaden, kein Foul. Ansonsten stimme ich zu, dass Visual Scripting verbessert werden kann, um dies überflüssig zu machen. GDscript ist einfach, wirklich einfach. Und wahrscheinlich nützlicher, um Kindern beizubringen, als einige geistreiche visuelle Skripte (sogar auf Blaupausen basierend). Godot muss nicht jedes andere System da draußen im Kern emulieren. Lassen Sie die Software ihren Fokus behalten und werden Sie nicht durch diffuse Fokussierung zum „Alleskönner, Meister aller Zeiten“.

@spyres hängt davon ab, ob @reduz und das Godot-Team jüngere Schüler in Schulen
Ich persönlich denke, wir können das Konstrukt in Schulen durch Godot vollständig ersetzen.
Das aktuelle Blaupausensystem wird dafür nicht funktionieren. Es ist komplizierter zu verwenden als gdscript und wie bereits erwähnt - nicht der beste Weg, um jemanden in Programmierparadigmen einzuführen -, da es seine eigenen Regeln hat.
Das Ziel ist nicht, gdscript oder das aktuelle Blueprint-System zu ersetzen, sondern im Gegenteil, Kindern die Möglichkeit zu geben, gdscript zu lernen, indem sie ihnen helfen. Auf diese Weise nutzt Yoyo Games ihr DnD Visual Scripting System, um auch Nicht-Programmierer nach und nach an Gml heranzuführen.
Ich denke, es schadet nicht, ein visuelles Skriptsystem zu haben, das für Nicht-Programmierer zugänglicher ist und besser darauf ausgelegt ist, sie auf gdscript umzustellen. Warum tun Sie?

Ich versuche, es als Add-On zu erstellen, stoße jedoch auf einige Einschränkungen in Bezug auf fehlende Dokumentation oder API. Ich möchte einen neuen Skript-Ressourcentyp registrieren und meinen Ereignisblatt-Editor in die Registerkarte Skripte einfügen - zum Bearbeiten von myscript.es-Dateien.
Weiß jemand wie das geht - oder hat ein Beispiel dafür?
Es ist hässlich, eine eigene Registerkarte zu haben und nicht dem ursprünglichen Design des Editors zu folgen. Ich möchte, dass mein Addon so integriert wird, dass es nahtlos in das Design von Godot passt.

@DrZanuff Godot hat eine Möglichkeit, alle Methoden aufzulisten, die in einem Knoten vorhanden sind, aber ich bin mir noch nicht sicher, wie ich sie noch nach Aktionen oder Bedingungen filtern soll. Vielleicht muss man sich einen godotzentrierteren Weg einfallen lassen, um dies zu tun. Erforsche es immer noch und bin offen für Ideen :)

Auf jeden Fall werden wir möglicherweise nie ein voll funktionsfähiges Addon haben. Dies ist nur, um die Idee zu erkunden, wie dies hier auf Godot-zentrierte Weise erfolgen könnte - zumindest für den Moment

Die Annahme, dass visuelle Skripte nicht stark verbessert werden können (oder werden) oder dass jüngere Kinder sie nicht verwenden können oder aus Konstrukten zu gdscript heranwachsen) scheint wirklich dumm. Zumal Visual Script ziemlich neu ist.

Wenn die Lösung für sehr junge Kinder _(die ich von den Entwicklern nie als primäre Demografie für Godot erwähnt habe)_ so groß ist, lassen Sie sie Konstrukt oder eine andere fokussierte Kinderlösung verwenden und fahren Sie dann mit der tatsächlichen Programmierung über GDscript fort, wenn sie sind bereit.

Wenn Sie es als Add-On erstellen und dieses Add-On unterstützen möchten, dann mobben Sie für Sie. Aber als etwas Duplizierendes, Aufblähen des Kerns und (wahrscheinlich) Verschwenden von begrenzter offizieller Entwicklerzeit mit zukünftigem Support, Integration usw. _ nein danke. _

@spyres bist du selbst entwickler? Oder ein Lehrer? Haben Sie das visuelle Skript von Godot tatsächlich bei einem Ihrer eigenen Projekte verwendet? Wenn ja, wie kann es verbessert werden, um ein besseres Werkzeug zu sein, um Menschen das Programmieren beizubringen?

@blurymind Ich finde deine Idee gut. Außerdem scheinen Sie bereits eine ziemlich solide Vorstellung davon zu haben.

Aber ich denke, "das Ersetzen von Konstrukten in Schulen durch Godot" ist kein triftiger Grund für diese Funktion. Ich kann mich nicht erinnern, dass Godot die Vision hatte, andere Engines wie Unity, Unreal usw. zu ersetzen. Godot versucht nicht, andere Tools zu zerstören. Wenn der Grund darin besteht, die Produktivität zu steigern, stimme ich dem zu.

Ich stimme @spyres auch zu, dass Godot nicht auf das Bildungssegment

Dennoch denke ich, dass dieses Ereignisblatt eine interessante Idee ist.

@blurymind Ich glaube, du vergisst, dass Godot kein Lehrmittel ist, Godot ist eine Spiel-Engine. Wenn Sie so etwas wie construct als externes Modul implementieren möchten, ist das in Ordnung und Ihnen überlassen, aber versuchen Sie bitte nicht, etwas, das für Spieleentwickler gedacht ist, in ein Spielzeug für Kinder zu verwandeln. Warum versuchen, Godot in ein Konstrukt umzuwandeln, wenn Sie in Wirklichkeit Konstrukte wollen? Warum nicht statt Godot verwenden?

@zaniar @ni-code Du hast recht. Es stimmt, dass ich persönlich mehr daran interessiert bin, ein visuelles Skripting-Tool zu entwickeln, das effizienter und klarer ist als unser derzeitiger Blueprint-Ansatz - eines, das einfach mehr Spaß macht. Ich mag Construct2 nicht, also ist es nicht wahr, dass ich Godot dazu machen möchte. Wie ich bereits erwähnt habe, finde ich das Design und die Macken ziemlich schlecht. Deshalb ist es für mich so frustrierend, dass die einzigen Orte, an denen Ereignisblätter zu finden sind, nicht so gut sind wie Godot.

Ich bin ehrlich der Meinung, dass selbst wenn Blaupausen verbessert werden, sie nie so klar und schnell zu erstellen sein werden wie ein Ereignisblatt - in dieser Hinsicht sind Ereignisblätter ein großartiges Werkzeug für das Rapid Prototyping, das oft unterschätzt wird. Aber Titel, die durch Clickteam-Fusion erstellt wurden, sollten für sich selbst sprechen. Manche mögen es als Spielzeug sehen - aber mir macht es einfach Spaß, so eine Spiellogik aufzubauen :)

Als jemand, der sowohl construct2 als auch Fusion verwendet hat, liebe ich den Event-Sheet-Ansatz und sehe in Godots API einen schönen Kandidaten für ein Event-Sheet-System - ohne die Mängel der Engines, die es inspirieren.
Godots Knotenverschachtelungsdesign wird damit sehr gut funktionieren, kombiniert mit der Klarheit von gdscript für Ausdrücke.
Ich erwarte nicht, dass es in Godot implementiert wird, aber ich werde weiterhin den Fortschritt des Plugins hier teilen, in der Hoffnung, nützliches Feedback und Hilfe bei der API zu erhalten. Einige der Entwickler hier haben Construct2 verwendet und kennen Godot sehr gut, daher könnten aus der Diskussion gute Ideen entstehen.

Ich habe tatsächlich eine Idee für das Ereignisblattsystem, das uns einen kleinen Vorteil gegenüber der Verwendung von gdscript verschafft - selbst für erfahrene Benutzer. Es soll mit gdscript verwendet werden, nicht anstelle von gdscript - vergiss das nicht

Ich freue mich auf die unvermeidlichen Visual Scripting-Verbesserungen, die (da sie vollständig integriert/unterstützt sind) nützlicher (und wahrscheinlich beliebter) sein werden als jedes verrückte "construct-lite"-Plugin, das auf Kinder ausgerichtet ist.

@spyres Bitte bleiben Sie „stumm“ oder dass das Potential sind Plugin sie (kostenlos!) Arbeit in investieren ist nur ein „janky Konstrukt-lite Kiddie-centric“ Sache sein würde.

Natürlich steht es den Leuten frei, ihre Zeit (wie ich glaube, nutzlos zu sein) nach Belieben zu verbringen, auch wenn dies dem Kerndesign von Godot nicht förderlich ist.

Im Interesse der Höflichkeit (obwohl " kinderzentriert " unbeholfen beschreiben , nicht auf Godots Kerndemografie konzentriert, etwas, von dem wir

Warum sollte man sich die Mühe machen, Konstrukte in Godot neu zu erstellen, wenn die eigentliche Konstrukt-Engine diese Funktionalität bereits auf robuste Weise bereitstellt?_

Schreit die demografische Gruppe der 7-jährigen Kinder wirklich nach dieser Art von Vervielfältigung?

Wenn @mhilbrunner seinen Beitrag beantwortet, fühlt es sich an, als würde man einem 7-jährigen Troll antworten :D
Er hat die meisten meiner Beiträge hier mit dem Daumen nach unten gedrückt - alle die Daumen nach unten sind tatsächlich seine.
Es scheint keinen Sinn zu machen, mit ihm zu streiten, denn er antwortet nicht wirklich auf Fragen - ich habe ihm ein paar berechtigte Fragen gestellt, die mir helfen könnten, Feedback zu erhalten. Was ich im Gegenzug bekommen habe, ist mehr davon

Hat github eine Möglichkeit, Personen am Posten zu hindern, wenn sie missbräuchlich sind?

Wow, obwohl ich sicherlich einige Ideen in Frage gestellt habe, habe ich _nie_ wirklich jemanden _That_ ist ziemlich beleidigend, würde ich sagen.

Was würde das Duplizieren der Funktionalität des Konstrukts innerhalb von Godot bieten, das nicht bereits von äh... Konstrukt bereitgestellt wird.

Gibt es einen legitimen Vorteil, den Funktionsumfang von Construct (wahrscheinlich in geringerer Weise) in Godot zu duplizieren, nur um 7-Jährige anzusprechen?

Warum würden Sie nicht einfach Konstrukt verwenden? Fehlt ihr Setup (das manche gerne duplizieren wollen) wirklich so?

Gibt es einen berechtigten Grund anzunehmen, dass Kinder nicht mehr zu Gdscript oder Visual Scripting wechseln können, wenn sie dem Konstrukt entwachsen sind?

@spyres Sie verwenden allgemein anstößige Begriffe, um Personen zu beschreiben, die Ereignisblätter und Ereignisblätter verwenden.
Sie sind keine "Kiddies" und das System ist nicht "janky". Habt etwas Respekt vor diesen Gemeinschaften, um Gottes willen. Woher kommt diese elitäre Haltung?

Construct2 hat viele sehr erfahrene Javascript-Programmierer - was für Sie offensichtlich gewesen sein sollte, wenn Sie sich die Mühe gemacht haben, das, was ich schreibe, tatsächlich zu lesen und den von mir bereitgestellten Links zu folgen. Einige der von ihnen erstellten Add-Ons integrieren es in 3D-Engines wie babylon und three.js, obwohl – ja – erfahrene Entwickler genießen es auch, Ereignisblätter zu verwenden und damit Spiele zu erstellen.

Clickteam-Fusion hat die Anzahl der Spiele weit übertroffen, die Godot-Spiele auf Steam, Kickstarter und sogar App-Stores in Bezug auf Anzahl und Umsatz gemacht haben. Dies ist eine vollständig auf Ereignisblättern basierende Engine, die von 10-80-Jährigen verwendet wird. Es ist eine Mischung aus allen Altersgruppen. Einige der Benutzer sind Filmemacher, andere sind Künstler - Leute mit Jobs, die Geld für Lizenzen ausgeben, Exporteure und so weiter. Verdammt, ich habe mit dem Verkauf von Sachen in ihrem Asset Store mehr Geld verdient als mit allem anderen, was bisher mit Godot zu tun hatte.
Hier einige Beispiele - Alonso Martin, Filmemacher, beschließt, ein Spiel zu machen:
https://www.kickstarter.com/projects/alonsomartin/heart-forth-alicia
Ein Haufen von 7 Jahren macht ein Spiel
https://www.kickstarter.com/projects/galaxytrail/freedom-planet-high-speed-platform-game

schau mal hier
http://indiegames.clickteam.com/
Diese Siebenjährigen wissen sicher, wie man Spiele macht und Geld verdient, eh
https://thinkgaming.com/app-sales-data/publisher/3107/scott-cawthon/

Mein Standpunkt, dies als besseres Werkzeug für den Programmierunterricht zu verkaufen, sollte kein Grund sein, es so falsch zu bezeichnen. Mit einer breiteren demografischen Gruppe von Benutzern haben Sie am Ende mehr Leute, die Spiele mit der Engine erstellen. Sollte das nicht offensichtlich sein? Warum ist das nicht offensichtlich :D

Wie oft muss ich wiederholen, dass ich nicht um eine Kopie von Construct2 bitte? Es ist, als ob Sie dieselbe Nachricht wiederholen, ohne tatsächlich etwas zu lesen. Was ich vorschlage, ist ein Godot-zentriertes Ereignisblatt, keine Kopie von dem in construct2

Wie motiviert mich das Lesen Ihrer Posts über das "janky"-System, ein kostenloses Add-On für Godot zu erstellen? Denken Sie ein wenig darüber nach

Whoa! Torpfosten verschieben trotz...

Lassen Sie mich klarstellen.

Construct ist ziemlich erfolgreich in dem, was es tut. Daher entgeht mir die Notwendigkeit (?!), seinen Funktionsumfang (ganz oder teilweise) in eine völlig andere Engine zu übertragen / zu duplizieren (ohne erkennbaren Nutzen).

Die Fragen zu den tatsächlichen Leistungen bleiben dieselben, obwohl manche sie (unerklärlicherweise) als "anstößig" empfinden.

Ist der Vorschlag, dass ein Add-On, das auf eine völlig andere Engine aufgepfropft ist, irgendwie besser ist als die Verwendung von Konstrukt? Ist etwas integriert (sogar per Add-On) etwas, von dem wir erwarten würden, dass viele Leute die robuste Lösung (dh das Konstrukt) vorziehen? Ich bezweifle das.

Aber hey, warum hier aufhören? Es gibt ausgezeichnete Werkzeuge (über das Konstruieren hinaus), um Kindern das Programmieren beizubringen (zB Scratch , Styncl , code.org usw.). Warum nicht auch diese in Godot integrieren!

Oder vielleicht auch nicht... ;-)

Gibt es jemanden, der Godots Visual Scripting verwendet hat und es scheint so gut zu sein, dass er nur Godots Visual Scripting verwendet?

@Zonacas Ich glaube nicht, dass Godots Visual Scripting dafür noch ausgereift genug ist, aber ich kann mich irren. Denken Sie daran, dass VS zu diesem Zeitpunkt erst seit etwa zwei Monaten veröffentlicht wurde. :)

@Zonacas versuche, den VS-Kanal auf dem Discord-Server

Hallo zusammen, ich habe ein Fortschrittsupdate für mein Proof-of-Concept-Addon.

Hier ist ein frisches Gif für dich:

Einige Hintergrundinformationen zu seiner Funktionsweise - Grundsätzlich besteht das Ereignisblatt aus Zellen. Eine Zelle kann entweder für Bedingungen (Getter/Ausdrücke) oder Aktionen (Setter, die mit Gettern/Ausdrücken gefüttert werden können) sein.
Auf der GUI-Seite wird die Ereigniszelle über einen Richtextlabel-Knoten und einen aus gdscript generierten bbcode erstellt. Wenn Sie darauf doppelklicken, verwandelt sich das Richtextlabel in einen Editbox-Knoten, der den eigentlichen gdscript-Ausdruck enthält.

Eine Ereignisblattzelle hat also 2 Modi:

• Bearbeitungsmodus - textEdit-Knoten, der mit gdscript eingegeben werden kann.
  Der einzige Unterschied besteht darin, dass der Benutzer If/else/while nicht eingeben muss - das ist kontextsensitiv für den übergeordneten Container, wie im Screenshot zu sehen. Jede Zeile ist eine neue Bedingung. Wenn der Benutzer die Zeile also nicht mit "oder" oder etwas anderem begonnen hat, weiß der Parser automatisch, dass eine neue Zeile den Vorwand "und" hat

Wenn weg geklickt, wechselt in den Ansichtsmodus.

• Ansichtsmodus - Richtext-Label - Beim Wechsel in den Ansichtsmodus wird ein bbCode aus dem im Bearbeitungsmodus befindlichen gdscript geparst und über ein interaktives Richtext-Label präsentiert. Abgesehen davon, dass er interaktiv und leicht zu ändern ist, besteht das Ziel darin, den gdscript-Code übersichtlicher darzustellen. Dies bedeutet, dass nur der Name und das Symbol des Knotens angezeigt werden (nicht der gesamte Pfad) und einige Wörter entfernt werden, wenn sie offensichtlich sind (wie get_ und set_). Da jeder anklickbare Teil eigentlich ein URL-Tag ist, kann der Benutzer beispielsweise beim Bewegen der Maus über einen Knotennamen einige Informationen erhalten, z. B. den vollständigen Pfad des Knotens.

Über das Menü Neue Bedingung/Aktion hinzufügen:
Dadurch wird eine neue gdscript-Codezeile für eine Bedingung oder Aktion erstellt. Das Tolle daran ist, dass Sie ganz einfach alle Knoten innerhalb einer Szene und ihre Methoden durchsuchen können - es funktioniert in umgekehrter Weise wie die automatische Vervollständigung im Editor von gdscript. Es zeigt alle Knoten und alle ihre Setter, Getter oder beide Methoden. Über einen Filter können Sie dann auf das Gewünschte eingrenzen.
Wenn es von einer Bedingungszelle aufgerufen wird, zeigt dieses Menü nur Getter an, wenn es von einer Aktionszelle aufgerufen wird, zeigt es sowohl Setter- als auch Getter-Methoden an.

Was ist als nächstes zu tun, damit dies funktioniert:

• Ich muss einen Weg finden, um Zellen zu ziehen - um die Reihenfolge der Ereignisse einfach ändern zu können.
• Auch Kopieren und Einfügen im Vorschaumodus.
• Als nächstes muss ich einen Ausdruckseditor erstellen, der angezeigt wird, wenn auf eine bestimmte Art von Vorschaumodus-Zellen-URL geklickt wird
• Finden Sie heraus, wie Sie mit Platzhalterelementen umgehen. Ich dachte darüber nach, Kommentare zu setzen, aber leider unterstützt Godot keine Inline-Kommentare: https://github.com/godotengine/godot/pull/18258, also muss ich möglicherweise zurück zum Zeichenbrett auf diesem

Die Idee entwickelt sich zu etwas mehr als nur einem Lehrmittel. Ich denke, ich kann Leuten, die gdscript bereits kennen und lieben, einige wirklich zeitsparende nützliche Funktionen anbieten, aber es wird noch einige Zeit dauern, dies so weit zu entwickeln, dass ich Ihnen vorstellen kann, wie es geht.

Danke an alle für die Unterstützung

Eine gute Idee für ein Plugin. Aber die offizielle Aufrechterhaltung von zwei visuellen Skriptsystemen wäre mühsam und mit geringem Gewinn.

XKCD:Normen

Ich verstehe nicht, warum dies kein tatsächliches Addon/Plugin sein kann und nicht nur ein Proof of Concept. Nicht alles muss standardmäßig mit der Engine gebündelt werden. Ich meine, wurde GDNative nicht deshalb entwickelt?

@Megalomaniak Das ist wahr und glauben Sie mir, wenn ich sage, dass ich dies als gdnative-Addon umschreiben würde, wenn ich genug Wissen über die API von Godot hätte. Aber selbst so weit zu kommen, hatte ich Mühe und es fehlen mir tatsächlich einige Schlüsselelemente, um dies in ein wirklich brauchbares Werkzeug zu verwandeln. Ich habe die Fragen hier gestellt, aber bisher hat mir niemand wirklich Antworten gegeben oder Beispiele gezeigt:

• Wie registrieren wir einen neuen Skriptressourcentyp im Godot-Editor und ermöglichen dem Benutzer, ihn an einen beliebigen Knoten anzuhängen? Im Moment operiert das Addon aus der Wurzel der Szene und ihrer Hacky.
• Wie schaffen wir es dann, dass Godot meine Eventsheet-GUI öffnet - so integriert wie das aktuelle Blueprint-System
• Wie bewirken wir, dass sich der editText-Knoten wie der gdscript-Editor von Godot verhält? Aktivieren Sie die Syntaxfärbung und die automatische Vervollständigung. Und wie geben wir ihm einen benutzerdefinierten Kontext?

Jemand mit sehr geringen Kenntnissen der API kann dies tun. So etwas steht nicht in der Dokumentation - es gibt auch keine existierenden Beispiele dafür.
Ich habe die Designideen, aber noch nicht das vollständige Bild, um es durchzuziehen

Bisher kann ich die Designkonzepte einfach weiter forcieren und mehr über die API erfahren, kann aber nicht mit Sicherheit garantieren, dass daraus ein Addon werden kann, das tatsächlich voll funktionsfähig ist. Die Leute scheinen es bisher sehr zu mögen

Bei solchen Sachen respektiere ich lieber die Wünsche der Entwickler:

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

Ich habe eine großartige Idee, die Godot besser machen wird.

Ihre Idee wird mit Sicherheit ignoriert.

Lass uns das tun, weil es Godot besser machen wird
Lass uns dies in Godot tun, weil es eine andere Spiel-Engine tut
Lass uns das entfernen, weil ich denke, es ist nicht nötig
Lass uns Unordnung und Blähungen beseitigen und Godot schöner aussehen lassen
Fügen wir einen alternativen Workflow für Leute hinzu, die ihn bevorzugen

@spyres Ich mache dies tatsächlich und suche Unterstützung von anderen Godot-Benutzern in der API für Dinge, die ich in der Dokumentation nicht finden kann - versuche, einen Beitrag zu Godot zu leisten.
Was machst du hier?

Du bist die einzige Person, die alles mit dem Daumen runterdrückt und in jedem Beitrag das Gleiche wiederholt. Das ist sehr ähnlich wie das, was ein Troll tut, würden Sie nicht zustimmen? Sie verfolgen das Gespräch auf der Seite, weg von der Diskussion der Designideen

@blurymind Der "Beitrag" eines Mannes ist die Ablenkung eines anderen Mannes (oder eines Motors). Entschuldigung, dass Ihnen das Konzept unterschiedlicher Meinungen (selbst der der Entwickler, die sie als wichtig genug empfanden, um sie als Teil der offiziellen Dokumente zu posten) so verwerflich erscheint.

Viel Glück mit deinem Add-On. :Grinsen:

@spyres, aber hast du tatsächlich etwas gemacht? Haben Sie schon einmal ein Addon für Godot erstellt? Benutzt du Godot?

Warum bist du hier? Sie versuchen nicht, zur Diskussion beizutragen

@blurymind Wow, unterschiedliche Meinungen stören dich wirklich so sehr? Wie traurig für dich.

@spyres jeder hier kann deine Meinung sehen - du spammst den Thread damit. Jeder einzelne Daumen hier unten gehört dir. Es ist nicht die Meinung - es ist der Spam. Zumindest in Sachen Design und bestimmte Dinge? Ich habe dir vorhin einige Fragen gestellt - du hast nie etwas beantwortet

Um es klar zu sagen, ich unterstütze jeden, der seine Zeit nutzt, aber er möchte so etwas als Add-On erstellen, das von Leuten wie mir, die keinen Wert darin finden, friedlich ignoriert werden kann.

Als alternativer Workflow eigentlich in Godot Core integriert? Äh, bitte, nein. Ich bin mit der Meinung der Entwickler von so etwas.

@spyres ja, das hast du schon gesagt. Scrollen Sie nach oben und lesen Sie es noch 5 Mal. Da ist einer von euch .. aber so oft

@blurymind Und es scheint dich irgendwie zu stören? Wow, alternative Meinungen und so.

Ich nehme an, _you_ haben überhaupt nichts richtig wiederholt? (Wer bist du, warum bist du hier, rechtfertige dich dagnabbit!). :grins:

Ich schätze, diese offiziellen Dokumentationskommentare, die von den Entwicklern geschrieben wurden, haben ein bisschen Verdauungsstörungen verursacht, oder?

ja, es ist super herzerwärmend

@blurymind Danke, dann umarmt es

Ich wünsche Ihnen wirklich viel Glück, dies über gdnative zu implementieren, und an diesem Punkt wird es für diejenigen da sein (sehr wenige, die ich vermute), die so etwas inoffiziell wollen.

Wenn Sie jedoch die Informationen nicht erhalten können, benötigen Sie Unterstützung, um dies zu erreichen. Vielleicht ist es an der Zeit, neu zu bewerten, wie viel Ihnen die Verfügbarkeit dieser alternativen Sprache wirklich bedeutet.

@spyres Bitte hör auf zu

@mhilbrunner Wenn dich meine abweichenden Meinungen so beunruhigen,

@spyres Ich habe in früheren Beiträgen festgestellt, dass dieses Addon darauf abzielt, gdscript zu verwenden und nicht als alternative Sprache zu dienen. Und ja, anscheinend moderiert niemand diesen Tracker

Nun, je früher Sie fertig sind, desto glücklicher werden wir alle sein, richtig? Ich bin mir sicher, dass es für ein paar Leute großartig sein wird, die es tatsächlich wollen, genau wie viele andere Add-Ons. Es ist schwer zu erkennen, dass Ihnen dies zu große Schmerzen bereitet, also passen Sie bitte auf sich auf und lassen Sie sich nicht durch mangelnde Informationen/Fortschritte unterkriegen. Ich bin sicher, dass Sie bald alle Informationen/Hilfen haben werden, die Sie brauchen, wenn die öffentliche Unterstützung überwältigend ist.

Mit den Worten eines weisen Mannes: "Mach dir keine Sorgen, sei glücklich". :grins:

Oder "Es ist alles Spiel und Spaß, bis ihm jemand das Auge ausschießt!" (ähm, warte, ich glaube nicht, dass das das Zitat war, nach dem ich gesucht habe...)

BEEINDRUCKEND. Seien Sie ehrlich, das ist unglaublich!

Als ich deinen Beitrag zum ersten Mal gelesen habe, stimmte ich zu, hatte aber ein wenig Angst, dass es einen großen Streit geben würde, aber als du vorbeikamst und zeigtest, dass du nicht nur bellen und kein Bissen hast und tatsächlich mit der Entwicklung eines Add-Ons begonnen hast, war ich beeindruckt.

Ich LIEBE die Interaktion mit GDScript, da dies ein großes Feature im Gamemaker Studio war (Austauschbarkeit von visuellem und richtigem Scripting), das mit einem Node-basierten System nicht wirklich machbar war.

Sobald das fertig ist, wird es TONNEN von Leuten helfen

Ich bin seit 6 Jahren Construct-Benutzer und kann definitiv sagen, dass dies der beste Weg ist, das schnellste und einfachste Visual Scripting zu erreichen.

Exzellente Idee!

Das wird sehr nützlich sein. Ich kann es kaum erwarten, bis es veröffentlicht wird!

Geniale Idee, kooperiere mit SnailOn.

1. Er ist ein Genie.
2. Er benutzt Godot ungefähr 3 Jahre.
3. Er verwendet Clickteam-Engines seit TGF
4. idealer Kandidat.

@boruok Ich bin seit den Anfangstagen ein Fan von snailons yt-Kanal. 😄 Seine Tutorials haben mir schon vor langer Zeit geholfen, Fusion zu lernen. Hat er einen Github-Account? Ich würde gerne seine Meinung zu einigen Dingen klären.

Übrigens, ich muss zugeben, dass ich eher zu einem Fusion-ähnlichen Klickmenü tendiere als das, was Construct2 verwendet, um zu entscheiden, wie Zellen gefüllt werden. Das in Update 1 vorgestellte Hilfsmenü ist definitiv vom Design von Clickteam beeinflusst. In diesem Addon werden Sie sehen, dass ich keine Kopie einer Engine erstelle, sondern Ideen ausleihe, die für einen godotesken Ansatz eines Ereignisblatts besser funktionieren würden. Es gibt auch ein bisschen Game Maker - in der Art und Weise, wie visuelles Skript nahtlos zu einem tatsächlichen Skript wechseln kann - etwas, das fortgeschrittene Benutzer möglicherweise zu schätzen wissen

Vielen Dank an alle, die die Fortschritte bei diesem Addon verfolgt haben. Die erste Reaktion ist überwiegend positiv
Dies motiviert mich sehr, die Idee weiter voranzutreiben und gleichzeitig zu versuchen, sie einfach und elegant zu halten.

Ohne Inline-Kommentare ist es schwierig, das einfache Umschalten zwischen Gdscript und Visualscript aufrechtzuerhalten, aber ich habe ein paar Ideen, wie man das überwindet und experimentiert - also arbeite ich an diesem atm.
Ich brauche eine Möglichkeit, in gdscript einen leeren Platzhalter zu definieren, wo ein Ausdruck erwartet wird.
Da Ausdrücke einen Werttyp zurückgeben, dachte ich daran, einfach die Wertkonvertierungsmethode in Godot zum Markieren des Platzhalters zu verwenden:
float() ## this will turn into a bbcode item that expects an expression resulting in a float
Aber das könnte etwas hässlich sein, da es viele unnötige Methoden zur Konvertierung von Variablentypen im endgültig generierten gdscript generiert

Wenn Godot Inline-Kommentare machen könnte, könnte ich sie stattdessen mit der Methode analysieren, die BBcode aus dem gdscript erstellt. Dies würde es mir ermöglichen, es mit einigen zusätzlichen Informationen zu füttern

Der beste Ansatz ist wirklich, einfach meine verdammte gdscript-to-BBcode-Parser-Methode intelligenter zu machen - was ich jetzt versuche

@blurymind Ich weiß nicht über git-account. btw, er hat wieder Videos geöffnet. Ich habe ihm ein paar PN über YouTube und Facebook geschickt. Hoffen wir, dass er hier erscheint.

@blurymind Ich unterstütze das zu 100%!
(Entschuldigung im Voraus für die Engländer)

Wenn wir uns die About- Seite genauer ansehen, die

Entwickler interessieren sich zum Beispiel für:

Ihre Erfahrung mit der Software und die Probleme, die Sie haben (uns liegt viel mehr daran als Ideen zur Verbesserung).
Die Funktionen, die Sie gerne implementiert sehen möchten, weil Sie sie für Ihr Projekt benötigen.
Die Konzepte, die zum Erlernen der Software schwer zu verstehen waren.
Die Teile Ihres Workflows, die Sie optimiert sehen möchten.
Teile, in denen Sie klare Tutorials verpasst haben oder die Dokumentation nicht auf dem neuesten Stand war.

Behalte dies im Hinterkopf:

• Das aktuelle Visual Scripting kann nur verwendet werden, wenn Sie wissen, wie man richtig programmiert. Und wird sehr schnell chaotischer als harter Code. Wem hilft das? Und Blaupausen sind auch nicht so hilfreich, es sei denn, Sie haben einen sehr speziellen technischen Hintergrund.

• Ereignisblätter auf höherer Ebene funktionieren gut. Wie der Erfolg aller oben genannten Apps zeigt. Wenn sie gut gemacht sind, sind sie wirklich einfacher zu verstehen und für Nicht-Programmierer zu verwenden.

• Warum sollte Godot Nicht-Programmierer bedienen?
  Ich sehe viele Einsatzmöglichkeiten dafür für viele Leute, die an professionellen Projekten arbeiten.
  In vielen Projekten, klein, mittel und groß, wird ein Teil des Teams die Programmierung übernehmen und ein anderer wird sein eigenes Ding machen. Musik & Sounds, Visuals/Animationen/SFX/UI, Spieldesign, Autoren, etc...
  Manchmal sind es sogar Ein-Mann-Teams oder branchenfremde Leute wie dieser Filmemacher, die ein ziemlich erfolgreiches Spiel machen.
  Manche Leute wollen sogar programmieren, aber aus vielen verschiedenen Gründen nicht programmieren.
  Zum Beispiel machen Probleme wie Legasthenie Code zu einem Albtraum, aber die Programmierung wäre immer noch über einen visuelleren Ansatz wie Ereignisblätter möglich.
  Die meiste Zeit haben diese Leute andere Dinge zu tun, als zu programmieren, während sie Dinge produzieren, die im Spiel benötigt werden.
  Ein Ereignisblatt würde es einem Grafiker, einem Sound- oder Game-Designer ermöglichen, seine Arbeit super einfach zu testen oder zu implementieren, ohne in Rohcode einzutauchen.
  Es würde auch ein superschnelles Prototyping ermöglichen, um den Proof-of-Concept zu testen. Werfen Sie eine Reihe von Archivbildern, klicken Sie hier und da ein wenig und Sie können überprüfen, ob Ihre Idee gerade Spaß macht. Sogar gute Programmierer und große Namen/Studios verwenden die einfachsten Dinge, die möglich sind, um zu Beginn eines Projekts zu iterieren.
  Mehr Feedback und Diskussionen zu all dem hier , und ich stimme dem OP voll und ganz zu.
  (Github ist nicht der beste Ort für Feedback dazu, Leute, die hierher kommen, sind normalerweise tief mit dem Programmieren beschäftigt und können die Notwendigkeit nicht erkennen, obwohl sie tatsächlich eine Minderheit sind.)

• Fazit: Den Leuten einfache, aber effiziente Werkzeuge zur Interaktion mit Godot zur Verfügung zu stellen, wäre auf vielen verschiedenen Ebenen ein Glücksfall für eine große Anzahl ernsthafter Erwachsener, die an professionellen Projekten arbeiten.
  (Nicht nur Kinder und Schulen, auch wenn es ihnen tatsächlich helfen würde.)

• Übrigens gibt es ein weiteres Tool namens GDevelop , das Ereignisblätter verwendet, wenn Sie sich weitere Beispiele ansehen möchten. Die vorherige Benutzeroberfläche (Version 4) ist ziemlich nett, die aktuelle (v 5) ist jedoch etwas schlecht, die App hat einige gute Ideen, aber einige Nachteile, und ihre Richtung ist noch etwas unklar, aber sie kann Ihnen helfen einige Ideen, oder zumindest ein anderer Vergleichspunkt.

Herzlichen Glückwunsch für die bereits geleistete Arbeit, dafür, dass Sie trotz gewisser Reaktionen positiv und motiviert bleiben und an Ihre Idee glauben. Auch ich bestätige, dass es in der Tat von entscheidender Bedeutung wäre und wichtige Probleme für mich beheben würde.

@TheGoklayeh Vielen Dank für die freundlichen Worte der Ermutigung. Ich weiß genau was du meinst. Wie bereits an dieser Stelle erwähnt - erfolgreiche Indie-Clickteam-Fusion hat die Zahl der erfolgreichen Indie-Godot-Spiele weit übertroffen.
Spiele, die veröffentlicht werden, Anzahl der Verkäufe auf Steam und Handy- und Kickstarter-Titeln, die ihr Ziel erfüllen.
Das sollte Beweis genug sein, dass professionelle Künstler und Designer es verwenden - nicht nur "Kiddies"

Was die neue IDE von Gdevelop angeht, finde ich sie großartig, aber nicht vollständig. Ein kluger Schachzug, den der Hauptentwickler gemacht hat, war die Portierung der Ide auf Javascript, was sie für Nicht-C++-Entwickler sehr zugänglich macht, um dazu beizutragen. Ich habe bis jetzt tatsächlich mit kleinen Korrekturen dazu beigetragen - nur um zu spielen und zu lernen. Dieses Wochenende werde ich versuchen, einige Schritte zu unternehmen, um Piskel darin zu integrieren 😃 - wenn alles in Ordnung ist, könnte es sein, dass es einen eingebauten Pixel-Editor gibt.
Der Hauptentwickler hat kürzlich einen Beitrag eines anderen Entwicklers zusammengeführt, der Drachenknochen sofort unterstützt. Wenn Sie möchten, probieren Sie die neueste Version von github aus - nicht die Online-Demo. Es hat die Ware
https://github.com/4ian/GD/releases

Ich mache auch immer noch einen langsamen Fortschritt bei diesem Addon. Einige Dinge müssen überarbeitet werden, bevor ich damit weitermachen kann.

Vielleicht wäre es eine gute Idee, alle Fusion-Benutzer und Construct2-Benutzer zu holen, die hier auch Godot verwenden. Zeigen Sie ihnen diesen Thread und bitten Sie sie um Feedback zum Design.
Snailon hat mich noch nicht kontaktiert - aber ja - er ist ein sehr erfahrener Programmierer, wenn es um Ereignisblätter geht. Ich wusste nicht, dass er auch ein Godot-Benutzer ist.

Das sieht fantastisch aus! Danke für die Entwicklung/das Vorantreiben, Blurymind.
Ich mache Gamedev seit 23 Jahren oder so, habe im Grunde alles ausprobiert - alle gängigen Gamedev-Tools/Engines, Programmiersprachen usw.. Und ich bevorzuge Ereignisblätter am Ende des Tages, weil ich damit Spiele beenden kann. :)
Wenn es in einem von oben nach unten aufgelisteten Ansatz zwischen Bedingungen und Aktionen aufgeteilt ist, ist es geordneter und prägnanter als jedes andere System. Da ich eher visuell orientiert bin, kann ich mit einer starren Struktur, die vertikal/horizontal ist, entspannt durch das Programm/die Ereignisse fließen.
Andere visuelle Skripte, die Spaghetti-Verbindungen erfordern, sind sehr unordentlich und ablenkend – die visuellen Details sind in einer lauten Ästhetik verstreut, die die Konzentration für visuell denkende Menschen stört (die gleichen Leute, für die Visual Scripting gedacht ist).
Ereignisblätter sind die besten für mich. Ich habe 23 Jahre damit verbracht, alles zu benutzen - Blitzbasic, Gamesfactory, Unity, C++, Javascript usw. Und ich bin mir sicher - ich liebe Ereignisblätter!!

Wollte nur einstimmen, die Bearbeitung von Blueprints / Knotenstilen ist extrem schwierig zu organisieren / "Spaghetti-Code" zu vermeiden. Für jeden, der der Meinung ist, dass es das gleiche ist wie Events im Clickteam/Construct/GDevelop-Stil, dann tut es mir leid, aber sie sind radikal anders und die Event-Sheets sind objektiv besser (Spiele sind regelbasiert WENN/DANN in der Natur, und Sie können viel einfacher wechseln von Ereignissen zu Code, aber Ereignisse im Allgemeinen sind sowieso schneller als das Programmieren der Spiellogik).

Ich bin sicher, dass es Momente gibt, in denen die knotenbasierte Bearbeitung praktisch ist, aber die ereignisbasierte Bearbeitung würde schnell die bevorzugte Option werden, wenn sie in das grundlegende Godot Visual Scripting aufgenommen würde.

@bigelod @prominentdetail Vielen Dank, dass Sie mehr Feedback dazu geben, was Ereignisblätter so gut macht - nicht nur für diejenigen, die Programmieren lernen - sondern auch für erfahrenere Programmierer.

ich denke du hast vollkommen recht. Ähnlich wie @prominentdetail habe ich mit Event Sheets in Fusion

Ich bemerke auch Trends in der Event-Sheet-Game-Engine-Community atm, die Godot wirklich nutzen könnte, um seine Benutzerbasis zu erweitern:

• Die Community von Entwicklern, die Ereignisblätter verwenden, sehnt sich nach einer 3D-Engine, die Ereignisblätter verwendet. Beide Clickteam-Fusions-Community versuchten, dies als Add-On (Firefly) und Construct (zahlreiche Plugins wurden ausprobiert) zu integrieren - aber diese Add-Ons boten keine 3D-Szenenbearbeitungsfunktionen - sie waren Hacks, um Ereignisblätter mit 3D-Engines zum Laufen zu bringen - setze auf 2d Engine-Editor nicht für 3D-Spiele entwickelt. Sie können nur eine 3D-Szene mit Ereignislogik erstellen - das macht es mühsam, Objekte zu platzieren, Materialien festzulegen usw.
• Sowohl lernende als auch erfahrene Programmierer mögen Ereignisblätter immer noch und verwenden sie für das Prototyping - nicht nur für den Unterricht.
• Viele Indie-Teams haben erfolgreich Event Sheets verwendet (und verwenden sie immer noch, um erfolgreiche Titel zu erstellen – Kicktarter, Steam und andere Plattformen – aber nur sehr wenige sind 3D-Projekte wegen des ersten Punktes

Dies als Add-On in Godot zum Laufen zu bringen, ist aufgrund einiger Dinge in der Engine, auf die ich nicht sicher bin, wie ich darauf zugreifen kann, schwierig. Die aktuelle Implementierung, die ich habe, ist schnell und unordentlich und tut nichts, außer dass Teile der GUI demonstriert werden können. Ich werde versuchen, es in einen vorzeigbareren Zustand zu bringen und werde es hier posten

Nebenbei bemerkt, ich habe es geschafft, Piskel zu bündeln und in Gdevelop zu integrieren. Das hat mich in den letzten Wochen beschäftigt. Du kannst es ausprobieren, wenn du willst :)
Ich habe mir auch angeschaut, wie Ereignisblätter in gdevelop erstellt werden

@blurymind Ok, sagen wir einfach, ich habe versucht, diesen Beitrag hier zu ignorieren, weil mir die Idee von zwei Visual Scripts nicht gefallen hat.

Aber es hat endlich gereicht, denke ich, dass es endlich an der Zeit ist, eine Diskussion zu beginnen. Ich glaube, Sie müssen die Dokumentation verwendet haben, um die GUI zu erstellen. Mockup ist ziemlich gute Arbeit, ich wollte fragen, ob es ein Repo gibt, in dem ich mir den Code vielleicht ein wenig ansehen kann. Vielleicht können Sie etwas tun, um es dem EventSystem ähnlicher und praktikabler zu machen.

Ich hatte vor, am aktuellen Visual Scripting-System zu arbeiten. Und als ich auf GDevelop stieß und es mir gefiel, kam ich hierher, um zu fragen. Nach einer Stunde Lesen ist die Schlussfolgerung klar, wir müssen einen Mittelweg finden.

Es ist einfach nicht möglich, zwei verschiedene Visual Scripting-Systeme zu unterhalten, eines davon muss sterben. Aber niemand, mich eingeschlossen, möchte sich von der Blueprints-Knotenstruktur trennen.
Aber dieses EventSystem ist zu lecker (zumindest für grundlegende Prototypen), um es nicht zu essen.

Ich wollte, dass VisualScripting eher ein Prototyping-Tool ist. Begrenzte Funktionen spielen keine Rolle, ob sie die Benutzerbasis tatsächlich erhöhen können.
Mehr Nutzer bedeuten auch mehr Spenden, wenn dies vorher noch niemandem aufgefallen ist, dann sollte man darüber nachdenken.

Aber Blueprints ist ein Tool auf Branchenebene, also hat es seine Verwendung und könnte Godot den größeren Fisch bringen, was auch für Godot wichtig ist. Und ich sagte, ich weiß vielleicht auch nicht viel darüber.

Die Frage ist also einfach, was tun? - Beides zu wählen ist einfach keine Möglichkeit.
Aber ein Hybrid könnte Godot populärer machen.
Da Sie mit beiden Visual Scripting-Stilen mindestens mehr Erfahrung haben als ich. (Ich bin eher ein Programmierer als ein Künstler, also kodiere ich mich gerne durch) Warum nicht versuchen, eine Lösung zu finden.

Dies wird wahrscheinlich mehr Leute einbringen, als nur EventSystem allein könnte. Und es ist auch ein guter Schachzug, das Knotensystem am Leben zu erhalten.

Was also, wenn kein Mittelweg erreicht werden kann. Etwas wird einfach absterben. Egal was es ist.

Persönlich könnte ich für Blueprints stimmen, weil ich bereits Erfahrung damit habe und ich möchte, dass der größere Fisch Unreal verglichen wird.
Aber nur zum Vergleich, ich habe GDevelop in weniger als 15 Minuten abgeholt. GDScript unter ein paar Stunden an verschiedenen Tagen und Blueprint ist sicher doppelt so hoch wie GDScript.
Obwohl es auch mein Erfahrungsniveau als Programmierer zeigt.

Ich kann mich einfach nicht entscheiden. Hier sehen.

1. Einheit: 4011
2. Unwirklich: 316
3. Spielmacher: 274
4. Konstrukt: 223
5. Godot: 75
   _Liste von Reduz' Tweet Anzahl der Spiele pro Engine in Global Jam._

Ich will Godot ganz oben haben. Hoffentlich wird etwas VS-Liebe dazu beitragen, dies zu erreichen.
Aber Unreal + Godot + GameMaker + Construct schafft es immer noch nicht. Aber macht es immerhin zur Nummer 2.

Ich bin höllisch verwirrt, was ich für die Zukunft von Godots Visual Scripting planen soll. Denn auf das aktuelle System zu warten oder gedankenlos zu versuchen, etwas zu verbessern, das kaputt ist, wird nicht helfen.

"EventSystem ist bis zu einem gewissen Grad wie Programmieren mit Scratch. Der Blueprint ist zwar völlig einzigartig, aber leistungsfähiger als EventSystem, da EventSystems durch die Tiefe unübersichtlicher und weniger lesbar werden."

Was?? Das genaue Gegenteil ist der Fall, wenn Sie das Ereignissystem von Construct ausprobieren, insbesondere andere Ereignisblätter einbeziehen und Gruppen verwenden.

Das beste Knotensystem ist immer ein Code-Spaghetti im Vergleich zu einem durchschnittlichen EventSystem.

@bigelod Stimmt, so sollte man es nicht sagen. Ich dachte, es ist ähnlich. Ich habe diesen Kommentar über einen Zeitraum von 2 Stunden geschrieben, während ich EventSystems lernte. Tut mir leid, das wird es beheben.

Ja, ich weiß, das Beste sind Blaupausen und es ist einfach großartig, so etwas zu haben, aber ein Ereignissystem fügt mehr anfängerfreundliches Zeug hinzu. Und hilft auch beim Erlernen der Programmierung.

@swarnimarun Vor vielen Jahren habe ich den Godot-Entwicklern die Ereignisblätter auf demselben Tracker vorgestellt. Aber ich habe damals keinen guten Job gemacht und es gab schon mehr Unterstützung für Blaupausen, da viele Godot-Benutzer auch Ex-Unity/Unreal-Benutzer waren. Blueprints haben bereits gewonnen und sind jetzt in Godot.

Jetzt unterstützen viele Benutzer, die eigentlich von Engines wie Clickteam Fusion, Game Maker und Construct kommen, Event Sheets und verwenden Blueprints nicht sehr gerne. Sie werden das Gegenteil von dem sagen, was Sie sagen, und erklären, was bereits erklärt wurde – warum Blaupausen im Vergleich zu einem Ereignisblatt und sogar Skripten verwirrend sind. hab ich auch schon gemacht.

Selbst wenn Sie sich andere Foren zu Visual Programming Engines ansehen, können Sie die negativen Reaktionen auf jede neue Blueprints-System-Engine sehen:
https://rpgmaker.net/forums/topics/23922/?post=857285#post857285

Jetzt sehe ich am Ende des Tages keinen Grund, warum beide Systeme nicht existieren können. Sie können zusammenarbeiten – so wie Blueprints mit gdscript-Knoten zusammenarbeiten können.

Tatsächlich möchten Sie in einer idealen Welt, dass Ereignisblätter erstellt und schnell mit granularer Logik und Blaupausen prototypisiert werden, um sie in Zustandsautomaten zu organisieren.
Wieso den? Denn beide Systeme haben Vor- und Nachteile.

Godots Blaupausen können sehr schnell zu einem Durcheinander werden, wenn Sie beginnen, einen einfachen Ausdruck mit Knoten zu erstellen. Derselbe Ausdruck kann in einem Ereignisblatt oder einem Skript viel klarer sein.

Open-Source-Projekte sind demokratisch – je mehr eine Community eine Idee unterstützt, desto wahrscheinlicher ist es, dass sie Wirklichkeit wird. Aber das bedeutet nicht, dass eine andere Idee getötet werden muss. Beide Ideen werden allgemein gemocht oder nicht gemocht.

Jeder hier muss erkennen, dass sowohl mit Ereignisblättern als auch mit Blaupausen von Grund auf neu programmiert wird. Am wichtigsten ist, wie klar das System ist, das ihnen erlaubt, ihre Logik zu strukturieren. Bei Blaupausen kann die Ausführungsreihenfolge zu einem Durcheinander werden und das Debuggen erschweren. Die Einrichtung erfordert im Vergleich zu einem Ereignisblatt auch viel mehr Klicks und Schritte. Dies ist mein Haupt-Pitch hier – sowohl an Profi-Entwickler als auch an Fans der visuellen Programmierung. Aber vergessen wir auch nicht, dass es eine Frage des persönlichen Geschmacks ist. Ich werde nicht versuchen, Blueprint-Entwickler zu Fans davon zu machen. Ich möchte stattdessen darauf hinweisen, dass viele Entwickler visueller Programmierung keine Blaupausen mögen und Ereignisblätter bevorzugen.

Das Ereignisblatt kann gdscript für seine Ausdrücke verwenden und auf diese Weise tatsächlich denjenigen helfen, die von einer Ereignisblatt-Engine kommen, es sehr schnell zu lernen

Event-Systeme können wahrscheinlich als benutzerdefiniertes Tool zum Erstellen von Knoten verwendet werden.

Ich möchte nur etwas ansprechen - ehrlich gesagt glaube ich nicht, dass Eventsheets nur für Prototypen sind. Ich denke, ein Teil des Problems mit der Denkweise, dass Evensheets nur für das Prototyping sind, liegt darin, dass viele der Tools, die sie verwenden, das Konzept vorantreiben, dass es einfacher ist, Dinge zu erstellen, ohne dass man programmieren kann. Jeder, der die Eventsheets tatsächlich über einen längeren Zeitraum verwendet, weiß, dass es sich um eine echte Programmiermethode handelt, die das Verständnis grundlegender Programmierkonzepte erfordert, und dass Sie damit vollständig vollständige und funktionsreiche Spiele erstellen können.
Ein Teil des Problems besteht darin, dass die Tools, die Eventsheets verwenden, versuchen, die technische Natur herunterzuspielen, um Amateure und Leute anzuziehen, die nicht viel Erfahrung in der Entwicklung von Spielen haben. Dies schadet in der Tat dem Image von Eventsheets und lässt es anderen Leuten, die mehr Erfahrung mit anderen Tools haben, nicht so leistungsfähig erscheinen. Sie haben dann auch viele Leute, die Ereignisblätter verwenden, die sich nicht sicher sind, was sie tun, weil ihnen gesagt wurde, dass sie kein Programmierverständnis benötigen. Die Beispiele, die die Leute damit erstellen, repräsentieren dies also nicht so gut. Das heißt nicht, dass es keine großartigen Beispiele gibt. Es hat nur ein gewisses Vorurteil entwickelt.

..Eine Hybride könnte eine Möglichkeit sein, dieses Vorurteil zu durchbrechen, indem es den Leuten ermöglicht, es auf eine neue Art und Weise zu interpretieren, die vielleicht einen ernsteren Ton hat. Sie hätten vielleicht die Gelegenheit, die Probleme der vorherigen Systeme zu lösen und den Hybrid besser erscheinen zu lassen als die Systeme, von denen er inspiriert wurde.

@prominentdetail wirft einen sehr guten Punkt auf.
Um es hinzuzufügen, sage ich nur Folgendes:
Godot hat die Möglichkeit, die erste richtige 3D-Spiel-Engine zu sein, die Ereignisblätter unterstützt. Dies wird es per Definition im Moment über alle anderen Event-Sheet-Engines heben.
Wie ich bereits erwähnt habe, wurde dies sowohl in der Clickteam-Fusion als auch in Construct versucht - als Plugins, sogar in Game Maker. Und es ist ein klobiges Durcheinander, weil die Editoren dieser Engines keine 3D-Fähigkeiten haben.

Clickteam-Fusion - Firefly-Engine:
http://clickstore.clickteam.com/firefly
https://store.steampowered.com/app/267655/Firefly/
Es wird auf Steam geschwenkt - da es ein schreckliches Buggy-Addon ist

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

Sehen Sie sich nur an, wie mühsam es ist, eine einfache 3D-Szene einzurichten, ohne einen 3D-Szeneneditor zu haben
https://youtu.be/VUGsTdBpRCQ?t=6m17s

IMHO klingt ein Hybrid nach einer großartigen Möglichkeit, die Nachteile von beiden zu nutzen.

Der Ansatz sollte darin bestehen, einen Ereignisblatt-Prototyp zu erstellen, um seinen Wert zu zeigen und Feedback zu erhalten.

Nachdem das System etwa eine Stunde lang getestet wurde, scheint es recht leistungsfähig zu sein. Und das Interessante daran ist, dass es wahrscheinlich genauso viel Programmierkenntnisse wie GDscript braucht, um die meisten Dinge zu erstellen, außer Bewegungen oder die meisten grundlegenden Dinge, für die Hilfsfunktionen hinzugefügt wurden.

Ich glaube, dass Leute, die zu viel Angst haben, Programmieren auszuprobieren, wahrscheinlich die einzigen sind, die es in Gegenwart von GDScript brauchen könnten.

Eventsheet kann leicht ein Werkzeug zum Erlernen der Programmierung sein, insbesondere mit der Godot-API. Da Godot bereits viele der gleichen Hilfsfunktionen hat. Die Implementierung von EventSheet könnte also tatsächlich in der Lage sein, GDScript zu verwenden.
Denn Sie können im Wesentlichen ein System erstellen, das das EventSheet in GDScript konvertiert und in einem separaten versteckten Ordner speichert, der zur Kompilierzeit aktualisiert wird und von der Engine verwendet werden kann. Das habe ich zumindest herausgefunden. Dies könnte die einfachste Lösung sein.

Obwohl ich sehe, dass es einfach nicht den Platz von Visual Scripting / Blueprints einnehmen kann, ist es nicht sehr visuell, hauptsächlich Code in einer Spalte, was das Verständnis erleichtert.

Ich verstehe nicht, warum es so veröffentlicht wird, es sei denn, jemand hat Grundkenntnisse in der Programmierung mit EventSheet, was sich als mühsamer erweisen könnte.

Während ich derzeit auf die Korrektur der Visual Scripting-Seite warte, könnte ich versuchen, etwas damit zu erstellen, wenn ich Zeit finde. Es könnte Spaß machen (wird mir helfen, die Godot-API zu lernen), zu versuchen, eine Basisversion von EventSheet zu implementieren. Wenn ich Fortschritte mache, werde ich hier aktualisieren.

Wie unterscheiden sich Ereignisblätter von gdscript/Skriptsprachen?

Für Neulinge (Dinge, die es einladender machen als das Programmieren):

• Es gibt eine visuelle Darstellung der Logik - mit Symbolen, Farben und so wenig Text wie möglich
• Bedingungen werden in der linken Spalte dargestellt, Aktionen in der rechten - Beim Codieren befinden sich sowohl Bedingungen als auch Aktionen in einer Spalte - was es für einige schwieriger macht, zwischen den beiden zu unterscheiden, wenn sie die Logik einer anderen Person lesen.
• Anstelle einer langen Textkette werden Methoden als einfache Wörter angezeigt - in Englisch und Syntaxzeichen werden nach Möglichkeit entfernt - das Entfernen des Syntaxrauschens macht es viel klarer zu lesen
• Intelisense/Autovervollständigung präsentiert dem Benutzer die gesamte API - damit er alle verfügbaren Setter oder Getter sehen und die gewünschten herausfiltern kann - umgekehrt wie es beim Codieren der IDE funktioniert - wo die Autovervollständigung angezeigt wird, nachdem Sie mit der Eingabe und der gesamten API begonnen haben ist noch in der Motordokumentation versteckt. Es hat auch visuelle Hinweise, um Dinge zu finden (Symbole). Es zeigt direkt den Typ der zurückgegebenen oder erwarteten Variablen an
• Mit der Gruppierungslogik können Sie daraus Ihren eigenen Ordner erstellen, den Sie ein- und ausklappen und verschieben können. Die Möglichkeit, Logikblöcke zu reduzieren, von denen Sie beschlossen haben, dass sie zusammenklappbar sein sollten, ist sehr praktisch, wenn Sie Ihren Code organisieren und Teile davon ausblenden möchten, an denen Sie nicht arbeiten.

Für erfahrenere Benutzer:

• Sie haben die Möglichkeit, die Reihenfolge der Ereignisausführung sehr einfach zu ändern, indem Sie gefüllte Zellen ziehen und ablegen. Was bedeutet das? Beim Codieren einer ide- können wir dies mit Strg+x und Strg+v tun. In einem Ereignisblattsystem können Sie einfach per Drag & Drop eine logische Zeile oder Zellen von einer Zeile in eine andere neu anordnen.
• Bereits etablierte Logik ist optisch klarer zu finden und zu lesen als Code – wiederum aufgrund der visuellen Hinweise und des Layouts der linken und rechten Spalte – zusätzlich zur Farbcodierung. Das ist wirklich großartig, wenn Sie etwas prototypieren
• Das Ereignisblatt kann sich standardmäßig automatisch um Knotenpfade für den Benutzer kümmern. Wenn Sie also ein Ereignisblatt zusammenstellen, müssen Sie nicht auf andere Knoten (übergeordnete oder untergeordnete Knoten) zugreifen, indem Sie deren Pfade relativ zu etwas herausfinden. Sie haben weiterhin die Möglichkeit der Codeflexibilität, aber das System übernimmt dies für Sie, wenn Knoten ihre Eltern-Kind-Beziehungen nicht dynamisch ändern.
  Um zu einem Knoten zu gelangen, müssen Sie ihn lediglich aus dem Hilfsmenü auswählen. Das beschleunigt die Sache
• Es ist immer noch sehr ähnlich wie gdscript - weil alle Ausdrücke in gdscript sind, aber es gibt Ihnen einige zusätzliche Produktivitätsvorteile. Ich denke, wenn es gut gemacht wird, werden gdscript-Benutzer dies lieben - erfahren oder nicht.

Ich denke, wenn ich die Vorteile zusammenfassen muss:
für Neulinge - der Code ist auf den ersten Blick viel klarer, einladender, da ihnen die API der Engine präsentiert wird und die Logik, die sie hinterlegen, visuelle Hinweise (Symbole von Knoten) enthält.

für erfahrenere - Sie können immer noch gdscript in alle Ausdrucksfelder schreiben, aber jetzt können Sie auch einige Teile des Prozesses schneller machen (z Bestellung oder Anforderungen (kein Ausschneiden und Einfügen erforderlich)

Ich wurde irgendwie von Javascript abgelenkt und würde es lieben, wenn andere das ausprobieren :) Aber ich werde darauf zurückkommen

Ich stimme @mhilbrunner zu, dass es ein eigenes System sein sollte, aber es wäre großartig, wenn es möglich wäre, es mit dem Blueprints-System zu kombinieren - so wie Sie gdscript mit Blueprints in einem Projekt kombinieren können

@blurymind
Sie sagten, Sie arbeiten an einem solchen Plugin?
Wie heißt das Repo? ist es schon auf deinem github?

Ich kann bestätigen, dass eventshee leichter zu verstehen ist, ich habe es gelernt, als ich ungefähr 10 bis 11 Jahre alt war und ein schlechtes Englisch hatte (ich bin kein Muttersprachler), während ich viel mehr Zeit und Englischkenntnisse brauchte, um zu lernen, wie es geht Code.

Manchmal kann es schneller sein, als Code zu schreiben, wenn Sie sich daran gewöhnt haben, können Sie so schnell klicken, wie Sie denken.

Der einzige Nachteil, den ich sehe, ist, dass Sie faul werden, wenn Sie traditionellen Code lernen müssen.

Ich habe angefangen daran zu arbeiten, aber dein Code scheint fortgeschrittener zu sein als meiner, ich fürchte, ich kann nicht hilfreich sein, aber ich würde es trotzdem gerne versuchen

@Elmapul Ich glaube nicht, dass sein Repo viel helfen wird.
Und das Programmieren ist in Wirklichkeit viel schneller, wenn Sie so denken, bedeutet dies, dass Sie kein wirklich guter Programmierer sind, der mit Sprachen wie Python gearbeitet hat.
Obwohl EventSheet für Anfänger hilfreicher und nachsichtiger ist, ist das so.

Ich dachte nur, ich würde etwas erwähnen - da ich mich im Laufe der Jahre mit verschiedenen Tools beschäftigt habe.
Ich bin in erster Linie Künstler, also verbringe ich die meiste Zeit damit, Kunst zu schaffen. Dafür setze ich meine meiste Zeit ein, und dafür wurde mein Geist gestärkt. Es gab viele Fälle, in denen ich längere Pausen vom Programmieren einlege, während ich andere künstlerische Dinge mache, wie z. B. freiberuflich usw.
Als Künstler ist es schwierig, bei einem bestimmten Gamedev-Tool auf dem Laufenden zu bleiben, das spezifische Syntaxmuster erfordert – Muster, die Sie konsequent ausführen müssen, um den Überblick zu behalten.
Als Künstler wird also erwartet, dass Künstler höchstwahrscheinlich nicht dieselbe Konsistenz und Priorität wie der auf Syntax basierende Codierungsstil haben.
Eventsheets sind eine Möglichkeit, diesen Buckel zu umgehen, wenn Sie sich vom Programmieren beurlauben lassen (denn als Künstler wird erwartet, dass Sie nicht ununterbrochen Zeit mit dem Programmieren verbringen). erfordert weniger Speicher für die Syntaxstruktur und die Muster, mit denen Sie beim Codieren vertraut sind.
Aus diesem Grund bevorzuge ich Eventsheeting, weil ich produktiver sein kann, anstatt ständig neu lernen zu müssen.

.. Im Grunde möchte ich also betonen, dass Ja-Codieren schneller ist, wenn Sie Ihre ganze Zeit diesem Beruf widmen und die geistigen Fähigkeiten aufbauen, die diese Denkweise begünstigen. Sie tippen es einfach ein und gehen - sie werden nie wirklich von diesem Lebensstil / Verhalten abgewendet. Für andere wird dies nie eine realistische Entscheidung sein, weil sie ihr Leben anderen Berufszweigen gewidmet haben, die ein anderes Verhaltensmuster und eine andere Praxis gestärkt haben.
Also ja.. du kannst einfach so sein wie.. oh wie auch immer - es ist scheiße, du zu sein.. schade, dass du deine Zeit nicht dem Vollzeit-Programmierer usw. widmst, was viele Leute entfremden würde, die nie voll sein werden- Zeitprogrammierer oder als technisch versierte. Und das ist sicher das Recht des Entwicklers.
Aber wenn Sie andere Arten von Personen einladen und mehr Leute dazu bringen möchten, das Tool unabhängig von ihrem technischen Potenzial tatsächlich zu nutzen, dann hilft es, offener für Dinge zu sein und zu versuchen, denen zu helfen, die nicht in der Lage sind, Ihrem bevorzugten System/Workflow zu entsprechen , etc..
Ich antworte nur, weil ich das Gefühl habe, dass Eventsheeting sehr dabei hilft, Fortschritte bei der Entwicklung von Spielen zu erzielen, ohne die Drop-out-Effekte, die auftreten, wenn eine Person weggeht und zurückkommt usw. Es gibt weniger, das eine Person wie mich daran hindert, aufzugeben , und kehre einfach zu seiner/ihrer normalen Arbeit zurück. Am Ende schaffe ich also tatsächlich mehr, auch wenn es etwas länger dauert oder technisch etwas weniger beeindruckend ist.

@prominentdetail Für alle Absichten und Zwecke kann Visual Scripting genau das tun, sodass Sie sich keine Sorgen machen müssen, sobald die Implementierung vollständiger ist, wird es die meisten künstlerischen Probleme beim Erinnern der Syntax lösen.

Ich habe Blueprints verwendet, nachdem ich das Codieren für eine ganze Träne verlassen hatte, und es fühlte sich innerhalb weniger Minuten immer noch natürlich und richtig an. Daher denke ich, dass die meisten Leute damit zurechtkommen.

Es spielt keine Rolle, welche Sprache Sie beherrschen, die visuelle Skripterstellung mit richtig gruppierten Ereignis- und Aktionsoptionen ist schneller als die erforderliche Zeit, es sei denn, Sie geben sehr kurze Variablennamen und Datentypen ein.

Das heißt, wenn die Ereignisse auf Tastenkombinationen abgebildet würden, wäre es tatsächlich schneller, wieder zu "tippen", aber dennoch sind es die Ereignisse/Aktionen, die von Grund auf schneller sind als Standardcode (da Aktionen und Bedingungen oft eine ganze komplexe Funktion darstellen) , vorgefertigt und flexibel für die meisten Anwendungen).

Mein Argument bleibt, dass das Ereignisblatt sowohl leichter zu erlernen ist als
Blaupausen und schneller einzurichten.

Außerdem ist es besser beim Übergang
neue Leute zu aktuellen Skriptsprachen.

Ein Event-Blatt-System kann, wenn es gut gestaltet ist, genauso schnell sein wie das Schreiben
gdscript. Wenn Sie sich mein Mockup-Gif ansehen, ist es ziemlich ähnlich, als würde man einfach tippen
Code mit automatischer Vervollständigung bei Verwendung der Hilfsmenüfilterung.

Wie auch immer, ich finde immer noch heraus, wie das geht und Gott sei Dank Godot
gdscript wird getippte Skripte bekommen, was besser geeignet ist
zum Generieren von BBCode für mein Ereignisblatt.
Zum Beispiel eine der Feinheiten
eines Ausdrucksfeldes in einem Ereignisblattsystem besteht darin, dass es Ihnen eine
klare Anzeige der erwarteten Variablenart und leuchtet sogar in
grün, wenn gültig (siehe Clickteam-Fusion).
Ich versuche derzeit herauszufinden, wie man ein Ausdrucksfeld erstellt, das dies kann
Nehmen Sie gdscript, aber verwenden Sie auch das Hilfsmenü, das ich erstellt habe. Auch dies ist nur das Experimentieren, wie es funktionieren könnte. Das ist alles andere als brauchbar..

Am Mittwoch, den 30. Mai 2018, 22:59 Uhr schrieb Daven Bigelow, [email protected] :

Es spielt keine Rolle, welche Sprache Sie beherrschen, Visual Scripting mit richtig
gruppierte Ereignis- und Aktionsoptionen sind schneller als die Zeit, die es braucht
es sei denn, Sie geben sehr kurze Variablennamen und Datentypen ein.

Das heißt, wenn die Ereignisse Tastenkombinationen zugeordnet würden, wäre dies der Fall
in der Tat wieder schneller zu "tippen", aber trotzdem sind es die Ereignisse/Aktionen, die
sind von Grund auf schneller als Standardcode (wie Aktionen und Bedingungen oft
stellen eine ganze komplexe Funktion dar, vorgefertigt und flexibel für die meisten Anwendungen).

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/godotengine/godot/issues/17795#issuecomment-393333602 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AGMbVT30aPs63RYwxtFqDTHWVqclenRBks5t3xZTgaJpZM4S8wyr
.

@blurymind Ich habe empfohlen, dies mit C++ zu tun, es ist mit dieser Methode sowohl besser geeignet als auch vollständiger. Sogar ich, der vor ein paar Wochen mit C++ angefangen habe, kann es jetzt verwenden, Fehlerkorrekturen und neue Funktionen erstellen. Es ist also nicht so schwer, wahrscheinlich ein bisschen. Ich muss jedoch immer noch Stackoverflow verwenden.

Aber wenn Sie bleiben und GDScript verwenden und nur einen Prototyp erstellen möchten, den andere in ein vollständiges Tool umwandeln können, sollten Sie das Repository meiner Meinung nach hier teilen, egal wie unvollständig es ist.
Ich helfe gerne. Ich mag die Idee von EventSystem sehr. Und VisualScripting ist derzeit kaputt, also nicht viel für mich zu tun.

Das Problem ist, dass ein Ereignissystem mühsam zu implementieren sein kann, in Godot implementieren Sie es wahrscheinlich als Skriptsprache. Aber das ist nicht die Absicht, sondern der Event-Manager, also sollte er global sein oder in der Lage sein, die gesamte Szene allein zu handhaben und dann Gruppen zu verwenden, um die Arbeit in Abschnitte zu unterteilen.
All dies ist möglich und sollte auch kein Problem darstellen.

@swarnimarun Gibt es ein Hallo-Welt-Modul, das eine neue
Können Sie gute Tutorials für den Einstieg empfehlen, die Ihnen geholfen haben?

Auf jeden Fall denke ich jetzt daran, die gdscript-Syntax zu ändern, die das Helper-Menü in typisiertes gdscript generieren würde:
https://github.com/godotengine/godot/pull/19264
Dann wird das in BBCode konvertiert, der die interaktive Ereignisblatt-Zellschnittstelle rendert

Ich habe dieses Flussdiagramm erstellt, um zu erklären, wie es im Moment funktioniert
https://www.draw.io/#Hblurymind %2FGodot-eventSheetPrototype%2Fmaster%2FEventSheetDiagramPlan.xml

@blurymind Ich empfehle, nicht für Tutorials zu
Mir hat keiner wirklich geholfen. Ich brauchte auch nicht viel Hilfe. Ich bin ziemlich gut darin, Sachen aufzusammeln, also hat alles gut geklappt. Trotzdem bin ich erst am Anfang, das ist verglichen mit den erfahrenen Entwicklern.

Und ich glaube, Sie verwenden GDScript für die gesamte Programmierung oder verwenden C++.
Denn es gibt keine Module, mit denen Sie standardmäßig oder beim Start etwas tun können. Man muss aus dem lernen, was schon da ist. Und erstellen Sie Ihre eigenen.

Die Konvertierung in typisiertes GDScript sollte einfach sein, wenn Sie GDScript verwenden und wenn Sie C++ verwenden, ist eine kleine Portierung erforderlich. Und soweit ich weiß, sollte die PR jetzt jederzeit zusammengelegt werden. Es wurde überprüft und scheint in Ordnung zu sein. Habe es noch nicht probiert, bin aber total begeistert.

Und lassen Sie mich raten, derzeit verwenden Sie GDScript mit get_method_list() und get_property_list() wahrscheinlich. Aber ich würde Ihnen empfehlen, auch Signale und Gruppen zu verwenden, Signale sind der Godot-Ereignisauslösemechanismus. Ich kenne das EventSystem nicht wirklich, aber wenn Sie so etwas in Godot erstellen möchten. Stellen Sie sicher, dass Sie Godot in vollem Umfang nutzen.

Und zu guter Letzt, wenn du Hilfe brauchst, schreib mir einfach auf Twitter oder Discord. Ich werde jetzt ein paar Tage frei sein.

@swarnimarun Ich verwende gdscript, um das Addon zu schreiben, es werden bereits Signale verwendet, um beispielsweise Ereignisse auszulösen.
Ja, ich verwende get_method_list() und get_property_list(), um auch das Hilfsmenü zu rendern

Haben Sie bei Twitter und Zwietracht das gleiche Handling?

Im Moment ist mein Plan, die GUI in gdscript als Prototyp zu erstellen, da ich mehr weiß als c++.
Ich habe auch etwas Erfahrung in Javascrit, aber das wird hier nicht viel helfen

Das eingegebene gdscript wird von den Hilfsmenüs für den Ausdrucksmodus generiert - es ist einfach besser für die Konvertierung in BBCode, um die Benutzeroberfläche mit einem Rich-Text-Label zu rendern

@blurymind Das ist dann sehr gut. Das habe ich in den Gifs oben nicht gesehen. Also habe ich einiges angenommen.

Was meinen Griff angeht, ist der auf Discord Swarnim. Und ich glaube, Sie kennen meinen Twitter-Code bereits.

@blurymind - Ausgezeichnete Arbeit. Ich habe buchstäblich gerade angefangen, C++ zu lernen, wegen der Leistungsverbesserung in Godot im Vergleich zu GDScript (3 bis 4 mal schneller, abhängig von Ihrer Metrik - siehe bunnymark ). Wenn es überhaupt möglich ist, würde ich empfehlen, direkt nach Gold zu greifen und dafür C++ zu verwenden, auch wenn dies ein Learning-on-the-Job bedeutet - es wird sich lohnen. Geben Sie mir ein paar Wochen Zeit, um ein Gefühl für C++ zu bekommen, und ich helfe Ihnen auch gerne, wenn Sie möchten.

@colludium Die 3- bis 4-mal höhere Geschwindigkeit ist den Aufwand für das Erlernen von C++ nicht wert. Wenn Sie lernen möchten, optimierte Spiele zu erstellen, lernen Sie stattdessen C# (wird schneller, wenn es in Godot reift). Und jetzt, da typisiertes GDScript auf den Markt kommt, wird GDScript viel schneller als zuvor. In der Nähe von C# ist zu glauben.

C++ ist eine Qual. Vertrau mir. Pointer und Refs und das Kompilieren von Code sind nichts als Schmerzen. Es sei denn, Sie wollen eine Zukunft als Spieleentwickler für ein großes Unternehmen aufbauen oder studieren gerade oder sind so schlau, dass Sie GDScript vollständig kennen oder als Programmierer auf Profi-Niveau sind.

Wenn Sie immer noch lernen möchten, dynamisch GDScript-Code zu erstellen, während Sie gerade dabei sind, denn wie wir wissen, ist das Erstellen eines Exportsystems für eine Sprache mühsam, so dass das direkte Generieren von GDScript-Code die ganze Sache viel einfacher macht.
Und als zusätzlichen Bonus können Sie eine Ansicht für Ansichtscode erstellen und Neulingen helfen, das Codieren schneller zu lernen.

@blurymind Wollte fragen, welche Version von EventSystem Sie als Basis verwenden, weil ich einen Prototyp des Systems als C++-Modul erstellen wollte, damit ich es zumindest auf der Basisebene mit Ihrem synchron haben möchte.

@swarnimarun - danke für den Rat

@colludium Sagen wir, was immer Sie einfacher finden, wenn Sie Ihren Hintergrund als Javascript ansehen, empfehle ich GDScript, da es auch dynamisches Tippen hat und mit dem eingehenden statischen Tippen der perfekte Begleiter sein sollte.
Und lassen Sie mich Ihnen sagen, wenn Sie jemals denken, dass C++ eine Sprache ist, die Sie lernen sollten, schauen Sie sich einfach die Rust vs C++-Seite eines Forums an.

@swarnimarun Ich verwende Godot 3.0.2
Hier ist das Test-Repository, zu dem ich das Projekt hinzugefügt habe
https://github.com/blurymind/Godot-eventSheetPrototype
Es steht jedem frei zu forken oder Pull Requests zu machen 👍

Bitte zögern Sie nicht, ein c++-Modul zu schreiben. Was ich bisher funktionsfähig habe, ist nur der Kernbaustein der Schnittstelle - der Logikzellencontainer.

Der BBcode-Parser (er verwendet nur reguläre Ausdrücke) und das Rendern von Hilfsmenüs sind die Dinge, die für Sie am nützlichsten sein könnten, obwohl ich persönlich darüber nachdenke, ihre Funktionsweise zu ändern - sie wurden in meiner Freizeit zwischen der Arbeit und anderen Projekten zusammengeschlagen . Die Sache ist in Bezug auf den ATM-Code ein Durcheinander, daher wäre es für mich eine große Hilfe, erfahrenere Programmierer zu haben.

Der Rest ist nur eine statische Schnittstelle, die für Screenshot-Zwecke eingerichtet wurde

Eine sehr wichtige Sache ist, eine Art bearbeitbares Wörterbuch zu erstellen, das alle Knoten in der Szene und ihre Pfade verfolgt. Anstelle von statischen Knotenpfaden sollte das Hilfsmenü gdscript generieren, das Pfade aus einem Wörterbuch verwendet, das aktualisiert sie automatisch und wenn ein Knoten vom Benutzer gelöscht und von der Logik des Ereignisblatts nicht gefunden wird, kann er erneut verknüpft werden

Teilen Sie auf jeden Fall mit, wenn Sie etwas haben - auch wenn es einfach ist. Ich werde versuchen, etwas mehr C++ zu lernen und mit Ihnen als Modul zu schreiben :)

@blurymind Endlich! jemand, der sehr klar verstanden hat, dass die visuelle Skripterstellung von Godot Engine 3.x nutzlos ist (zu komplex für Anfänger, nutzlos für Experten).

Das GDevelop-Ereignissystem ist großartig! Es ist besonders nützlich, um komplette 2D-Spielvorlagen zu erstellen und später erweiterte Funktionen über GDScript hinzuzufügen. Dies wird Godot Game Engine viel einladender, beliebter und weit verbreiteter machen!

Ich liebe Godot Engine aufrichtig, aber 2D-Spiele für mobile Geräte zu erstellen, ist nicht die einfachste und unmittelbarste Lösung. Es könnte mit einem vereinfachten System / Ereignissystem viel mehr bieten). Godot hat einen ausgezeichneten Animationseditor, er ist wirklich nett und funktional, er braucht nur ein benutzerfreundlicheres System, wenn ich einen 2D-Plattformer erstellen möchte, ohne Tausende von Codezeilen schreiben zu müssen (was ich nutzlos finde, um ein einfaches Super- Stilvorlage mario bros für NES).

Ich finde , dass die Idee von @blurymind ist fantastisch! die Godot-Community ist enorm gewachsen und ich bin damit zufrieden. Ich habe keinen Zweifel, dass das Ereignissystem mit den nächsten Releases implementiert wird. Visual Scripting (ich wiederhole) ist derzeit absolut nutzlos (ich kann nicht einmal Tutorials finden und niemand verwendet es, was ich im Web sehen kann).

Grüße und vielen Dank für Ihre fantastische Arbeit!

@XenonCoder Du machst zum Schluss noch einen interessanten Punkt

Visual Scripting (ich wiederhole) ist derzeit absolut nutzlos (ich kann nicht einmal Tutorials finden und niemand verwendet es, was ich im Web sehen kann).

Dies ist ein gutes Beispiel dafür, wo etwas von Natur aus schwer zu verwenden ist und später als selbsterfüllende Prophezeiung verwendet wird, um zu erklären, warum es nicht gemacht werden sollte (zB: "SEE! Niemand will visuelles Scripting!"), anstatt zuzugeben, dass es einfach nicht ansprechend oder anfängerfreundlich gemacht wurde.

Es ist wie ein halbes Geschenk, denn ohne die Umsetzung ist es in der Tat nutzlos.

Das gleiche gilt für jede Ergänzung der Engine, die nicht gut dokumentiert oder mit Beispielen versehen ist.

@bigelod Stimme dir

Godot Game Engine ist einfach fantastisch! Es hat ein unglaubliches Potenzial. Um 2D-Spiele zu machen, ist es die Nummer 1! Ich habe jahrelang mit allen bestehenden Game Engine und Frameworks experimentiert und kann mit absoluter Sicherheit sagen, dass Godot ein Projekt ist, das Großes verspricht.

So sieht beispielsweise der neue Visual Shader sehr gut aus und verspricht Großes für die Zukunft. Ich habe einige Tests gemacht und es gefällt mir als Idee sehr gut. Aber um die Logik eines Videospiels zu erkennen, ist Visual Scripting eine Falle.

Wir brauchen Tutorials, Dokumentation im Allgemeinen und vor allem ein vereinfachtes System im Stil von Build 3, GDevelop, Game Maker Studio 2. Zunächst als Addon, um hauptsächlich 2D-Spiele zu erreichen, wird es in Zukunft verbessert und offiziell implementiert. Mir ist klar, dass es keine leichte Aufgabe ist, es ist nur eine Idee, Godot Game Engine zur idealen Lösung für Enthusiasten, Studenten und Videospielprofis zu machen.

Danke euch allen.

Um die Game-Engines herum bildeten sich Stores. Es wurde normal - Add-Ons auf kommerzieller Basis zu schreiben. Für Konstrukt einschließlich. Alle letzten bedeutenden C2-Plug-Ins sind kommerziell. Dies liegt nicht nur an der Marktbildung, sondern auch an der Komplikation der Produkte, einem großen Zeitaufwand für das Testen und Beheben von Kompatibilitätsfehlern.
Ich denke... Godot befindet sich in einer anderen Nische, und wenn Juan die Anwendung vereinfachter Programmierung nicht schreibt und unterstützt, ist es unwahrscheinlich, dass jemand anderes diese Arbeit zu Ende bringt.

Ich bin mit Klik 'n Play, The Games Factory und Multimedia Fusion aufgewachsen und verwende heutzutage Construct 2. Visuelles Skripting mit Ereignisblättern unterscheidet sich grundlegend von der Verwendung von miteinander verbundenen Zustandsmaschinenknoten im Blueprint-Stil, und für Leute, die an Ereignisblätter gewöhnt sind, ist es die einfachste und effizienteste Art der Programmierung. Ich würde gerne eine Möglichkeit zur Skripterstellung in GoDot mit Ereignisblättern begrüßen.

Ich bin bei gdscript, der Dokumentation und der Plugin-API auf einige Einschränkungen gestoßen, die mich daran hindern, meine Vision von diesem Addon vollständig auszuführen. Selbst wenn ich es in einen funktionsfähigen Zustand bringe - es wird wahrscheinlich Einschränkungen haben.

Eine Sache, die mir immens helfen wird, dorthin zu gelangen, ist das optionale typisierte gdscript - weshalb ich aufgehört habe, daran zu arbeiten, bis es in Godot ist. Nun, das ist zusammengeführt - ich werde wieder daran arbeiten, als Proof-of-Concept-Addon, wann immer es Zeit ist.

Die Idee ist, dass das generierte gdscript des Ereignisblatts getippt wird. Die typisierten Daten geben dem Ereignisblatt-GUI dann zusätzliche kontextbezogene Daten bezüglich der erwarteten Parametertypen.

Wenn Interesse daran besteht, dass dies ein richtiges C++-Modul oder ein gdnative-Addon ist, kann jeder versuchen, dies zu implementieren.

Wenn man bedenkt, wie viele Leute es wollen, wird mich nichts glücklicher machen, als dies zu einem Teil von Godot zu machen - oder zumindest als Teil von Godot zu arbeiten.

Leider habe ich einen Vollzeitjob, der im Moment die meiste Zeit in Anspruch nimmt :(
Sorry für die langsamen Updates

Um diese Diskussion zu ergänzen, möchte ich allen hier ein fantastisches Beispiel für eine visuelle Skripting-Engine präsentieren, die einen auf Knotenverbindungen basierenden visuellen Programmieransatz verwendet, der derzeit an seiner demografischen Ausrichtung versagt
https://youtu.be/b8GZ21YCh50?t=4m12s
Es ähnelt https://www.reddit.com/r/unrealengine/comments/4nt0up/need_help_debugging_this_blueprint/

Beachten Sie die Alternativen, die Gamesfromscratch präsentiert

Eine Sache, die ich hier in diesem Entwurfsvorschlag vermeiden möchte, ist, ein Verhalten vorzudefinieren, das außerhalb dessen liegt, was Knoten bereits in Godot tun - auch das Erstellen vieler Registerkarten und GUIs.
Ein Godot-Ereignisblatt sollte genau wie gdscript-Code funktionieren - nur auf taktile/visuelle Weise
Es sollte nicht versuchen, eine einfach zu bedienende Spiel-Engine auf Godot aufzubauen, sondern das, was Godot hat, zugänglicher und schneller zusammenzustellen machen

Vielleicht könnte es mit visueller Schrift sogar über Touchscreens zugänglich sein?

Tatsächlich ist visuelles Scripting im Ereignisblatt-Stil sehr gut für Touch geeignet
Bildschirme

Am Mittwoch, den 1. August 2018, 06:46 Uhr schrieb Elmapul, [email protected] :

Vielleicht könnte es mit visueller Schrift sogar über Touchscreens zugänglich sein?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/godotengine/godot/issues/17795#issuecomment-409456475 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AGMbVdqoa3AdMNfiM986iwIpNeqzqjVLks5uMUCvgaJpZM4S8wyr
.

@blurymind Wenn das Plugin-System dafür Verbesserungen benötigt, öffne ein Problem, es wurde bereits geändert, da andere Plugins etwas Besonderes brauchten.

Es ist eine großartige Idee! Ich habe diese Blaupausen nie wirklich verstanden, aber der ereignisbasierte Ansatz ist bekannt, insbesondere in Modding-Communitys wie dem Warcraft III World Editor.

Beispielbildschirme:


Kategorien und eine saubere Liste von Auslösern sehen zumindest für mich großartig aus. Sie sind leichter wahrzunehmen als Bildschirme aus dem ersten Post.

Es ist größtenteils das gleiche wie Sie gesagt haben, jedoch mit der Möglichkeit, Bedingungen als Aktionen hinzuzufügen und weitere Aktionen darin zu verschachteln.

@Wiadomy
Dieses Bild ist zu klein, um etwas zu sehen/zu lesen

@Elmapul
Entschuldigung, da stimmte etwas nicht. Aktualisiert.

@Elmapul Während mein Konzept-Addon noch keine Verschachtelung durchführen kann, enthält das von mir vorgeschlagene Ereignisblatt die Verschachtelung. Sowohl gdevelop als auch construct unterstützen die Verschachtelung von Zeilen - Sie können es sofort ausprobieren, wenn Sie möchten :)

@blurymind hat endlich mit der Arbeit an der Event Sheet-Implementierung begonnen. Kennen Sie Ressourcen, die die Implementierung im Detail besprechen, etwa eine Forschungsarbeit oder einen Artikel über die Funktionsweise und Implementierung?
Das wird eine große Hilfe sein. Um mich mit dem Entwerfen des Ereignisblattsystems für Godot zu beginnen.
Denn es wäre nicht korrekt, die Construct- oder GDevelop-Methode zu verwenden, da die Funktionsweise von Godot ganz anders ist und wir Dinge namens Signale haben, die auch integriert werden müssen und noch einiges mehr.

Wenn Sie allgemeine Informationen benötigen, finden Sie hier einige Informationen zu den Ereignisblättern von Konstrukten: https://www.scirra.com/manual/74/events
verschiedene Firmen implementieren ihre Eventsheets etwas unterschiedlich und haben daher jeweils ihre eigenen Macken.
Vielleicht kann ich ein Video erstellen, das die verschiedenen Teile der Konstruktmethode zusammenfasst (da dies derzeit wahrscheinlich der beste Weg ist).. Ich kenne keine Forschungsarbeiten, aber das wäre interessant zu finden.

@prominentdetail Danke für den Link, es scheint, als
Meine erste Idee war, etwas Ähnliches wie das Addon von @blurymind zu haben, aber jetzt ist es wahrscheinlicher, dass wir eine andere API für Event Sheet haben sollten, die das Programmieren erleichtert und keine Version von GDScript in visueller Form ist.

Was denken Sie also, sollte das Event System eine andere API haben, um die Benutzerfreundlichkeit zu erhöhen, oder einfach nur ein Wrapper für GDScript sein.

@swarnimarun ist wirklich das Beste, die Engines eine Weile zu verwenden und darüber nachzudenken, wie dies auf eine bessere Art und Weise erfolgen kann. Construct classic und gdevelop sind imo tolle Beispiele.

Aus meiner Sicht sind Signale in Godot genau wie eingebaute Funktionsereignisse. Das Verbinden von Signalen ist in Godot bereits visuell :)

Das Setzen eines Signals von einem Ereignisblatt ist nur eine Aktion, die im Helper-Menü verfügbar ist - unter der Haube ist das nur eine Setter-Methode. Es wäre also das gleiche wie bei gdscript.

Wenn ein Knoten integrierte Methoden enthält, sollte diese im Menü verfügbar sein, das Sie erhalten, wenn Sie auf "Integrierte Funktion hinzufügen" klicken.

Ich denke stark, wir sollten es einfach halten und ein Wrapper für typisiertes gdscript sein, aber wenn das nicht möglich oder praktisch ist - könnte eine andere API sein. Es wäre eine Untersuchung wert, wie das aktuelle in Godot implementierte visuelle Skript als Abstraktion funktioniert.

Wenn Sie sich fragen, wie benutzerdefinierte Funktionen im Konstrukt erstellt werden, finden Sie hier einen Link zu deren Dokumentation
https://www.scirra.com/tutorials/823/creating-function
:)

@blurymind Es ist eigentlich viel einfacher und viel weniger Arbeit, es als Wrapper für GDScript zu behalten, aber die Sache ist, dass viele der Funktionen von Event Sheet auf diese Weise mühsamer werden, zumindest verstehe ich es so.
Ich denke, ich werde es für den Anfang gleich lassen und später bei Bedarf Dinge hinzufügen.

@swarnimarun danke, dass du dir die Zeit

Ich denke, das größte Problem ist, dass VisualScript, wie alle anderen Sprachen, die Sie zum Skripten von Godot verwenden können, versucht, mit Funktionen, Variablen, Signalen und allem anderen so nah wie möglich an der Funktionalität von GDscript zu sein. Dies wäre mit einem Ereignisblattsystem nicht möglich, da Sie viele Funktionen verlieren würden. (Ich weiß, es ist möglich, aber es würde schnell aufgebläht)

@Jummit außer Sie können es vollständig, versuchen Sie Construct 2. Es wird nicht mehr aufgebläht als Standardcode.

Und es könnte alle Funktionen von GDscript haben? Worauf warten wir dann? Lassen Sie uns Ereignisblätter in Godot besorgen!

@Jummit Godot hat alle gewünschten Funktionen in Form von 'Knoten'

'Knoten' in Godot sind wie 'Verhalten' in construct2
Das Platformer-Verhalten in construct2 ist wie ein weniger mächtiger kintematicbody2d-Knoten :)
Sie müssen nicht alles von Grund auf neu erstellen.

Noch cooler ist, dass Sie diese Knoten in einer Eltern-Kind-Beziehung verschachteln können, während Verhaltensweisen darauf beschränkt sind, wie Module an ein einzelnes Spielobjekt angehängt zu werden.

Ich bin fest davon überzeugt, dass ein Godot mit einer eingebauten Event-Sheet-Funktion und ein paar zusätzlichen Plugins aus der Community eine schnellere Engine für das Prototyping werden kann als construct2 oder 3.
Es hat viel Potenzial, das ungenutzt ist.

Die Schnelligkeit des Prototypings in C2 wird maßgeblich durch die Interaktivität der Zellen bestimmt – sie können gezogen, kopiert und mit Hotkeys verändert werden, einschließlich Bedingungsobjekten, während Dropdown-Listen den Fehler fast vollständig eliminieren.

@swarnimarun , ich habe eine allgemeine Übersicht über verschiedene Konstrukte erstellt: https://www.youtube.com/watch?v=ioz3gHtA-Lg
Es ist im Grunde für jeden geeignet, der mit Konstrukten nicht allzu vertraut ist, um ein Gefühl dafür zu bekommen. Ich habe wahrscheinlich verschiedene Dinge übersehen, da ich nicht alles geplant habe, aber es könnte ein grundlegendes Verständnis vermitteln. Ich sollte wahrscheinlich einige Videos machen, in denen ich tatsächlich mehr entwickle, um die Workflow-Seite davon zu zeigen, anstatt über verschiedene Dinge zu schwafeln. Lassen Sie es mich wissen, wenn Sie etwas behandelt oder erforscht haben möchten.

Das ist für mich verdammt hässlich. Ich meine, Skripte im Video.

@Wiadomy es ist viel besser im Gebrauch als in diesem Video. Ereignisblätter sehen am Ende immer sauberer und lesbarer aus als jedes knotenbasierte System

@Wiadomy , aufgrund der Bildschirmaufzeichnung musste ich einen Monitor verwenden und auch die Textgröße relativ groß halten. Construct formatiert den Text so, dass einige Dinge aufgrund des Platzbedarfs auf dem Bildschirm zusammenlaufen können, wenn Sie einen langen fortlaufenden Ausdruck eingeben.
Um einiges davon zu lösen, können Sie den Text herauszoomen und auch einen anderen Monitor verwenden, um Platz zu schaffen, um die Ereignisse besser aufzulisten.
Ich könnte die Ausdrücke auch etwas aufteilen, um es auch ordentlicher zu machen, aber dies ist ein älteres Projekt von mir und auch etwas experimenteller.
Außerdem machen Sie sich mit den visuellen Hinweisen und Mustern in der Struktur der Ereignisblätter vertraut, sodass es einfacher wird, alle verschiedenen Teile in den Ereignissen zu verfolgen. Eine solche Standardstruktur ist sehr nützlich, um sich an jedes Projekt anpassen zu können und den Workflow sehr schnell zu machen.

Ist dieses Projekt jetzt tot?

@ Amr512 Ich glaube nicht, dass es tot ist. Es besteht sicherlich ein großer Wunsch, diese Funktionalität auf Godot zu bringen.
@reduz hat sich kürzlich sogar auf Twitter für gdevelop interessiert
https://twitter.com/reduzio/status/1085206844275081218

Obwohl ich eine Weile nicht an dem Addon gearbeitet habe, habe ich beschlossen, tatsächlich zu gdevelop selbst beizutragen - um mehr darüber zu erfahren, wie das Ereignisblatt programmiert ist - und um es zu einer besseren Alternative zu den bezahlten zu machen Optionen.
https://github.com/4ian/GDevelop/

Einige Universitäten haben damit begonnen, gdevelop zu übernehmen, um Programmierkurse zu unterrichten
https://github.com/4ian/GDevelop/issues/882

Mein fehlerhaftes Godot-Addon dient derzeit nur zu Präsentationszwecken und erfordert viel Arbeit, bevor es funktionsfähig ist. Natürlich steht es jedem frei, es zu forken und zu versuchen, es weiter voranzutreiben.
Eine große Sache, die meinem Addon derzeit fehlt, ist ein sortierbares Baum-GUI-Element für die Ereigniszeilen. Es gibt auch noch keine Funktionalität, um Ereignisblätter tatsächlich in gdscript zu rendern, noch gibt es einen richtigen Ausdruckstexteditor mit automatischer Syntaxvervollständigung und Farbgebung (die Idee ist, Standard-Gdscript für die Syntax zu verwenden). Es fehlen viele Schlüsselelemente, die ein Ereignisblatt ausmachen würden, aber das Hauptziel besteht darin, darzustellen, wie ein Ereignisblatt in Kombination mit gdscript für die Ausdruckssyntax verwendet werden kann. Ich denke, die beiden wären eine sehr leistungsstarke Kombination für das Prototyping von Spielen - selbst für erfahrene Entwickler

@blurymind Ich habe ein Ticket zu Ihrem Projekt hinterlassen (Fehler bei Godot 3.1beta3).
Ich liebe die Idee total.

Ich bin zufällig über dieses Problem gestolpert und wusste nicht, dass dieses Zeug bereits häufig in anderen Engines / Frameworks verwendet wird, also musste ich irgendwie mein eigenes schreiben, sieht sehr ähnlich aus, findest du nicht? 👀.

Regel = Ereignis
Ereignisblatt = Schema

Die vorherige Implementierung verwendete ziemlich "niedrige" Eigenschaftsprüfungen und entsprechende Aktionen, aber ich dachte, dass diese Art von System tatsächlich nützlicher ist, um Gameplay-"Bausteine" zu definieren, indem es Bedingungs-/Aktions-Basisskripte erweitert, die "höher" sind. Ebene" in Abstraktion. Das ist eigentlich der Grund, warum ich überhaupt die Terminologie "Regel" gewählt habe.

Sie müssen das Gameplay und das Spiel-Framework bereits etabliert haben, um dies in vollem Umfang nutzen zu können, so dass es nicht der Out-of-the-Box-Erfahrung zum Schreiben eines Spiels ohne Codierung dient, sondern es tatsächlich so ergänzt, dass es möglich ist Um bestehende Funktionalitäten auf vielfältige Weise zu kombinieren und effizient zu organisieren, erstellen Sie einfach neue Regeln mit unterschiedlichen Bedingungen und Aktionen mit Ihren einfachen GDScripts.

Und ja, es ist ein weiterer Grund für die Verwendung eines solchen Systems, den Spielern die Möglichkeit zu geben, ihre eigenen Spielmodi/Missionen/Herausforderungen per Modding zu erstellen.

@Xrayez kannst du git repo teilen? Ich denke, Sie haben Recht, dass meine Implementierung zu granular ist, aber es stimmt, wie gdscript und die API von Godot funktionieren.
Ich denke auch, dass Sie beim Betrachten des Screenshots den Punkt übersehen - es sollten nur zwei Spalten sein, nicht drei. Links = Bedingungen, rechts = Aktionen. Außerdem sollten Sie in der Lage sein, Ereignisse per Drag-and-Drop zwischen Zellen zu ziehen und Zeilen per Drag-and-Drop zu verschieben und zu verschachteln. Um dies zu erstellen, müssen wir einen sortierbaren Baum verwenden. Spielen Sie mit gdevelop and construct, Sie werden eine bessere Vorstellung davon bekommen, was diese Veranstaltungsblätter so schön macht

Vielleicht könnte meine Implementierung als etwas Ähnliches wie DSL angesehen werden, daher können die Unterschiede liegen. Viele Regeln sind nur Sandbox-Implementierungen von Funktionen, die auf bestimmte Spielanforderungen zugeschnitten sind. Im Wesentlichen erben Bedingungen und Aktionen nur diese kleinen Skripte mit den Methoden, die in untergeordneten Klassen implementiert werden müssen:

class_name SchemeCondition extends Node

func is_met(object): # override
    return true

class_name SchemeAction extends Node

func perform(object): # override
    pass

Die Regeln sind einfach eine Sammlung von diesen Bedingungen und Aktionen und ausgeführt werden , je nachdem , ob alle oder alle Bedingungen erfüllt sind, nichts Besonderes in der Tat.

Ich verstehe, dass die Leute, die Dinge beitragen und implementieren, gerne codieren und nicht alle den Reiz von No-Coding-Programmierung sehen, aber viele andere sind tatsächlich daran interessiert.

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

Viele Tools für Nicht-Programmierer werden entwickelt und verwendet. Viele gute Spiele werden dank dieser gemacht.
Hollow Knight wurde zum Beispiel mit Spielmacher gemacht.

Du hast sogar Sachen wie Dreams , die ziemlich viel Lärm machen.

Diese Art von Tool würde Godot viel Attraktivität und Zugänglichkeit und damit neue Leute bringen.

Ich habe kürzlich in gdevelop eine Möglichkeit implementiert, dem Ereignisblatt über eine Dropdown-Liste wie diese neue Anweisungen hinzuzufügen

Es ist etwas, was meiner Meinung nach gut für Godot funktionieren könnte.

Sie verwenden das Richtextlabel, um jede Zelle zu rendern, diese Zellen sind in der linken und rechten Spalte verschachtelt, die dann einer Zeile untergeordnet ist. Zeilen werden von einem sortierbaren Baum verwaltet. Jede Zeile enthält tatsächliches gdscript, das ein Interpreter in einfache kurze Beschreibungen mit Miniaturansichten und anklickbaren Bereichen umwandelt, um Ausdrücke einzugeben.
Genau das macht der Spielemacher. Ihre visuellen Programmierdaten werden als tatsächliche gml gespeichert.

Der knifflige Teil, den ich fand, als ich damit begann, eine gdscript-Erweiterung zu erstellen, bestand darin, die Ausdrucksfelder zu erstellen. Wie fügen wir einen Code-Editor in ein Eingabefeld ein und lassen ihn die Autovervollständigung für uns durchführen? Wie geben wir ihm einen Abschluss- und Validierungskontext? Ohne validierte automatisch vervollständigte Ausdrucksfelder ist dies tot im Wasser.

Wir haben alle UI-Teile, um dies in Godot zu erstellen, aber wir haben buchstäblich keinen einzigen erfahrenen Entwickler, der etwas daran tut. Ich habe noch keine Arbeit gesehen

Wie auch immer, wenn meine c++-Kenntnisse besser wären, hätte ich es versucht :) Aber ich kenne Javascript, also gehen meine Beiträge stattdessen an gdevelop

Würde gerne eine ereignisbasierte Lösung in Godot sehen. Ich habe Godot in der Vergangenheit ausprobiert, aber ich konnte mich mit dem Workflow nicht anfreunden. Mein Verstand ist eher für Ereignisblätter geeignet, wenn ich ein Spiel entwickeln möchte.

Ich bin jetzt Programmierer und fange sogar an, in die Motorenentwicklung einzusteigen. Aber ich kann immer noch ziemlich zuversichtlich für Ereignisblätter bürgen.

Konstrukt 2 war tatsächlich mein allererster Kontakt mit vielen grundlegenden Programmierkonzepten, durch einen Kurs, den ich zurück in der High School besuchte. Ich habe das Gefühl, dass es den Lernprozess für mich massiv vereinfacht und beschleunigt hat – sowohl die Engine im Besonderen als auch die Programmierung im Allgemeinen – und gleichzeitig eng genug in den tatsächlichen Code übersetzt, sodass ich mich beim Übergang von den Ereignisblättern nicht völlig verloren fühlte zum regulären alten Textskript. Obwohl ich mir da nicht 100% sicher sein kann, glaube ich wirklich nicht, dass ich einen dieser Vorteile in gleichem Maße hätte bekommen können, wenn es stattdessen die Spaghetti-Art des visuellen Skriptings wäre.

Aber ich stimme zu, dass es wahrscheinlich eine schlechte Idee ist, zwei verschiedene visuelle Scripting-Systeme zu unterhalten. Das heißt, ich denke nicht, dass wir am aktuellen System festhalten sollten, nur weil wir es bereits haben. Ich denke, wir sollten wirklich in Erwägung ziehen, auf das andere System umzusteigen, wenn die Daten dies rechtfertigen. Das heißt, ich denke, wir sollten versuchen, eine bessere Vorstellung davon zu bekommen, wie viel zugänglicher das Ereignisblattsystem im Vergleich zu unserem aktuellen System ist. Das Ziel von Visual Scripting sollte es sein, die Engine für Leute, die mit regulärem Scripting nicht vertraut oder nicht vertraut sind, freundlicher zu machen. Ein solides visuelles Skripting-System könnte einen großen Unterschied darin machen, wie zugänglich Godot ist, und könnte bedeuten, die Unterstützung und Akzeptanz von viel mehr Menschen zu bekommen, die Godot sonst nicht in Betracht gezogen hätten.

Eigentlich war der Hauptgrund, warum ich ursprünglich von Construct 2 abgerückt bin, einfach, dass ich bereits in 3D einsteigen wollte. Am Ende probierte ich Unity, Unreal, Godot und Amazon Lumberyard aus und entschied mich für Godot, nur weil es sich einfacher zu öffnen und zu verwenden anfühlte und sich der Importprozess besser anfühlte. Aber wenn Godot das Event-Sheet-Style-System hätte, hätte ich wahrscheinlich sofort Godot verwendet. Zugegeben, für mich persönlich macht es jetzt keinen Unterschied, aber hier geht es wiederum darum, Godot so freundlich wie möglich zu Nicht-Programmierern (dh einem erheblichen Teil neuer/angehender Spieleentwickler) zu machen.

Ich habe die 112 Beiträge, die jetzt versteckt sind, nicht gelesen, also entschuldige ich mich, wenn ich etwas wiederholt oder verpasst habe, aber ich wäre total daran interessiert, die Idee als Prototyp zu erstellen oder auf andere Weise beim Testen und Überlegen zu helfen.

Ich denke, wir sollten wirklich in Erwägung ziehen, auf das andere System umzusteigen, wenn die Daten dies rechtfertigen. Das heißt, ich denke, wir sollten versuchen, eine bessere Vorstellung davon zu bekommen, wie viel zugänglicher das Ereignisblattsystem im Vergleich zu unserem aktuellen System ist.

Wir haben bereits sehr wenige Betreuer für das aktuelle Visual Scripting-System. Ich glaube nicht, dass ein kompletter Wechsel zu unseren Lebzeiten vollzogen werden würde :slightly_smiling_face:

Wir haben bereits sehr wenige Betreuer für das aktuelle Visual Scripting-System. Ich glaube nicht, dass ein kompletter Wechsel zu unseren Lebzeiten vollzogen werden würde 🙂

Nun, angenommen, wir bekommen zuerst einen funktionierenden Prototyp des Ereignisblatts, dann wäre der Code größtenteils schon fertig, und es wäre nur die Frage, ob wir stattdessen auf dieses System umsteigen wollen, oder?

Ich habe auch mit Construct 2 angefangen und festgestellt, dass Ereignisblätter großartig zu lösen sind 2
Probleme:

• Wie bei jedem visuellen Scripting bieten Sie alle Möglichkeiten von jedem
  Modul/Plugin/Add-On/Funktion, dies ist sehr nützlich, um neuen Code zu lernen.
  Visuelle Knoten verwandeln sich jedoch ziemlich schnell in Spaghetti-Code (ich bin ein Blender-Typ,
  Ich kenne Spaghetti in Compositor und Shadern).
• Event Sheet ist wie Prahlerei für Rest API, Sie beginnen mit gut dokumentierten
  Code, der das Dropdown-Menü des Ereignisblatts ausfüllt und Sie erhalten eine saubere GUI
  Möglichkeit, Ihren Code zu konsumieren, können Sie erweitern, indem Sie unordentlich werden, und Sie können
  Code daraus generieren (JS from Construct2), daher meine Frage: Könnten wir?
  Code daraus generieren?

Wenn ja, sollte das Ereignisblatt meiner Meinung nach Priorität haben, um die Verwendung zu erleichtern.
jeder und optimierte Low-Level-Code-Generierung.
Wenn Godot verwendet werden könnte, um eine Python/C#/...-API in einen sauberen Satz zu verwandeln
Ereignisse, dann Benutzer-Build-Ereignisse, dann generiert Godot Code daraus, du bist
Lösen eines sehr, sehr schwierigen Benutzerproblems: Lernen Sie, wie man über eine einfache Benutzeroberfläche programmiert.

Ich weiß, dass Ereignisblätter nicht alle Probleme lösen, aber Sie können zumindest 500 codieren
Ereignisse, wie Sie es in einer Tabelle tun, ohne sich in der Grafik zu verlieren
überall verlinkt.

Am Mittwoch, 8. April 2020 um 19:44 Uhr schrieb Jay [email protected] :

Wir haben bereits sehr wenige Betreuer für das aktuelle Visual Scripting
System. Ich glaube nicht, dass ein kompletter Wechsel in unserem jemals vollzogen werden würde
Lebenszeit

Angenommen, wir erhalten einen funktionierenden Prototyp des Ereignisblatts, dann der Code
wäre meist schon erledigt, es wäre nur eine Frage, ob wir
möchte stattdessen darauf umsteigen, oder?

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/godotengine/godot/issues/17795#issuecomment-611096608 ,
oder abmelden
https://github.com/notifications/unsubscribe-auth/AAAP6LM4PU6RYLO5NK5IL23RLSZWHANCNFSM4EXTBSVQ
.

Ich habe mit Construct 2 angefangen und bin schließlich dazu übergegangen, Plugins mit JavaScript zu entwickeln, daher haben Ereignisblätter einen Platz in meinem Herzen. Sie waren für Uneingeweihte einfach und intuitiv, wobei der Großteil der Magie aus der einfachen Visualisierung der verfügbaren Methoden (Aktionen und Bedingungen) für jede Klasse (Plugin) resultierte. Ehrlich gesagt ist GDScript in VSCode jetzt genauso gut, mit vollständiger Intelligenz und automatischer Vervollständigung, die das Leben zum Kinderspiel machen. Obwohl ich vor 2 Jahren ein großer Fan dieser Idee war, habe ich meine Meinung jetzt geändert. Mir wäre es lieber, wenn die Godot-Entwickler ihre Zeit und Mühe darauf konzentrieren, andere Engine-Verbesserungen hinzuzufügen.

Könnten wir daraus Code generieren?

Ich müsste mir das genauer ansehen, aber ich denke ehrlich gesagt, dass es ziemlich trivial wäre, und tatsächlich ist es wahrscheinlich der beste Weg, es zu tun. Das heißt, ich denke, der beste Weg, eine Sache im Ereignisblattstil zu handhaben, besteht darin, sie im Grunde als grafisches Frontend für eine normale gdscript-Datei zu verwenden. Aktionen im Ereignisblatt-Editor würden einfach die gdscript-Datei bearbeiten. Zum Beispiel würde das Verschieben eines Blocks von einer Stelle an eine andere im Ereignisblatt-Editor im Grunde genommen wie ein virtuelles Ausschneiden + Einfügen in die gdscript-Datei erfolgen. Und jede gdscript-Datei kann entweder im Skript-Editor oder im Ereignisblatt-Editor angezeigt und bearbeitet werden. Dies scheint der beste Weg zu sein, sowohl aus Sicht der Benutzerfreundlichkeit als auch aus Sicht der Implementierung. Allerdings kenne ich mich mit der Motorenentwicklung noch nicht so gut aus, also kann ich mich irren.

Mir wäre es lieber, wenn die Godot-Entwickler ihre Zeit und Mühe darauf konzentrieren, andere Engine-Verbesserungen hinzuzufügen.

Ich stimme ziemlich zu. Ich denke, der ideale Weg, dies zu tun, wäre für jeden, der daran interessiert ist, gemeinsam zu versuchen, einen funktionierenden Prototypen zusammenzustellen, und dann kann die Community versuchen, herauszufinden, ob es sich lohnt, auf dieses als das wichtigste visuelle Skripting-System zu wechseln oder nicht. Ich würde keine Hauptentwicklungszeit für diese Idee verlangen, bis eine Entscheidung getroffen ist oder zumindest nahe ist.

Ich bin auch nicht genug in Gdscript oder Godot.
Aber was ich als VS Code-Erweiterung entwickelt habe, geht auch in diese breite Richtung
(https://github.com/j2l/blocklight).
Visuelles Verstehen des Codes durch Spielen mit einem Teil davon und visuell
Verknüpfen der Variablen und Ergebnisse (Knoten in den meisten visuellen Skripten oder Farben
in meiner Erweiterung) ist für viele der fehlende Eckpfeiler.
Eigentlich verstehen wir Code, wenn wir ihn gelernt haben, obwohl wir das sollten
Sehen Sie sich die Variablen und die Links der Chunks an, bevor Sie alle
Code.
Design vor dem Codieren :)

Am Mittwoch, 8. April 2020 um 20:08 Uhr schrieb Jay [email protected] :

Könnten wir daraus Code generieren?

Ich müsste es mir genauer anschauen, aber ich finde es ehrlich gesagt hübsch
trivial, und tatsächlich ist es wahrscheinlich der beste Weg, dies zu tun. Das ist,
Ich denke, der beste Weg, mit einer Sache im Ereignisblattstil umzugehen, ist im Grunde
Lassen Sie es als grafisches Frontend für eine normale gdscript-Datei fungieren. Aktionen
im Ereignisblatt-Editor aufgenommen würde einfach die gdscript-Datei bearbeiten. Ziehen um
ein Block von einem Ort zum anderen im Ereignisblatt-Editor würde im Grunde genommen
unter der Haube wie ein virtuelles Ausschneiden + Einfügen in die gdscript-Datei tun. Und
jede gdscript-Datei kann entweder im Skripteditor oder in . angezeigt und bearbeitet werden
Ereignisblatt-Editor. Dies scheint der beste Weg zu sein, sowohl von a
Usability- und Implementierungssicht. Das heißt, ich bin
Ich kenne mich noch nicht so gut mit der Motorenentwicklung aus, daher kann ich mich irren.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/godotengine/godot/issues/17795#issuecomment-611108712 ,
oder abmelden
https://github.com/notifications/unsubscribe-auth/AAAP6LN7GFGSBDZ537XXA6DRLS4Q5ANCNFSM4EXTBSVQ
.

Ich liebe die Idee, dass es eine normale Gdscript-Datei generieren würde. Wäre echt toll zum lernen

Als ich anfing, Spiele zu entwickeln, war das Ereignissystem von Klik & Play eine wirklich großartige Möglichkeit für mich, mich mit der Programmierlogik zu beschäftigen, und ich gehe immer noch gerne darauf zurück.

Ich liebe die Idee, dass es eine normale Gdscript-Datei generieren würde. Wäre echt toll zum lernen

Als ich anfing, Spiele zu entwickeln, war das Ereignissystem von Klik & Play eine wirklich großartige Möglichkeit für mich, mich mit der Programmierlogik zu beschäftigen, und ich gehe immer noch gerne darauf zurück.

Ich denke, das ist möglicherweise einer der größten Vorteile gegenüber dem aktuellen Spaghetti-System - aufgrund seines Designs wird es den Leuten das Erlernen der Programmierung und der API von gdscript/godot erleichtern.

Einige Leute hier kommentierten - aber warum sollten Sie sich die Mühe machen - es ist zu ähnlich wie das Skripting in der Präsentation.
Meine Antwort darauf ist - genau. Wenn Sie Spaghetti lernen, bleiben Ihnen Spaghetti. Sie lernen das Ereignisblatt kennen, Sie werden gdscript kennen, indem Sie sehen, was es generiert und diese Ausdrucksfelder verwenden.

Es wird Ihnen die Ausführungsreihenfolge und das Lesen von Code beibringen.

Sehen Sie, was das Konvertieren in GML im Game Maker bewirkt
https://docs2.yoyogames.com/source/_build/3_scripting/1_drag_and_drop_overview/changing_dnd.html

Wirklich interessanter Blurymind! Ich hatte die gleiche Idee und unterstütze dies voll und ganz.
Ich erstelle immer noch Erweiterungen für Clickteam Fusion 2.5, aber alles, was ich in Fusion hinzufügen möchte, ist in Godot.
Alles, was ich brauche, ist, eine weitere Abstraktionsschicht (Ereignisblatt) in Godot zu platzieren, um die Entwicklung zu erleichtern.
Ich habe nicht den ganzen Thread gelesen, aber aus meiner Sicht besteht der Hauptunterschied zwischen Visual Scripting in Godot und Event-Sheets in anderen Game-Engines darin, dass Visual Scripting "nur" eine visuelle Ansicht des Codes ist und Event-Sheets eine Abstraktion von den Code mit einer vereinfachten Ansicht. Es ist besser lesbar, faktorisiert Dinge, die mehrere Codezeilen in einer Zeile benötigen, und die Signal-/Slot-Verknüpfung erfolgt automatisch.
Eigentlich würde das Hinzufügen einiger Vorlagen (vordefinierte Szenen) zu abstrakten CF2.5-integrierten Objekten und trotzdem GDScript die meiste Arbeit für mich erledigen, aber das Ereignisblatt wird mich definitiv effizienter in Godot machen als das, was ich in CF2.5 tue jetzt.

Wirklich interessanter Blurymind! Ich hatte die gleiche Idee und unterstütze dies voll und ganz.
Ich erstelle immer noch Erweiterungen für Clickteam Fusion 2.5, aber alles, was ich in Fusion hinzufügen möchte, ist in Godot.
Alles, was ich brauche, ist, eine weitere Abstraktionsschicht (Ereignisblatt) in Godot zu platzieren, um die Entwicklung zu erleichtern.
Ich habe nicht den ganzen Thread gelesen, aber aus meiner Sicht besteht der Hauptunterschied zwischen Visual Scripting in Godot und Event-Sheets in anderen Game-Engines darin, dass Visual Scripting "nur" eine visuelle Ansicht des Codes ist und Event-Sheets eine Abstraktion von den Code mit einer vereinfachten Ansicht. Es ist besser lesbar, faktorisiert Dinge, die mehrere Codezeilen in einer Zeile benötigen, und die Signal-/Slot-Verknüpfung erfolgt automatisch.
Eigentlich würde das Hinzufügen einiger Vorlagen (vordefinierte Szenen) zu abstrakten CF2.5-integrierten Objekten und trotzdem GDScript die meiste Arbeit für mich erledigen, aber das Ereignisblatt wird mich definitiv effizienter in Godot machen als das, was ich in CF2.5 tue jetzt.

Früher habe ich CF benutzt, als es Multimedia-Fusion genannt wurde schneller sein als tippen.
Konstrukt und CF sind Referenzen dafür, wie ein gutes visuelles Skripting aussieht (gdevelop kommt dorthin)

Danke schön
Ich unterstütze diese wunderbare Idee
Sie sagen, Konstrukt 2 wird in Rente gehen!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

Ich frage mich, ob es möglich ist, mit dem Entwickler von Konstrukt 2 zu verhandeln, um das Ereignissystem als Opensource zu öffnen und es in Godot, Unity usw.
Es ist ein Verlust, dass das Konstrukt 2 Ereignissystem ungenutzt in den Regalen vernachlässigt wird

Danke schön
Ich unterstütze diese wunderbare Idee
Sie sagen, Konstrukt 2 wird in Rente gehen!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

Ich frage mich, ob es möglich ist, mit dem Entwickler von Konstrukt 2 zu verhandeln, um das Ereignissystem als Opensource zu öffnen und es in Godot, Unity usw.
Es ist ein Verlust, dass das Konstrukt 2 Ereignissystem ungenutzt in den Regalen vernachlässigt wird

Ich bezweifle, dass wir irgendeinen Code von construct2 auf Godot verwenden können - sie sind eine völlig andere Codebasis.

Ihre beste Wahl für eine Open-Source-Alternative ist der Wechsel zu gdevelop
https://github.com/4ian/GDevelop

Dieses Ausgabeticket wird wahrscheinlich bald geschlossen. Wenn also Interesse an diesem Veranstaltungsblatt in Godot besteht, müssen wir es möglicherweise bald woanders hin verschieben :) (oder zu gdevelop)

Dieses Ausgabeticket wird wahrscheinlich bald geschlossen. Wenn also Interesse an diesem Veranstaltungsblatt in Godot besteht, müssen wir es möglicherweise bald woanders hin verschieben :)

Was? Wieso den?

@TheGoklayeh Es kann geschlossen werden, da wir Feature-Vorschläge zu Godot-Vorschlägen migrieren.

Das heißt, @blurymind konnte den ersten Beitrag bearbeiten , um die passen Vorschlag Vorlage . Wir könnten dieses Problem dann in das Vorschlags-Repository verschieben.

Wir brauchen wirklich eine 3D-Engine, die Ereignisblätter verwendet.

Danke schön
Ich unterstütze diese wunderbare Idee
Sie sagen, Konstrukt 2 wird in Rente gehen!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

Ich frage mich, ob es möglich ist, mit dem Entwickler von Konstrukt 2 zu verhandeln, um das Ereignissystem als Opensource zu öffnen und es in Godot, Unity usw.
Es ist ein Verlust, dass das Konstrukt 2 Ereignissystem ungenutzt in den Regalen vernachlässigt wird

Das könnte ihr Geschäft ruinieren. und Clickteam zusätzlich.

Danke schön
Ich unterstütze diese wunderbare Idee
Sie sagen, Konstrukt 2 wird in Rente gehen!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505
Ich frage mich, ob es möglich ist, mit dem Entwickler von Konstrukt 2 zu verhandeln, um das Ereignissystem als Opensource zu öffnen und es in Godot, Unity usw.
Es ist ein Verlust, dass das Konstrukt 2 Ereignissystem ungenutzt in den Regalen vernachlässigt wird

Das könnte ihr Geschäft ruinieren. und Clickteam zusätzlich.

Wenn sie etwas umbringt - Clickteam wäre wegen fehlender Updates für ihre Software (letztes im Jahr 2019) dafür verantwortlich, dass Scirra ihre Benutzer dazu zwingt, zu einer Miet-der-Software-Lizenz zu wechseln, die sie zwingt, jedes Jahr zu zahlen oder zu erhalten ausgeschlossen. Beide Unternehmen haben Fehler und ihre Community hat keine Kontrolle darüber, was mit der Software passiert. Hier glänzt Open Source

@TheGoklayeh Es kann geschlossen werden, da wir Feature-Vorschläge zu Godot-Vorschlägen migrieren.

Das heißt, @blurymind konnte den ersten Beitrag bearbeiten , um die passen Vorschlag Vorlage . Wir könnten dieses Problem dann in das Vorschlags-Repository verschieben.

Kann das jemand statt mir machen? :)
Ich habe die Hoffnung verloren, dass diese Funktion jemals Godot nativ erreichen wird (keine Erweiterung). Der Spaghetti-Ansatz hat Godot-Benutzer und Entwickler überzeugt

@blurymind Wenn Sie diesen Vorschlag nicht mehr unterstützen, ist es meiner Meinung nach besser, ihn zu schließen. Jemand anderes, der daran interessiert ist, an einem Event-Sheet-Ansatz zu arbeiten, könnte dann einen neuen Vorschlag zu Godot-Vorschlägen eröffnen . (Aufgrund des hohen Arbeitsaufwands halte ich es nicht für sinnvoll, ein Angebot zu eröffnen, wenn niemand technisch in der Lage ist, es zu erfüllen.)

Trotzdem enthält dieser Thread viele wertvolle Diskussionen, also danke trotzdem :slightly_smiling_face:

Ich finde diesen Vorschlag sehr albern :)
Aber können wir das Ereignissystem mit Konstrukt 3 Engine erstellen?!
Ich denke, das Spiel kann Codes generieren und diese in einer Textdatei über node.js an die Godot-Engine senden

Das ist lächerlich .. aber ich denke, Konstrukt 3 ist stark genug, um ein Ereignissystem zu erstellen
Das ist im Moment besser als nichts

Ja, hoffentlich haben wir es zumindest geschafft, eine Idee zu einem solchen System in Godot zu bekommen, seine Vorteile gegenüber dem aktuellen visuellen Codierungssystem und Meinungen über andere Engines, die es verwenden

Ich mag es ehrlich gesagt, wie GDevelop es macht, aber Godot, das Event-Skripte erstellt, ist nichts, wofür ich jetzt (heute) bin.
Ich habe einmal versucht, es zu implementieren, und wurde mit der Erkenntnis getroffen, dass Godot eine extrem granulare / Low-Level-API hat, damit es direkt von einem Visual Scripting-System bereitgestellt werden kann.
Das aktuelle Visual Scripting-System ist enthalten und warum ich es vorziehen würde, eine benutzerdefinierte Abstraktionsschicht zu haben, aber dennoch robust zu sein.
Eine solche Implementierung ist für Ereignisskripte wahnsinnig schwer zu schreiben, es sei denn, Sie verwenden mehrere DSL-ähnliche Unterereignisskriptsprachen, von denen jede für einen bestimmten Teil der Engine verwendet wird.

Ein verallgemeinertes visuelles Scripting-System, das einfach und leicht zu verwenden ist, wäre ziemlich schwer zu erreichen und ist das, was ich als "Einhorn-Projekt" bezeichne.
Denn die zunehmende Generalisierung würde sehr wahrscheinlich zu einer viel größeren Komplexitätszunahme des genannten Systems führen.

Ich plane, Visual Scripting schrittweise in eine Richtung zu entwickeln, in der es spezialisierte Schnittstellen für alle Teile der Engine haben kann.
Stellen Sie sich für jeden Typ von primitiven komplexen Knoten eine andere Art der Bearbeitung vor, wie in Blueprints, die einen Ausdrucksknoten haben.
https://docs.unrealengine.com/en-US/Engine/Blueprints/UserGuide/MathNode/index.html

Aber um es klarzustellen, ich bin nicht gegen Event Scripting. Ich würde gerne sehen, dass jemand einen Vorschlag macht, der einige spezifische Systeme des Godot abdecken kann und warum und wie es nützlich sein kann. Persönlich finde ich es ganz nett zum Programmieren von Behaviours, wie GDevelop das macht.
http://wiki.compilgames.net/doku.php/gdevelop5/behaviors
http://wiki.compilgames.net/doku.php/gdevelop5/behaviors/events-based-behaviors

Ich werde es nicht verwenden, um ein richtiges Spiel zu schreiben, aber wenn wir einfache Verhaltensweisen haben, mit denen wir uns fallen lassen und mit denen wir spielen können, sehe ich es als eine ziemlich unterhaltsame Möglichkeit, das Projekt für Kinder zu optimieren, die lernen, Spiele zu machen.
Oder jemand, der es nicht gewohnt ist, es für Game Jams zu programmieren.

Obwohl das gleiche über VisualScript gesagt werden kann, wird die Modularität damit wahrscheinlich viel einfacher zu erreichen sein. Das Problem wäre die Vereinheitlichung und Konsistenz (Visual Shader und VisualScript verwenden völlig unterschiedliche Codebasen, nur Ähnlichkeit sind die verwendeten UI-Knoten).
Dennoch können wir sicherlich versuchen, ein Event Script-System als Plugin (C++ Plugin, hoffentlich wird es nach 4.0 einfach zu machen) zu haben, das von der Community gewartet und bei Bedarf zu Godot hinzugefügt werden kann. (Ich bin irgendwie voreingenommen in Richtung einer modularen Game Engine)

Wie auch immer, das sind nur meine 2 Cent.

Warum wurde mein Kommentar als Offtopic markiert? Zensiert jemand die Community und wer? Das verheißt nichts Gutes. Es gibt außer meinem noch andere Kommentare, die nicht zum Thema gehören.

@prominentdetail Hier ist meine Anti-Bump- einzufügen :slightly_smiling_face:

Bitte stoßen Sie keine Probleme an, ohne wichtige neue Informationen beizutragen. Verwenden Sie stattdessen den :+1: Reaktions-Button im ersten Beitrag.

(Ich wünschte, GitHub hätte eine Möglichkeit, private Nachrichten zu senden oder zumindest einen benutzerdefinierten Grund für das Verstecken anzugeben, damit ich den Kommentarthread nicht damit überschütten müsste.)

PS: Dies ist die typische Etikette auf GitHub; es ist nicht spezifisch für dieses Repository.

Ich unterstütze diesen Vorschlag, aber ich glaube nicht, dass sich irgendjemand die Zeit nehmen würde, ihn umzusetzen.
Es hat nicht genügend Unterstützung von Entwicklern, die es tatsächlich umsetzen können.

War einen Versuch wert und die Diskussion war sicher interessant :)

@blurymind, wenn Sie den Vorschlag immer noch unterstützen und bereit sind, sich die Zeit zu nehmen, ihn im für GIPs erforderlichen Format zu verfassen. Es lohnt sich IMO zu machen.

In Godot werden Dinge hinzugefügt, wenn sich jemand, der sich für ein Feature interessiert, die Zeit nimmt, es zu implementieren. Es ist sehr zufällig und sporadisch. Aber wir verlassen uns fast ausschließlich darauf, dass Mitwirkende zufällig entscheiden, Funktionen hinzuzufügen.

Nur weil die derzeit aktiven Entwickler kein Interesse an Ihrem Vorschlag haben, heißt das nicht, dass nicht jemand vorbeikommt und ihn umsetzt.