Godot: C# als Skriptsprache

Das Hinzufügen weiterer Funktionen zu GDscript wäre meiner Meinung nach ein besserer Weg, um an das Skripting heranzugehen

Für mich ist der Hauptgrund, Godot gegenüber anderen Spiel-Engines zu wählen, das vereinfachte Skriptschema. Godot bietet nicht an, eine neue Programmiersprache zu lernen. Es bietet an, Godot und seine Skriptsprache als kombiniertes Tool für die Spieleentwicklung zu lernen. Dies ist ein weniger einschüchternder Ansatz, als Neueinsteigern das Erlernen von C++ oder einer anderen Programmiersprache für die Skripterstellung anzubieten.

Vielen Dank für die Eröffnung dieser Ausgabe. Ich denke, dies ist ein Thema, bei dem es einen großen Unterschied zwischen der rational besten Wahl und dem gibt, was die Mehrheit verlangen wird.

Der wichtigste Grund, warum es mehr als eine Engine gibt, ist, dass es neben eindimensionalen Faktoren wie Leistung bei allgemeinen Aufgaben oder Zugänglichkeit der Schnittstellen mehrdimensionale Faktoren wie Leistung für bestimmte Situationen gibt (es gibt keinen offensichtlichen Gewinner, wenn Sie eine Engine vergleichen optimiert für 3D-Spiele und eine für 2D-Spiele optimiert) oder die Benutzerfreundlichkeit für bestimmte Benutzergruppen (eine anfängerfreundliche Oberfläche muss normalerweise fortgeschrittene Funktionen verbergen).
Um also einen Platz unter anderen Engines zu finden, muss eine Engine eine "Philosophie" wählen.

Nun ist eine Skriptsprache ein integraler Bestandteil einer Engine, daher sollte die Philosophie der Sprache zur Philosophie der Engine passen oder ihr zumindest nicht widersprechen.

Was ist also Godots Philosophie? Schauen wir uns einige Fakten an:

• Im Vergleich zu Godot ist jeder andere große Motor aufgebläht.
  Godots Download ist kleiner als 20 MB, die gesamte "Installation" ist eine ausführbare Datei, die weniger als 50 MB groß ist. Lumberyard hingegen hat eine anfängliche Downloadgröße von etwa 5,5 GB, derzeit ist mein Installationsordner davon 15,3 GB groß. Der Hauptgrund dafür ist die Philosophie von Amazon in Bezug auf Abhängigkeiten. Dieser anfängliche Download enthält 10,5 GB erstellte Images von 42 Abhängigkeiten, und wenn Sie zuvor mit Amazon-Webdiensten gearbeitet haben, wissen Sie, dass das AWS SDK in diesem Aspekt nicht so anders ist, also ist es keine Frage der Notwendigkeit oder Fähigkeit, es ist eine Frage nach Wahl. Während Lumberyard beispielsweise Boost und Lua enthält, enthält Godot seine eigenen Versionen der wichtigsten STL-Container und verwendet GDScript anstelle von Lua, was die Größe gering hält, Abhängigkeiten entfernt und den Code viel lesbarer und zugänglicher macht.
• Godots Quellcode ist sehr zugänglich.
  Das beginnt mit der Wahl des Build-Systems (SCons), das Python als Build-Sprache verwendet. Die meisten anderen Projekte verwenden vorhandene Build-Systeme mit proprietären Build-Sprachen oder schreiben ihr eigenes proprietäres Build-System, was sich negativ auf die Lesbarkeit des Build-Codes auswirkt.
  Auch der Quellcode selbst ist in dieser Hinsicht überdurchschnittlich. Ich habe etwa genauso lange gebraucht, um herauszufinden, wie man einen einzelnen Unreal Blueprint-Knoten in C++ schreibt, wie ich gebraucht habe, um den Code für meine erste Pull-Anfrage an Godot zu schreiben. Das soll nicht heißen, dass der C++-Code von Unreal nicht lesbar war, er ist einfach nicht so sauber wie der von Godot, da er mehr Makros verwendet und vom Benutzer verlangt, mehr von Unreals Standardprojektcode zu verstehen als von Godot.
• Godot fördert KISS- und OO-Prinzipien.
  Um das zu veranschaulichen, schauen wir uns einige einfache Objekte in Unity an. Das erste Konzept, mit dem Sie in Unity konfrontiert werden, ist das von GameObjects mit angehängten Komponenten. „composition over inheritance“, wie es oft genannt wird (ich bevorzuge Michael J. Dickheisers Formulierung „Containment versus Inheritance“ aus „C++ for Game Developers“, die nicht wie ein Schlachtruf klingt und zum Nachdenken über das Thema anregt) ist ein gelungenes Muster aufgrund der gebotenen Flexibilität. Diese Flexibilität hat jedoch ihren Preis. Wenn alles in Ihrem Spiel ein GameObject ist, können Sie nicht wirklich einen Verweis auf "den Spieler" erhalten, da es keinen Spieler gibt, sondern nur ein GameObject, an das möglicherweise eine Player-Komponente angehängt ist oder nicht (oder vielmehr diese mehreren Komponenten, die machen Spieler hoch).
  Die Unity-Entwickler sahen das gleiche Problem, manchmal möchten Sie nur einen Button erstellen, kein GameObject mit Button-Komponente. Was sie also getan haben, ist Folgendes: Sie erlaubten Ihnen, "einen Button" über die Editor-Oberfläche zu erstellen, die tatsächlich ein GameObject mit einer angehängten Button-Komponente erstellt. Darüber hinaus haben sie die wichtigsten Mitglieder von GameObject durch jede Komponente geleitet, sodass Sie jetzt eine Referenz auf einen Button genauso verwenden können, wie Sie eine Referenz auf ein GameObject verwenden würden. Sie können einen Button nach seiner Position fragen, Sie können ihn nach einer Liste seiner Komponenten fragen - obwohl der Button eigentlich eine Komponente ist, nicht das Objekt, an das er angehängt ist.
  Jetzt haben wir also eine Mischung aus den beiden beliebtesten Arten, eine Spielwelt zu beschreiben – kompositionsbasiert und in einfachen Objekten. Aber wenn Sie sich Anfängerprojekte (und sogar einige Projekte für Fortgeschrittene) ansehen, werden Sie feststellen, dass Unity auch die dritte Art der Interpretation einer Spielwelt ermöglicht: die prozedurale Programmierung.
  In Unity ist jedes Objekt immer Teil einer "Szene". Anders als in Godot beschreibt dieser Begriff einen Top-Level-Teil des Spiels (Haftungsausschluss: Unity hat jetzt einen SceneManager, der über den Szenen sitzt, aber mein Punkt ist immer noch gültig), was bedeutet, dass ein Feind, wenn er auf den Spieler schießen möchte, es einfach tun kann Durchsuchen Sie die aktuelle Szene nach dem Spieler und interagieren Sie mit ihm. Das ist die Kernidee der prozeduralen Programmierung – Sie haben eine Folge von Befehlen, die den Zustand der Umgebung ohne Rücksicht auf den Besitz verändern. Technisch gesehen ist es natürlich immer noch objektorientierte Programmierung, aber da jedes Objekt davon ausgehen kann, Teil derselben Szene zu sein, sind Sie in der Lage, Code zu schreiben, der sich wie globaler Code verhält. Wenn Sie beispielsweise ein Objekt instanziieren möchten, müssen Sie nur "Instantiate(templateObject)" aufrufen, und eine Kopie des templateObject wird instanziiert und der Szene hinzugefügt. Sie brauchen nicht zu fragen, zu welcher Szene das Objekt hinzugefügt werden soll, da es immer die eine Szene gibt, zu der alles gerade gehört.
  Unity fördert also eine Mischung aus Komposition, objektorientiertem Denken und prozeduraler Programmierung.

Godot hingegen fördert objektorientiertes Denken, da beispielsweise jedes einzelne Objekt in Ihrem Spiel als eigene Szene gebaut werden kann. Diese Szenen können von selbst gestartet werden, was es Ihnen ermöglicht, sie zu testen, sie selbst zu ändern usw. Das wiederum erfordert, dass Sie diese Szenen so erstellen, dass kein Zugriff auf die Umgebung erforderlich ist. Wenn beispielsweise ein Feind mit dem Spieler interagieren möchte, ist es viel praktikabler, Signale zu verwenden, um der zugrunde liegenden Szene mitzuteilen, dass eine Interaktion angefordert wird, oder einfach die Szene aufzufordern, dem Feind einen Hinweis auf den Spieler zu geben. Sie können die Spielszene immer noch nach dem Spieler durchsuchen, aber wenn Sie dies tun, wird die feindliche Szene nicht in der Lage sein, alleine zu laufen, so dass das Design einfach auch nicht zu den Tools passt.

Wie wirkt sich das auf die Wahl der Skriptsprachen aus?
C# ist für Sprachen, was Unity für Engines ist. Die Philosophie von C# war schon immer, dass, wenn ein Feature nett wäre, es in die Sprache aufgenommen würde. Sehen Sie sich einfach die Liste der Funktionen an, die mit jeder Version hinzugefügt wurden: https://en.wikipedia.org/wiki/C_Sharp_ (programming_language)#Features_added_in_versions
Jetzt können Sie argumentieren, dass es nichts Schlechtes ist, ein Feature zu haben, oder? Sie müssen es nicht verwenden, lassen Sie es einfach, wenn es Ihnen nicht gefällt. Leider gilt das nicht für eine Sprache. Mit der heutigen Bedeutung des Internets sind Sprachen keine Werkzeuge mehr, sie sind Kulturen. Früher oder später müssen Sie nach Hilfe googeln, Sie werden Module oder Objekte verwenden, die von anderen erstellt wurden, Sie werden neue Funktionen verwenden, die von der Community in die Engine eingebaut wurden, und früher oder später wird dies erfordern, dass Sie Sprachfunktionen verwenden, die Sie nie beabsichtigt hatten benutzen.
Auch wenn Sie in einem Team arbeiten, werden Sie es zu schätzen lernen, eine Sprache zu verwenden, die einen gemeinsamen Programmierstil fördert und Ihnen nicht Dutzende von Möglichkeiten bietet, denselben Code zu schreiben.

Jetzt fragen Sie sich vielleicht, ob ich damit sagen will, dass eine Sprache mit weniger Merkmalen immer besser ist als eine mit mehr Merkmalen. Natürlich ist das nicht der Fall. Vergleichen wir, wie Java das Problem gelöst hat.
Mit C# können Sie nicht verwalteten Code schreiben. Verwenden Sie einfach das entsprechende Schlüsselwort und Sie können es direkt in derselben Datei verwenden. Außerdem können Sie mit LINQ Funktionscode schreiben, der sich wie SQL-Code liest und sich wie Funktionscode verhält. Um vollständig zu verstehen, was eine Datei tut, müssen Sie möglicherweise ziemlich viel über Programmierparadigmen wissen.
Wenn Sie Java schreiben, können Sie auch funktionale Programmierung verwenden, Sie müssen es nur in eine separate Datei schreiben, einen anderen Compiler verwenden und es "Clojure programmieren" nennen. Wenn Sie es vorziehen, objektorientierte und funktionale Programmierung zu kombinieren, können Sie es "Programmierung von Scala" nennen. Der wichtige Teil ist, dass Sie immer noch Code für die JVM schreiben, der problemlos mit Code aus anderen JVM-Sprachen interagieren kann.
Die .NET-Sprachen haben die gleiche Fähigkeit, es wird nur nicht in der C#-Philosophie verwendet. Sie hätten genauso gut entscheiden können, sich an ein oder zwei Programmierparadigmen in C# zu halten und eine neue Sprache zu erstellen, um neue Paradigmen hinzuzufügen, aber stattdessen haben sie sich für „eine Sprache, um sie alle zu erobern“ entschieden – was völlig in Ordnung ist, es ist großartig, es zu haben so eine sprache. Sie sollten sich nur dieser Philosophie und der Wahlmöglichkeiten bewusst sein, die Sie als Programmierer haben.

Lange Rede kurzer Sinn: Von allen Sprachen, die wir haben, ist C# meiner Meinung nach am schlechtesten für Godot geeignet. Es passt natürlich zu Unity, aber wenn Sie all diese Optionen haben, warum sollten Sie dann eine Sprache wählen, die das Mischen und Anpassen von Paradigmen in einer Engine fördert, die saubere OO-Prinzipien und KISS-Programmierung in jedem anderen ihrer Teile fördert?

Wenn Sie also denken, dass C# eine nette Ergänzung zu Godot wäre, widerspreche ich Ihnen NICHT - ich sage nur, dass es noch bessere Alternativen gibt, die zuerst evaluiert werden sollten und die sofort vergessen würden, sobald C# implementiert ist.

@hubbyist

Das Hinzufügen weiterer Funktionen zu GDscript wäre meiner Meinung nach ein besserer Weg, um an das Skripting heranzugehen

Das kann sicher passieren, ich denke nicht, dass es mit den anderen Vorschlägen unvereinbar ist.

Für mich ist der Hauptgrund, Godot gegenüber anderen Spiel-Engines zu wählen, das vereinfachte Skriptschema. Godot bietet nicht an, eine neue Programmiersprache zu lernen. Es bietet an, Godot und seine Skriptsprache als kombiniertes Tool für die Spieleentwicklung zu lernen. Dies ist ein weniger einschüchternder Ansatz, als Neueinsteigern das Erlernen von C++ oder einer anderen Programmiersprache für die Skripterstellung anzubieten.

Aber Godot kann bereits von C++ aus verwendet werden, also würde sich nichts wirklich ändern (vorausgesetzt, GDScript wird beibehalten), außer dass das Codieren in C++ für diejenigen, die dies tun möchten, einfacher wird (derzeit erfordert das Schreiben von Modulen das Kompilieren von Godot vollständig, und es ist nicht integriert in den Arbeitsablauf).

@Warlaan schöne Analyse. Wenn Sie meinen Beitrag lesen, bin auch ich anderer Meinung, dass C# eine gute Wahl für Godot ist, deshalb habe ich vorgeschlagen, die bereits vorhandenen C++-Fähigkeiten zu erweitern, um es möglich zu machen, es als Skriptsprache zu verwenden, wobei GDScript die Standardsprache für die meisten Benutzer bleibt.

Benutzer sollten in der Lage sein, ziemlich viel in GDScript zu schreiben, aber es ist unvernünftig zu glauben, dass ein großes Spiel in GDScript geschrieben werden würde. Meiner Meinung nach spricht außer der GDScript-Leistung nichts dagegen, dass Godot für große Spiele geeignet ist, denn die Engine ist sehr gut konzipiert und hat bereits eine ziemlich gute Leistung (und Vulkan wird sie wahrscheinlich noch besser machen).

Meiner Meinung nach spricht die Leistung die meisten Godot-Benutzer nicht an, aber sie könnte mehr Profis zu Godot bringen, was mehr Beiträge bedeutet, was ein besseres Godot für alle bedeutet.

@paper-pauper Ich habe verstanden, dass wir auf derselben Seite stehen. Als ich schrieb „wenn Sie denken, dass C# eine nette Ergänzung wäre“, habe ich „Sie, den anonymen Leser“ angesprochen, nicht Sie persönlich. ;-)
Und ja, jede neue Skriptsprache wird GDScript die Aufmerksamkeit entziehen. Ich bezweifle, dass sich die Community um mehr als eine Sprache kümmern wird, früher oder später werden einige Funktionen von beiden nicht verfügbar oder kaputt sein, vielleicht sogar bis zu dem Punkt, an dem eine der Sprachen wegfällt.

Ich stimme auch zu, dass die einzigen wirklichen Probleme hier die Kompilierzeiten von C++ und die Leistung von GDScript sind.
Das Argument, dass die Leute C# bereits kannten, ist meiner Meinung nach einfach falsch. Ich arbeite jetzt seit ungefähr 4 Jahren professionell mit C# (hauptsächlich mit C++ und SQL) und das einzige, was ich in dieser Zeit gelernt habe, ist, dass ich höchstwahrscheinlich nie sagen kann, dass ich diese Sprache wirklich beherrsche. Immerhin wächst mit C# 6 und den Vorschlägen für 7 die Anzahl der Features noch.
Wenn wir also davon sprechen, C# zu kennen, können wir uns eigentlich nur darauf beziehen, die grundlegendste Syntax zu kennen, die selbst der schlechteste Anfänger in ein paar Tagen wieder lernen sollte. Ich habe kürzlich vor einer Klasse von Spieledesignern, die zuvor ausschließlich Unity verwendet haben, einen Vortrag über verschiedene Spiele-Engines gehalten, und keiner von ihnen hat die Syntax von GDScript schlecht kommentiert, während tatsächlich einige, die das Programmieren aufgegeben hatten, jetzt wieder motiviert sind.

Also ja, eine Lösung, die GDScript beschleunigt und C++ weniger umständlich zu kompilieren und zu verwenden macht, wäre auch mein Favorit.

Viele Leute, die C# "kennen", verwenden viele seiner Funktionen nicht, die es von Java unterscheiden. Werfen Sie einfach einen Blick auf die unzähligen Unity-Skripte, die nicht viel weiter gehen als Unterklassen.

Allein aus diesem Grund bin ich sehr skeptisch, was die praktischen Vorteile von C# angeht. Sie sind in vielen Kontexten nett, nur nicht in der Spieleentwicklung. Außerdem bietet C++1x bereits viele dieser Dinge (einschließlich Typinferenz, Iteratoren und einige grundlegende Funktionswerkzeuge) ohne Overhead.

Außerdem ist es möglich, dass der von der CLR (oder sogar der JVM) verursachte Overhead dazu führen könnte, dass Godot _schlechter_ abschneidet, obwohl ich einige Vorteile in der Verwendung des Garbage Collectors der JVM sehe (weiß jemand mehr über Godots Speicherverwaltung)?

Ich habe in Foren von Leuten gelesen, die Godot wegen GDScript nicht verwenden. Ich denke, das ist engstirnig, weil daran nichts auszusetzen ist, außer der Tatsache, dass es eine schlechte Auswahl an Bibliotheken gibt, was ich in einem anderen Ticket, Nr. 3943, anzugehen versuchte, indem ich eine Lösung vorschlug, die keinen Overhead hat und plattformübergreifend ist Unterstützung.

Ohne ein C++ JIT über LLVM implementieren zu müssen, gibt es eine Lösung, die auf nativem Code läuft und kein Hantieren mit Godots Quellen erfordert: dynamisches Linken.

Die erste würde nativen Code ermöglichen, ohne Godot von Grund auf neu kompilieren zu müssen: Sie kompilieren es einfach als .so-Datei und fügen es dann Ihrem Ladepfad hinzu und verwenden es dann ohne Overhead aus GDScript (da es sich nur um Funktionsaufrufe handelt).

Dies sollte sehr einfach sein (über libdl?), Aber soweit ich verstanden habe, wird dies aufgrund plattformübergreifender Bedenken nicht getan.

Außerdem gibt es die Idee, GDScript in C++ zu kompilieren, ähnlich wie es ENIGMA mit seiner Sprache tut. Das ist nicht einfach, bietet aber offensichtlich beste Performance.

Weiß jemand mehr über Godots Speicherverwaltung?

Aus den Dokumenten :

Wenn eine Klasse von Reference erbt, werden Instanzen freigegeben, wenn sie nicht mehr verwendet werden. Es gibt keinen Garbage Collector, nur eine einfache Referenzzählung. Standardmäßig erweitern alle Klassen, die keine Vererbung definieren, Reference. Wenn dies nicht erwünscht ist, muss eine Klasse Object manuell erben und instance.free() aufrufen. Um Referenzzyklen zu vermeiden, die nicht freigegeben werden können, wird eine Weakref-Funktion zum Erstellen schwacher Referenzen bereitgestellt.

Nur zur Anmerkung...

Ein großer Vorteil von GDscript ist, dass es sich um eine Sprache handelt, die vollständig unter der Kontrolle von Reduz und den anderen Entwicklern steht, wie sie für Godot-Entwickler funktioniert, nicht von einem externen Team abhängig ist und daher auf eine spezifische Weise entwickelt werden kann Motordesign und haben, was die Benutzer anfordern.

Eine andere Sache ist, dass, obwohl GDscript derzeit keine wirkliche Hochleistungssprache ist, es wahrscheinlich viele Bereiche gibt, in denen die Leistung erheblich verbessert werden kann, während die Einfachheit und dynamische Typisierung beibehalten werden.

Dann ist da noch die Tatsache, dass GDscript keinerlei Kompilierkenntnisse erfordert und dass Sie nichts außer Godots eingebautem Editor benötigen (was den Arbeitsablauf schön und ordentlich macht, ganz zu schweigen von einfach und schnell).

Nur eine Frage, wie funktioniert der GDscript-Interpreter intern? Analysieren Sie jede Zeile zur Laufzeit wie in der alten Basic-Sprache oder konvertieren Sie das gesamte Skript in eine Bytecode-Tabelle und führen Sie dann den Bytecode aus?

@RebelliousX

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

Ich glaube, es gibt keine ernsthaften Sprachen mehr, die wie BASIC funktionieren! :)

Hallo!
Hier ist die Geschichte von GDScript:
//////////////////////////
Geschichte
Ursprünglich wurde Godot entwickelt, um mehrere Skriptsprachen zu unterstützen (diese Fähigkeit besteht noch heute). Derzeit wird jedoch nur GDScript verwendet. Dahinter steckt eine kleine Vorgeschichte.

In den frühen Tagen verwendete die Engine die Skriptsprache Lua. Lua ist schnell, aber das Erstellen von Bindungen an ein objektorientiertes System (unter Verwendung von Fallbacks) war komplex und langsam und erforderte eine enorme Menge an Code. Nach einigen Experimenten mit Python erwies es sich auch als schwierig einzubetten.

Die letzte Skriptsprache von Drittanbietern, die für ausgelieferte Spiele verwendet wurde, war Squirrel, aber sie wurde auch fallen gelassen. An diesem Punkt wurde deutlich, dass Godot durch die Verwendung einer integrierten Skriptsprache optimaler funktionieren würde, da die folgenden Barrieren erfüllt waren:

• Godot bettet Skripte in Knoten ein, die meisten Sprachen sind nicht darauf ausgelegt.
• Godot verwendet mehrere eingebaute Datentypen für 2D- und 3D-Mathematik, Skriptsprachen bieten dies nicht und ihre Bindung ist ineffizient.
• Godot verwendet Threads stark zum Heben und Initialisieren von Daten aus dem Netz oder von der Festplatte, Skriptinterpreter für gängige Sprachen sind dafür nicht geeignet.
• Godot hat bereits ein Speicherverwaltungsmodell für Ressourcen, die meisten Skriptsprachen stellen ihre eigenen bereit, was zu doppeltem Aufwand und Fehlern führte.
• Bindungscode ist immer chaotisch und führt zu mehreren Fehlerpunkten, unerwarteten Fehlern und allgemeiner Unwartbarkeit.

Schließlich wurde GDScript als benutzerdefinierte Lösung geschrieben. Die Sprache und der Interpreter dafür waren kleiner als der verbindliche Code selbst für Lua und Squirrel und genauso funktional. Mit der Zeit hat sich eine eingebaute Sprache als großer Vorteil erwiesen
////////////////////////

Meiner Meinung nach kann c++ am besten sein. Es gibt einige Lösungen wie:
https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledCPlusPlus
Sogar ein Angel-Skript kann normalerweise wie eine Laufzeitumgebung kompiliert werden.
Bei der Skripterstellung liebe ich Python, weil ich immer Lösungen liebe, die Spiele und wissenschaftliche Simulationen mischen (Python hat viele wissenschaftliche Bibliotheken). Also reklamiere ich! in einer anderen Ausgabe, warum Godot eine eigene Physikbibliothek hat: https://github.com/godotengine/godot/issues/4217
Es gibt einige Probleme mit Sprachen wie C#: https://github.com/godotengine/godot/issues/2790

Netter Fund, @alabd14313 - das würde so ziemlich die meisten Probleme lösen, während GDScript in Ruhe gelassen wird.

Über RCCPP ist es eine sehr gute Idee. Ich denke, wenn Godot es im Editor-Modus unterstützen und dann in Builds deaktivieren würde, wäre die maximale Leistung gegeben und die Iterationszeiten wären ziemlich schnell. Ich habe gehört, dass andere Engines wie die Unreal Engine etwas Ähnliches mit C++ machen, und ich denke, es wäre ziemlich nett, wenn Godot eine nahtlose Skript-ähnliche C++-Codierung erlauben würde.

Es scheint, dass die Autoren ihr Handwerk verstehen, denn auf dieser Seite haben sie die meisten Alternativen zu ihrem Ansatz aufgelistet (einschließlich der von mir erwähnten, dem LLVM JIT).

Ich denke, dieser Ansatz ist am sinnvollsten, weil Godot in C++ geschrieben ist (und ich glaube nicht, dass sich das jemals ändern wird, wenn man bedenkt, dass C++ in ein paar Jahren noch besser sein wird), es hat bereits eine funktionierende C++ API und C++ hat so ziemlich die maximal wünschenswerte Leistung bei null Overhead und es gäbe keine zusätzlichen Laufzeiten oder Speichermanager. Ich hoffe die Entwickler schauen sich das an.

Ich bin etwas überrascht, dass dieser Thread, der afaik als Reaktion auf den Vorschlag, C# als Skriptsprache hinzuzufügen, gestartet wurde, noch kein einziges Argument FÜR C# enthält, selbst nachdem sechs Personen ihre Meinung geäußert haben.
Vielleicht ist die Entscheidung, C# hinzuzufügen, nicht so vorsätzlich, wie ich aufgrund der Gerüchte, die ich gehört habe, angenommen habe.

@Warlaan , was passiert, wenn du diese URL in der Facebook-Gruppe postest? :)

Bitte ändern Sie den Titel in etwas wie "C++ als Skriptsprache".
C++17 hat mehr Funktionen:
http://blog.mattnewport.com/warum-c17-die-neue-programmiersprache-fur-spiele-ist-die-ich-will/
Ich bewundere Godot-Entwickler und danke ihnen für ihre Arbeit. aber ich wehre mich gegen Box2D/LiquidFun/Bullet-Bibliotheken. Auf diese Weise können sich Entwickler auf die Pipeline konzentrieren und nicht auf Komponenten wie Physik. Mit C++ können sie sich auf die Leistung konzentrieren, anstatt gdscript zu warten und zu aktualisieren. Theoretisch kann RCCPP einige neue Funktionen wie den Werkzeugmodus besser implementieren. Vielleicht...

@reduz erwähnte vor einigen Monaten, dass er visuelles Skripting implementieren möchte, so etwas wie unwirkliche Blaupausen. Mit RCCPP kann der Workflow zwischen C++ (für Programmierer) und Visualscripting (für Level Designer und Künstler) wie folgt implementiert werden:
Einführung in die C++-Programmierung in UE4
C++ und Blaupausen
So können Programmierer in einer Gruppe neue Blueprint-Klassen für Künstler entwickeln und Künstler diese verwenden, anstatt direkt zu codieren.

@Warlaan IMHO liegt es daran, dass ein Großteil des C#-Gesprächs von Leuten angeheizt wurde, die wollen, dass Godot eine Abzocke von Unity ist, aber zum Glück erkennen viele hier, dass Godot sein eigenes Ding ist und Unity in vielerlei Hinsicht bereits voraus ist, und es wäre nicht fair um es von den gleichen Problemen beeinflussen zu lassen.

@alabd14313 Ich würde den Titel ändern, aber vielleicht ist es besser, eine separate Ausgabe zu erstellen und diese für die Nachwelt aufzubewahren, damit sie verlinkt werden kann, wenn jemand C# vorschlägt (wie es oft der Fall ist).

Ehrlich gesagt zögere ich mit dem visuellen Scripting, aber wenn es als Modul implementiert werden kann, warum nicht? Natürlich denke ich, dass das Vorhandensein von Visual Scripting (Designer und Neulinge), GDScript (Leute, die programmieren können oder bereit sind, es zu lernen) und C++ (Programmierer) Godot zu einem ziemlich ausgewogenen Programm machen würde, das für alle Erfahrungsstufen geeignet ist, aber die C++-Codierung weniger machen würde Umständlicher und einfacher zu gestaltende Schnittstellen zu Bibliotheken von Drittanbietern sollten meiner Meinung nach eine höhere Priorität haben, da sie viele professionelle Benutzer (und folglich Mitwirkende) anziehen können.

Imho Visual Scripting ist bei weitem nicht raffiniert genug, um Sinn zu machen. Es ist großartig für Marketing und Anfänger zum Programmieren zu bringen, aber aus meiner Erfahrung ist die Lernphase, in der Anfänger Flussdiagramme bevorzugen, sehr kurz.
Für alles andere als die einfachsten Ruffolgen sind die mir bekannten Systeme (Unreal, Cryengine, Fungus, Stingray) einfach nicht hilfreich. Ich meine, dieser Screenshot stammt zum Beispiel aus dem offiziellen Werbevideo der Stingray-Engine. Das nenne ich Spaghetti-Code. Und die offiziellen Beispiele in der Cry-Engine sehen auch nicht besser aus, auch wenn man an der Menge der Kommentarelemente erkennen kann, dass man sich viel Mühe gegeben hat, den Graphen lesbar zu machen bzw. zu versuchen.
Wenn Sie denken, dass das nicht so schlimm ist, möchte ich Sie daran erinnern, dass jede Verbindungslinie, die außerhalb des Bildschirms beginnt, eine Variable mit einem (hoffentlich) aussagekräftigen Namen wäre, wenn Sie diesen Code in einer textbasierten Sprache sehen würden.

Flowgraphs sind etwas hilfreich, wenn es um Shader/Materialien geht, da zwar Zwischenergebnisse angezeigt werden können, aber auch dort leidet das System stark darunter, dass eine kurze Gleichung gefällt
Float x = (ab)*(a+b)/(1-(a+b))
füllt leicht einen ganzen Bildschirm, wenn es als Diagramm ausgeführt wird, da jede Multiplikation, Summe oder Differenz ein Knoten mit zwei Eingängen und einem Ausgang ist. Das sind mindestens 10 Knoten für die obige Formel, und wenn Sie kein Verbindungschaos verursachen wollen, müssen Sie die a- und b-Knoten duplizieren.

Die Flussdiagrammsysteme, die wir heute haben (zumindest die, die ich kenne), nehmen die Option weg, Werten aussagekräftige Namen zu geben, denn anstatt ein Ergebnis in eine benannte Zwischenvariable zu stecken, verbinden Sie es einfach mit dem nächsten Knoten. Das macht selbstdokumentierenden Code fast unmöglich und erfordert viel mehr Aufwand in die Dokumentation.
Was diese Systeme hinzufügen, ist die Option, Knoten zu platzieren, wo immer Sie möchten, was meiner Erfahrung nach eher zu weniger lesbarem Code führt als zu einem, der leichter zu lesen ist.

Und bitte sprechen Sie nicht über Flussdiagramme, als ob sie nicht codieren würden. Sie sind genauso viel Codierung wie jede andere Programmiersprache. Sie tippen nicht, das ist alles.

Visual Scripting ist für Designer und Künstler gedacht, um Änderungen vorzunehmen, ohne Programmieren lernen zu müssen. Einige Künstler sind auch in der Lage, einfache interaktive Spiele damit zu machen. Es hat sein Ziel, wo es definitiv nützlich ist, es ist nur nichts für Programmierer.

@Warlaan Nun, es hängt davon ab, wie Sie "Programmierung" definieren. Sicherlich ist Visual Scripting mit der Definition von Algorithmen verwandt, also ist es nicht weit vom Programmieren entfernt, aber beim Programmieren geht es auch um andere Dinge.

Es gibt jedoch einige gute Implementierungen der visuellen Programmierung. PureData ist eines und es gibt auch GDevelop , ein ziemlich gutes Programm zum Erstellen von FLOSS-Spielen (schade, dass es nicht beliebter ist). Kurz gesagt, obwohl ich es persönlich nicht mag (aus einigen der von Ihnen genannten Gründe), ist es auch wahr, dass wir beide programmieren können, daher ist visuelles Programmieren für uns eine langsame und umständliche Methode, um vergleichbar schlechte Ergebnisse zu erzielen.

Trotzdem stimme ich @reduz zu, dass einige Leute darin einen Appell sehen. Sie sind nicht die Leute, die solche Threads herumhängen würden, aber sie machen auch Spiele. Ich denke, sie könnten Godot etwas bringen.

Der Grund, warum Flussdiagramme gut für die Shader-Bearbeitung funktionieren, ist, dass sie sehr visuell sind (Sie haben Knoten, mit denen Sie Bilder laden, Farben auswählen usw. können, ohne die Dateipfade und Werte manuell einzugeben). Sie haben auch absolut keine Angst, auf die korrekte Syntax und die korrekte Schreibweise von Funktionen zu achten. Es ist auch nicht nötig, sich so komplexe Aufgaben wie das Arbeiten mit einer Matrix auszudenken (es wird alles für Sie berechnet).

Godots Methodik für die Shader-Bearbeitung erweist sich als guter Ansatz, da sie die Vertex-, Fragment- und Lichtkomponenten sauber trennt und auch eine klare Anleitung dazu gibt, mit welcher Art von Daten Sie arbeiten (ob es sich um normale Informationen oder Kamerainformationen handelt).

Jetzt mit dem visuellen Scripting denke ich, dass es sogar für mäßig komplexe Dinge nützlich sein könnte, wenn die Knoten in Bezug auf die Spielmechanik auf einem ausreichend hohen Niveau sind (sie machen komplexere Dinge und haben mehrere Eingaben) und wenn es Knoten gibt, die das können ermöglichen es Ihnen, ein Skript auszuführen oder einen Ausdruck/eine Gleichung zu erstellen (die wiederum verwendet werden können, um Werte auf komplexe Weise zu manipulieren). Die Probleme, die ich bei anderen visuellen Knotensystemen dieser Art gesehen habe, sind, dass sie versuchen, so nah wie möglich an der wörtlichen Programmierung zu sein (dh eine Reihe von Low-Level-Funktionen als Knoten zu haben, anstatt eher wie eine Knotenversion von zu sein Logikbausteine ​​von Blender oder Drag & Drop von GameMaker).

Sicher, es erlaubt immer noch nicht so etwas Feinkörniges und Fortgeschrittenes wie das, was Sie mit reinem Skripting machen können, aber es hätte immer noch eine Verwendung für Dinge wie einfache Objekttypen innerhalb eines Spiels (die keine sehr komplexe Logik benötigen ) oder wenn Sie mal schnell etwas raushauen müssen.

Ich stimme zu, dass einige Leute einen Reiz darin sehen, und ich stimme auch zu, dass es nichts für Programmierer ist (es sind nur unsere Definitionen von "Programmierer", die sich unterscheiden ;-) ), also schlage ich vor, dass wir die Diskussion dabei belassen, da es etwas vom Thema abweicht.

Ein weiteres nützliches Feature von C++ ist sein statischer Typ. Die Einrichtungen "auto" und "decltype" können den Typ eines Objekts erkennen. Editor und Codevervollständigung können einfacher sein. Anstatt sich auf den internen Code-Editor zu konzentrieren, können wir eine andere externe IDE verwenden. Im Moment denke ich, dass Codelite und qtcreator einen besseren Status bei der Codevervollständigung haben. Codeblocks haben einige Probleme mit c++11-Kewords. Auch eclipse-cdt hat eine gute Codevervollständigung. Ein Plugin für qtcreator ist eine gute Idee (wie unreal-visual studio und Unity-Monodevelop). Externe IDE kann mit einem Systempfad in Godot-Einstellungen (wie /use/bin/qtcreator) identifiziert werden, es muss nicht mit Godot kompiliert und gepackt werden (im Gegensatz zu Unity-Paket mit integriertem Monodevelop).
Es gibt andere Tools wie cppcheck und valgrind, die Plugins in qtcreator haben.
Wenn Sie eine Vorschau dessen haben möchten, was RCCPP ist:
Demo

Ich würde gerne eine C++-basierte Skriptsprache für Godot sehen, aber die Implementierung aller C++-Funktionen wäre umständlich, wie z. B. die Programmierung von Vorlagen. Es muss einige Einschränkungen für diese Art von Skriptsprache (STL) geben, und Vorlagen sollten nicht verwendet werden. Auch RTTI kann Leistungsprobleme verursachen.

Ich liebe GDscript, meine einzige Beschwerde darüber ist die Verschmutzung des Namensraums von Variablen. Beim Umgang mit großen Skripten können Variablendefinitionen vor ready() sehr unordentlich werden und anfällig für Fehler im Code sein, da Variablen zwischen Funktionen derselben Skriptdatei geteilt werden .

Meine 3 Cent. (äh... am Ende waren es 20, aber lass es sein...)

Wie bei @alabd14313 bereits erwähnt, "ist es an dem Punkt, an dem es ist", aufgrund der jahrelangen Entwicklung, die Godot in die heutige Form geführt hat.
Egal ob die Natur dies tut oder wir Menschen, die Korrektur der Dinge zur Zeit der Schöpfung scheint die beste Art der Entwicklung zu sein, und ich muss zugeben, dass ich Godot dank dessen sehr genieße, wie es ist und wo die Evolution es hingebracht hat.

Es hat alle benötigten Teile.

Knoten, die zu komplexeren Objekten kombiniert, als Szene gespeichert und dann als "einfaches" Objekt in einer anderen Szene wiederverwendet werden können, was eine großartige und mega flexible Funktion ist, die wirklich nur durch die eigene Vorstellungskraft und Kreativität des Benutzers begrenzt ist.

Einfach zu bedienendes und zu erlernendes GDScript, leistungsfähig genug, um alle Knoten so zu steuern, wie wir Programmierer es gewohnt sind - durch Eintippen von Codezeilen.
Außerdem geht es schnell und einfach (Code-Vervollständigung / Build-Dokumentation / nützliche Tooltips hier und da) ohne Kompilieren, einfach tippen, ausprobieren, anpassen und wieder bis zur Perfektion polieren.

Die Bereitstellung auf mehreren Plattformen mit WIRKLICH einem Klick (nicht zu erwähnen die Bereitstellung auf Android über WLAN/ADB, Lebensbearbeitung, Debugging usw. ist nur ein Meisterwerk der Kunst, nein ... Es ist mehr, es ist eine Magie!)

Zusätzlich all diese Vertrautheiten mit häufig verwendeten Tools wie Mixer ect.
(Zeug importieren und es funktioniert sofort, alles ist da und wie es sein sollte)

Und schließlich gebe ich zu, dass manchmal sogar extreme Kreativität nicht ausreicht, wenn es darum geht, etwas millionenfach in einer Schleife zu machen und in 1 Frame zu passen. Hier kommt C-Zeug ins Spiel. Wenn Sie C kennen, es brauchen, hindert Sie nichts daran, Plugins, eigene benutzerdefinierte Knoten usw. zu erstellen, die genau das tun, was Sie möchten.

Es hat fast alles, und mit der Zeit, glaube ich, wird es alles haben.
(Gemeint sind die Dinge, die heute "noch nicht implementiert" sind und die man "irgendwie" oder "mit bloßen Händen" erledigen muss (sprich: externes Tool dafür verwenden) z )

Godot ist erstaunlich und ein magisches Ding, perfekt auf seinem Weg, wohin es geht.Benötigt hier und da Anpassungen und Ergänzungen, aber das war's.

Visuelles Scripting?
äh. Es könnte uns Programmierer dazu zwingen, die Denkweise "ein wenig" auf ungewöhnliche Weise zu ändern, und ich glaube nicht, dass es so flexibel und lesbar sein kann wie normaler Code.
Stellen Sie sich vor, Sie codieren und haben eine einfache Zeile wie diese ( abc / def ) * ghi
dann der schnelle Weg, wie üblich (?) um Tipparbeit zu sparen, Sie markieren einen Teil von etwas, fügen hier ein, schneiden dort aus, fügen erneut ein und in 5 Sekunden und fünf Tastendrücken landen Sie bei "einfach" (weil Sie wissen, was es tut) einzeilig wie ((((abc/def+((abc/def)_ghi^4))_ghi)+(abc/def_(100))_ghi)+abc)
Es ist üblich, vielleicht machen es viele von uns superschnell auf diese Weise.
Stellen Sie sich nun vor, es auf visuelle Weise zu tun ...
Es könnte den ganzen Bildschirm und viel Mausarbeit erfordern, und es würde nicht so gut lesbar aussehen, wie es sollte.
(Natürlich sieht so ein Liner auch nach einem Jahr nicht einfach aus aber dafür sind Kommentare da)

Was, wenn jemand 100 solcher Zeilen untereinander hat?
Visuell könnte er einen Fußballplatz bekommen, um es zu zeigen. Was ist mit Analysieren, Ändern, das ist ein Durcheinander und große Kopfschmerzen.
Natürlich können Programmierer dies tun, weil es keine Sprache ist, die jemanden zum Programmierer macht, sondern eine bestimmte Denkweise, die Algorithmen erstellt, Daten als kleine Teile und als Ganzes manipuliert.
Die Sprache, egal ob C, Python, PHP, Java oder Visual Scripting, ist nur ein Werkzeug, um die Gedanken aufzuschreiben.
Und hier, meiner Meinung nach, ist das normale Tippen mit der Tastatur die schnellste und lesbarste Form, um es aufzuschreiben.
Auf der anderen Seite: Wenn jemand nicht programmieren kann, erwarten Sie, dass er plötzlich algorithmisches Genie und Wahrnehmungsvermögen offenbart, um sich nicht in der eigenen Idee und der visuellen Darstellung davon zu verlieren, wenn man bedenkt, dass wir, wenn wir an Spiel denken, über etwas Komplexeres sprechen als zwei Bälle schlagen? einander mit Physik.

Also für wen wäre Visual Scripting wirklich geeignet?
Um Programmierern das Leben schwerer zu machen oder Godot auf Level zu beschränken - Engine für "einfache Spiele" für Anfänger ?

Leute, in #1220 gibt es eine lange Diskussion über Visual Scripting. Lassen Sie uns hier bitte nicht noch einmal über dieselben Themen diskutieren.

Leute, in #1220 gibt es eine lange Diskussion über Visual Scripting. Lassen Sie uns hier bitte nicht noch einmal über dieselben Themen diskutieren.

Die meisten Beiträge hier waren so lang, dass ich mich vielleicht beim Lesen verloren habe.
Entschuldigung :entspannt:

@RebelliousX Selbst mit RTTI hätte C++ immer noch eine viel bessere Leistung als GDScript. Obwohl es stimmt, dass Vorlagen ein Problem sein könnten.

Die von @reduz in #3936 vorgeschlagene Lösung würde das Codieren in C++ bereits ziemlich trivial machen - Sie tun es einfach mit Ihrem Editor und Compiler Ihrer Wahl und verlinken gegen Godots API. Wenn dies implementiert ist, auch wenn Scripting in C++ nett wäre, wäre es in Bezug auf die Leistung nicht viel anders als das Schreiben von Code in C++ und das anschließende Aufrufen von GDScript. Kurz gesagt, ich denke, die Konzentration auf # 3936 (was eine einfache Lösung ist) würde sich erheblich verbessern:

• Leistung (da das Schreiben von Teilen in C++ extrem einfach wäre)
• Verfügbarkeit von Bibliotheken von Drittanbietern (da Wrapper einfacher verteilt werden können, aber nicht so einfach wie #3943)
• Benutzerbasis und Mitwirkende (viele C++-Programmierer würden Godot übernehmen)

Dann könnte der Fokus auf der statischen Typisierung in GDScript und der Optimierung des Interpreters (über JIT oder durch Kompilieren von GDScript nach C++) liegen, aber dies kann später erfolgen, wenn das Schreiben von Modulen vereinfacht wird.

Ich möchte nur ein paar Punkte erwähnen, die sich in diese Diskussion eingeschlichen haben, aber noch nicht angesprochen wurden:

• Einige von uns sprechen über die Verbesserung des bestehenden Systems (GDScript als Skriptsprache, C++ als Backend-Sprache) durch Erleichterung der C++-Entwicklung und Steigerung der GDScript-Leistung. Andere sprechen davon, C++ (oder Java / C# / ...) als Skriptsprache zu verwenden. Es mag den Anschein haben, als gäbe es keinen wirklichen Unterschied zwischen der Ermöglichung schneller C++-Entwicklung und der Umwandlung in eine Skriptsprache, aber ich erkläre gerne, wie ich die negativen Auswirkungen mächtiger Skriptsprachen auf die Qualität des Spieldesigns erlebt und beobachtet habe. Und wenn dies nicht zum Thema der Diskussion wird, werde ich das gerne in den Foren oder anderswo tun, wo es diesen Thread nicht kapert.
• @RebelliousX : Wenn Sie über "Variablen-Namespace", "große Skripte" und "Variablen zwischen Funktionen gemeinsam nutzen" sprechen, klingt es sehr danach, als hätten Sie die objektorientierte Natur von GDScript nicht vollständig verstanden (nichts für ungut). Jede GDScript-Datei ist eine Klasse, daher sollten Namenskonflikte zwischen (Member-)Variablen genau so oft vorkommen wie in jeder anderen objektorientierten Sprache. Sie teilen keine Variablen zwischen Skripten, Sie schreiben mehrere Funktionen, die auf den Zustand des umgebenden Objekts zugreifen können.

@Warlaan Zum ersten Punkt, denke ich, könntest du hier posten, da er mit dem Thema zusammenhängt.

@Warlaan nichts für ungut genommen. Ich weiß, dass GDscript eine eigene Klasse ist, und ich weiß, dass Variablen wie normale Member-Variablen in der C++-Klasse sind, aber anscheinend haben Sie meinen Punkt völlig verfehlt. Sie werden es verstehen, wenn Sie ein Skript mit mehr als 1000 Codezeilen haben. Was ich will, sind Referenzen oder Zeiger, anstatt Myriaden von Member-Variablen zu erstellen, übergeben Sie sie einfach zwischen Member-Funktionen. So ist es sicherer.

Ich mag C#, aber ich sehe Vor- und Nachteile.

Vorteile:

• Gute Werkzeugunterstützung (Seien wir ehrlich, würden Sie in C# ohne Visual Studio oder MonoDevelop programmieren?)
• Geeignet für Großprojekte
• Weit verbreitet und ausgereift, gibt es unzählige Support-Threads im Internet.
• Gute Leistung, Kompromiss zwischen C++ und Skriptsprachen bei gleichzeitiger Plattformübergreifendkeit
• Relativ einfach an C++ zu binden

Nachteile:

• Müll gesammelt: Große Spielprojekte müssen auch Zuweisungsstrategien implementieren, um zu verhindern, dass GC-Kicks zu oft passieren, das kann unangenehm sein
• Nicht so integriert wie GDScript (Knotenpfadvervollständigung? Skriptmitgliedsvariablen auf Knoten? Speicherzuweisungsmodell?)
• Die Laufzeit ist schwer und das .NET-Framework noch mehr. Wie in Unity sollten die Standardbibliotheken auf die von Godot umgestellt werden.
• Nicht die beste Lösung für das eigentliche Skripting, in dem Sinne, dass Dinge schnell und schmutzig erledigt werden. C# ist ausführlicher und restriktiver als GDScript.
• Noch keine Richtlinien bezüglich Godot-Entwicklung. Die Sprache ist generisch und kann viele Dinge tun, und wie Warlaan sagte, haben Entwickler unterschiedliche Kulturen (Sie könnten buchstäblich einen WPF-Codierer haben, der Godot ausprobiert und sich fragt, warum es keine MVVM-Möglichkeit gibt, GUIs zu erstellen: p)

Das meiste davon gilt auch für Java.
Vielleicht habe ich andere Dinge vergessen, weil es hier spät ist.

Ok, das ist meine Erfahrung bezüglich funktionsreicher Skriptsprachen bzw. ein völliges Fehlen einer Skriptsprache, abhängig von Ihrer Definition von "Skriptsprache". Ich werde versuchen, es kurz zu halten. ;-)

Ich arbeite seit einigen Jahren als Dekan für Technik an der School4Games in Berlin, Deutschland. An dieser Schule haben wir keine Fakultät für „reines“ Gamedesign, aber unser Gamedesign-Kurs heißt „Game Development“ und enthält genügend Programmierstunden, um Gamedesignern beizubringen, wie sie ihre eigenen Prototypen entwickeln und die Möglichkeiten und Grenzen verstehen der Hardware und gängigen Softwarearchitekturen.
Die Studenten, die ich unterrichte, sind also Leute, die manchmal ein erhöhtes Interesse am Programmieren haben, aber keiner von ihnen hat sich als Programmierer beworben.
Jedes Semester müssen sie Teams bilden und ein Spiel entwickeln. Da fast alle potenziellen zukünftigen Arbeitgeber unserer Studenten Unity verwenden, war es eine Voraussetzung für die ersten zwei Semester, mit dieser Engine zu arbeiten.

Kommen wir nun zur Wirkung von Skriptsprachen:
Diese Schüler teilten sich in zwei Gruppen auf. Eine, die entweder versucht, das Programmieren zu vermeiden oder die Hoffnung verloren hat (was bedeutet, dass sie an Programmierkursen teilnehmen, aber nicht um Hilfe bitten, wenn sie in Schwierigkeiten geraten, sondern stillschweigend aufgeben) und eine, die so tief in die Programmierung eintaucht, dass sie direkt zu Themen überspringt, die das tun Normalerweise würden Sie sich beim Schreiben von Spielprototypen nicht darum kümmern. Zum Beispiel hat einer meiner Studenten aus dem ersten Semester kürzlich ein Tutorial veröffentlicht, wie man ein Singleton in C# mithilfe von Generika schreibt, damit Sie eine Unity-Komponentenklasse in ein Singleton verwandeln können, indem Sie von der generischen Klasse aus dem Tutorial erben. Das Interessante ist nicht so sehr, dass er diesen Artikel schreiben konnte, schließlich bekam er natürlich Hilfe von seinen Lehrern und es gibt ziemlich viele Ressourcen zu diesem Thema im Internet. Der interessante Punkt ist, dass ein Student, der sich für einen Kurs beworben hat, der sich hauptsächlich auf Spieldesign und nicht auf Programmieren konzentriert, an einem so spezifischen Programmierthema interessiert wäre. Der Code aus diesem Tutorial wird sich nie aufgrund von Änderungen im Spieldesign ändern, es ist ein reines Programmierkonstrukt.
Etwas Ähnliches geschah mit einem anderen Schüler, der eine ähnliche Klasse benutzte, um Informationen von einer Spielszene zu einer anderen zu transportieren. Er war ziemlich überrascht, als ich ihm zeigte, dass er dasselbe mit einem öffentlichen statischen Mitglied machen könnte, was zeigt, dass er nach vollständigen, komplizierten Lösungen suchte, bevor er alle grundlegenden Elemente darin vollständig verstanden hatte.

Wenn Sie also weiter vorn gesprungen sind, fasst dies den bisherigen Text zusammen: Während es möglich ist, einfachen Code in funktionsreichen Sprachen zu schreiben, habe ich mehrmals beobachtet, dass Menschen einfache Lösungen wahrscheinlich ablehnen, wenn es komplizierte Alternativen gibt.

Das liegt nicht nur an Vorurteilen. Sicher, das ist wahrscheinlich ein Faktor. Wenn Sie sehen, dass der Code in Tutorials, Beispielen oder anderen Klassen in Ihrem Projekt kompliziert aussieht, können Sie daraus schließen, dass Ihr Code auch kompliziert aussehen sollte. Aber ich denke, der wahre Grund ist, dass es beim Programmieren sinnvoll ist, zu versuchen, Code zu erstellen, der fehlersicher ist. Es ist ein natürlicher Wunsch, Code zu schreiben, der nicht kaputt geht, sobald er an einer anderen Stelle verwendet wird oder sobald er andere Eingaben erhält. Und das erfordert, dass Sie herausfinden, welche Optionen es gibt, auf die Sie sich möglicherweise vorbereiten müssen.
Ich denke, dieses Gefühl, alle Eventualitäten prüfen zu müssen, trennt meine Schüler in diejenigen, die in der riesigen Anzahl von Funktionen von C# ertrinken, und diejenigen, die sofort loslegen und den Fokus auf die Sprache verlieren.

Zylann erwähnte den Ausdruck „quick and dirty“. Wir verwenden diese beiden Begriffe oft als Phrase, aber wenn Sie darüber nachdenken, sind das eigentlich zwei verschiedene Faktoren. Ob es möglich ist, schnell zu codieren, ist durchaus messbar. Ob der resultierende Code andererseits schmutzig ist oder nicht, hängt von vielen Faktoren ab, der wichtigste ist die Anzahl der Funktionen, die die verwendete Sprache hat.
Beispielsweise ist das Erstellen eines Knotens der obersten Ebene und dessen Verwendung als Singleton in Godot völlig in Ordnung, da GDScript nicht die Funktionen bietet, die zum Implementieren des Musters auf die gleiche Weise erforderlich sind, wie Sie es in Sprachen wie C# tun würden. Sicher, die Verwendung der Autoload-Funktion wäre besser, da dies der erste Ort ist, an dem andere Entwickler nach Singletons suchen würden (und die Syntax ein wenig schöner wird), aber wenn ein Team beschließt, es auf diese Weise zu implementieren, bezweifle ich, dass es viel davon geben würde Streit. Stellen Sie sich andererseits vor, dass jemand ein Singleton in Unity implementiert hat, indem er einfach ein öffentliches statisches Mitglied zu einer Klasse hinzugefügt hat. Es ist genauso schnell, in gewisser Weise ist es sogar dasselbe (beide sind Klasseninstanzen an der öffentlichsten Stelle), aber da C# die Option bietet, den Konstruktor privat zu machen, greifen Sie über eine Eigenschaft mit verzögerter Initialisierung usw. auf den Singleton zu erwartet, dass Sie dies tun, sonst wird der Code als sehr schmutzig wahrgenommen, wenn er nicht gebrochen ist.

Nun, die Tatsache, dass Game-Design-Studenten in Themen wie diese eintauchen, mag ein vager Hinweis darauf sein, worum es mir geht, aber ich denke, ich kann es noch besser veranschaulichen, indem ich über die Situation bei meinem ersten Job bei einem großen F2P-MMO-Entwickler spreche. Das Team, dem ich beigetreten bin, ist einer der erfahrensten Spieleentwickler in Deutschland. Deren Entwicklungsleiter baut seit 1995 eigene Motoren im eigenen Haus und obwohl sie gerade von einem anderen Unternehmen gekauft wurden, gehörten sie damals zu den erfolgreichsten Entwicklern.
Als ich dem Team beitrat, verwendeten sie die dritte Version der hauseigenen Engine, die keine Skriptsprache hatte. Sie hatten zuvor eine implementiert, aber in dieser Version der Engine kehrten sie dazu zurück, keine Skriptsprache zu verwenden, da es Probleme mit der Codequalität gab, die die Spieledesigner lieferten. Mit anderen Worten, da die Skriptsprache zu mächtig war, wurde die Entscheidung getroffen, die Barriere zwischen Programmierern und Spieledesignern so weit zu verschieben, dass Spieledesigner nur noch Level bearbeiten und Einstellungen in Konfigurationsblättern ändern, während die Programmierer die gesamte Programmierung übernehmen - im Nachhinein ich bemerkte, dass dies ziemlich die gleiche Situation ist, in der meine Studenten enden (und es scheint, dass viele professionelle Studios, die mit Unity arbeiten, am Ende landen).
Warum sollte es mich interessieren? Wenn das immer wieder vorkommt, beweist das dann nicht, dass es eine erfolgreiche Arbeitsweise ist? Meine Antwort ist nein, denn es gab Probleme, sowohl technische als auch im Spieldesign, die sich leicht dadurch erklären ließen, dass die Kommunikation zwischen Programmierern und Spieledesignern auf das Schreiben von Aufgaben in die eine Richtung und das Offenlegen von Einstellungen in die andere Richtung reduziert wurde. Aus der Sicht der Spieledesigner wurden die Features zu Black Boxes, die aktiviert und deaktiviert werden konnten, aber auf dieser Seite des Teams gab es niemanden, der Alternativen diskutieren oder sogar Prototypen entwickeln konnte.
Die Programmierer hingegen wurden fast automatisch in eine Backend-Mentalität gedrängt. Die „Quick and Dirty“ KISS-Mentalität war vorbei, weil keiner von uns vorhersagen konnte, wie die von uns erstellten Funktionen verwendet werden würden. Ich erinnere mich lebhaft, wie einmal die Datenbank zusammenbrach, weil ein Spieledesigner eine Ostereiersuche implementiert hatte, wodurch die Inventare viel größer wurden als früher. Das war das letzte Mal, dass ich einfach davon ausgegangen bin, dass die Anforderungen an ein Feature wahrscheinlich ungefähr gleich bleiben würden.

Deshalb denke ich, dass es extrem wichtig ist, eine Skriptsprache mit geringem Funktionsumfang als definierten Bereich für Spielcode zu haben, und warum ich denke, dass das Fehlen einer Skriptsprache einen schlechten Einfluss auf das Spieldesign hat.

• Schnellen Code zu schreiben bedeutet, Funktionen zu ignorieren, die ihn in „schnellen und schmutzigen“ Code verwandeln.
• Der Wunsch, sauberen Code zu schreiben, teilt die Entwickler in diejenigen, die nicht programmieren, und diejenigen, die mehr Zeit damit verbringen, über das Codieren nachzudenken, und weniger Zeit mit dem Spiel.
• Das wiederum spaltet das gesamte Team in eine Hälfte, die am Spieldesign arbeitet, ohne die Codebasis zu kennen, und eine, die an Features arbeitet, ohne zu wissen, wie sie verwendet werden, sodass niemand übrig bleibt, der Engine-Features basierend auf dem Spiel entwickeln könnte entwerfen oder schlagen Sie ein Spieldesign vor, das auf Funktionen basiert, die leicht implementiert werden könnten.

Die Spieleentwicklung ist heute ohne den Einsatz vorgefertigter Klassenbibliotheken nicht mehr wegzudenken, schließlich macht das Engines mit Toolsets wie Godot, Unity, Unreal etc. so erfolgreich. Aber der Unterschied zwischen all diesen Engines besteht darin, wo die Grenze zwischen Programmierung und Spieldesign gezogen wird und wie groß die Lücke zwischen den beiden Seiten ist.
Und basierend auf meinen Beobachtungen denke ich, dass die Wahl der Skriptsprache einer der wichtigsten Faktoren ist, die eine solche Lücke schaffen oder schließen können.

Der Grund, warum ich mich übrigens so sehr für Godot engagiert habe, ist, dass ich daran arbeite, es als obligatorische Engine für das erste Semester zu etablieren. Nur damit Sie wissen, dass ich nicht nur rede, sondern auch meine Konsequenzen ziehe. ;-)

@RebelliousX Ich muss zugeben, dass ich immer noch nicht ganz verstehe, worauf du hinauswillst. Aber da Sie gesagt haben, dass Sie Referenzen oder Hinweise wünschen, könnten Sie eine neue Feature-Anfrage öffnen und dort ein Codebeispiel für Ihr Problem posten? Um ehrlich zu sein, klingt es immer noch so, als ob Ihr Problem eher auf der Codearchitektur als auf fehlenden Sprachfunktionen beruht.

Ich hätte hinzufügen sollen, dass KISS hauptsächlich kleinen Teams zugute kommt. Godot ist so funktionsreich, dass ein Entwickler ein Spiel machen kann. Aber sobald ein Projekt mehr Entwickler hat, werden "quick-and-dirty" Dinge unwahrscheinlicher und bleiben für Prototyping oder temporäre Korrekturen übrig, dann müssen Regeln/Richtlinien aufgestellt werden. Es hängt also wirklich davon ab, wer die Engine verwendet und wofür.

Godot im Allgemeinen hat auch mehr Einschränkungen als wir denken. Sie können aus einem bestimmten Grund keine Singletons oder globalen Variablen im "c-static-Stil" erstellen: Speicherlecks und Thread-Freundlichkeit. GDScript ist aus einem bestimmten Grund nicht so gut ausgestattet wie Python: Es konzentriert sich auf Aufgaben und Leistung der Spieleentwicklung. Das Szenensystem ist aus einem bestimmten Grund auch objektorientiert: Sie können unabhängige "Boxen" erstellen, die getestet und wiederverwendet werden können :)

In diesem Thema geht es um das Hinzufügen einer C#- (oder Java-) Modulunterstützung, aber ich sehe keinen Beispielcode. Probieren wir mal spontan was aus :)

using GodotEngine;

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

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

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

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

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

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

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

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

}

Was denkst du?
Diese Datei könnte dann als DLL-Asset kompiliert (oder on-the-fly ausgeführt) werden. Aber wenn wir darüber sprechen, müssten wir ein csproj wie Unity generieren?

@Warlaan danke, dass du deine Erfahrung geteilt hast. Korrigieren Sie mich, wenn ich mich geirrt habe (es war ein langer Beitrag), aber wollen Sie sagen, dass es für die Programmierer besser ist, eine Sprache mit weniger Funktionen anzubieten, damit sie sich auf die Entwicklung ihrer Spiele konzentrieren können, anstatt zu übercodieren?

Wenn ja, ist dies eine sehr subtile Beobachtung. Ich denke, die Godot-Entwickler müssen das Beste für ihre Benutzerbasis tun – sie wissen, was das Beste ist.

Und ich selbst habe mich heute gefragt, ob einige Leute hier (mich eingeschlossen) nicht nur subtil nach Urho3D fragen, während andere nach GDevelop fragen. Godot ist eindeutig ein Mittelklasse-Tool zwischen diesen beiden (aber perfekt geeignet für Profis, eher wie Urho3D), und ich denke, das sollte auch so bleiben, aber Unity wird immer einen Schatten darauf werfen, weil viele Leute hier sind kommen davon.

Ich denke nicht, dass es fair ist zu erwarten, dass Godot eine Unity-Abzocke ist - Godot hat eindeutig ein besseres Design und, soweit ich weiß, eine bessere Leistung. Einige Leute denken jedoch, dass GDScript nicht für "ernsthafte" Entwicklung geeignet ist und niemals sein wird, da es sich um eine benutzerdefinierte Laufzeit handelt, obwohl die alte Version von Mono, die Unity verwendet, in gewisser Weise auch eine "benutzerdefinierte" Laufzeit ist. Und außerdem, wenn Sie C# in Unity schreiben, schreiben Sie Code, der größtenteils nur in Unity funktioniert und deren Designmustern folgt, also können Sie genauso gut eine andere Sprache verwenden.

Ich denke, diejenigen, die C# wollen, liegen falsch, aber ein guter Kompromiss wäre meiner Meinung nach Folgendes anzubieten:

1) Bessere Leistung (statische Typisierung, vielleicht ein JIT)
2) Bessere Unterstützung für Bibliotheken von Drittanbietern (über FFI und einfachere C++-Integration)

für GDScript. Der Rest kann in C++ erledigt werden, einschließlich des Schreibens von Modulen, die andere Skriptsprachen implementieren (die nicht von Erstanbieter sein müssen – jeder kann ein C#-Modul schreiben, wenn er möchte).

@Zylann Ich sehe ehrlich gesagt keinen Vorteil darin, diesen Code anstelle des entsprechenden C++ zu schreiben, und der C++-Code wird eine bessere Leistung haben.

@paper-pauper Der Vorteil des Schreibens dieses Codes ist derselbe wie bei GDScript: Sie müssen die Engine nicht für jede Plattform neu kompilieren, auf die Sie exportieren möchten, und ... nun, Sie haben die Wahl der Sprache (und die Leistung ist nicht der einzige Punkt, wie ich bereits erwähnt habe). Ich stimme zu, dass die GDScript-Erfahrung derzeit überlegen ist und C++ die beste Wahl für reine Leistung ist. Aber es gibt Leute, die C++ einfach nicht machen wollen, was auch immer es gut ist.
Ich persönlich interessiere mich nicht für Godot+C#, sondern bewerte nur, was passiert, wenn Sie es zu Godot hinzufügen. Und es ist nicht so einfach :p

Nachdem Sie das großartige Buch Game Scripting Mastery gelesen haben (Sie können nicht viele Bücher zu diesem Thema finden, außer dem Non-Gaming-Buch über Compiler The Red Dragon). Meine Schlussfolgerung ist, dass GDscript angemessen ist, es ist so einfach, einer Skriptsprache ständig Funktionen hinzuzufügen, dass sie ihre Leistungsfähigkeit verliert. Das Wichtigste ist, eine nicht aufgeblähte Skriptsprache zu implementieren und sie so allgemein wie möglich für verschiedene Projekte geeignet zu machen. Aus demselben Buch heißt es, dass Unreal C++ mit LLVM verwendet.

Eine andere Idee, die leichter sein könnte als die Implementierung einer separaten Laufzeit: Wie wäre es, einen Transpiler wie TypeScript (der C# ohne die Laufzeit sehr ähnlich ist) so anzupassen, dass er GDScript anstelle von JavaScript ausgibt? Dies muss nicht in Godot enthalten sein, sondern könnte ein Modul eines Drittanbieters sein. Es würde zumindest statische Typisierung (zur Kompilierzeit) und eine Reihe von Bibliotheken bieten, mit der gleichen Leistung wie GDScript (weil es GDScript wäre).

Ich mag TypeScript, aber ich sehe keinen Sinn darin, eine solche Komplikation hinzuzufügen. Wenn jemand das tut, muss er es pflegen, um mit neueren Versionen von TS kompatibel zu sein. Außerdem ist TS eine Obermenge von JS. Wäre dies also in der Lage, JS in GDScript zu transpilieren? Und dann hätten wir einige Leute mit Fehlern im Transpiler, die denken, es sei ein Fehler in der Engine.

Ich denke immer noch, dass es eine bessere Idee ist, eine statische Version von GDScript zu haben, die einfacher auf JIT zurückgreifen kann und dennoch eng mit der Engine und dem aktuellen GDScript selbst verbunden ist.

Der Sinn von C# besteht darin, eine etablierte Sprache zu verwenden, die auch außerhalb von Godot verwendet werden könnte. TypeScript mag dazu passen, aber ich bin nicht davon überzeugt, dass es einfacher ist, einen TS-Transpiler zu erstellen, als eine Mono-Laufzeitumgebung einzubetten.

Für mich, wie ich im IRC sagte, wäre die beste Option die Möglichkeit, dynamisch verknüpfte Module zu erstellen. So können Sie einfacher in C++ arbeiten und es kann auch Module von Drittanbietern mit verschiedenen Sprachen geben, z. B. eines für C# und eines für C++ als Skriptsprache. Es würde die Fähigkeit erhöhen, Godots Ressourcen zu erweitern, ohne die Haupt-Engine-Binärdatei aufblähen zu müssen.

@vnen

Für mich, wie ich im IRC sagte, wäre die beste Option die Möglichkeit, dynamisch verknüpfte Module zu erstellen. So können Sie einfacher in C++ arbeiten und es kann auch Module von Drittanbietern mit verschiedenen Sprachen geben, z. B. eines für C# und eines für C++ als Skriptsprache. Es würde die Fähigkeit erhöhen, Godots Ressourcen zu erweitern, ohne die Haupt-Engine-Binärdatei aufblähen zu müssen.

Oh, ich stimme zu 100 % zu - tatsächlich habe ich in #3936 eine ähnliche Ansicht geäußert. Ich habe es nur rausgeschmissen, da wir die Laufzeit von C # als Nachteil erwähnt haben :)

Für mich ist dieses Beispiel-C#-Modul von @Zylann sehr schön, ich würde sofort von Unity wechseln, wenn das verfügbar wäre – es geht nicht um die höhere Leistung von C++ oder die „Einfachheit“ von GDScript, es geht darum, bequem zu sein.

Ich bin noch ganz neu bei Godot und hatte bisher kaum die Gelegenheit, ein Testspiel zu machen, also findet ihr meine Meinung vielleicht nicht gültig, aber für mich ist GDScript die größte Hürde, nicht wie es mit Nodes funktionieren soll und Szenen - das verstehe ich (und es ist ziemlich ordentlich!).

Aber für mich ist es buchstäblich die Syntax von GDScript, die gelinde gesagt wirklich abschreckend ist, ganz zu schweigen davon, dass der Code-Editor stark fehlt - ich würde gerne VS verwenden, da ich bereits alle Verknüpfungen kenne.
Ich habe Jahre des Schreibens von C# in meine Hände eingearbeitet und ehrlich gesagt fühle ich mich wie ein Kind, das versucht, in GDScript zu schreiben.

Was würde verloren gehen, wenn Entwickler bequem schreiben könnten? Ich brauche nicht die Fülle, die Mono oder Extravaganz wie Linq ist, ich möchte mich einfach wohlfühlen, während ich meinen Code schreibe.
Ich würde mich mit einer C#-ähnlichen Syntax für GDScript zufrieden geben, zumindest die Option, geschweifte Klammern, Semikolons und explizite Typen zu verwenden - ich kann implizite Typen persönlich nicht ausstehen, sie machen mich verrückt.
Ich denke, GameMaker lässt Variationen in der Syntax zu, um unterschiedliche demografische Merkmale zu berücksichtigen.

Dies sind natürlich nur meine 2 Cent von mehreren Stunden mit Godot – fühlen Sie sich frei, anderer Meinung zu sein (wie ich sicher bin, dass die meisten von Ihnen es tun werden).

Außerdem glaube ich, dass mir etwas fehlt – was genau an GDScript ist es, das jeder so sehr liebt?
Ich versuche nicht zu beleidigen, ich sehe es nur noch nicht.
Ich bin ziemlich vertraut mit Perl, also kenne ich die Macht der impliziten Typen und so weiter, aber es muss mehr als das geben, richtig?

@Pikl :

Außerdem glaube ich, dass mir etwas fehlt – was genau an GDScript ist es, das jeder so sehr liebt?
Ich versuche nicht zu beleidigen, ich sehe es nur noch nicht.

Bei GDScript geht es weniger um die Syntax (die pythonisch ist), sondern vielmehr darum, wie integriert sie in die Engine ist. Es mag pedantisch klingen, aber die Syntax ist das geringste Problem, wenn Sie zu einem anderen System wechseln. Am wichtigsten ist die API. Selbst wenn wir jetzt C# hinzufügen würden, würden Sie sich wahrscheinlich mit dem neuen Paradigma unwohl fühlen, da die Art und Weise, wie Sie es in Unity tun, nicht die gleiche ist wie in Godot.

Entschuldigung, aber wenn wir Sprachen hinzufügen würden, um die Komfortzone jedes Programmierers zu erreichen, würden wir die Ewigkeit damit verbringen, genau das zu tun. Während es sinnvoll sein könnte, Unity-Benutzern den geringsten Stress zu bereiten (wir versuchen gerade, einen Godot-Leitfaden für Unity-Benutzer zu erstellen), denke ich nicht, dass Godot sich anpassen sollte, um wie Unity zu funktionieren. Andernfalls müssten wir dasselbe für Benutzer von Unreal, Urho3D, GameMaker usw. tun.

Das soll nicht heißen, dass es C# nicht gibt (es könnte sein, wenn es machbar ist und im Interesse der Engine liegt), es ist nur so, dass diese Argumente auch für viele andere Sprachen und Engines gelten würden.

@Pikl Zunächst einmal danke, dass Sie das erste Argument für C # geliefert haben. Lassen Sie mich nun erklären, warum ich Ihre Meinung für ungültig halte. ;-P

Schauen wir uns den Anfang des Codebeispiels von Zylann genauer an:

    using GodotEngine;

    public class Spikeball : RigidBody2D {

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

Als Faustregel gilt, dass jedes Keyword und jedes Nicht-Keyword-Zeichen eine Bedeutung hat. Wenn nicht, sollte es nicht da sein.
Es beginnt mit
using GodotEngine;
was bedeutet, dass sich dieser Code auf Funktionen bezieht, die aus dem "GodotEngine"-Paket importiert wurden. Da jedes Skript in Godot auf diese Funktionen verweist und es keine anderen Pakete zum Importieren gibt, ist es sinnlos, diese Zeile hinzuzufügen, also entfernen wir sie.

Als nächstes haben wir
public class Spikeball : RigidBody2D {
Alles in GDScript ist öffentlich, warum sollte man es also erwähnen?
class Spikeball : RigidBody2D {
Jede GDScript-Datei enthält eine Klasse mit demselben Namen wie das Skript. Das ist nicht nur eine Codierungskonvention wie in anderen Sprachen, es ist so definiert, wo ist also der Sinn, den Klassennamen zu wiederholen?
: RigidBody2D {
Da das : das einzige sinnvolle "Schlüsselwort" in dieser Zeile ist, ersetzen wir es durch etwas besser Lesbares.
extends RigidBody2D {
Jeder Programmierer mit ein wenig Erfahrung wird Einrückungen verwenden, um die verschiedenen Bereiche des Codes zu markieren. Das bedeutet, dass der Code innerhalb der Klasse durch die umgebenden geschweiften Klammern UND durch die Einrückung identifiziert werden kann, weshalb die Entwickler von Python entschieden haben, die Einrückung obligatorisch zu machen und die nun überflüssigen geschweiften Klammern loszuwerden.
In unserem Fall ist eine Einrückung auf Klassenebene nicht einmal erforderlich, da jede Skriptdatei als eine Klasse definiert ist (es sei denn, Sie verwenden Unterklassen, die durch Einrückungen gekennzeichnet sind).
extends RigidBody2D

Als nächstes haben wir die Exportzeilen.

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

Die []-Zeichen markieren Attribute, die in gleichnamigen Klassen definiert sind, was ein Mechanismus ist, den es in Godot nicht gibt, also verwendet es stattdessen einfach Schlüsselwörter.

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

Auch hier ist alles öffentlich:

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

und Sie müssen den Datentyp nicht angeben.

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

Exporte sind eine Ausnahme, da der Inspektor wissen muss, welches Widget angezeigt werden soll, sodass der Typ eigentlich nur eine zusätzliche Information für das Schlüsselwort export ist.

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

Der Unterschied zwischen diesem C#-Code

    using GodotEngine;

    public class Spikeball : RigidBody2D {

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

und diesen GDScript-Code

extends RigidBody2D

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

ist einfach, dass alle Zeichen und Schlüsselwörter entfernt wurden, die nicht die Optionen beschreiben, die Sie in Godot haben.
Ich gehe davon aus, dass jetzt ziemlich klar ist, was die Leute an GDScript mögen. Sie sind nicht gezwungen, Dinge einzugeben, die bedeutungslos oder überflüssig sind, und die Syntax spiegelt die Optionen wider, die Sie haben, anstatt auf Optionen oder Sprachfunktionen hinzuweisen, die in Godot nicht vorhanden sind.

Da ich von einem C++/C#/TorqueScript-Hintergrund komme, muss ich sagen, dass Godots Paradigma ein paar Tage braucht, um sich daran zu gewöhnen, aber sobald seine Einfachheit "Klick" macht, können Sie von der Idee zur Ausführung so schnell wie Sie tippen können.

@vne :

Es ist nur so, dass diese Argumente auch für viele andere Sprachen und Engines gelten würden

Fair genug, ich halte weder den Atem an, noch erwarte ich, entgegenzukommen – das ist nicht mein Territorium.

Im Moment versuchen wir, einen Godot-Leitfaden für Unity-Benutzer zu erstellen

Vielleicht konnte ich damit helfen? Ich benutze Unity seit mehreren Jahren und kenne das Ding im Vergleich zu jeder anderen Engine ziemlich gut - ich wäre eine gute Laborratte für diesen Leitfaden.

@Warlan :

Ich gehe davon aus, dass jetzt ziemlich klar ist, was die Leute an GDScript mögen. Sie sind nicht gezwungen, Dinge einzugeben, die bedeutungslos oder überflüssig sind, und die Syntax spiegelt die Optionen wider, die Sie haben, anstatt auf Optionen oder Sprachfunktionen hinzuweisen, die in Godot nicht vorhanden sind.

Das macht absolut Sinn - es geht einher mit Perls Ideologie, die Anzahl der Tastenanschläge zu reduzieren, die zum Eingeben eines Skripts erforderlich sind. Aber wirklich, die Anzahl der Tastenanschläge, die ich für dieses Beispiel tatsächlich eingeben würde, wäre dieselbe - ich verwende die automatische Vervollständigung von VS bis zum Maximum und muss selten mehr als 3 Zeichen für irgendein Schlüsselwort, Typ oder Variablennamen eingeben, bevor ich die Leertaste drücke oder öffne Klammer, um es zu vervollständigen. Und was die eigentlichen zusätzlichen "unnötigen" Zeichen betrifft, ich bevorzuge es, sie dort zu haben, das ist nur eine syntaktische Zuckerpräferenz.
Godot hat eine automatische Vervollständigung, aber es ist langsam, es dauert so lange, dass ich oft meine gesamte Codezeile eingetippt habe, bevor sie die meiste Zeit überhaupt angezeigt wird.

Was die Leute also an GDScript mögen, ist, dass es so minimal wie möglich ist und genau die Funktionalität bietet, die zur Verwendung verfügbar ist, und nicht mehr, sowie die Anzahl der Tastenanschläge reduziert.

Ich verstehe das, aber es hilft mir nicht mehr dabei, es zu genießen - ich fühle mich einfach nicht wohl dabei, GDScript zu tippen, aber ich kann es einwandfrei lesen. Ich habe keine Mühe, es zu lernen, ich mag es einfach nicht, wie es scheint.
Vielleicht würden mich ein paar Stunden mehr beim Erstellen eines Space Invaders-Klons überzeugen - ich möchte GDScript mehr mögen als ich.

Nachtrag:
Ist es möglich, in Godot nur C++ zu verwenden? Ich denke ehrlich gesagt, ich würde es vorziehen, C++ zu lernen und das über GDScript zu verwenden.

Vielleicht konnte ich damit helfen? Ich benutze Unity seit mehreren Jahren und kenne das Ding im Vergleich zu jeder anderen Engine ziemlich gut - ich wäre eine gute Laborratte für diesen Leitfaden.

@StraToN hat in der Facebook-Gruppe um diese Art von Hilfe gebeten. Kontaktieren Sie ihn (ich bin mir nicht sicher, ob jemand anderes auch daran arbeitet).

@neikeq Danke, fertig!

@Warlaan Ich verstehe Ihren Codevergleich, aber für mich beweist er hauptsächlich, dass C # mehr Funktionen hat und daher ausführlicher ist.

Sie brauchen using , weil es Namespaces gibt, um Namenskollisionen mit vielen Klassen zu vermeiden (was mir bereits in meinem eigenen Spielprojekt passiert).
Sie benötigen public , da es einen Begriff der Kapselung gibt, um Codiererfehler im Laufe der Zeit zu verhindern.
Sie haben [SomeClass] , weil wir integrierte Anmerkungen erweitern können, um sie an unterschiedliche Projektanforderungen anzupassen und die Werkzeuge zu verbessern.
Was die geschweiften Klammern betrifft ... Ich sehe keinen Vorteil, außer bei der Definition von Bereichen.

Diese Funktionen sind aus einem bestimmten Grund hier. Unter ihnen würde ich Skalierbarkeit sagen. Würden Sie ein riesiges plattformübergreifendes 3D-Spiel mit der gesamten Codebasis in GDScript entwickeln? Ja, du kannst. Aber viele Benutzer werden C++, C# oder Java wegen der von mir aufgeführten Vorteile bevorzugen (und ich spreche nur von der Sprache, nicht vom Framework).

Aber gleichzeitig gibt es kein "riesiges" Spielprojekt, das ich kenne, das mit Godot entwickelt wurde, also nicht so viele Beispiele :p
Außerdem sehe ich ein paar schlechte Features in C# (Achtung: persönliche Meinung voraus):

Sie können statische Variablen haben. Das ist falsch, so viele Fehler kommen von globalen Zuständen/Singletons. Im Gegensatz zum automatischen Laden sind sie nicht an einen Szenenbereich gebunden.
Sie können ein Semikolon am Ende einer while()- oder if()-Anweisung falsch eingeben, wodurch es nutzlos und schwer zu finden ist.
Sie können übercodieren. Ich stimme zu, dass C#-Code bei falscher Verwendung sehr kompliziert werden kann, während ein einfacherer Code dasselbe tun würde. Aber es kommt auf die Person/Erfahrung an.

Oh. Ich habe preload() nicht erwähnt. Dies kann es einfach nicht nach C # / Java schaffen, es sei denn, Sie verlassen sich auf Compiler-Tricks: p

Hat jemand schon angefangen, ein Mono-Modul zu experimentieren?

Um meine bescheidenste Meinung als C#-Entwickler hinzuzufügen ...

Ich glaube nicht, dass es viel Wert hat, C# zu Godot hinzuzufügen, da Sie immer noch Godots Klassen lernen müssten, um etwas zu erledigen, und das einzige, was Sie wirklich durch das Hinzufügen von C# gewinnen würden, der vertrautere (für viele) C-Stil ist Syntax und statische Typisierung.
Über die Syntax lässt sich streiten, Python hat den Ruf, für Anfänger leicht erlernbar zu sein, und da GDScript Python sehr ähnlich ist, denke ich, dass das auch für Python gilt.
Etwas erfahrenere Programmierer sollten ohnehin keine Probleme haben, sich mit dieser Syntax vertraut zu machen, sie ist konsistent und hat erheblich weniger Fallstricke als die Syntax im C-Stil in freierer Form.

Auf der anderen Seite kann die statische Typisierung einen gewissen Wert haben, abgesehen davon, dass sie die Leistung verbessert, kann sie in gewisser Hinsicht auch zur Geschwindigkeit der Entwicklung beitragen. Tools zur automatischen Vervollständigung lieben es, wenn man ihnen sagt, welchen Typ eine Give-Funktion/Methode erwartet und zurückgibt, aber nur Typhinweise können dies erreichen.
Dies könnte jedoch zu GDScript hinzugefügt werden, es ist keine zusätzliche Sprache erforderlich.

Auch die Implementierung von C# wäre wahrscheinlich nicht so einfach, und es würde viel Zeit und Mühe aufgewendet werden, die Engine in den Zustand zu versetzen, in dem sie sich derzeit befindet, aber jetzt mit C# an der Spitze oder anstelle von GDScript.

Als Schlussbemerkung, von der ich weiß, dass einige Leute den falschen Weg nehmen werden, habe ich Folgendes zu sagen:

Ich habe beobachtet, dass einige Programmierer, die in unserem Handwerk vielleicht nicht so sicher sind, wie sie es sein sollten, die Tendenz haben, sich mit aller ihnen zur Verfügung stehenden Kraft an das Zeug zu klammern, das sie kennen.
Dieses Phänomen scheint mir in den C#-Entwicklergemeinschaften besonders weit verbreitet zu sein, obwohl dies möglicherweise nur meine Voreingenommenheit ist.
Wenn einer der Leute, die dies lesen, der Meinung ist, dass sie in diese Beschreibung passen könnten, kann ich nur empfehlen, aus dieser vertrauten Box herauszutreten und etwas Neues zu lernen, es ist keine so entmutigende Aufgabe, wie Sie vielleicht denken, und sobald Sie eine Firma haben Wenn Sie diese neue Sache verstehen, werden Sie wahrscheinlich auch Ihr Verständnis dessen erweitern, was Sie bereits wussten. Es lohnt sich einfach.

Ich würde statische Typen lieben, aber wie würden Sie in diesem Fall mit Generika umgehen? Würden Sie in diesem Fall einfach einen dynamischen Typ verwenden oder möchten Sie Einschränkungen verwenden können? - Erlaube zum Beispiel nur Ints und Bools.

Namensräume wären sehr willkommen, ich bin überrascht, dass sie nicht bereits in GDScript existieren.

Die Option, Klammern anstelle von Doppelpunkten für Methoden zu verwenden, wäre auch schön, ich weiß, dass sie unnötig sind, aber ich mag es, sie dort zu haben - es ist, als würde man ein Buch ohne Punkte lesen, es ist erschütternd.

Tipphinweise könnten die Lücke schließen, die verhindert, dass die Codevervollständigung vollständig funktioniert. Ich hatte einmal an einem Projekt mit Lua gearbeitet, und sie wollten das auch haben. Die Recherche führte mich hierher: https://github.com/andremm/typedlua/blob/master/examples/http-digest/http-digest.tl#L48
So kann ein Funktionsparameter werden, wenn man zu weit in Type Hinting xD eintaucht
Aber ich denke, es sollte einen Kompromiss geben. Sehen Sie sich nur an, wie TypeScript oder Haxe abschneiden (beide erlauben das Mischen von Varianten und Typisierungen). Außerdem ist Type Hinting bereits in Godot vorhanden. Es wird nur in export() verwendet :)

Hat jemand schon angefangen, ein Mono-Modul zu experimentieren?
@ Zylan

Schauen Sie sich GodotSharp an . Der aktuelle Stand im Repository ist noch nicht nutzbar. In meinem lokalen Repo habe ich es geschafft, genug Zeug zu implementieren (nur Vector2 und Matrix32 sind als Basistypen verfügbar), um die 2d/Platformer-Demo in C# zu übersetzen, mit Ausnahme der Instanzierung von Feinden und Kugeln, die von GDScript aus erfolgt, da Referenzen noch nicht funktionieren.
Dies ist ein Beispiel für die Player-Klasse: https://github.com/neikeq/GodotSharp/blob/master/platformer_cs/Player.cs

@Pikl

Nachtrag:
Ist es möglich, in Godot nur C++ zu verwenden? Ich denke ehrlich gesagt, ich würde es vorziehen, C++ zu lernen und das über GDScript zu verwenden.

Ja, es ist möglich, aber derzeit ist es nicht so einfach und/oder bequem und Sie müssen Godot von Grund auf neu kompilieren. Bitte zeigen Sie etwas Unterstützung für #3936, wenn Sie daran interessiert sind, dass C++ ein erstklassiger Bürger ist, damit es ohne viel Arbeit zusammen mit GDScript (oder ausschließlich) verwendet werden kann.

@Zylann Pikl fragte nach einer Änderung der Syntax von GDScript, damit sie der von C# ähnelt, damit sie für Unity-Entwickler einfacher zu lesen ist. Das habe ich kommentiert. Ja, C# hat mehr Funktionen, was der einzige Grund ist, warum die Schlüsselwörter und Zeichen, die ich entfernt habe, überhaupt dort waren. Und deshalb ist es nicht nur unnötig, sie hinzuzufügen, nur um GDScript-Code zu haben, der wie C # -Code aussieht, sondern imho falsch, da Sie eine Syntax verwenden würden, die auf Sprachfunktionen hinweist, die GDScript nicht hat.

@Pikl Es geht nicht um die Anzahl der Tastenanschläge, sondern um die Anzahl der Auswahlmöglichkeiten und die implizite Bedeutung der zusätzlichen Zeichen. GDScript verfügt einfach nicht über einige der Funktionen, die die zusätzlichen Schlüsselwörter legitimieren würden. Zum Beispiel müsste jeder Variablen, Klasse und Funktion das Schlüsselwort "public" vorangestellt werden, da der Standard-Sichtbarkeitsmodifikator von C# nicht öffentlich ist (mit Ausnahme von Namespaces - er ändert sich je nach Anwendungsfall ... eine andere Situation, in der Microsoft das entschieden hat KISS ist halt eine Band aus den 80ern) und da ist in GDScript alles öffentlich.

Warum also nicht C# mit all seinen Funktionen hinzufügen?
Wie Zylann bereits erwähnte, ist der Effekt des Hinzufügens von C# zu Godot nicht so einfach vorherzusagen. Wenn Sie es noch nicht getan haben, würde ich es begrüßen, wenn Sie meinen langen Beitrag in diesem Thread lesen (https://github.com/godotengine/godot/issues/5081#issuecomment-225226235). Als Entwickler hätte ich immer nach mächtigeren Sprachen gefragt. In meiner Freizeit schaue ich mir gerade Kotlin an, nur weil Papier-Armee es im ersten Post erwähnt hat.
Aber seit ich die Gelegenheit hatte, die Auswirkungen von Programmiersprachen auf das Ergebnis und das Verhalten von Spieleentwicklern zu untersuchen, wurde mir klar, wie wichtig es ist, eine angemessene Sprache zu wählen, anstatt eine mächtige.
Wie ich im verlinkten Beitrag erklärt habe, bin ich mir sicher, dass C# einen spürbaren Einfluss auf die Kultur in der Unity-Community hat, die Programmierer als Menschen sieht, die

• Sachen für den Asset Store schreiben
• Tutorials schreiben
• Fehler beheben.

Meiner Erfahrung nach gibt es in Unity nicht viel von einer Gameplay-Programmierkultur. Sobald Sie auf Probleme stoßen, suchen Sie nach Mustern oder vorgefertigten Assets, um sie zu lösen. Es gibt tatsächlich eine beträchtliche Anzahl von Leuten, die ihre Muster auswählen, bevor sie überhaupt etwas über ein Projekt wissen, und diese Art von mentaler Inflexibilität wirkt sich auf die Spielergebnisse aus.

Und das ist nur mein liebstes Gegenargument, es gab noch einige andere gute in den ersten Beiträgen. ;-)

Das Problem mit JVM ist, dass es zu schwer ist. Hat sich jemand Avian angeschaut ? Wie kompatibel ist es mit der Java-Welt?

@neikeq Das bedeutet nicht, dass es eine schlechtere Leistung hat - AFAIK, die JVM hat eine bessere Leistung als die CLR und auch einen Garbage Collector, der viel besser für die Spieleentwicklung geeignet ist. Es ist auch auf den meisten Computern installiert, unabhängig davon, ob es sich um Windows oder Mac oder GNU/Linux handelt.

Es hat auch eine größere Fülle hochwertiger FLOSS-Bibliotheken und, unabhängig davon, was manche Leute sagen, eine bessere plattformübergreifende Unterstützung.

Ich würde sagen, dass zwischen den beiden die JVM eindeutig besser für die Spieleentwicklung ist (aber ich würde sie und die CLR trotzdem vermeiden).

Avian sieht interessant aus. Ich habe keine Erfahrung damit, daher kann ich Ihre Frage nicht beantworten, und ich befürchte, dass sich seine Kompatibilität als ebenso problematisch herausstellen könnte wie die Mono-Version von Unity, was es wirklich umständlich macht, Bibliotheken von Drittanbietern zu verwenden, es sei denn, Sie zufällig einen für eine der bereitgestellten .NET-Versionen finden.

Aber eine leichtgewichtige Java-Implementierung als zusätzliche Option neben GDScript & C++ für Fälle zu haben, in denen Sie schnelle Bearbeitungszeiten benötigen und die Codequalität beeinträchtigen können (wie Game Jams oder schnelles Prototyping neuer Backend-Ideen), wäre schön.

@neikeq Avian ist darauf ausgelegt, Java-Scripting für C++-Projekte bereitzustellen, also ist es wirklich ein guter Kandidat. Es kann sehr klein sein (etwa 100 kb, wenn ich mich richtig erinnere). Ich habe von einigen libGDX-Spielen gehört, die Avian verwendet haben, um iOS-Ports freizugeben ... Die jMonkey-Engine verwendet Avian auch auf iOS). Im Allgemeinen kommt Avian ohne die gesamte Verpackung aus, die normalerweise mit JVM geliefert wird, wie Sun/Oracle-Klassen. Ich denke jedoch nicht, dass dies ein Problem ist, da „ursprüngliche“ Java-Klassen überhaupt nicht gut für Spiele geeignet sind. Aus diesem Grund bieten Bibliotheken wie libGDX ihre eigene Implementierung für Vektoren oder Datenstrukturen an.. und am Ende denke ich, dass wir es tun würden müssen diese Klassen ebenfalls neu implementieren. (Es ist jedoch einfach, verschiedene Teile der ursprünglichen Java-Klassen einzubetten, aber je mehr wir einbinden, desto größer wird Avian.)

@paper-pauper Ich meinte schwer, vorausgesetzt, es wird mit dem Spiel gebündelt. Aber wie Sie sagten, es ist auf den meisten Computern installiert, und angesichts der Popularität von Frameworks wie libGDX könnte es die beste Option sein.
Mein Problem mit C++ als Alternative zu GDScript ist, dass seine Syntax schrecklich ist. Das ist ein Produktivitätskiller. Es ist gut für die Entwicklung von Engines und Modulen, aber ich würde kein ganzes Spiel damit schreiben. Trotzdem bin ich für #3936 und etwas Ähnliches wie Unreal, aber ich würde es nicht als alternative "Skriptsprache" ansehen.

@kubecz3k Unterstützt es andere JVM-Sprachen? zB: Kotlin

@neikeq ja, soweit ich weiß, ist es vollständig kompatibel mit Java-Bytecode, sodass es jede jvm-fähige Sprache (kotlin, scala, jpython usw.) unterstützt.
Ich denke, wir könnten einige Fragen in der Avian Google Group stellen: https://groups.google.com/forum/#!forum/avian
es scheint ziemlich aktiv zu sein

+1 dazu, C++ nicht als alternative Skriptsprache anzusehen. Wie ich bereits sagte, ist es gut, dass Godot eine Sprache hat, die für die Skripterstellung und eine für die Backend-Entwicklung optimiert ist, im Gegensatz zu einer Sprache, die in beiden Bereichen irgendwie "meh" ist.

Das soll nicht heißen, dass ich nicht gerne dynamische Lib-Unterstützung und schnellere C++-Entwicklung sehen würde.

Aber um nicht zu begeistert von Avian zu sein, hier ist ein Blogbeitrag des Hauptentwicklers von libGDX, in dem er erklärt, warum libGDX Avian nicht für ios-Portierungen verwendet. http://www.badlogicgames.com/wordpress/?p=3925 (scrollen Sie nach unten zum Vogelteil)
Ich bin kein JVM-Programmierer/Hacker (aber der Autor ist es - da er auch an RoboVm gearbeitet hat (noch ein weiteres JVM, das von Microsoft gekauft und geschlossen wurde)), also weiß ich nicht, wie viel davon sich wirklich in das verwandeln würde Situation, in der Avian nur als Skriptsprache verwendet wird (und nicht die Kern-Engine antreibt)

Die meisten von Ihnen sind wahrscheinlich Programmierer mit mehr Erfahrung als ich, aber da sind meine 2 Cent. Vor einem Jahr habe ich mich für C# entschieden. Aber ich habe die GDScript-Syntax sehr schnell gelernt. Am Ende des Tages müssen Sie immer noch die API lernen, und das ist wahrscheinlich das zeitaufwändigste, was zu lernen ist. Also ja, ich brauche C# nicht. @Warlaan hat viele gute Gründe gegen C# angeführt. Auch die Implementierung von C# würde viel Zeit in Anspruch nehmen. Es würde auch mehr Bugs bedeuten. Ja, wir haben eine großartige Community, die zur Codebasis beiträgt, aber wir haben immer noch nur ein @reduz. Ich denke, die Zeit, die zum Implementieren von C# benötigt wird, sollte in Funktionen investiert werden, die wir wirklich brauchen. Wie viele Godot-Entwickler sind mit GDScript zufrieden? Ja, es könnte schneller sein, aber sonst habe ich keine Probleme damit. Ich hätte lieber eine tolle Skriptsprache als zwei nicht so gute. Sogar Unity hinkt mit altem Mono hinterher.

Was ich gerne hätte, ist die statische Typisierung in GDScript. Nicht C++ als Skriptsprache, nicht C#. Konzentrieren wir uns auf GDScript und machen es noch besser als es jetzt ist.

Da die Engine, für die ich 14 Jahre lang die Entwicklung leitete, im Visual Scripting-Thread erwähnt wurde, dachte ich, ich gebe hier meinen Senf dazu, da wir eine neue Engine entwickelten, die vollständig in unserer eigenen C#-ähnlichen Sprache geschrieben war.

Wir haben unseren eigenen Compiler geschrieben (ebenfalls in unserer eigenen Sprache geschrieben, nachdem wir ihn in C++ gebootet haben), der zu C++-Code (fast reinem C) kompiliert wurde, der dann in die Compiler aller von uns unterstützten Plattformen eingespeist wurde (XBox/PS/PC/Wii/ etc). Wir haben unseren eigenen Generations-Garbage Collector geschrieben, um seine Leistung nach Bedarf anpassen zu können. Auf diese Weise wurde er in der gesamten Engine verwendet, was bedeutete, dass er gut getestet und profiliert war. Und da wir nach C++ kompilierten, konnten wir C++-Code problemlos in „nativen“ Funktionen schreiben, die nach Bedarf System-APIs aufrufen oder plattformspezifische Operationen (SIMD) enthalten konnten.

Ich kann mir nicht wirklich vorstellen, wie frustrierend es für Unity sein muss, einen Haufen C++-Code mit Mono zusammenführen zu müssen – was wahrscheinlich erklärt, warum es hinterherhinkt, wie @GlaDOSik betonte. Es war sicherlich nichts, woran keiner von uns interessiert war.

Unser Hauptziel war es, die Sprachen, die zwischen der Engine, dem Editor und den Tools sowie dem Gameplay-Code verwendet werden, in einer einzigen Sprache zu vereinheitlichen. Zuvor waren die Engine und die Tools vollständig C++ und eine visuelle Skriptsprache (es sah zumindest aus wie C-Code) wurde für das gesamte Gameplay verwendet, das von Leveldesignern bevorzugt wurde, aber die Mehrheit der Gameplay-Programmierer, die die Mehrheit schrieben, verärgerte des Codes. Es ermöglichte uns auch, die Sprache auf Dinge zuzuschneiden, die wir möglicherweise für die Gameplay-Entwicklung benötigen (wie die Unterstützung von Zustandsmaschinen).

_Du kannst es aber nicht jedem recht machen._ Wenn ich an einem hässlichen Durcheinander von Spaghetti-Blaupausen/etc. Node-basiertem „Code“ arbeiten oder versuchen müsste, jemandem dabei zu helfen, Fehler zu beheben, würde ich mir als Vergeltung die Augen ausstechen wollen. Ich würde erwarten, dass ein Künstler, der versucht, C++-Code zu lesen, dasselbe tut. Was Sie tun können, ist, _viel_ Zeit damit zu verschwenden, darüber zu streiten, was die _beste_ Lösung ist, und noch mehr zu versuchen, es allen recht zu machen. Irgendwann müssen Sie sich nur noch darauf konzentrieren, die produktivsten Tools für die richtigen Leute zu entwickeln – und manchmal bedeutet das, dass einige Leute etwas Neues lernen müssen.

„Wenn es nicht C++ ist, ist es langsam“ scheint oft das Mantra zu sein, aber ich würde sagen, dass die Mehrheit der _vertriebenen_ Spiele heutzutage mit etwas anderem als C++ als Gameplay-Code geschrieben wird. Ich habe noch niemanden gesehen, der Leistungsprobleme speziell von GDScript gepostet hat, obwohl ich sicherlich neugierig wäre, von ihnen zu hören, was langsam war.

Was meine Einführung in GDScript angeht, ging es ungefähr so:

• OMG Python-like!? Das ist verrückt, Leerzeichen sollten keine Rolle spielen!
• Hmm, kein Fan von "lower_case"-Stil (sehen Sie, Sie können es nicht jedem recht machen).
• Nun gut, das ist eigentlich ziemlich cool und gut durchdacht.
• Ja, das ist gut in den Editor integriert, ich könnte sicherlich sehen, dass es damit sehr produktiv für Gameplay-Code und einige Editor-Plugins ist!

Es sieht so aus, als ob viel Mühe und Zeit in GDScript gesteckt wurde, und es scheint das richtige Werkzeug zu sein. Also wollte ich wirklich nur denen ein Lob aussprechen, die daran gearbeitet haben!

@Ziflin Hey! Ich freue mich, Sie hier zu treffen, Vicious war eine der ersten Spiel-Engines, die wir professionell verwendet haben (obwohl wir von @punto- angeheuert wurden, um sie zu hacken und Probleme damit zu beheben, anstatt sie tatsächlich zu verwenden).

Die visuelle Skriptsprache war wirklich ein Albtraum, aber der Quellcode war wirklich gut gemacht, sauber und organisiert. Nach der Arbeit mit Torque war es ein Glücksfall. Ich habe viel gelernt, damit zu arbeiten. Sony hat großartige Arbeit geleistet, um es in Lateinamerika zu verkaufen, weil jeder es hier vor einem Jahrzehnt benutzt hat.

Ich denke, der erstaunlichste Moment, an den ich mich bei der Arbeit damit erinnere, ist, versehentlich auf ein Stück Code zu stoßen, das die Sprachen auflistet, und es gab einen Kommentar "Portugiesisch wird nicht unterstützt".

Wir haben wirklich sehr darüber gelacht und Witze gemacht, und der Spieleproduzent (der hinter uns stand und wir haben ihn nicht bemerkt) hat vor Angst gezittert und gesagt: „Warte was? Jetzt bleibt nur noch, das Spiel ins Portugiesische zu übersetzen , Das ist ein Scherz, oder?"

Aber wir haben einfach Chinesisch für Portugiesisch verwendet, alles hat gut funktioniert und das Spiel wurde ausgeliefert. Schön zu wissen, dass ihr es immer noch entwickelt!

(Zitat von @Ziflin ) Ich habe noch niemanden gesehen, der Leistungsprobleme speziell von GDScript postete, obwohl ich sicherlich neugierig wäre, von ihnen zu hören, was langsam war.

Ich habe persönlich einen CPU / Gdscript-Engpass in diesem Projekt erreicht: http://godotdevelopers.org/index.php?topic=15519.0

Ich habe einige grundlegende KI- und grundlegende Pseudophysik der alten Schule in GDscript geschrieben, um jedes der 8 Autos zu steuern.
Ich habe nicht öffentlich über dieses Performance-Problem geweint, weil es noch ein paar kleine Optimierungsmöglichkeiten gab.
Aber wenn ich mehr Autos hinzufügen wollte, wäre ich gezwungen gewesen, Gdscript für C++ fallen zu lassen ( edit: was ich gerne vermeiden würde, da ich nicht wirklich immer wieder kompilieren möchte).

Ich denke auch, dass ich letztes Jahr bei diesem anderen Projekt, bei dem GDscript für die grundlegende KI für alle Fehler (Tiere) verwendet wurde, auf den gleichen CPU-/Gdscript-Engpass gestoßen ist: http://ludumdare.com/compo/ludum-dare-32/? action=preview&uid=50893
Je mehr ich Bugs (Tiere) hinzufügte, desto geringer wurde die Performance.

Ich könnte meine Erfahrungen dazu teilen, wenn jemand möchte.

@SuperUserNameMan Bitte machen Sie weiter, aber ich denke, dass dieses andere Ticket, das ich #5049 eröffnet habe (das speziell über die GDScript-Leistung spricht), dafür besser geeignet ist.

@paper-pauper: Ich bin mir nicht sicher, ob ich # 5049 beitragen könnte (wobei es eher um das Hinzufügen von JIT geht, worüber ich nur einen Daumen nach oben hinzufügen könnte). Die Erfahrung, die ich teilen konnte, bezieht sich eher darauf, welche Art von Engpass ich erreicht habe, was die spezifischen Symptome waren, wie ich umgehen musste, wie ich optimiert habe und welche "Godot-Designvorteile" ich opfern musste.

@SuperUserNameMan Ich habe noch nicht wirklich viel über die Implementierung von JIT über Typrückschluss nachgedacht, aber dafür muss die VM zuerst statische Typisierung unterstützen

Mich würde am meisten interessieren, auf welche Art von KI-Code Sie sich beziehen.
Mein Vorurteil wäre, dass jeder Code, der Leistungsprobleme verursachen kann, wenn er auf nur 8 Entitäten ausgeführt wird, wahrscheinlich kein wirklicher Spielecode ist und als solcher sowieso in eine C++-Klasse gesteckt werden sollte, deshalb frage ich.

@reduz Haha, anscheinend ist es eine kleine Welt! Und ja, das visuelle Scripting geriet irgendwie außer Kontrolle (es war wirklich nur für den Umgang mit Triggern und kleinen Teilen der Ereignislogik gedacht). Vicious hat zwar Anfang dieses Jahres seine Pforten geschlossen, aber es hat viel Spaß gemacht, dort zu arbeiten.

@paper-pauper Ich werde mir das andere Thema ansehen, das du erwähnt hast. Ich wollte nicht wirklich, dass die Leute anfangen, Performance-Probleme in diesem Thread zu posten.

Wenn GDScript statische Typisierung hinzufügen würde, wäre es _vielleicht_ einfacher, eine Option zu haben, um es direkt in C++ zu konvertieren, was zusätzlichen Overhead durch IL->C++-Übergänge vermeiden und die Laufzeit klein halten würde (kein JIT-Compiler usw.). Sie könnten dann in GDScript Prototypen erstellen oder Mods damit erstellen, aber dann könnten Sie es auch automatisch in C++ konvertieren, um zusätzliche Geschwindigkeit zu erzielen, wenn dies für endgültige Builds erforderlich ist.

Dadurch würden auch die bestehenden IDEs (VC++ usw. und der Godot-Editor) beibehalten, an die die Leute gewöhnt waren. Wir haben eigentlich nur VC++ verwendet, um unsere Sprache zu debuggen, und unser Compiler generierte #LINE -Anweisungen in den .cpp-Dateien, sodass Sie den ursprünglichen Code problemlos schrittweise durchlaufen und Haltepunkte setzen konnten. Theoretisch könnten Sie also mit normalem GDScript im Editor Prototypen erstellen und debuggen, aber während 'GDScript->C++' aktivierter Builds könnten Sie immer noch Ihre C++ IDE/Debugger verwenden und Breakpoints/Debug in den GDScript-Dateien setzen. Für uns waren die generierten C++-Dateien temporär und wir haben sie uns immer nur angesehen, wenn es ein Problem bei der Codegenerierung gab.

Jedenfalls nur ein Gedanke. Die Tatsache, dass Sie jetzt eine nette Skriptsprache haben, ist definitiv ein Plus und macht es sicherlich möglich, Dinge wie von Benutzern erstellte Mods, schnelles Prototyping und das Hinzufügen neuer Funktionen zur Sprache zu tun.

Tatsächlich habe ich auch nicht verstanden, dass ich meine Performance-Probleme in diesem Thread posten sollte. Hier war besser geeignet: https://github.com/SuperUserNameMan/kart-zero/issues/1

@Ziflin Was wir eigentlich in anderen Themen besprochen haben, ist das Hinzufügen einer minimalen C-API zum Schreiben von Godot-Modulen/Skripten mit einfachem C über eine minimale API, die Godots gesamte Reflexions-API offenlegt. Dies würde ein allgemeines Problem lösen, das wir bezüglich der Verteilung von Bindungen haben zu verschiedenen Arten von Bibliotheken, ohne Godot neu kompilieren zu müssen

Beispiele hierfür sind Typen, die Steam-API, ODBC, SQLite, Kinect usw. binden möchten. All dies erfordert das Schreiben von Modulen in C++. Wenn Sie dies mit einer C-API tun, wird das Problem des dynamischen Verknüpfens mit C++ gelöst (das aufgrund der Tatsache, dass jeder Compiler oder jede Compilerversion eine eigene ABI hat, und der Probleme mit der Symbolgröße, die zwischen Godot-Versionen auftreten können, sehr begrenzt ist). C hat keines dieser Probleme.

Sobald das funktioniert, sollte es wirklich einfach sein, GDScript in C zu kompilieren und es zur Laufzeit zu laden, wenn das Spiel läuft oder exportiert wird.

@reduz Ah cool. Sie sprechen also im Grunde davon, eine „Plug-in“-DLL schreiben zu können, die GDScript offenlegen kann, was sie will? (oder habe ich das falsch verstanden?)

Sobald das funktioniert, sollte es wirklich einfach sein, GDScript in C zu kompilieren und es zur Laufzeit zu laden, wenn das Spiel läuft oder exportiert wird.

Funktioniert dies für jemanden, der eine DLL schreiben möchte, die mehrere neue, von C++-Knoten abgeleitete Typen enthält?

Es ist ein bisschen traurig, dass die Unterstützung für neue C++-'Module' anscheinend ausreicht, um einige der Probleme mit DLLs zu beheben.

Warum nicht eine einbettbare Skriptsprache wie Lua oder Ruby verwenden?

@jersten , weil Sie die Dokumentation gelesen haben - http://docs.godotengine.org/en/latest/reference/gdscript.html

@Ziflin ja, aber Sie müssen die C-API über Reflexion verwenden (obwohl Sie über Reflexion nach Funktionszeigern fragen können, also sollte es schnell genug sein ...). Das Ziel wäre hauptsächlich, eine einfache Möglichkeit zum Laden von DLLs zu haben, die das ABI-Problem vermeidet, und auch eine einfache Möglichkeit, GDScript in C zu kompilieren und als .so zu laden.

Ich werde hier meine 2 Cent für das geben, was es wert ist. Ich habe nie in C# codiert, sondern nur in Java. Obwohl ich persönlich Java bevorzugen würde, weil ich es verwendet habe und es mochte, unterstütze ich tatsächlich C# gegenüber Java. C# ist das, was Unity-Spieleentwickler verwenden, also würde Godot es zu einem Teil dieses Indie-Entwickler-Ökosystems machen, das Unity geschaffen hat. Auch Java ist nicht einmal eine gute Wahl, wenn Sie eine JVM-Sprache wollen. Es gibt andere bessere Sprachen, die zu JVM kompiliert werden können.

Ich denke, die Leute verfehlen sowieso den Punkt. C#/Java != Skriptsprache. GDScript ist ausreichend; leicht erlernbar usw.

Das Hinzufügen einer Sprache wie Java (für welche Zwecke eine JVM erstellen?! Syntax?! Benötigen Sie eine JVM mit einer bestimmten Version, um zu funktionieren?!?) .

Wenn es ein Problem mit GDScript gibt, sollte darauf hingewiesen werden; und dann versucht zu beheben.

Ich bin nicht einverstanden. Ich glaube, C# würde viele Unity-Entwickler oder Entwickler anziehen, die mit C-ähnlichen Sprachen vertraut sind und eine nette Alternative zu Python wie GDScript bieten. Das letzte Teil des Puzzles wäre ein visuelles Scripting, das Künstler anziehen würde, die nicht an Codierung gewöhnt sind. Dies sollte so ziemlich jeden abdecken.
Auch egal, was Sie codieren, Sie müssen immer noch Godots Klassen und Funktionen lernen, die in jeder Sprache gleich wären.

An alle Leute, die C# argumentieren, weil Unity-Entwickler es kennen, bedenken Sie Folgendes: Viele Unity-Entwickler wissen nicht, wie man in C# programmiert. Was sie wissen, ist die Verwendung der Unity-API, die zufälligerweise C#-Bindungen hat. Sie bringen sie zu Godot, selbst wenn es sich um C# handelt, sie wissen sowieso nicht, was sie tun, und sind genauso verloren, als würden sie ihnen eine andere Programmiersprache zur Verfügung stellen.

Das Einbeziehen zusätzlicher Sprachen ist nur mehr Overhead und mehr, das das Projekt aufrechterhalten muss, als es nicht sollte.

Ich habe viel darüber nachgedacht, und meine Hauptsorge bei der Unterstützung von etwas wie C# ist, dass die meisten Leute, die es verwenden würden, Unity-Benutzer sein würden, die zu Godot kommen. Natürlich würden wir C# nicht in die offiziellen Vorlagen aufnehmen, und ich bezweifle sehr, dass sie das Modul selbst erstellen würden ...
Es könnte am Ende ein großer Aufwand sein, eine Sprache zu unterstützen, die nur von wenigen verwendet wird.

Ich glaube da liegt ein Missverständnis vor:

• Sie sehen GDScript und denken, dass GDScript auf Augenhöhe mit C# ist; fehlt der grundlegende Punkt, dass C# keine Skriptsprache ist.
• Aufgrund der oben genannten Tatsache, wenn jemand "Java oder C#" sagt; Was sie wirklich verlangen, ist ein Umschreiben der Engine in C#/Java oder das Hinzufügen einiger Bindungen, um diese Sprachen zu unterstützen (lol nein).

Da ich letzteres vermute; Debuggen in C#/Java ist auf mehreren Plattformen ein Alptraum; da diese beiden Sprachen nicht plattformunabhängig sind (inb4 gibt es Laufzeiten auf praktisch allen Betriebssystemen); es wird zu „Einmal schreiben, überall debuggen“ (deshalb kommen Spiele, die für Monogame geschrieben wurden, zuerst auf Windows heraus; und dann schließlich auf Linux/Mac, weil die Entwickler für diese Plattformen debuggen müssen). Aus diesem Grund beschädigen JVM-Updates Anwendungen.

Das Hinzufügen von Unterstützung für diese Sprachen fügt der Engine keinen Wert hinzu.

Wenn das Argument "Moar Unity-Entwickler" lautet; dann sollte eine Dokumentation erstellt werden, um Unity-Entwicklern beim Übergang zu helfen; dass Layoutunterschiede usw.

Deshalb habe ich am Ende gesagt, dass es egal ist, welche Sprache Sie verwenden, Sie müssen immer noch Godot-API-Klassen und alles lernen. Es ist nicht so, dass Unity-Entwickler Insta-Experten sein werden, weil sie C# kennen. Ich denke, es ist eher eine "Aura der Güte" für Godot, wenn es C # unterstützt. Die Leute haben das Gefühl, mehr zu wissen, und plötzlich ist Godot zugänglicher und nicht mehr so ​​beängstigend. Das negativste an Godot von Nicht-Godot-Benutzern ist, dass es eine eigene Skriptsprache hat. Als Godot-Benutzer wissen Sie, dass BS, weil GDScript eine lustige und einfache Sprache ist, aber für Außenstehende mag es wenig einladend erscheinen.
Ich kann nicht aus der Sicht von Entwicklern sprechen, aber vielleicht ist es mehr Aufwand als es wert ist, es sei denn, Entwickler haben etwas aus der Implementierung von C # heraus, dann lohnt es sich. Am Ende ist die Entscheidung der leitenden Entwickler und was auch immer sie entscheiden, ich werde damit rollen. Ich bin sicher, es wird eine gute Entscheidung sein.

Ich stimme Ihnen zu, dass GDScript etwas abstoßend ist, weil es praktisch eine unbekannte Sprache ist. Aber nachdem ich gelesen hatte, warum Lua und Python entfernt wurden und welche Vorteile das Hinzufügen von GDScript hat, war ich weniger besorgt.

Eine andere Sache, die relevant sein könnte: Es gibt eine andere MIT-lizenzierte Engine, die bereits C # unterstützt und Unity ähnlicher ist, Atomic Game Engine . Ich schlage vor, dass alle Leute, die dringend etwas brauchen, das Unity so nahe wie möglich kommt, es versuchen sollten.

Ich gebe hier nur meine 2 Cent dazu. Für mich ist der große Vorteil von C# die Leistung, während es immer noch einfacher zu handhaben ist als C++. GDScript, das dynamisch typisiert ist und so, ist sehr schnell zu schreiben, wird aber nie ultraschnell laufen (obwohl es ziemlich viel optimiert werden könnte, was geplant ist). C++-Module sind sehr schnell, aber etwas umständlich damit zu arbeiten; C++ ist nicht gerade eine freundliche Sprache, und die Engine neu kompilieren zu müssen, um sie zu verwenden, ist nicht wirklich optimal. Für mich ist C# eine Art Kompromiss: viel schneller als GDScript und mit der richtigen Unterstützung viel einfacher zu handhaben als C++-Module.

Davon abgesehen muss es nicht C# sein. Alles andere, was einen ähnlichen Effekt hätte, würde meiner Meinung nach gut funktionieren, sei es statisch typisiertes kompiliertes/JIT-GDScript oder etwas anderes wie Swift oder so. C# ist vielleicht das Beste für „Marketingzwecke“; Selbst ohne eine ähnliche API wären Entwickler von anderen Engines/Frameworks wahrscheinlich damit vertrauter. Modifiziertes GDScript ist möglicherweise einfacher zu implementieren und würde wahrscheinlich viel besser integriert werden.

Ich weiß, dass der Thread mittlerweile sehr lang ist, aber bitte lesen Sie alle obigen Beiträge, bevor Sie selbst etwas posten. Das Argument, dass C# Leute anziehen würde und für Unity-Benutzer sehr praktisch war, wird nicht stichhaltiger, wenn es ein Dutzend Mal mehr erwähnt wird.

Sehen Sie hier, warum C# meiner Meinung nach großartig für Unity und schlecht für Godot ist, sehen Sie hier , warum das Hinzufügen von C# zu schmutzigem Code führt, nicht nur in Ihren eigenen Projekten, sondern auch in Online-Tutorials, dem kommenden Asset Store usw Das Argument, dass die Leute viele neue Dinge lernen mussten, wenn sie von C# zu GDScript wechseln, ist ungültig.

Lassen Sie mich das Argument kommentieren, dass C# neue Leute anziehen würde.
Warum wollen wir, dass mehr Menschen Godot verwenden? Ich verstehe vollkommen, dass Open-Source-Projekte eine Community brauchen

• fügt Funktionen hinzu
• behebt Fehler
• erstellt wiederverwendbare Assets
• macht Vorschläge für neue Funktionen
• findet Fehler oder Probleme mit dem Workflow
• schreibt Tutorials

Aber all das braucht Leute, die die Kernidee des Motors verstehen und schätzen. Leute, die einer Bibliothek unnötige Funktionen hinzufügen, helfen nicht, und es gab mehr als ein Projekt, das unter solchen Funktionen litt, manchmal bis zu dem Punkt, an dem das Projekt aufgegeben oder aufgeteilt wurde.
Unity leidet besonders unter Leuten, die Tutorials schreiben, obwohl sie nicht wirklich verstehen, was sie tun, was zu einem großen Teil die Schuld von C# ist.

Wenn Menschen nicht einmal bereit oder in der Lage sind, eine so einfache Sprache wie GDScript zu lernen, dann ist es höchst fraglich, ob sie sich die Zeit nehmen werden, die Designphilosophie hinter Godot vollständig zu verstehen, bevor sie anfangen, aktiv zur Community beizutragen. („Aktiv beitragen“ bedeutet alles vom Senden von Pull-Requests bis zum Posten ihrer Meinung über Godot auf Facebook.)

Godot ist kein kommerzieller Motor. Unity hat ein Interesse daran, so viele Leute wie möglich einzubeziehen, da sie alle potenzielle Kunden sind und für die Engine werben. Es wäre sicherlich schön, eine große Community von Benutzern zu haben, die Godot so schätzen, wie es ist, aber es macht keinen Sinn, einige von Godots Qualitäten zu opfern, um eine größere Community zu bedienen.

@Warlaan- Leute wollen im Allgemeinen keine Zeit verschwenden und verwenden alle Code-Snippets, die sie finden, wenn sie ihre Projekte erstellen, besonders am Anfang, wenn Sie lernen. Für Anfänger sind Ihre Punkte leicht relevant, da sie am Ende lernen werden, in welcher Sprache die von ihnen verwendeten Code-Snippets geschrieben sind. Ich weiß das, weil ich so gelernt habe, Beispiele zu betrachten, und ich kannte kein GD-Skript, aber ich habe es gelernt. Das Problem ist nicht, was das Beste ist oder wie sich dies auf die Tutorials usw. auswirkt oder verkompliziert. Das Problem (für mich) ist C # mehr als jede andere Sprache, die Godot zu einem Teil dieses Indie-Entwickler-Ökosystems macht, zu dem Unity gehört. Hier geht es nicht einmal um Einheit, sondern um Godot.

EDIT: einige unnötig harte Sprache entfernt ;-)

@trollworkout Nichts für ungut, aber du hast meinen Punkt nicht wirklich verstanden und ich habe das Gefühl, dass du auch nicht wirklich durchdacht hast, was du gesagt hast.

1. Ja, die Leute wollen keine Zeit verschwenden. Die vollständigen Spezifikationen von GDScript: ein paar Bildschirme. Bücher, die C# erklären: normalerweise mindestens 500 Seiten. Ich habe ein paar Tage damit verbracht, GDScript zu lernen, und ich bin mir ziemlich sicher, dass es keine einzige Funktion hat, die ich nicht kenne. Ich arbeite seit Jahren sowohl beruflich als auch in meiner Freizeit mit C# (unter Verwendung von Window Forms, WPF, XNA und Unity) und finde immer noch Codeschnipsel, die Funktionen verwenden, die ich nicht vollständig verstanden habe. Nach C# zu fragen, weil es weniger Zeitverschwendung war, macht keinen Sinn.
2. „Anfänger lernen am Ende die Sprache, in der die von ihnen verwendeten Codeschnipsel geschrieben sind“ – siehe Punkt 1. Die Vorstellung, dass man C# aus Codeschnipseln lernen könnte, ist weit von der Wahrheit entfernt. Die Dinge, die Sie auf diese Weise lernen können, sind so grundlegend, dass es nicht länger als ein paar Tage dauern wird, um eine andere Sprache zu „lernen“. Sie haben selbst gesagt, dass Sie GDScript auf diese Weise gelernt haben.
3. "C# wird Godot zu einem Teil dieses Indie-Entwickler-Ökosystems machen". Und was soll das bedeuten?
   Könnten Sie Unity-Code-Snippets in C#-Godot verwenden? Nein.
   Könnten Sie Unity-Assets in C#-Godot wiederverwenden? Nein.
   Könnten Sie Unity-Tutorials lesen und sie Wort für Wort auf C#-Godot anwenden? Nein.
   Was ist also dieses „Indie-Entwickler-Ökosystem“, auf das Sie sich beziehen?

Wie Papier-Armee sagte, gibt es viele Engines und Bibliotheken zur Auswahl.
Möchten Sie ein Komponentensystem wie das von Unity? Siehe Atomic Game Engine.
Möchten Sie weiterhin C# in einer Engine verwenden, aber das Komponentensystem aufgeben? Siehe CryEngine / Luberyard.
Möchten Sie weiterhin C# verwenden, aber auf die Engine verzichten? Siehe MonoGame.

Der Gedanke, dass das Hinzufügen von C# zu Godot Anfängern hilft, ist falsch, da Sie selbst sagten, dass Sie das Skripting in Godot gelernt haben, indem Sie sich Codeschnipsel angeschaut haben. Wenn Sie auf diese Weise lernen, mit einer Engine zu arbeiten, möchten Sie dann nicht eine Sprache, die Ihnen implizit sagt, wie die Engine funktioniert, anstatt eine, die für Tausende von verschiedenen Anwendungsfällen entwickelt wurde?

Ich gebe hier nur meine 2 Cent dazu. Für mich ist der große Vorteil von C# die Leistung, während es immer noch einfacher zu handhaben ist als C++. GDScript, das dynamisch typisiert ist und so, ist sehr schnell zu schreiben, wird aber nie ultraschnell laufen (obwohl es ziemlich viel optimiert werden könnte, was geplant ist). C++-Module sind sehr schnell, aber etwas umständlich damit zu arbeiten; C++ ist nicht gerade eine freundliche Sprache, und die Engine neu kompilieren zu müssen, um sie zu verwenden, ist nicht wirklich optimal. Für mich ist C# eine Art Kompromiss: viel schneller als GDScript und mit der richtigen Unterstützung viel einfacher zu handhaben als C++-Module.

Alle von Ihnen erwähnten Probleme mit C++ sind gültig und könnten über #3936 behoben werden. Wir haben das schon oft diskutiert, aber hier sind nur der Klarheit halber die Probleme mit GDScript, die wir objektiv erkennen können:

1. Schlechte Unterstützung für Bibliotheken von Drittanbietern
2. Schwache Leistung

In der Lage zu sein, Teile in C++ zu schreiben, behebt beides leicht. C# (oder eine andere Sprache) würde diese auch beheben, aber mit einer zusätzlichen Laufzeit, schlechterer Leistung und plattformübergreifender Unterstützung und viel zusätzlicher Arbeit (während Godot bereits in C++ geschrieben ist). Die rationale Wahl ist also, das zu verwenden, was bereits vorhanden ist (C++), es zu verbessern und diese Probleme natürlich mit GDScript zu beheben.

Ich habe diesen Thread schnell gelesen und gesehen, dass GDScript to C ins Auge gefasst wurde.

Wenn dies der gewählte Weg ist, wäre es eine gute Sache, den tcc-C-Compiler in den Editor einzubetten, um das generierte C zu kompilieren. Er hat eine sehr schnelle Kompilierzeit, ist sehr klein und lässt sich leicht einbetten. Vielleicht wäre das der beste Weg, um die Dinge zu beschleunigen.

TCC wird unter der GNU Lesser General Public License vertrieben.

(Quelle)

Dies macht es wahrscheinlich ungeeignet für die Aufnahme in Godot. Es scheint auch nicht mehr gewartet zu werden.

@Warlaan Ich muss nicht zu viel nachdenken. An diesem Punkt haben wir alle schon ungefähr 10 Mal dasselbe gesagt, ich denke, wir wissen ziemlich genau, wo wir alle stehen. Außer meinen 2 Cent und ein paar Ideen habe ich nicht viel mehr beizutragen, da ich kein Entwickler bin und die Engine nicht so gut kenne. Ich lasse diejenigen zu Wort kommen, die es besser wissen. Ich wollte nur meine Unterstützung zum Ausdruck bringen und das ist alles.
Offtopic:
Aber ja, in Bezug auf Punkt 2., um den Sie viel Aufhebens gemacht haben, dass Sie Ihren Kommentar bearbeiten mussten. Sie sagen also, dass Sie eine Sprache nicht anhand von Beispielen lernen können? Ich denke, Sie gehen davon aus, dass die Leute es nicht lernen können, es sei denn, sie lesen 500-seitige Handbücher, für die C # bekannt ist, weil Sie Grund 1 nennen, es abzulehnen. Nun, ich bin der lebende Beweis dafür, dass Sie falsch liegen. Wie denkst du, habe ich GDScript gelernt? Mit den API- und Demo-Beispielen und dem Herumfragen von Fragen. Wohlgemerkt, ich hatte 0 Python-Kenntnisse, bevor ich anfing, also war alles daran ziemlich fremd. Als Randbemerkung frage ich mich, wie viele Leute libGDX-Handbücher kaufen und wie viele Leute tatsächlich "How to do X in libGDX" googeln, wahrscheinlich warum der Asset Store in Unity so schlecht ist. Und damit bin ich erstmal fertig, weil ich nichts mehr zu sagen habe.

( @Calinou : Bellard hat zugelassen, dass ein Fork von TCC BSD oder MIT wird. Aber als ich das letzte Mal nachgesehen habe, hat der Entwickler des Forks keinen Quellcode veröffentlicht. Vielleicht würde Bellard also akzeptieren, dass die Godot-Community auch TCC neu lizenzieren darf?)

Ich bin mir nicht sicher, ob TCC als Compiler so gut ist wie GCC oder Clang - ihre Größe unterstützt viele Architekturen und eine ziemlich optimierte Codegenerierung (bessere Leistung).

Was ist mit Godot, das optional entweder von GCC oder Clang abhängt, um C zu kompilieren? Sie sind auf den Computern der meisten Leute installiert, die die Spiele sowieso bauen würden (die Größe spielt also keine Rolle), und so machen es auch andere Sprachen, die nach C kompilieren (wie Chicken ). Sie unterstützen auch C++, falls das jemals benötigt wird.

Wenn sie zu optionalen Abhängigkeiten gemacht werden, können diejenigen, die GCC oder Clang nicht installiert haben (was seltsam für einen Entwickler ist, der ein Spiel für die Verteilung erstellen soll, aber trotzdem), einfach den GDScript-Interpreter so verwenden, wie er gerade ist.

Ich schlug vor, TCC als JIT für GDScripts zu verwenden. Das wichtigste Merkmal war also die Kompilierungsgeschwindigkeit. Und ich denke, die Ergebnisse könnten bereits viel schneller sein als die aktuelle Lösung.

Die meisten Leute wollen C/C++ wegen der Leistung und Lua/Javascript, um einfacher und schneller zu schreiben, also warum nicht das Beste aus beiden Welten haben?

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

Effizient wie C, ausdrucksstark wie Python und flexibel wie Lisp

Vorteile:

• Kompiliert in C, C++, Obj-C oder JS ( http://nim-lang.org/docs/backends.html )
• (Python / Pascal) wie ( https://learnxinyminutes.com/docs/nim/ )
• GC oder Handbuch (http://nim-lang.org/docs/gc.html)
• Kann an anderer Stelle als Godot verwendet werden
• Plattformübergreifend (Windows, Linux, OSX, Mobil)
• Hilft beim Konvertieren von C-Code in Nim
• Unterstützt C-Bibliotheken
• Optimierbarer Compiler
• MIT-lizenziert
• Open Source
• Typsicher

Nachteile:

• Erfordert einen C/C++-Compiler auf dem Computer des Entwicklers -> gcc , vcc , llvm_gcc , icc , clang oder ucc _(nicht wirklich ein Betrug, meiner Meinung nach)_
• Kleine Gemeinde
• Noch nicht 1.0

Die TODO-Liste von Nim ist klein, sie liegt nahe bei 1,0:
https://github.com/nim-lang/Nim/blob/devel/todo.txt

wie Paper-Pauper sagte (über einen Compiler im Computer des Entwicklers):

Sie sind auf den Rechnern der meisten Leute installiert, die die Spiele sowieso bauen würden
https://github.com/godotengine/godot/issues/5081#issuecomment -227706106

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

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

Es ist nicht meine Lieblingslösung, aber wenn Sie diesen Weg gehen müssen, empfehle ich Ihnen dringend, Haxe ( haxe.org ) anstelle von Nim zu verwenden.

Ich kann die Lizenz von Haxe nicht kommentieren (der Compiler selbst verwendet "GPLv2+", die Standardbibliothek verwendet MIT), aber alle anderen Faktoren machen es meiner Meinung nach zu einer überlegenen Wahl.
Es ist eine getestete Plattform (derzeit in Version 3.2.1), im Gegensatz zu Nim, das noch nicht einmal Version 1.0 ist, aber was mir viel wichtiger ist, die Syntax ist viel näher an anderen bekannten Sprachen. Wenn ich die Nim-Beispiele lese, scheint es mir, dass die Entwickler hinter dieser Sprache versucht haben, ungewöhnliche und / oder hässliche Lösungen zu finden.

Aber wie ich bereits erwähnt habe, ist es nicht meine Lieblingslösung und hier ist der Grund:
Zwischensprachen wie Nim oder Haxe haben viele "semantische Abhängigkeiten". Ich meine nicht Abhängigkeiten von Bibliotheken oder ausführbaren Dateien, die vorhanden sein müssen, ich meine, dass sie sich auf andere Sprachen beziehen. Wie ich bereits sagte, sind Sprachen keine Werkzeuge mehr, sie sind Kulturen. Und selbst wenn Sie sie nur als Werkzeuge sehen, haben sie unterschiedliche Kernbereiche, für die sie entwickelt wurden. ZB macht es durchaus Sinn, dass der Befehl "echo" Text auf die Standardausgabe ausgibt, wenn er auf der Standardeingabe eingegeben wird. Es ist nur konsequent, denselben Befehl in einem Batch-Skript zu verwenden. Nach dieser Logik ist es verständlich, dass PHP denselben Befehl verwendet. Die Verwendung in einer Allzwecksprache wie Nim macht keinen Sinn, da im Grunde alle anderen Allzwecksprachen Methoden haben, die etwas mit "write" oder "print" im Namen heißen.
Ich habe keine Ahnung, warum Nim immer noch "echo" als Namen für diesen Befehl verwendet, aber das ist die Art von Dingen, die man bei Haxe oft beobachten kann und die ich in Zukunft von Nim erwarten würde, wenn nicht bereits in der ersten Version . Beispielsweise enthält die Standardbibliothek von Haxe sowohl eine substr(int, int)-Methode als auch eine substring(int, int)-Methode. Einer der beiden gibt den Teilstring vom ersten zum zweiten Index zurück, der andere den Teilstring vom ersten Index mit der Länge des zweiten Arguments. Der Grund dafür, dass beide existieren, ist, dass die Sprache, da sie verwendet werden kann, um Sprachen verschiedener Art zu ersetzen, Benutzer hat, die von verschiedenen Plattformen kommen, und es sei denn, es gibt jemanden mit einer sehr starken Hand, die entscheidet, was in diese Open-Source-Bibliothek kommt und was nicht Sie werden leicht mit einer solchen Mischung von Codierungsstilen enden.

Es ist sehr wichtig, die richtigen Werkzeuge für den richtigen Job auszuwählen. Sprachen wie Haxe (oder C# für diese Angelegenheit) versuchen, Ihnen eine Sprache zu geben, die für alle passt, so dass Sie meistens „nur ein Tool“ verwenden, das leider so aussieht.

Ich möchte meine 2 Cent hinzufügen, nachdem ich eine Weile mit Godot gearbeitet habe.
Was ich gerne sehen würde (und auch mit ... begrenztem Erfolg angeschaut habe) ist C++ als erstklassige Sprache in Godot.
Schreiben der rechenintensiven Logik (Kollisionslösung, Physik, Transformationen und KI) in C++ und Skripten der Knoten mit GDScript (Trigger, Bedingungen, Animationen und Sounds).

GDScript IST ziemlich einfach zu erlernen, was Godot in dieser Hinsicht etwas näher an Gamemaker als an Unity bringt.
Aber nachdem ich 3 kleine Spiele geschrieben und mit ein paar Demos herumgespielt habe, muss ich sagen, dass GDScript für alles, was über sehr einfache Spiele hinausgeht, fehlt.

Codedateien werden einfach zu lang und dem Code-Editor fehlen viele nützliche Funktionen, die in anderen IDEs zu finden sind, wie z.

GDScript fehlen auch viele grundlegende Funktionen von prozeduralen Sprachen , wie z . , _ Aufzählungen _.
_ Es gibt kein Klassen-Szene-Beziehungsbewusstsein _ wenn es also nicht vorgefertigt ist, ist es eine "externe" Klasse und muss vorgeladen werden.

Aufgrund der Natur von GDScript gibt es auch keine Funktionsreferenzen und keine Vorlagen.
Es ist nichts Aufsehenerregendes, aber es ist sehr nervig.

Auge776; GDscript ist nur dann für mehr als einfache Spiele unbrauchbar, wenn Sie sich entscheiden, die anderen Funktionen zu ignorieren (z. B. die Verwendung von Knoten und Callbacks, wo immer möglich), anstatt sich ausschließlich auf Funktionen wie _get_overlapping_bodies()_ zu beschränken.

Der Grund dafür ist, dass besagte Rückrufe und die Verwendung von Knoten viel schneller sind, als zu versuchen, alles mit einem großen Skript und sehr wenigen Knoten zu erledigen. Der Baum wird größer, aber das ist kein Problem mit Godots Szenen-Instanziierungssystem.

Zum Beispiel können Objekte, die eine konstante Rotationsrate benötigen, einfach eine Animation dafür verwenden, anstatt die Rotation manuell mit GDscript einzustellen, Dinge, die auf Timing angewiesen sind, können Timer-Knoten verwenden und so weiter. Ich denke, ein unmittelbarer (und unkomplizierter) Weg, um schnellere Spiele zu ermöglichen, wären mehr Knotentypen zur Auswahl (jeder mit eigenen Rückrufen und Verbindungen).

Codedateien werden einfach zu lang

Meinst du solche Skripte? https://github.com/Algorithmus/CastlevaniaClone/blob/master/game/players/player.gd
Glauben Sie, dass C# dies verhindern kann? Ich persönlich nicht. Tatsächlich macht es es aufgrund der Tools (ja, wenn Leute C# meinen, meinen sie oft implizit VS) und der statischen Typisierung einfacher, Fehler früher in diesen langen Skripten umzugestalten und zu erkennen, obwohl Knotenpfadfehler nicht erkennbar wären, bis das Spiel läuft. Abgesehen davon können Skripte durch gutes Design und die Verwendung von Knoten erheblich vereinfacht werden.

Dem Code-Editor fehlen viele nützliche Funktionen, die in anderen IDEs zu finden sind, wie z. B.: Reduzieren von Bereichen, Regionen, Springen zum Anfang/Ende des aktuellen Bereichs.

Diese können in Zukunft hinzugefügt werden, wenn Sie danach fragen, obwohl Sie problemlos einen externen Editor verwenden können (https://atom.io/packages/lang-gdscript), Godot hat sogar Autovervollständigungsdienste.

Wenn Sie tatsächlich ein RIESIGES Spiel erstellen, möchten Sie Godot wahrscheinlich mit C++ erweitern.
Eigentlich finde ich das wegen des Engine-Rebuild-Prozesses derzeit etwas abschreckend, aber es gibt Gründe dafür .

Es gibt kein Klassen-Szene-Beziehungsbewusstsein

Wie meinst du das? Sie wissen, dass Sie ein Skript in den Stamm einer Szene einfügen können, richtig? Außerdem können C#-Editoren nicht erraten, was sich in der Szene befindet, in der sie verwendet werden, während GDScript dies kann.

Aufgrund der Natur von GDScript gibt es auch keine Funktionsreferenzen und keine Vorlagen.

Es gibt funcref und signal wenn Sie nach etwas suchen, das Lambdas und Ereignissen ähnelt, und Templating ist keine Sache, da die Sprache dynamisch ist. Dynamische Sprachen bevorzugen häufig die Verwendung von Ententypisierung anstelle von Schnittstellen und Generika. Auch Komposition über Vererbung spielt sich sehr gut, wenn Sie wiederverwendbare Dinge wollen.

GDScript fehlen auch viele grundlegende Funktionen prozeduraler Sprachen

Ich stimme ein bisschen zu. Einige von ihnen wurden angefordert, aber ich erinnere mich nicht an die Probleme, Sie müssen suchen. Zum Beispiel würde ich gerne ein for , das auf etwas anderem als ganzzahligen Bereichen und Containern (Float?) iterieren kann, also verwende ich while . Das ist in der Tat ein bisschen nervig, aber nichts allzu Ernstes.

Meinst du solche Skripte? https://github.com/Algorithmus/CastlevaniaClone/blob/master/game/players/player.gd

Ich muss sagen, dass selbst wenn die Datei lang ist, ich schon viel Schlimmeres gesehen habe und sie immer noch ziemlich lesbar ist, obwohl der Code ziemlich prozedural ist. Jetzt verstehe ich endlich, warum eine einfache Syntax für GDScript besser ist: Sie ist die beste für durchschnittliche Spiellogik, die hauptsächlich aus if s und Funktionsaufrufen besteht.

Ich würde gerne jemanden sehen, der argumentiert, dass dieselbe in C# geschriebene Datei einfacher zu lesen oder zu schreiben ist oder andere praktische Vorteile als die Leistung bietet (die ohnehin schlechter ist als die von C++). Ich denke, C# wäre ein Overkill für diese Art von Skripting, das komplizierter ist als das Skripting, das in einigen professionellen 2D-Spielen verwendet wird.

Ich stimme ein bisschen zu. Einige von ihnen wurden angefordert, aber ich erinnere mich nicht an die Probleme, Sie müssen suchen. Zum Beispiel würde ich gerne ein for sehen, das auf etwas anderem als ganzzahligen Bereichen und Containern (float?) iterieren kann, also verwende ich while. Das ist in der Tat ein bisschen nervig, aber nichts allzu Ernstes.

Könnten Sie den for -Teil und einige Beispiele für das, worauf Sie sich in Pseudo-GDScript beziehen, ein wenig vertiefen?

@paper-pauper die Dinge, die GDScript fehlt, haben nichts mit C# zu tun, aber zum Beispiel for i in range(-PI, PI) funktioniert nicht in GDScript, ebenso wie for i=0, i < size and stuff, ++i . Ich würde auch gerne ternär schreiben, anstatt ein Drei-Zeilen-wenn schreiben zu müssen. Aber wie gesagt, es gibt bereits Probleme im Tracker und es wird mich nicht davon abhalten, GDScript zu verwenden: p

Aber selbst wenn alle Ihre Skripte maximal 200 Zeilen lang und relativ gut gestaltet sind, werden Sie Probleme haben, diese Codebasis zu pflegen und zu überarbeiten, wenn Sie Tausende davon in Ihrem Spiel haben: und das liegt nicht so sehr an der Sprache, aber wegen der Tools : Ein großer Teil der Popularität von C# ist darauf zurückzuführen, dass Visual Studio eine verdammt gute IDE dafür ist. Ich bin mir ziemlich sicher, wenn Godot geeignete Tools integriert (Goto-Definition, zuverlässiges Umbenennen von Klassen/Funktionen/Mitgliedern, alle Referenzen finden usw.), wird die Arbeit an riesigen GDScript-Codebasen viel einfacher. Allgemeiner gesagt, das würde ich gerne in Godot sehen, wie kann es gut für BIG-Spiele skalieren, weil ich bisher keine gesehen habe (einschließlich meiner eigenen Projekte).

for i in range(-PI, PI)

Das bringt meinen Kopf dazu, sich um seine eigene Achse zu drehen, bis er eine Division durch Null erreicht und anfängt, Entropie zu zerstören. Ich hoffe, dass keine Sprache eine so unvorhersehbare Aussage implementiert. Was tut es? Iterieren Sie über ganze Zahlen zwischen -PI und PI (dh -3, -2, ..., 2, 3) oder zwischen Vielfachen von PI (dh -PI und 0), oder iterieren Sie über Floats, die einem Voodoo-Standardschritt ähnlich sind 0.176 oder ln(2) , die ein Sprachprogrammierer am geeignetsten fand?

@akien-mga oops tut mir leid. Ich hätte in der Tat ein Schrittargument hinzufügen sollen xD, aber es funktioniert immer noch nicht. Hier ist das Problem, das ich dafür gemacht habe https://github.com/godotengine/godot/issues/4164

Ich stimme zu, dass Godot Werkzeuge vermisst. Das Hauptproblem ist die Duck-Typing-Natur von GDScript, die es schwieriger macht, zu wissen, was was ist, und es daher schwierig macht, einige Aktionen wie "Referenzen finden" oder "Zur Definition gehen" auszuführen.

Es ist geplant, Typhinweise zu GDScript hinzuzufügen, aber da dies optional ist, bin ich mir nicht sicher, wie viel verbessert werden kann. Es wird sicherlich viel zur Codevervollständigung beitragen und die Arbeit an besseren Werkzeugen erleichtern.

@vnen Ein EMACS-Modus für GDScript in (M)ELPA wäre meiner Meinung nach schon ein Schritt in die richtige Richtung :)

Oh ja, hätte fast diese beiden Probleme vergessen, die mich lustigerweise in der Praxis tatsächlich verlangsamt haben:

• Argumente sind nicht Teil der Signatur einer Funktion. Das bedeutet, dass Sie keine Funktionen überschreiben können.
  In der Praxis führt das Vorhandensein von function doFoo(a,b,c,d) und function doFoo(a,b) in derselben Klasse dazu, dass die Kompilierung fehlschlägt. Am Ende habe ich sie in doFoo4(a,b,c,d) und doFoo2(a,b) umbenannt und eine Reihe von Skriptdateien umgestaltet.
• Da Aufzählungen nicht unterstützt werden, sind alle Flags und Rückgabecodes zwangsläufig ints, sodass Sie sie erraten müssen, und viele sind derzeit noch undokumentiert.

PS: Offensichtlich wurden die Funktionen nicht wörtlich doFoo genannt. ;)

EDIT: @Ace-Dragon: Andere Engines haben mir beigebracht, dass komplexe eingebaute Knoten/Komponenten/etc. kann und wird sich ändern und dabei das Spiel brechen. Aus diesem Grund verlasse ich mich abgesehen von einfachen Trigger-Callbacks (Kollisionen, Werte, Timer) lieber nicht zu sehr auf sie.
Ich bin auch kein großer Fan des Signal-Slot-Paradigmas, also vermeide ich es, wenn möglich. Andererseits ziehe ich Threads auch Coroutinen vor, nenne mich einen Ludditen :)

@Zylann : ~1200 LOC?... pffft Nein, ich spreche von der echten Sache... 20k+ LOC pro Datei. Ein RPG-Entwickler, der Unity verwendet, das unbenannt bleiben soll (nein, ich arbeite nicht für sie), hat routinemäßig Klassen mit 25k+ loc. Andererseits machen sie alle ihre Funktionen statisch und verwenden C#, als wäre es C. :ängstlich:

Sorry für das Off-Topic.

@ eye776 Mir

Und bahnbrechende Änderungen an der Engine können in einem freien Programm wie Godot leicht erkannt und rückgängig gemacht werden, sodass sie kein Grund zur Sorge sein sollten.

@ eye776 Ich habe auch noch nie dynamische Sprachen mit Funktionsüberschreibung gesehen. GDScript hat Standardparameter, sodass diese stattdessen verwendet werden können.

Außerdem, wer ist der Verrückte, der mehr als 20.000 LOC in einer einzigen Datei macht? Das Problem liegt hier nicht am Tool... In der ganzen Godot-Quelle gibt es keine einzige Datei, die ich mit 10K LOC finden konnte.

Was ich zustimme, ist, C++ ein wenig mehr Liebe zu geben. Aber für die Verwendungen, die Sie zuvor zitiert haben, stimme ich nur AI zu. Und auch prozedurale Generierung, um noch eines zu nennen. Wenn Sie jetzt die Engine-Physik, das Rendern usw. neu erstellen, dann sage ich, Sie verwenden Godot nicht einmal mehr, Sie haben nur eine Abzweigung gemacht. Wenn Sie sich nicht auf die eingebauten Typen verlassen können, wofür brauchen Sie die Engine?

Natürlich ist GDScript nicht perfekt (keine Sprache ist es). Es ist auch nicht in Stein gemeißelt. Aufzählungen, Switch/Case- und ternäre Operationen sind einige wahrscheinliche Ergänzungen in der Zukunft (dazu gibt es bereits offene Fragen). Nur weil es gerade etwas nicht hat, heißt das nicht, dass es nie etwas haben wird.

Schließlich helfen "Zweifel" nicht wirklich weiter. Was wir brauchen, sind Benchmarks und Use Cases. Es gibt bereits ziemlich komplexe Spiele, die in GDScript geschrieben wurden, also sehe ich nicht, was wirklich fehlt.

@vnen nur zum Spaß: godot/drivers/gles2/rasterizer_gles2.cpp ist 11K LOC :p (es ist das größte, das ich gefunden habe, aber es ist eine seltene Ausnahme).

@vnen

Wenn Sie sich nicht auf die eingebauten Typen verlassen können, wofür brauchen Sie die Engine?
Nun, als plattformübergreifender Qualitätskontext für den Anfang. Aber das bedeutet nicht, dass ich meine eigenen Sprite- oder Modellklassen schreiben werde.

Godot hat mich im März einmal verbrannt (v 2.0.1). Ich habe mit einer 3rd-Person-Kamera und einem Charakter herumgespielt und versucht, Godots eigene Physik für Bewegungen (Widerstand und Kräfte) zu verwenden, und es zum Laufen gebracht.
Das Update der nächsten Nebenversion (v 2.0.2) brach im Grunde die Geschwindigkeit des Charakters (2-3x schneller) für genau die gleichen Werte.
Ich fand heraus, dass es besser war, es einfach kinematisch zu halten und meine eigene "Physik" zu machen.

Außerdem habe ich mich, unabhängig von Godot, viele Male verbrannt, weil ich mich auf automatisierte Dinge wie die Storyboards von XCode verlassen habe.
Irgendwie hörte ich auf, mich von Shiny umwerben zu lassen und betete, dass der von der IDE hinter meinem Rücken automatisch generierte Code nicht mit meinem durcheinander kommt.

Jedenfalls tut es mir sehr, sehr leid, dass ich den Thread entgleist habe.

@eye776 Hast du den Commit-Diff von 2.0.1 zu 2.0.2 überprüft, um zu sehen, was dein Spiel kaputt gemacht hat? Es könnte ein Fehler gewesen sein und die Meldung könnte der gesamten Community zugute kommen.

Mono oder CoreCLR? Und warum?

Mono:

• MIT-lizenziert
• stabil
• Möglichkeit verlassen zu werden
• gute Dokumentation

CoreCLR:

• MIT-lizenziert
• immer noch nicht 1.0 (derzeit ist es RC2)
• klein
• schlechte Dokumentation

Wir verwenden Mono, weil es auf Mobilgeräten und im Internet bereitgestellt wird. Ich denke hier ist
Null Chance, dass es aufgegeben wird, weil es viel tragbarer ist. Meine Vermutung
ist, dass beide Codebasen schließlich zusammengeführt werden.

Am Do, 4. August 2016 um 13:45 Uhr, Hubert Jarosz [email protected]
schrieb:

Mono oder CoreCLR? Und warum?

Mono:

• MIT-lizenziert
• stabil
• Möglichkeit verlassen zu werden
• gute Dokumentation

CoreCLR:

• MIT-lizenziert
• immer noch nicht 1.0 (derzeit ist es RC2)
• klein
• schlechte Dokumentation

—
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/5081#issuecomment -237611905,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AF-Z2zRjC8u_owFzCCyeqIhF8W5XqCtLks5qchchgaJpZM4Ivn7R
.

Zusätzlich zu dem, was @reduz oben erwähnt hat, ist die API gekapselt, sodass es nicht allzu schwierig ist, später bei Bedarf zu CoreCLR zu wechseln.

CoreCLR: immer noch nicht 1.0 (derzeit ist es RC2)

Er erreichte am 14. Juni einen stabilen Wert von 1,0.

Mono: Möglichkeit, verlassen zu werden

Basierend worauf?

Mono: gute Dokumentation

ahaha

Basierend worauf?

Warum sollte Microsoft drei Stacks von .NET entwickeln? Es ist nicht gut in Bezug auf die Ressourcen. (.NET Framework, Mono, .NET Core)

ahaha

Ich habe beide Dokumente über C++/C#-Interop (was wir für Godot brauchen) überprüft und es ist ganz in Ordnung, in Mono dokumentiert. In coreCLR musste ich einen Teil ihres Codes durchforsten und Entwickler um Hilfe bitten, damit meine App funktioniert.

Das Referenzhandbuch hat zu viele undokumentierte Funktionen, defekte Links...

Theoretisch bin ich hier voreingenommen ... Aber ich hoffe, meine Argumente sind objektiv ...

• Ich sehe keinen Rückgang der Mono-Entwicklung: https://github.com/mono/mono/graphs/contributors
• Die Entwicklung für Mono unter Windows war noch nie so stark wie heute (irgendwie ein Beweis (ohne Tonnen von Commits zu verlinken) https://github.com/mono/mono/pull/3231 Miguel sagt: "Da wir jetzt echte Betreuer haben") Making vorherigen Punkt noch deutlicher
• Das Einbetten der API in Mono ist kampferprobt (nicht nur Unity, es gibt viele andere private Benutzer)
• Mono TODAY läuft auf PS4, Android, Windows, iOS BITCODE (dafür wurde jahrelang gearbeitet), AppleTV und vielen weiteren Plattformen...

Also meiner Meinung nach, wenn Sie dies in naher Zukunft (weniger als 3 Jahre) und auf den meisten Spieleplattformen liefern möchten ... Gehen Sie mit Mono.

Hallo,

Einige Kommentare:

• Zusätzlich zu den von David Karlas aufgelisteten Plattformen fügen wir auch native Unterstützung für WebAssembly, XboxOne, UWP und Win64 hinzu.
• Das gemeinsam genutzte Beispiel könnte auch mit virtuellen Methoden (schnellerer Versand) oder mit C#-Ereignissen erstellt werden.
• C# war in der Vergangenheit bei vielen Sprachinnovationen führend und hat überall gute Ideen hervorgebracht. Es hat viele Ideen aus der Sprachforschung populär gemacht und auf den Massenmarkt gebracht, die wir jetzt für selbstverständlich halten, Dinge wie Iteratoren, nicht gelöschte Generika, Lambdas, asynchrone Programmierung, Eigenschaften, Plattformaufrufe, aber es ist eine der Sprachen, die es sind am aktivsten in der Öffentlichkeit entwickelt . Zum Beispiel fügt die kommende Version eine Menge neuer Funktionen hinzu, einschließlich meiner Lieblingsmustererkennung.
• Im Allgemeinen zeigt Unity kein modernes C#, da sie eine ältere Runtime verwenden. Dies wird sich hoffentlich bald ändern. Das aktuelle Mono unterstützt jedoch alle neuen C#-Funktionen, einschließlich der "asynchronen" Programmierung, die ideal für Spielcode ist, da Sie ihn linear schreiben können und der Compiler Ihren Code automatisch als Zustandsmaschine umschreibt - wie Coroutinen oder die Fortgeschrittenen Version von "yield", wie sie in Unity verwendet wird.
• Synchronisierungskontexte bedeutet, dass Sie asynchronen Code schreiben können, der in einem bestimmten Kontext ausgeführt wird. Beispielsweise haben Sie möglicherweise eine spielgebundene Ausführung oder eine IO-gebundene Ausführung oder eine Haupt- vs. Hintergrund-Thread-gebundene Ausführung. Dies ist alles Teil des Systems.
• Während der Bereitstellung haben Sie die Wahl zwischen JIT-Kompilierung oder statischer Kompilierung (AOT) mit oder ohne LLVM, sodass Sie so schnell wie C++ werden, modulo der Tatsache, dass C# Array-Begrenzungsprüfungen durchführt (das heißt, wenn Sie native Puffer, du bekommst deine Leistung zurück, auf Kosten der Sicherheit)
• Angesichts des starken Fokus von Mono auf Mobilgeräte wurde Monos GC in den letzten Jahren nicht auf Server, sondern auf interaktive Workloads abgestimmt. Unser neuer GC ist generationsübergreifend mit kleinen Baumschulen, die sehr schnell gesammelt werden können und nicht den gesamten Haufen scannen müssen.

Der Grund, warum Microsoft mehrere CLRs entwickelt (wir haben drei: CoreCLR für JIT-Workloads; CoreRT-Familie für die statische Kompilierung in UWP; Mono für mobile Workloads), liegt daran, dass sie alle leicht unterschiedliche Zwecke erfüllen. Die Interna konvergieren, wo immer es möglich ist, beispielsweise hat Mono jetzt etwa 60 % des Kerncodes durch Code ersetzt, der direkt mit dem Rest von .NET geteilt wird. Finden Sie heraus, welcher Workload für Sie besser geeignet ist.

Sie können heute mit einer VM beginnen und in Zukunft zu einer anderen wechseln. Derzeit hat Mono eine größere API-Oberfläche, funktioniert auf Mobilgeräten, wurde für interaktive Workloads optimiert und unterstützt mehr Architekturen (wie ARM64).

Die gute Nachricht ist, dass der Austausch einer VM gegen eine andere oder die Unterstützung beider VMs ein paar Tage Arbeit bedeutet, sodass Sie sich nicht auf eine bestimmte Implementierung festlegen müssen.

@migueldeicaza Willkommen! Toll, dass du dich entschieden hast, an unserer Diskussion teilzunehmen und dich für Godot interessierst :+1: Hoffentlich bleibst du noch eine Weile bei uns :)

Danke für die nette Aufschlüsselung @migueldeicaza! Ich habe zwei kurze Fragen an Sie oder andere Mono-Entwickler.

1) Wie sieht die aktuelle Einrichtung zum Debuggen von eingebettetem Mono unter Windows mit Visual Studio aus? Unity hat ihr Plugin, aber ich konnte nichts anderes als Plugins finden, die eine Verbindung zu Linux/OSX-Computern herstellen.

2) Was ist der empfohlene Weg zur Laufzeit-Neukompilierung (Kompilieren, Entladen und Neuladen, sagen wir eine Assembly für Gameplay oder Tool-Plugins im Editor)? C# stellt (sehr) leider keine Assembly.Unload()-Methode zur Verfügung, und der Umgang mit AppDomains und Cross-AppDomain-Problemen scheint für diese Situation übermäßig lästig zu sein.

Als Referenz verwendet nicht nur Unity Mono – https://github.com/xamarin/urho (C#/Mono-Bindungen für die Urho3D-Engine) – dieses hat eine MIT-Lizenz, sodass wir ihre Lösung einfach nachschlagen können.

Meine zwei Cent:

C# ist für die Spieleprogrammierung anderen Sprachen auf ähnlichem Niveau weit überlegen, da es benutzerdefinierte Werttypen unterstützt. Dies ist ein äußerst wichtiges Feature für die Leistung, zu dem Java (und JVM im Allgemeinen) buchstäblich _keine_ Alternative dazu hat.

Du erhältst:

• Vom Stapel zugewiesene mathematische Typen, die mathematische Operationen und temporäre Objekte ohne Heap-Zuweisungen unterstützen.
• Optimierte, Cache-freundliche kontinuierliche Sammlungen.
• Generika, die Werttypen verwenden (einschließlich primitiver Typen)

Darüber hinaus verfügt C# über weitere Funktionen, die Ihnen das Leben erleichtern. Ich sehe keinen Vorteil darin, Java anstelle von C# zu verwenden, wenn C# Java einfach in so ziemlich allem schlägt, was in der _Spiele_-Programmierung wichtig ist.

Hallo zusammen,
Ich habe nicht alles oben gelesen (einfach zu viel :))
Aber ich hatte einige Feiertage, also habe ich ein Prototypmodul für Godot erstellt, das als msDotNetHost fungiert, also kann ich einige Ergebnisse liefern, die ich durchgegangen bin, vielleicht sind sie hilfreich. Leider sind meine Ferien zu Ende gegangen und ich möchte wieder für Geld programmieren :), aber es macht/war lustig :)

Aktueller Stand ist:
o) das Modul erweitert die Node-Klasse, um die Node-Ereignisse für netCode offenzulegen
(init, tree_entered, ready, process, fixedprocess....)),
o) "net host/wrapper module" fertig (unter Verwendung des Microsoft dotNet-Host-Mechanismus)
Es ist in einer dynamischen Bibliothek gekapselt, sodass ein Wechsel zu Mono später einfach sein sollte
o) dotNet-Methoden werden gebunden und aufgerufen (init, tree_entered, ready, process, fixedprocess....)
o) Knotenklasse wird verpackt und an netAssembly gebunden (manuell geschriebener Code für Prototyping)
o) Aufrufe von Godot (von netCode) funktionieren über einen selbst geschriebenen Bindungsmechanismus
(von dll in godot-exe ), sodass die exe keine Funktionen exportieren muss.
o) Aufgrund der Verwendung von msDotNet ist es für die nahe Zukunft an Windows gebunden.

meine Roadmap für die Einbeziehung von .Net wäre:

1. Modul für Godot mit Microsoft .Net-Hosting-Mechanismus (erledigt)
2. Godot-Klassen umhüllen
   (mein aktueller Stand: Schreiben eines Wrapper-Generators, der Godot-C++-Code parst,
   Parsing ist abgeschlossen, Generierung läuft)
3. Holen Sie das Projekt aus dem Prototypenzustand heraus (vervollständigen Sie die Kanten, testen Sie es ...)
4. Schreiben Sie den Mono-Hosting-Mechanismus, um Windows-Anleihen loszuwerden
5. Visual Studio irgendwie zum Debuggen von Mono aktivieren, um xamarin/monodev loszuwerden (wie Unity vs-Plugin )
6. Viel Spaß mit Hunderten von neuen Godot .net-Entwicklern :)

einige Fragen:

1. Ich frage mich, ob ich den für gdscript verwendeten Bindungsmechanismus wiederverwenden könnte. aber ich habe keine Zeit, alles zu bewerten, gibt es da draußen ein paar gute Tuts oder ein paar Highlvl-Tipps für mich?

2.
Derzeit generiere ich einen Wrapper, der alle Godot-Methoden in Funktionen verpackt, damit sie einfach über die DLL-Grenze und die C++/NetCode-Grenze aufgerufen werden können. (selbst geschriebener Bindungsmechanismus für netCode)
Ich möchte den Godot-Code (außer meinem Modulcode) nicht ändern, um kompatibel zu bleiben.
auch statisch, nicht statisch, virtuell nicht virtuell hat mich zum weinen gebracht, deshalb habe ich mich für diesen weg entschieden.
eine bessere Lösung dafür?

einige zusätzliche gedanken:

Microsoft .Net vs. Mono:

Ich denke, es spielt keine Rolle, ob Sie Mono oder msDotNet verwenden, da dotNet-Code in den meisten Fällen unverändert auf beiden ausgeführt wird. Der einzige Versuch, beides zu unterstützen, besteht darin, für jeden von ihnen einen "Host" zu schreiben (das ist der kleinste Teil eines "GodotDotNet"). Ich habe mich für msDotNet für das Prototyping entschieden.
Nun, Mono unterstützt viele Plattformen, msDotNet nur Windows, warum also msDotNet unterstützen/verwenden?
Die Antwort: Produktivität, Debugging

msDotNet:
Besonders beim Schreiben/Prototyping des DotNetModuls brauche/will ich SCHNELLES Kompilieren und Debuggen, bedeutet, dass Ihr Debugger von C++ in NetCode springen sollte und umgekehrt.
Ich wähle VisualStudio, weil es beides debuggen kann. ABER nur, wenn Sie msDotNet verwenden.
Wenn Sie dies tun, ändern Sie ein Stück netCode, drücken Sie auf Ausführen und in 1 Sekunde! es ist kompiliert und läuft!!! einschließlich der Möglichkeit, in Godot zu debuggen. (wenn du nichts in godot geändert hast, dann musst du die normalerweise 30sek bis 1min warten...verdammt langsame scons! :) )

Mono:
Mono muss das Endziel sein, darüber gibt es keine Diskussion (Plattformunabhängigkeit), aber:
Wenn man Mono verwendet, hat man ein großes Problem beim Debuggen: Mono hat seinen eigenen Debugging-Mechanismus!
Für mich ist es ein großer Erfolg für die Produktivität, denn wenn Sie kein Monodebug-Plugin für Visual Studio schreiben (Unity hat dies getan), können Sie Mono-Hosted-Netcode in Visual Studio nicht debuggen und in C ++ - Code debuggen (es gibt Hack-Lösungen, aber ...).
Ich habe versucht, eine Mono-basierte Lösung einzurichten, aber am Ende habe ich beide parallel verwendet, VisualStudio (für C++) und xamarin/monodev (Netcode).

Fazit:
Prototypzustand: msDotNet
lateron: mono, für Benutzer, die nicht daran interessiert sind, in Godot/C++ und Plattformunabhängigkeit zu debuggen
Danach: Erstellen Sie ein vs-Plugin zum Debuggen von Mono

C# im Vergleich zu Java:
die antwort ist klar c#! java ist für scritpkids! (Oh, was denken C++-Programmierer über C#-Entwickler :))
nein das war ein Witz :)
Ich verstehe die Diskussion nicht ... wenn das .net-System implementiert ist, können Sie jede Sprache verwenden, die dotNet unterstützt, einschließlich beider Sprachen und mehr.
Dies ist nicht der Fall, wenn das Java-System unterstützt wird ...

@Ziflin :
Frage 1:
habe das auch gesucht ... nur monoRemotedebugger ist die (nicht) Lösung atm :(
meine empfehlung ist, wie oben angegeben: verwenden sie microsofts dotnet-hosting für das prototyping
dann irgendwann auf mono umschalten.
Alternative:
Starten Sie xamarin im gehackten Modus, lassen Sie es auf localhost hören, setzen Sie die Haltepunkte, starten Sie dann Ihr Projekt in vs. Ich habe es getestet, es funktioniert, aber ...
für mich ist das keine lösung! ich will einen "hit run and debug in 1 second"- Mechanismus und das mit 1 Klick!
In meiner Freizeit habe ich nicht viel Zeit, also ist Produktivität mein Hauptziel.

Frage 2:
Ich kenne Mono noch nicht so gut, aber ich denke, Sie müssen das in C++ tun, Mono-Hosting implementieren und es von "außen" in C++ verwalten.

Die offiziellen C#-Bindungen von @CharlesWoodhill sind bereits fertig und können hier eingesehen werden https://github.com/neikeq/GodotSharp/

cool tnx, dann weiß ich wie ich einige meiner nächsten ferien verbringe ;)

Hallo, ich bin gerade auf GodotSharp gestoßen, aber das ist gelöscht.

das ist gefallen.

Die offizielle Version, die ich im IRC gehört habe, war etwa so:

@neikeq pusht nicht gerne unfertigen Code, also arbeitet er an seinem lokalen Zweig

Gut zu wissen, ich wollte gerade mein eigenes Modul machen, aber ich denke, ich könnte es genauso gut für Godot 2.2 oder 3.0 tun

Es wird keine 2.2-Version geben, Godot-Entwickler haben alle 2.2-Funktionen auf 3.0 verschoben.

Dies ist mein erster Kommentar. Ich kam von Unity und der Wechsel zu GDscript war ein Traum. Ich habe die Sprache in weniger als einem Tag gelernt. Ich liebe es, wie gut die Sprache in die Engine implementiert ist, und meine Produktivität ist erheblich gestiegen.

Meine Hauptsorge ist, dass GDscript mit zusätzlicher C#-Unterstützung nach einer Flut von Unity-Entwicklern zurückbleiben oder weniger Entwicklung erfahren wird. C# ist eine schöne Sprache, aber nicht mein persönlicher Favorit

Außerdem macht es mir Sorgen, dass Godot versucht, mehr wie eine andere Engine zu sein, anstatt für sich allein zu stehen. Unity ist eine fabelhafte Erfolgsgeschichte, aber nicht die beste Engine, die ich je benutzt habe. Es ist aufgebläht und fehlerhaft. Einmal wurde mein gesamtes Projekt ohne Bestätigung gelöscht. Der Umgang mit Fehlern und Dingen, die nicht so funktionierten, wie sie sollten, war ein ständiger Kampf. Ich kann nicht zählen, wie oft ich eine Szene, an der ich gerade arbeitete, komplett neu erstellen musste, weil die Dinge nicht richtig funktionierten. Ich habe einmal den gesamten Inhalt einer alten Buggy-Szene kopiert und in eine neue Szene eingefügt, damit es plötzlich funktioniert, obwohl beide Szenen identisch sind. Ich habe Wochen damit verloren, Physikfehler zu jagen, die auf magische Weise erscheinen und verschwinden würden.

Ich mag es wirklich, dass Godot schlank und einfach zu verstehen ist. Die Arbeit mit Godot war, als würde man ein gut gestimmtes Musikinstrument benutzen. Nachdem ich fast ein Jahr darin gearbeitet habe, weiß ich einfach, wie ich alles tun muss, was ich tun muss, auch wenn ich es noch nie zuvor getan habe. Ich hoffe nur, dass der Zustrom von Unity-Benutzern die Richtung der Engine nicht mehr in Richtung Unity lenken wird. Wenn ich Unity wollte, würde ich Unity verwenden.

@zaywolfe Ihre Bedenken wurden einige Male von anderen Benutzern geäußert. Du musst dir keine Sorgen machen. GDScript wird weiterhin die Hauptsprache in Godot sein.

Ich mag GDScript nicht . Ich verstehe, dass das nach Python modelliert wurde, aber ich fühle mich sehr mickrig. C++ oder Java inklusive (out of the box) wäre meiner Meinung nach eine tolle Idee. Ich persönlich fühle mich angewidert, GDScript in der Entwicklung zu verwenden, bis zu dem Punkt, an dem ich mich frage, ob ich Godot verlassen und wiederkommen soll, wenn eine neue (oder alternative) Sprache implementiert wurde. Tut mir leid, aber wenn Sie die harten Fakten von einem Programmierer möchten, haben Sie sie.

Außerdem möchte ich erwähnen, dass ich Godot manchmal sogar für ein einfaches Software-Prototyping verwende. Somit würde eine tief integrierte Programmiersprache möglicherweise Türen für die Softwareentwicklung innerhalb der Engine öffnen. Das wäre wirklich ein Unity-Killer. (Falls natürlich Java oder C++ gewählt wurde)

Vielen Dank an die treuen Entwickler für Ihre harte Arbeit. Ich schaue zu Ihnen allen auf und freue mich auf die zukünftigen aktualisierten Versionen!

@VenHayz Ich weiß nicht, ob Sie die Godot-Dokumentation lesen, aber Sie können Ihre Spiele bereits seit der ersten Version von Godot in C++ schreiben - http://docs.godotengine.org/en/stable/reference/custom_modules_in_c++.html

Was ist mit der Verwendung des Microsoft .net-Kerns? Es ist plattformübergreifend und leistungsorientiert, außerdem ist es Open Source und wird aktiv weiterentwickelt

Hallo, nur ein zufälliger Typ, der vorbeikommt

Ich wollte Sie wissen lassen, dass ich Godot nicht verwende, weil ich die von Ihnen verwendete Skriptsprache nicht mag

Wenn Sie Java oder C# hinzufügen, werde ich Godot direkt nach Ihrer Ankündigung installieren und verwenden :)

@RUSshy auf Wiedersehen, es ist dein Verlust, Godot ist großartig, GDScript ist großartig, wenn du ein echter Programmierer bist, wirst du buchstäblich zwei Stunden brauchen, um mehr als genug zu wissen, um ein Projekt zu starten. Echte Programmierer müssen viele Sprachen beherrschen, Sie können bei Ihrem Java/C# bleiben und für immer ein "zufälliger" Typ sein, der als Bastler vorbeikommt. Ich versuche nicht unhöflich zu sein, sondern nur Fakten zu nennen. Wenn Ihnen etwas an dieser Engine nicht gefällt, tragen Sie etwas Code bei, sie ist im Gegensatz zu den meisten anderen Engines kostenlos.

Der Gott des Marketings bevorzugt C#. :Lachen:

@RebelliousX Wenn Sie sich für Java oder C# entscheiden, haben Sie eine Menge Bibliotheken zur Hand, die Sie verwenden können

Es ist einfach nutzlos, sich auf hausgemachte Skriptsprache zu beschränken, Ihr neues Wissen wird nirgendwo anders anwendbar sein, und Sie werden nicht in der Lage sein, unzählige Bibliotheken zu finden oder Ihr Wissen oder vorhandene Lernressourcen wiederzuverwenden

Heutzutage ist die Auswahl verrückt, seien Sie nicht engstirnig

@RUSshy Willst du mich verarschen? Ich (und mehrere andere) haben buchstäblich seitenlange Erklärungen über die Vorteile von GDscript gegenüber C# geschrieben, und Sie glauben, Sie könnten die Diskussion mit einem kurzen Absatz lösen, ohne etwas zu lesen, was zuvor gesagt wurde?

"Seien Sie nicht engstirnig" - tolle Idee, wie wäre es, wenn Sie GDscript gegenüber aufgeschlossen sind?
"Ihr neues Wissen wird anderswo nicht anwendbar sein" - das ist einfach falsch. Sie können mangelndes Wissen nicht durch Kopieren und Einfügen von Code ausgleichen, den Sie nicht verstanden haben.
"Sie werden nicht in der Lage sein, unzählige Bibliotheken zu finden" - lernen Sie den Unterschied zwischen einer Skriptsprache und einer Backend-Sprache kennen. Oder - verrückte Idee - lesen Sie, was ich darüber geschrieben habe.

Ernsthaft, die Kühnheit mancher Leute...

Es wurde mehrfach an verschiedenen Stellen gesagt, dass ein C#-Integrationsmodul in Arbeit ist. Es geht so schnell wie die Zeit, die die Leute dafür haben. Die einzige Möglichkeit, es schneller zu machen, besteht darin, zu dieser Integration beizutragen :)

@Warlaan zum zweiten Punkt: Wenn Sie zuvor eine Menge Code in C # geschrieben haben, können Sie ihn nicht wiederverwenden, es sei denn, Sie portieren ihn vollständig. Sie müssen den Code einer Bibliothek auch nicht verstehen, um sie verwenden zu können. Der Punkt ist, wenn Sie etwas benötigen, das zuvor in C# enthalten war (eine einzelne Datei oder eine Reihe von Bibliotheken, potenziell geschlossene Quellen), müssen Sie entweder alles portieren, eine C#-Laufzeitumgebung einbetten oder eine C-Implementierung finden. Das ist nicht unmöglich, aber zeitaufwändig.
Das bedeutet jedoch nicht, dass Godot nicht viele vorhandene Bibliotheken verwenden kann ... C/C++ hat auch jede Menge davon.

Das droht ein Flammenkrieg zu werden.
Das Protokoll ist so lang, dass Leute dieselben Fragen oder dasselbe Thema wiederholen, anstatt es zu lesen.
Auch technisch gibt es nicht mehr viel zu diskutieren.

Die Zukunft von Godot in Bezug auf das Skripting ist bereits ziemlich klar:

• GDScript wird die Hauptsprache bleiben und es gibt Pläne oder Ideen, es zu optimieren (aber dies ist nicht der richtige Ort, um das zu diskutieren).
• Ab 3.0 wird C# als Scripting-Alternative unterstützt. Wir werden separate Binärdateien bereitstellen, um zu vermeiden, dass die zusätzliche Größe, die durch die Mono-Laufzeit verursacht wird, Personen aufgezwungen wird, die sie nicht verwenden.
• DLScript ist auch an der Arbeit. Es wird Benutzern ermöglichen, gemeinsam genutzte Bibliotheken für die Skripterstellung zu verwenden. Diese Bibliotheken können in jeder Sprache geschrieben werden, die C-Linkage und gemeinsam genutzte Bibliotheken unterstützt (erwarten Sie Sprachen wie Rust und D). Es ist jedoch noch nicht klar, ob es für 3.0 bereit sein wird (es sei denn, ich bin veraltet).
• Vergessen Sie nicht, dass es auch Visual Scripting in 3.0 geben wird!

Wenn jemand vorhat, etwas anderes beizutragen, ist dies auch nicht der richtige Ort, um darüber zu diskutieren.

Ich denke, dieses Thema kann und sollte geschlossen werden.

Einverstanden.

Könnten Sie bitte einen Link zu den Quellcodes der C#-Integration bereitstellen?

https://github.com/neikeq/GodotSharp

Wie funktioniert die GodotSharp-Integration? Ist zum Testen einsatzbereit?
Kann mit Source Build von Godot Master verwendet werden?

@nictaylr Es wird derzeit nicht mit Master gebaut. Wenn Sie es testen möchten, müssen Sie 2.2-Legacy verwenden. Mit dieser Version funktioniert es sehr gut

Ich arbeite daran, es für eine 3.0-Alpha im April bereit zu haben.

Zufällige Idee, aber nachdem ich mit Godot tief in C++ nachgedacht hatte, dachte ich an etwas möglicherweise Besseres. Die D-Sprache. Es fällt unter eine wohl "niedrige" Sprachquote, mit Schnittstellen zu C und (etwas) C++-Unterstützung. Es hat Klassen und ist sehr modern. Obwohl es beängstigend klingt, sieht es sehr nach GDScript aus , und ich könnte mir vorstellen, dass es für sehr große Projekte verwendet wird. Es ist leistungsfähig genug, um mit C und C++ (gcc/g++) mit einem Compiler namens GDC zu konkurrieren. (DMC kann auch zum Kompilieren verwendet werden, aber GDC kompiliert direkt zu gcc) Weitere Informationen zu GDC finden Sie hier

Wie auch immer, nur ein kurzer Vorschlag oder vielleicht für Ideen.

@VenHayz Ich arbeite an einem Modul, das die Verwendung gemeinsam genutzter Bibliotheken für Skripte ermöglicht. Ich habe bereits einige Anstrengungen unternommen, um die Verwendung von C++ damit zu vereinfachen. Sie können D auch verwenden, um diese Bibliotheken zu erstellen. Wenn Sie daran interessiert sind, D-Bindungen zu erstellen, kontaktieren Sie mich im IRC oder Discord.

@karroffel das ist echt cool. Ich habe keine Erfahrung mit dem Schreiben von Bibliotheken und APIs (Verweis auf Ihre Erwähnung von "Bindungen"), obwohl ich wahrscheinlich nur einen Tag lang recherchieren und es tun könnte. Ich bin stolz darauf, schnell zu lernen. Ich würde dich gerne auf Discord kontaktieren, wenn es dir nichts ausmacht? Mein Zwietracht: _hasCat#3941

@VenHayz Ich kann dich nicht hinzufügen, du erlaubst anderen nicht, dich hinzuzufügen. Karroffel#8409 oder tritt dem Godot-Server bei

@neikeq Ist Ihr GodotSharp-Repo die Codebasis, die für die C#-Unterstützung in Godot 3.0 verwendet wird? Ich frage nur, weil ich versuche, eine ungefähre Vorstellung davon zu bekommen, welche Funktionen verfügbar sein werden, und wenn ja, werde ich in dieser Codebasis herumstöbern. Danke!

Ich sehe gottscharf aus, ist veraltet ? neue Funktion ? oder ist bereit zur Verwendung in der Entwicklungsumgebung?

Wie kann ich Godosarp aus Source für mich kompilieren?

@nictaylr Sie müssen den 2.2-Legacy-Zweig als Entwicklungs-Build verwenden.

Ich glaube, ich habe genug gelesen, um herauszufinden, ob jemand anderes dies erwähnt hat.

Ich persönlich möchte einfach nicht noch eine Sprache lernen, die ich nirgendwo anders anwenden kann. Ich habe nicht vor, viel 3D-Programmierung zu machen, nur ein paar Dinge hier und da.

Ja, es gibt viele Gegenargumente dagegen, aber ... es ist ein Open-Source-Projekt. Es besteht kein Grund, jemanden zu hassen, der eine neue Programmiersprache beisteuert.

Stellen Sie sich vor, Sie bringen Bier zu einer Kinderparty. Würden Sie sagen, dass „es keinen Grund gibt, jemanden zu hassen, der ein neues Getränk beisteuert“? Es besteht eine gute Chance, dass das Hinzufügen von C# der Entwicklung von GDscript schaden wird. Ich weiß, dass jeder fest entschlossen ist, GDscript als primäre Sprache für Godot beizubehalten, aber es ärgert mich immer noch, wenn mehrmals erklärt wurde, warum das Hinzufügen neuer Funktionen Nachteile hat, und die Leute immer noch fragen: "Was ist der Schaden?".

Auch die Frage nach C # anstelle von GDscript, weil "Sie nicht lernen wollen", ist ein wirklich dummes Argument. Von allen Sprachen, die ich in der Spieleentwicklung kenne, hat GDscript die wenigsten Funktionen und C# hat bei weitem die meisten. Wenn Sie nicht lernen wollen, sollten Sie GDscript dankbar sein.

Ich möchte diese Diskussion wirklich nicht immer wieder aufwärmen, also bitte, wenn jemand diesen Thread kommentieren möchte, BITTE VON OBEN LESEN.

Auch die Frage nach C # anstelle von GDscript, weil "Sie nicht lernen wollen", ist ein wirklich dummes Argument.

Ich hätte nichts dagegen, C# zu lernen, weil ich es vielleicht woanders verwenden könnte.

Schließ einfach den Thread, es wird gemein.

Es ist wahr, dass dieser Thread seinen Zweck erfüllt hat, lasst ihn uns sperren.