Mag deinen Beitrag wirklich.

BEARBEITEN:
Verdammt, es hat diesen Absatz übersehen

Haben Sie eine Möglichkeit, die Dateien tatsächlich in das Projekt zu kopieren, falls eine Änderung auf Quellebene gewünscht wird. Erst dann sollten die Dateien in den Projektordner selbst gebracht werden. "Geklonte" Assets könnten sich in einem versteckten Ordner wie .custom befinden.

Sie haben also im Grunde genommen die Bedenken behandelt, die ich hatte. (Verzeihung)
Ich gehe einfach genauer darauf ein, wie ich mir den Workflow + das Verhalten vorstelle.

POST:
Ein Workflow wird meiner Meinung nach jedoch übersehen.
Verwenden von Vermögenswerten nur als Ressourcen oder als erste Bausteine.
Mit dem aktuellen, wirklich transparenten und einfachen Ansatz können Sie auch einfach ein paar Assets herunterladen. einige Dateien löschen. Dann behalten Sie einige PNGs und ein Skript, das einige der gewünschten Funktionen enthält. Derzeit ist es möglich, sie nur zu bearbeiten und zu modifizieren.

Wenn Assets in einem .local/godot/assets -Ordner versteckt würden, würde diese Funktionalität irgendwie verloren gehen.

Vorschlag

Assets sollten weiterhin sichtbar und im Dateibrowser im Editor aufgelistet sein. Unabhängig davon, ob sie sich im Ordner .local/godot/assets oder im Projektordner selbst befinden. So können Sie die Dateien durchsuchen und verstehen, wie es funktioniert, falls es keine ordnungsgemäße Dokumentation gibt oder wenn Sie daraus lernen möchten.
Jeder Ordner, der ein Asset ist, sollte auch mit einem Symbol gekennzeichnet sein, damit Sie einen Überblick darüber haben, was ein Asset ist und wo die eigentlichen Dateien gespeichert sind.
Es sollte auch ein Editorfenster geben, das alle Assets auflistet. (in einer Tabelle)

• Heruntergeladen listet alle heruntergeladenen Assets auf. Sie können Ihrem Projekt mit einem Klick auf eine Schaltfläche hinzugefügt werden. Aber ansonsten sind sie die gleichen wie Assets in der Asset Lib. Diese Liste ist in jedem Projekt gleich und hat keine Auswirkungen auf das Projekt selbst. (Erleichtert nur den Überblick. Es ist auch einfach, diese Liste zu löschen und alle Assets beim Öffnen eines Projekts erneut herunterzuladen.)
• Immer aktiv (schaltet im Grunde nur "In diesem Projekt verwendet (aktiv/inaktiv)" für jedes Projekt um) Diese Assets werden JEDEM PROJEKT auf Ihrem Computer hinzugefügt (sogar neu erstellten). (Vielleicht muss das Asset selbst dies zulassen.) Diese sind wirklich Editor-orientiert. Wie eine Uhr in der Ecke, Git-Unterstützung, Aufgabenlisten oder mehr Standardressourcen: (eine benutzerdefinierte Umgebung, einige weitere Themen und ein Haufen Sprites, mit denen Sie zu Beginn jedes Projekts arbeiten können) ...
  Sie können pro Projekt manuell deaktiviert werden.
  Sie sind jedoch immer noch im Projektdateisystem aufgeführt und verhalten sich wie alle anderen Assed/Plugins. damit Sie ihre Dateien durchsuchen und sehen können, wie sie funktionieren/was sie tun.
• In diesem Projekt verwendet (aktiv/inaktiv) zeigt dies tatsächlich den verknüpften Ordner im Projektdateisystem an. und "fügt" (sie befinden sich immer noch im Ordner .local/godot/assets , verhalten sich aber wie lokale Projektdateien.) Dateien zum Projekt hinzu.
  Hier können Sie auch auswählen, welche Version des Assets Sie aktiviert haben möchten. Und wechseln Sie die Version.

Sobald Sie eine Datei aus einem Asset bearbeiten/speichern/aktualisieren möchten, werden Sie mit zwei Optionen aufgefordert

Sparen Sie in .local/godot/assets

Aktualisieren Sie entweder das Asset in .local/godot/assets , wodurch es in eine benutzerdefinierte Benutzerversion versetzt wird.
Wenn der Paketmanager auf Git basiert, könnte die benutzerdefinierte Benutzerversion ein zusätzlicher Commit sein. das bekommt commit --amend ed, wenn Sie speichern.
( 3.2.5/user zum Beispiel) und ist dann auch in all Ihren anderen Projekten verfügbar. (beim Aktualisieren der Version in diesen anderen Projekten auf Ihre Benutzerversion)
warum ist das nützlich?
Ein Thema aus dem Asset Store ist fast perfekt, aber Sie hassen die Schriftart ...
Ändern Sie die Schriftart, speichern Sie sie als neue Asset-Version. Rufen Sie alle Ihre anderen Projekte erneut auf und ändern Sie die Asset-Version in /user . Jetzt bist du glücklich.
Vielleicht könnte es auch eine Schaltfläche geben, um die Benutzerversion des Assets zu veröffentlichen.
Im Asset Store haben also andere Personen die Möglichkeit, auch eine Benutzerversion mit geringfügigen Änderungen auszuwählen.
Nur als Zwischenprodukt, um einen Pr für das Asset-Git-Repo zu erstellen. (oder der Autor der Asset Deicides, um die Änderungen von einer /user -Version zu einer neuen Version auf dem Master herauszupicken.)

Lokal zum Projekt machen

kopiert die Dateien aus dem .local/godot/assets -Ordner in das aktuelle Projekt ... entfernt jedes spezielle Asset-Verhalten (wie Version ...) und jetzt können Sie damit herumspielen, wie Sie wollen. (Außerdem verliert der Ordner sein benutzerdefiniertes Erscheinungsbild als Asset.)

Dadurch kann der Asset Store auch den Use Case von Templates abdecken. Und ist eine perfekte Wahl für fast alle kunstbezogenen Vermögenswerte. Da Sie an den Assets arbeiten können, um sie so zu gestalten, wie Sie sie benötigen.
Sie können immer nur eine Reihe bereits heruntergeladener Assets aktivieren (sagen wir einige grundlegende Prototyp-Sprites), sie lokal machen und sie importieren lassen.

zufälliger Gedanke

Dies könnte sogar eine nette Lösung für Ihre eigene lokale Asset-/Ressourcenbibliothek/Sammlung sein. Mit einem Ordner in .local/godot/assets können Sie seinen Inhalt zu jedem Godot-Projekt mit einer netten Editor-Benutzeroberfläche hinzufügen, ohne ihn in Ihrem Betriebssystem-Dateimanager suchen zu müssen.

Ich stimme zu, dass sowohl die AssetLib- als auch die Asset-Lib-Integration (sowohl im Editor als auch mit GDScript) Liebe brauchen, wenn wir sie als Alternative zur Aufnahme von Dingen in die Core-Engine weiter vorantreiben.

Allerdings bin ich persönlich anderer Meinung, wie stark hier ein Plugin gepusht werden soll.

Die erste Frage, die wir uns bei einer neuen PR stellen, sollte nicht lauten: Kann es sich dabei um ein Plugin handeln? Aber wird dies eher genug verwendet, um im Kern zu sein? .

Es gibt Probleme mit Dingen in Plugins:

• Die Leute müssen in erster Linie wissen, wonach sie suchen. Godot richtet sich an Anfänger . Anfängerfreundliche Software versucht normalerweise, alles zu haben, was jemand (vernünftigerweise) braucht, weil sie sonst erst lernen müssen, was ihnen fehlt und wie sie es bekommen werden.
  Es gibt einen Grund, warum Anfänger Ubuntu und nicht Gentoo verwenden. Unabhängig davon, wie schön Sie dieses Abhängigkeitssystem gestalten.
• Entscheidungslähmung liegt vor. Wenn es eine Funktion in Godot gibt, großartig, dauert es eine Sekunde, um sie zu verwenden. Wenn es 5 Plugins dafür gibt, welches werde ich verwenden? Beispielsweise gibt es mehr als 5 Konsolen -Plugins. Welches sollte ein Anfänger wählen, und warum, und wie viel Zeit sollte er vernünftigerweise für diese Entscheidung aufwenden?
• Plugins werden aufgegeben, haben weniger Qualität, hinken hinterher, wenn sie aktualisiert werden. Es gibt noch weniger Grund, darauf zu vertrauen, dass ein zufälliges Plugin mich nicht in die Luft jagt, als Godot zu vertrauen, wo genügend Leute dahinter stecken.
• Siehe Einheit . Ihre Assets werden meistens sogar bezahlt , und es ist immer noch scheiße, dass man für viele Dinge erst Plugins braucht, die irgendwann schlecht integriert sind oder bei Updates kaputt gehen - oder eingestellt werden, obwohl sie bezahlt werden und sich meist zumindest etwas Support leisten können.
• Dokumentation : Davon haben wir sowieso nicht genug. Jede Funktion, die nicht im Kern enthalten ist, kann ich nicht in offiziellen Tutorials/Dokumenten verwenden. Zufällige Einzelpersonen für Plugins werden wahrscheinlich keine Dokumentation oder nur kurze Beispiele bereitstellen, nicht das wertvollere Stück, Demos oder vollständige Tutorials bereitzustellen, wie diese Funktion nahtlos in ein Projekt mit anderen integriert werden kann.

Beispiele:

• Federarmknoten. (https://github.com/godotengine/godot/pull/18822) Ziemlich kleine Ergänzung, getrennt in eine eigene Klasse, sollte also nichts kaputt machen, wird von vielen 3D-Spielen verwendet, wenn nicht von jedem einzelnen Third-Person-Spiel . Antwort: sollte ein Plugin sein.
• Sogar für das RNG-Zeug wurde diskutiert, es als Plugin zu haben. Als ob nicht 90% der Spiele irgendwo einen RNG brauchen.

Bearbeiten: Um es klar zu sagen, ich bin dafür, Aufblähen zu vermeiden. Aber das ist ein Ausgleich, und ich möchte Unterstützung dafür aussprechen, dass nicht alles in Plugins enthalten ist. Sehr spielspezifisches oder nicht weit verbreitetes Zeug, proprietäre Plugins, große Abhängigkeiten, ja bitte , stellen Sie diese in die Asset Lib!

@karroffel Dies ist ein ausgezeichneter Beitrag und ich stimme größtenteils allem zu, was Sie gesagt haben. Zu diesem Punkt möchte ich jedoch Stellung nehmen:

Assets werden mit der zugehörigen Version gespeichert, alle in .local/godot/assets oder so ähnlich. Sie sind nicht mehr Teil des Projekts selbst, sondern systemweit verfügbar.

Dies ähnelt der Funktionsweise des Python-Pip-Systems. Die Leute haben dann festgestellt, dass die neueste Version eines Pakets die anderen Projekte, die Sie in Ihrem System haben, vermasselt hat. virtualenv löst dieses Problem. Im npm-Ökosystem von Javascript werden Module standardmäßig lokal in einem Projekt installiert und systemweit ist eine Opt-in-Funktion ( npm install --global ). Anschließend checken Sie Ihr package-lock.json in die Quellcodeverwaltung ein, um sicherzustellen, dass alle im Team dieselbe Version jedes npm-Moduls verwenden, und um Konflikte zu vermeiden.

Systemweite Pakete sind gut, da sie das Aufblähen der Systeme der Benutzer reduzieren. Das Fixieren von Versionen ist gut, weil es dem Team hilft, einen konsistenten Satz von Versionen zu halten, und Ihnen helfen kann, eine vollständige Sammlung von Versionen zu identifizieren, die gut zusammenarbeiten.

Wenn wir den systemweiten Weg gehen, würde ich vorschlagen, das Versions-Pinning beizubehalten. Zum Beispiel:

.local/godot/assets/fsm/1.0
.local/godot/assets/fsm/1.1

Projekt A könnte fsm-1.0 verwenden, während Projekt B fsm-1.1 verwendet. Projekt C kommt daher und könnte beides wiederverwenden. Benutzer sollten in der Lage sein, bestimmte Versionen von Plugins in ihren dependencies.json -Dateien oder Mindestpatch-, Neben- oder Hauptversionen anzugeben.

Nachdem die Abhängigkeiten heruntergeladen wurden, kann eine dependencies-lock.json -Datei generiert und in die Quellcodeverwaltung eingecheckt werden.

@mhilbrunner Ich stimme definitiv zu, ich denke, die Mentalität "Dies sollte ein Plugin sein" wird etwas zu stark vorangetrieben, genau diese Situationen haben diese Gedanken ausgelöst. Ich denke, dass häufigere Dinge wie der SpringArm es wert sind, in der Engine zu sein, und der InterpolatedCamera , den Juan entfernen möchte, ist wahnsinnig nützlich und cool! Auch wenn diese Dinge nur ein paar Zeilen Code sind, dauert es eine Weile, bis sie richtig sind, also ist "das ist zu klein" auch eine schlechte Rechtfertigung dafür, in Richtung AssetLibrary zu drängen.

Meine Gedanken drehten sich hauptsächlich um "Nun, der Projektleiter hat gesagt, dass es so ist, also was kann getan werden, um die neue Situation zu verbessern?"

Ich würde es begrüßen, wenn das starke Drängen von Funktionen als Plugins etwas verringert würde, aber ich denke, die vorgestellten Änderungen würden so oder so sehr helfen!

@saltares Ja, das war mein Gedanke. Ich bin ein großer Fan von Fracht für Rust. Es funktioniert ziemlich gleich. Bibliotheken werden in einem systemweiten Ordner in allen Versionen installiert, die jemals lokal benötigt wurden. Die Beschreibung befindet sich in einer Datei und eine bestimmte Konfiguration befindet sich in einer .lock -Datei, es funktioniert ziemlich gut!

Ich bin froh, dass das schon einige Diskussionen ausgelöst hat :blush:

Hier ist meine Meinung zu den oben genannten Punkten:

Sachen aus dem Motor schieben

Dinge außerhalb des Motors zu schieben, ist meiner Meinung nach der richtige Weg. Es gibt zu viele Plattformen, auf denen die Bereitstellungsgröße von Bedeutung ist (mobil, html5) und ein Aufblähen ein großes Problem für ein Projekt von der Größe von Godot ist, sodass wir nicht einfach alles einbeziehen können.

Die Philosophie sollte für mich sein, dass etwas nur dann Teil des Motors sein sollte, wenn ALLE folgenden Kriterien erfüllt sind:

1. Es wird relativ häufig verwendet
2. Es ist schwierig, es selbst zu tun
3. Es gibt nur eine Möglichkeit, diese Funktion auszuführen

Dies schließt Federarm, Gelände aus und ich hoffe, dass es in Zukunft helfen kann, Funktionen wie InterpolatedCamera, Vehicle usw. zu entfernen, von denen ich glaube, dass sie außerhalb des Motors liegen sollten.

Die Hauptsorge dabei ist, dass, wenn etwas nicht offiziell ist, es nicht aufrechterhalten wird. Hier liegen Sie falsch.

Niemand hat gesagt, dass diese Dinge nicht offiziell sein sollten, wir können ein offizielles Repository dafür haben und sie können Erstanbieter-Erweiterungen sein. Demos werden auf diese Weise gepflegt und sind auf dem neuesten Stand, daher sehe ich nicht ein, warum dies nicht für ein offizielles Erweiterungs-Repo funktionieren würde.

Erweiterungen sollten sich wie ein Teil des Motors anfühlen

Zu diesen Punkten:

• Erleichtern Sie das Erweitern benutzerdefinierter Knoten, ermöglichen Sie die sprachübergreifende Skriptvererbung

Ich bin sehr dagegen. Dies hat überhaupt keinen praktischen Nutzen, und die Implementierungskosten sind sehr hoch. Tut mir leid, Leute, ich weiß, dass es sich wie ein nettes Feature anfühlt, aber die Gewichtung von Kosten/Nutzen/Risiko ist auf der sehr negativen Seite.

Ich finde es auch positiv, dass benutzerdefinierte Knoten oder Ressourcen so aussehen sollten, als ob sie KEIN Kern wären, was für Endbenutzer eine gute Sache ist. Benutzer sind nicht dumm und diese Informationen sollten ihnen nicht verborgen bleiben.

Wenn ein neuer Knoten aus einer Erweiterung hinzugefügt wird und dies mit einem Skript erfolgt, sollte dies sogar im Erstellungsdialog angezeigt werden.

• Die Skriptvererbung wird beim Anhängen eines Skripts nicht empfohlen - Überschreiben ist die Standardeinstellung für diese Fälle.

Dies muss auf jeden Fall getan werden und wäre eine sehr willkommene Ergänzung.

• Fügen Sie eine ordnungsgemäße Abhängigkeitsverwaltung mit systemweiten Installationen von Assets hinzu. Verschieben Sie Addons aus dem Projekt selbst mit einer Möglichkeit, sie zur Änderung zurückzubringen

Mein Gefühl dazu ist, dass es entweder fantastisch funktionieren oder zu einem kompletten Durcheinander und Add-Ons führen kann, die ohne ersichtlichen Grund kaputt gehen. Wenn ich mir anschaue, wie andere Engines damit arbeiten, scheint es mir nicht so wichtig zu sein, Abhängigkeitsmanagement zu haben.

• Ermöglichen Sie die Referenzierung von Skripten nach Klassennamen und Namespace, um im Fall von Assets superlange Pfade zu vermeiden.

Dies ist etwas, das wir zuvor besprochen haben, aber wir sind zu dem Schluss gekommen, dass es hauptsächlich von der Skriptsprache abhängig sein sollte (und nicht von der Engine selbst als Kern-ScriptDB bereitgestellt wird), mit einer kleinen Verbesserung der Benutzerfreundlichkeit im neuen Skriptdialog, falls Sie dies wünschen Verwenden Sie eine globale Klasse.

Mein Gefühl dazu ist, dass es entweder fantastisch funktionieren oder zu einem kompletten Durcheinander und Add-Ons führen kann, die ohne ersichtlichen Grund kaputt gehen.

Ich denke, die Add-Ons sollten in unserem Fall niemals automatisch aktualisiert werden, sondern es sollte stattdessen eine Liste der installierten Add-Ons mit aufgelisteter Version und manueller Aktualisierung geben, sodass der Benutzer ein Update anfordern und sofort überprüfen kann, ob etwas kaputt gegangen ist.

Dieser Kommentar ist aufgrund seiner großen Länge in zusammengeklappte Abschnitte unterteilt.

Willst du eine Kamera? Godot hat eine Kamera, die einem Spieler folgen kann, mit wenig bis gar keinem Code von Ihnen. Möchten Sie eine Animation in Godot erstellen? Sie können nicht nur Charakteranimationen erstellen, dasselbe System kann (fast) das Zwischensequenzsystem ersetzen, an dem Sie so hart gearbeitet haben, und benötigt nur etwa fünf Zeilen Code von Ihnen. Der Editor wurde sogar verwendet, um andere Editoren wie RPG in a Box zu erstellen. Es ist fantastisch, wie viel man in Godot erschaffen kann.

Nun, da das aus dem Weg geräumt ist, kann hoffentlich jeder, der dies liest, verstehen, was ich denke, wenn ich versuche, auf einige Punkte von reduz bezüglich des Herausschiebens von Dingen aus der Engine zu antworten. (Dies wird nicht auf den Abschnitt „Erweiterungen sollten sich wie ein Teil der Engine anfühlen“ antworten, da ich derzeit keine Gedanken dazu habe.)

Dinge außerhalb des Motors zu schieben, ist meiner Meinung nach der richtige Weg. Es gibt zu viele Plattformen, auf denen die Bereitstellungsgröße von Bedeutung ist (mobil, html5) und ein Aufblähen ein großes Problem für ein Projekt von der Größe von Godot ist, sodass wir nicht einfach alles einbeziehen können.

Ich kann zustimmen, dass Blähungen ein Problem darstellen, aber wenn ich sehe, was Sie bisher entfernen möchten, frage ich mich, ob es sich wirklich überhaupt lohnt, dieses Zeug zu entfernen. Selbst wenn Sie Knoten wie Vehicle, InterpolatedCamera usw. entfernen ... Wie groß ist der Unterschied in der Dateigröße wirklich? Vielleicht ein halbes Megabyte? Vielleicht ein paar Megabyte? Auch wenn es mehrere Megabyte spart, was ist überhaupt der Unterschied zwischen einem 35-MB-Download und einem 45-MB-Download? Die Spiel-Assets werden diese 10-MB-Lücke trotzdem schnell füllen! Wenn Sie nicht vorhaben, den halben Motor auszubauen, verstehe ich den Sinn nicht.

Wenn Sie wirklich daran interessiert sind, so viel Speicherplatz wie möglich zu sparen, könnte ich vorschlagen, es dem Endbenutzer zu erleichtern, stattdessen die Knoten, die er nicht benötigt, aus der Engine zu entfernen? Lassen Sie die Leute, die den Motor benutzen werden, entscheiden, ob sie mit dem Aufblähen einverstanden sind – entscheiden Sie nicht für sie.

Jetzt können wir natürlich nicht einfach jeden einzelnen Vorschlag aufnehmen, der uns gegeben wird...

1. Es wird relativ häufig verwendet
2. Es ist schwierig, es selbst zu tun
3. Es gibt nur eine Möglichkeit, diese Funktion auszuführen

... und diese Richtlinien sind ein guter Ausgangspunkt, um zu hinterfragen, was im Motor erlaubt sein sollte. Es besteht kein Zweifel, dass alle drei Punkte bereits für jede einzelne Feature-Anfrage berücksichtigt werden, die durch den Issue Tracker kommt.

Etwas sollte nur dann Teil des Motors sein, wenn ALLE unten aufgeführten Kriterien erfüllt sind

Aber komm schon. Das Schicksal eines Features oder Knotens sollte nicht so stark davon abhängen, ob es sich um ein Kernfeature handelt. Ihre vorgeschlagenen Richtlinien sind großartig, verstehen Sie mich nicht falsch, aber wir sollten sie nicht als Checkliste verwenden. Das macht YoYo Games, wenn Sie ein Feature in ihren Foren vorschlagen, und ist ein weiterer Grund, warum ich von ihrer Engine weggedrängt wurde – kann es mit einer Erweiterung erstellt werden? Jawohl? Dann ist unsere Antwort eine Verlängerung. Schätzen Sie, wie viele Funktionsanfragen abgelehnt wurden, weil sie stattdessen in Erweiterungen umgewandelt werden könnten, unabhängig davon, wie sinnvoll es für die Engine wäre, wie einfach es im Vergleich dazu zu implementieren wäre oder wie die Community darüber denkt diese Funktion.

Was ich sagen will, ist, dass Sie diese Richtlinien auf jeden Fall im Hinterkopf behalten können. Sie können sie jedes Mal berücksichtigen, wenn eine Funktion vorgeschlagen wird. Aber ob sie alle zutreffen, sollte NICHT der entscheidende Faktor dafür sein, ob eine Funktion aufgenommen wird. Wägen Sie die Idee gegen diese Richtlinien ab, überlegen Sie, wie wichtig jede dieser Richtlinien ist, und legen Sie Gewicht auf diese Faktoren ... Nur weil eine Idee dies nicht tut scheint es zu oft verwendet zu werden, macht es nicht automatisch zu einer schlechten Idee (denken Sie daran, dass Sie vielleicht nicht wissen, wie es wirklich verwendet wird, selbst mit mehrjähriger Erfahrung). Nur weil eine Idee einfach selbst umzusetzen ist, ist sie nicht automatisch eine schlechte Idee. Und nur weil wir eine Idee auf mehr als eine Art und Weise umsetzen können, heißt das noch lange nicht, dass sie eine schlechte Idee ist! Ganz zu schweigen davon, dass vielleicht jemand Idee X vorschlägt, weil er glaubt, dass andere davon profitieren würden.

Denken Sie daran, dass dies eine Engine ist, die sich selbst als anfängerfreundlich bezeichnet, und jedes Mal, wenn ein Anfänger etwas Unspezifisches für sein Spiel programmieren muss, das nicht Teil der Engine ist, oder in einer Asset-Bibliothek nach dem benötigten Code suchen muss , oder einen langen Weg gehen, um das zu bekommen, was sie aus der Engine herausholen wollen, könnte es sie ein wenig weiter in Richtung einer anderen Engine oder manchmal sogar weg von der Spieleentwicklung als Ganzes treiben.

tl;dr : Richtlinien sind großartig, wenn sie als Richtlinien und nicht als Checklisten verwendet werden.

Die Hauptsorge dabei ist, dass, wenn etwas nicht offiziell ist, es nicht aufrechterhalten wird. Hier liegen Sie falsch.

Niemand hat gesagt, dass diese Dinge nicht offiziell sein sollten, wir können ein offizielles Repository dafür haben und sie können Erstanbieter-Erweiterungen sein. Demos werden auf diese Weise gepflegt und sind auf dem neuesten Stand, daher sehe ich nicht ein, warum dies nicht für ein offizielles Erweiterungs-Repo funktionieren würde.

Ich persönlich bin mit dieser Idee nicht einverstanden. Neben dem, was ich oben gesagt habe (dass Sie durch das Entfernen aus der Vanilla-Engine nicht viel Speicherplatz sparen), muss ich fragen, ob wir sie alle in GDscript konvertieren werden oder ob wir dies benötigen sie, die Engine neu zu kompilieren, nur um diese Knoten zu erhalten.

• Wenn wir sie als C++ behalten und eine Neukompilierung benötigen ... warum aber? Es gibt keinen guten Grund, warum wir die Engine jemals neu kompilieren müssen, es sei denn, wir ändern einen Kernteil davon oder fügen unsere eigene Funktionalität hinzu. Das ist nur zusätzliche Zeit, die der Entwicklung weggenommen wird, weil wir auf den Abschluss des Kompilierungsprozesses warten und den durchschnittlichen Benutzer dazu auffordern, andere Tools zu installieren, die er möglicherweise nie wieder verwendet, nur um einige First-Party-Knoten zu erhalten. Das hört sich jetzt nach Blähungen an!

• Wenn wir sie in GDscript umwandeln, dann wird das mit allen Beschränkungen von GDscript einhergehen. Einschränkungen wie der potenzielle Overhead zusätzlicher untergeordneter Knoten (insbesondere wenn Sie den Benutzer auffordern, diesen Erstanbieter-Knoten als Szene zu importieren), Pfade anstelle von Klassennamen verwenden zu müssen, um auf ihre Klassen zu verweisen (obwohl Sie dies angesprochen haben, es scheint, aber ich habe das Gefühl, ich muss es ansprechen), geringere Leistung (egal wie gering der Unterschied sein mag, er ist immer noch geringer) usw.. Es ist ein bisschen idealer als C++, weil Sie von der Neukompilierung zu gewechselt sind Drag-n-Drop, aber...

Beide Optionen bedeuten auch, dass die Dateien für diese Knoten mit jedem neuen Benutzer (für C++) oder mit jedem neuen Projekt (für GDscript), das sie verwenden möchte, in die Engine importiert werden müssen. Ich weiß nicht, wie es allen anderen geht, aber das klingt für mich nach Ärger und klingt so, als würde es Ihre erste Richtlinie ("Es wird relativ oft verwendet") sehr umstritten machen. Ich werde versuchen zu erklären, warum ich das denke.

Durch den zusätzlichen Aufwand für die Verwendung dieser Knoten bin ich mir ziemlich sicher, dass die Anzahl der Verwendungen dieser Erstanbieterlösung sinken wird und diese Erstanbieterlösung wirklich nicht mehr "relativ oft" dort verwendet wird, wo sie zuvor gewesen sein mag. Das wiederum wird langsam die Anzahl der Alternativen erhöhen, die dieselben Funktionen nachbilden, wenn die Leute aufhören zu lernen, dass es eine Erstanbieterlösung gibt – wenn ich mir ziemlich sicher bin, dass wir vorhandene Versionen (in diesem Fall unsere eigenen) bevorzugen würden verbessert werden, anstatt ein neues mit Feature X, ein neues mit Feature Y und ein neues mit diesen beiden Features, aber nicht so optimiert, und so weiter zu erstellen ... Es schafft diesen Markt für Alternativen, wenn Menschen weiß nicht, dass es eine First-Party-Lösung gibt. Es verursacht ein Durcheinander .

Außerdem sagen Sie, dass sie beibehalten werden. Das ist großartig! Aber wer soll sie pflegen? Was sind unsere Richtlinien für das Hinzufügen neuer Dinge zu diesem Repository? Und werden wir uns die Mühe machen, sicherzustellen, dass dieses Repository von Erstanbieter-Erweiterungen immer funktioniert, egal ob mit einer stabilen Version oder mit Master? Lohnt sich im Grunde der Aufwand eines eigentlich separaten Projekts?

Übrigens bevorzuge ich die Implementierung mehrerer Skripts pro Knoten
statt sprachübergreifender Vererbung. Ersteres ist nur ein paar Zeilen
des Codes..

Am Sonntag, den 10. Juni 2018 um 13:51 Uhr schrieb Plyczkowski [email protected] :

Mein Gefühl dazu ist, dass es entweder fantastisch funktionieren oder zu einem führen kann
komplettes Durcheinander und Add-Ons, die ohne ersichtlichen Grund kaputt gehen.

Ich denke, die Add-Ons sollten in unserem Fall niemals automatisch aktualisiert werden, aber
stattdessen sollte es vielleicht eine Liste der installierten mit der aufgelisteten Version geben
und manuelle Aktualisierung, sodass der Benutzer eine Aktualisierung anfordern und sofort prüfen kann, ob
irgendwas ist kaputt gegangen.

—
Sie erhalten dies, weil Sie kommentiert haben.

Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/godotengine/godot/issues/19486#issuecomment-396063688 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AF-Z21jtcnUhRyhdyEEnaM_hfTACsxOiks5t7U6HgaJpZM4UhqDC
.

Mehrere Skripte pro Knoten wurden ein paar Mal versucht und sind immer fehlgeschlagen.

Was versucht wurde, ist der Multiscript-Knoten, aber es war ein Ärger

Am Sonntag, den 10. Juni 2018 um 15:01 Uhr schrieb Zireael07 [email protected] :

Mehrere Skripte pro Knoten wurden ein paar Mal und immer versucht
Versagen.

—
Sie erhalten dies, weil Sie kommentiert haben.

Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/godotengine/godot/issues/19486#issuecomment-396068742 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AF-Z26u8Rqc1yL-BGX16CAx_iWsYEo1oks5t7V8CgaJpZM4UhqDC
.

Ich verstehe, dass Assets nicht so aussehen sollten wie die eingebauten Sachen. Aber ich denke auch, dass sie höherklassig sein sollten als von Benutzern erstellte Skripte. Sie sollten eine klare Trennung haben, damit es einfach ist, Assets zu ersetzen/aktualisieren, ohne sie aus Ihrem Projekt entfernen zu müssen.

Das Hinzufügen einer Ebene für Assets und deren bessere Integration in die Engine zur Erweiterung ist eine großartige Möglichkeit, den Kern klein und sauber zu halten und gleichzeitig neue Funktionen über die Asset-Bibliothek bereitzustellen. Wenn Assets neue Typen nicht nur für Knoten/Ressourcen, sondern auch zu erweiternde Klassen auf eine Weise registrieren können, die global zugänglich ist (dh nicht pfadabhängig), wäre es ein großer Vorteil für Frameworks, auf der Engine aufzubauen.

Frameworks wie Escoria könnten sehr davon profitieren, und es könnte andere Frameworks für Dinge wie RPGs, Platformer, Visual Novels usw. geben.

Alles, was ich hier sage, ist ziemlich abstrakt, aber eine klare Trennung dessen, was integriert ist, was Asset von Drittanbietern ist, und was Benutzercode ist (wie auch immer diese Trennung dargestellt wird), wird dazu führen, dass „den Kern klein halten und Erweiterungen bereitstellen „Geh ganz leicht voran.

Sprachübergreifende Vererbung klingt für mich nach einer schrecklichen Idee.

Bei der Arbeit, die ich mit der TypeDB in den EditorData gemacht habe, habe ich einen namespaced-typename für filepath HashMap beibehalten, der bei Änderung in ein Dictionary in den ProjectSettings konvertiert wird. In meiner Branche verwenden der GDScript-Parser und -Compiler diese Daten, um globale Namen für Typen zu erstellen. Zu diesem Zeitpunkt werden benutzerdefinierte Typskripts angezeigt. Die Skripte können auf sie zugreifen und sie namentlich erben. Darüber hinaus sind diese Daten für alle zugänglich, die ProjectSettings sehen können. Ein vom Editor gesehenes CSharpScript kann also eine Zuordnung generieren, die in das ProjectSettings-Wörterbuch eingegeben wird, sodass in C# deklarierte Typen für GDScript zugänglich sind. Es gibt wahrscheinlich auch eine Möglichkeit, die ProjectSettings-Wörterbuchdaten in ein C#-Objekt einzuschließen, das beim Zugriff Skriptobjekte zurückgibt, sodass C# auch namentlich auf GDScript-Typen zugreifen kann.

Diese Technik hält die gemeinsam genutzten Namespaces außerhalb des Kerns und rein innerhalb des Editor-Kontexts, wodurch Sprachen, die sich dafür entscheiden, ihre eigenen Mittel für den Zugriff auf die Daten vorbereiten können.

Ich mag jedoch den Vorschlag von @karroffel , sprachübergreifende Skriptvererbung zu ermöglichen (weiß nicht einmal, ob das möglich wäre). Duplizieren Sie irgendwie automatisch Methoden, die Aufrufe an das Basisskript delegieren, und definieren Sie auch dieselben Eigenschaften/Signale/Konstanten usw.

Auch ich hätte gerne einen optimierten Zugriff auf Inhalte in der AssetLibrary, mit der Möglichkeit, einige Plugins für den Editor insgesamt und andere Plugins für nur ein einzelnes Projekt zu behalten.

Das TypeDB-System, das ich mache, wird auch Editor-Unterstützung für ...

1. Alle eigenen benutzerdefinierten Skripte im CreateDialog anzeigen lassen
2. Durch das Erweitern eines benutzerdefinierten Typskripts werden Sie dieses Skript automatisch erweitern, wenn Sie dem Knoten ein Skript hinzufügen
3. Lassen Sie ein Skript entfernen, das ein benutzerdefiniertes Typskript erweitert, und stellen Sie das benutzerdefinierte Typskript nach dem Entfernen wieder her (Sie können also kein benutzerdefiniertes Skript entfernen – Sie müssen stattdessen den Befehl „Typ ändern“ im Editor verwenden).

Außerdem würden alle Änderungen an der Benutzeroberfläche, die ich vornehme, dafür sorgen, dass die benutzerdefinierten Skripte klar als Skripte verstanden werden und dass das fragliche Skript zugänglich bleibt. Benutzer werden immer wissen, was ein Skript ist, und ihnen erlauben, auf das Skript zuzugreifen, aber es gibt ihnen immer noch das Gefühl, in gewissem Maße wie In-Engine-Objekte zu sein. Selbst innerhalb von GDScript wird nicht global auf die Namen zugegriffen, als wären sie ein Kerntyp, sondern sie werden aus einem globalen Wörterbuch namens Scripts extrahiert. Bisher habe ich es mit benutzerdefinierten Typskripten gearbeitet, aber ich würde gerne erweitern, dass das Wörterbuch benutzerdefinierte Typszenen und alle im Projekt verfügbaren typischen Skripte oder Szenen registriert, wahrscheinlich über das Importsystem, wenn die Skriptsprache dies nicht tut haben eine einfache Möglichkeit, den Namespace-Typnamen zu erhalten.

Da ich Teil des Denkprozesses dieses Vorschlags war, möchte ich auf einige Dinge hinweisen:

Meine Vision von Godot

TLDR: Ich stelle mir Godot als ein Tool vor, das sehr einfach, modular und anfängerfreundlich mit Assets und Plugins erweitert werden kann.

Die Motive hinter der Ablehnung meiner SpringArm-PR sind mehr als nachvollziehbar, und deshalb haben @karroffel und ich darüber diskutiert, in welche Richtung die Engine gehen könnte, um leicht und gleichzeitig benutzerfreundlich zu bleiben.

Was ich gerne sehen würde, ist eine saubere, kleine und schnelle Kern-Engine und ein gut integriertes Ökosystem von Addons und Plugins.
Da ArchLinux mehr als ein Paket-Repository hat, denke ich, dass es großartig wäre, wenn Godot ein "offizielles" (von Godot verwaltetes) Repository für Kernfunktionen (und Knoten, die jetzt Kern sind) und ein weiteres Repository für die Community hätte. In das Godot-Kern-"Erweiterungs-Repository" würde ich alle Knoten legen, die mühsam zu codieren sind, aber nicht genug verwendet werden, um mit der Vanilla-Version der Engine ausgeliefert zu werden.
Randbemerkung: Was oft nicht berücksichtigt wird, ist, dass einige Funktionen möglicherweise einfach zu programmieren sind, aber auch viel Recherche erfordern, bevor diese wenigen Zeilen festgelegt werden.

Ich stelle mir vor, dass Benutzer Plugins und Assets herunterladen können, die sich anfühlen, als würden sie die Engine selbst „erweitern“: Je nachdem, was Sie herunterladen, haben Sie Godot-fps oder Godot-platformer oder Godot-racing.

Godot könnte die erste Engine sein, die sich wirklich Unix-ähnlich und modular anfühlt und sogar Unity mit seinen Editor-Erweiterungen übertrifft. Viele von Ihnen wissen, wie gut es sich anfühlt, wenn Ihr Linux-System nicht „diese Distribution“ ist, sondern Ihr ganz eigenes und angepasstes System mit Ihren ganz persönlichen Funktionalitäten.

Vorteile

TLDR: Dieser Ansatz würde es dem Godot-Management ermöglichen, technische Kernfunktionen und benutzerfreundlichere Plugins separat zu verwalten, ohne sich zu viele Gedanken über das Aufblähen der Engine zu machen

Das Gute an diesem Vorschlag ist auch die Trennung von Bedenken und der Umgang mit dem Beitragszahler. Ich habe das Gefühl, dass es im Moment nicht klar ist, was in Ordnung ist, im Kern zu sein, und was nicht. Es gibt keine klare Regel oder statistische Daten, über die man sprechen könnte. Einige mögen sagen, dass eine bestimmte Funktion weit verbreitet ist, und andere denken, dass dies nicht der Fall ist.

Die Aufteilung von Godot in verschiedene "Ringe" bietet die Möglichkeit für eine feinkörnigere Verwaltung von PRs und Features und kann @reduz und anderen sehr technischen Entwicklern mehr Zeit geben, sich auf technische Hardcore-Sachen zu konzentrieren , während ein anderes Team den Erweiterungsring verwalten würde. mehr Berücksichtigung von Benutzerfeedback und Benutzerfreundlichkeit , anstatt sich mit einem Aufblähen der Engine auseinanderzusetzen, da der "Verlängerungsring" bei Bedarf aufgebläht werden würde.

Über mehrsprachige Vererbung

Da Godot wächst, kann der Vermögensspeicher leicht zu einem flammenden Durcheinander werden. Die strenge Trennung zwischen Skriptsprachen kann buchstäblich jeden Versuch zerstören, den Menschen unternehmen, um Assets zu verkaufen und ein Ökosystem im Asset Store aufzubauen, wodurch viele Gelegenheiten für freiberufliche Werkzeugmacher vernichtet werden, Werkzeuge für Godot herzustellen und zu verkaufen.
Sprachbrücken müssen vollständiger sein, wenn wir wollen, dass eine Chanche ein lebendiges Ökosystem entwickelt.
Im Moment hört sich sprachübergreifende Vererbung für mich großartig an, aber ich bin nicht technisch genug, um etwas zu diesem Thema zu sagen. Ich möchte nur auf ein Problem hinweisen, das wahrscheinlich bald auftreten wird, zumal es eine so große Community rund um C# gibt.

Hinweis zur Bedienbarkeit

Ich benutze Godot jetzt seit fast einem Jahr, und in letzter Zeit habe ich das Gefühl, dass Leute, die über Funktionen entscheiden, die Engine nicht für etwas Größeres als kleine Demos verwenden. @LikeLakers2 wies auf ein Problem hin, das meines Erachtens von einigen Benutzern geteilt wird, die nicht tief in das Kernteam der Entwicklung eingebunden sind.

Ich denke, dass das, was als aufgebläht angesehen wird, ein triviales Thema im größeren Rahmen der Dinge ist, es ist nicht so, dass die Entscheidung, die wir jetzt treffen, das ist, was wir für das ganze Leben von Godot einhalten müssen. Da wir Open Source sind, können wir Änderungen vornehmen, wann immer wir möchten. Das einzige Problem ist, dass je länger wir warten, desto schwerer wird die Entscheidung für Änderungen.

Das ist jetzt auch eine Diskussion für einen anderen Tag. Gerade jetzt in der Gegenwart sind die Fakten,

1. Godot ist eine kompakte, schnelle und tragbare Spiel-Engine. Und ich mag es sehr, aber ....
2. Die ausführbare Datei von Godot ist etwa 45-60 MB groß, abhängig von verschiedenen Faktoren. Die Exportvorlage kann jedoch bis zu 300 MB groß sein. Nun, das ist ein schwerer Schlag für den ersten Punkt.
3. Godot hat viele erstaunliche Funktionen, die es zu einem Leckerbissen für Anfänger machen, wie Camera Follow, Parallax BG und Vehicles. Dies ist ein großes Plus gegenüber anderen ähnlichen Spiel-Engines. Da es das Erstellen von Spielen in Godot viel einfacher macht. Und macht Godot zu einem Zuhause für viele neue Entwickler, die nicht über die Fähigkeiten verfügen, ihre eigenen Implementierungen für solche Tools zu schreiben.

Was passiert nun, wenn wir Funktionen entfernen, die manche Leute als aufgebläht betrachten? Nun, der Motor wird sicherlich kompakter sein, aber ist das erforderlich? Ich sehe kein Problem darin, eine 100-MB-Engine herunterzuladen, wenn sie meine Anforderungen besser erfüllt. Aber was ist mit dem Exportieren, wird eine 100-MB-Engine nicht größere Spiele exportieren?

Wahrscheinlich ja, aber in einer Welt, in der Desktops nicht weniger als 256 GB SSD + 1 TB HDD zu verwenden scheinen und sogar Telefone Speicherplatz ab mindestens 16 GB haben, was sich höchstwahrscheinlich erhöht , wäre es das? SCHLECHT?
Ich meine damit, dass wir noch nichts entfernen müssen, wir müssen nur anfangen, ein paar Dinge besser zu verwalten, und das sollte es sein.
Features sollten eine Art Wichtigkeitsliste haben, um zu entscheiden, ob sie im Kern enthalten sein sollen oder nicht, aber das bedeutet nicht, dass es zu einem Gesetz wird, sondern eher zu einer Faustregel.

Und für die Erbsenzähler könnten wir einige extrem ungenutzte Werkzeuge entfernen, aber das war's. Funktionen blähen einen Motor nicht auf, es sei denn, wir sind nachlässig. Und selbst all das Aufblähen in Unity hat die Leute nicht davon abgehalten, es zu verwenden, oder?
Und ich meine absolut nicht, dass wir uns nicht um Blähungen kümmern sollten, aber vorsichtig zu sein und paranoid zu sein, sind zwei völlig verschiedene Dinge.

Was die mehrsprachige Vererbung betrifft, sehe ich hier keinen wirklichen Nutzen dafür. Sicher, wir sollten in der Lage sein, mit Skripten in mehreren Sprachen zu interagieren, aber Vererbung! Das ist wahrscheinlich mehr Arbeit, als ich mir vorstellen könnte, mit Vorteilen, die sich einfach nicht zu lohnen scheinen.
Dagegen könnte Multi-Script genau die Lösung für viele Probleme sein, von der Erstellung von Addons bis hin zu besserer Modularität. Obwohl das meine Perspektive ist.

Es gibt etwas zu sagen über die Begrenzung der Anzahl der Knoten- und Ressourcentypen, die in der Box enthalten sind. Indem Sie alle weniger genutzten Assets in einen externen Download verschieben, machen Sie es 1. neuen Leuten viel einfacher, das System durch einfaches "Herumspielen" in den Griff zu bekommen, ohne von der Breite der Funktionen überwältigt zu werden (Entscheidungsparese), und 2. am Ende nicht so viel Legacy-Gepäck erstellen, wenn sich herausstellt, dass einige der engeren Use-Case-Szenario-Assets am Ende einen Workflow haben, der nicht so gut ist wie etwas, das später mit einer anderen API kommt.

Wenn letzteres bei eingebauten Geräten passiert, bleiben Sie bei ihnen hängen. Wenn es mit herunterladbaren Assets passiert, neigen die beliebtesten dazu, im Laufe der Zeit zum De-facto-Standard zu werden, aber ihr Schicksal ist nicht dauerhaft mit dem von Godot verbunden. Das bedeutet, dass sie in Vergessenheit geraten können, ohne sich Sorgen machen zu müssen, dass die erwartete Kernkompatibilität gebrochen wird.

Der sprachübergreifende Vererbungspunkt bedarf einer Erklärung. Ich halte es nicht nur für eine schlechte Idee, sondern ich sehe nicht einmal, wie es im Entferntesten möglich ist.

1. Die ausführbare Datei von Godot ist etwa 45-60 MB groß, abhängig von verschiedenen Faktoren. Die Exportvorlage kann jedoch bis zu 300 MB groß sein. Nun, das ist ein schwerer Schlag für den ersten Punkt.

300MB die Exportvorlagen? Meinst du mit Vermögen?

@neikeq Die Sache ist, dass, wenn Ihr gesamtes Projekt in C # ist, Sie aber einen benutzerdefinierten Knoten verwenden, der aus der AssetLibrary heruntergeladen wurde, dieser Knoten nur ein normaler Knoten ist, höchstwahrscheinlich nur mit einem angehängten GDScript.

Wenn Sie den Knoten "erweitern" möchten, können Sie das nicht! Ich denke, Sie können einen untergeordneten Knoten hinzufügen, um neue Funktionen hinzuzufügen, aber auf diese Weise ist es nicht möglich, Dinge zu überschreiben .

Implementierung

Derzeit verwenden die Skriptsprachen ein wirklich ähnliches Muster für vererbte Aufrufe, das verallgemeinert werden könnte.

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/gdnative/nativescript/nativescript.cpp#L696 -L712

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/gdscript/gdscript.cpp#L638 -L651

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/mono/csharp_script.cpp#L1175 -L1191

Das Muster hier ist

Class *c = bottom;
while (c) {
    if (c->has_method(m)) {
        c->call(m);
        break;
    }
    c = c->base;
}

Es beginnt also am Ende des Skriptvererbungsbaums und versucht dann, die oberen Ebenen aufzurufen, wenn keine solche Methode gefunden wird.

Wenn jedes Skript anstelle der sprachspezifischen Vererbungsstruktur ein Ref<Script> parent_script hätte, könnte dies verallgemeinert werden

if (this_class->has_method(m)) {
    this_class->call(m);
} else {
    // method not declared here, go to base class
    parent_script->call(m);
}

Das ist vielleicht keine gute Idee, aber wenn wir die AssetLib mehr pushen, könnte es im Laufe der Zeit ein Problem werden, nicht die Option zu haben, Dinge sprachübergreifend zu überschreiben.

@neikeq Siehe das,

@swarnimarun Das sind Exportvorlagen für alle Plattformen, alle unterstützten Arches, Debug und Release, ihre Größe ist für das "Aufblasen" der Engine völlig irrelevant. Wir können entscheiden, nur die 64-Bit-Version von Linux X11 zu unterstützen, und diese Datei wird 20 MB groß sein ...

@akien-mga Ich wollte es nicht aufblähen nennen.
Ein neuer Benutzer wird es jedoch in voller Größe herunterladen, da er nicht erfahren genug ist, um zu wissen, dass er separat erstellen oder für eine bestimmte Plattform herunterladen kann.

Inwiefern ist es irrelevant, wenn wir Anfängern dies anbieten?

@akien-mga: Die Größe der Exportvorlagen ist wichtig, da Ihr Argument für das Entfernen von Knoten war

Bereitstellungsgröße ist wichtig (mobil, html5)

@swarnimarun @Zireael07 Ja, die Größe der Exportvorlagen ist individuell wichtig, aber mein Punkt ist, dass das Messen der Größe eines Bündels von Vorlagen uns keinen Hinweis gibt. Die Größe einer Vorlage (z. B. die Wasm-Release-Vorlage, 3,4 MB gezippt, oder die Android-Release-APK, 23 MB, gezippt mit armv7- und x86-Bibliotheken) ist viel relevanter als „alles herunterzuladen, was zum Entwickeln benötigt wird, dauert 350 MB“ (+ vielleicht 10 GB für Visual Studio, wenn Sie etwas bauen müssen ...). Was zählt, wenn es darum geht, welche Größe ein minimales Spiel auf Plattformen annimmt, auf denen es auf die Größe ankommt (Web, Mobil).

Obwohl ich denke, dass die Bereitstellungsgröße wirklich wichtig ist, denke ich auch, dass die Entwicklerzeit berücksichtigt werden muss. Zum Beispiel hat Unreal buchstäblich jede Funktion, nach der Sie suchen könnten, aber die Tatsache, dass es so viele gibt, macht den Entwicklungsprozess sehr ineffizient, da Sie jedes Mal, wenn Sie etwas damit machen müssen, zuerst herausfinden müssen, welche integrierte Funktionalität vorhanden ist Sie müssen es verwenden und dann lernen, wie man es richtig verwendet.

Das ist etwas, was ich an Godot wirklich liebe. Sie können Ihr Feature sofort codieren, und dann kommt jemand und sagt Ihnen: "Hey, wusstest du, dass wir dieses eingebaute Ding haben, das du verwenden kannst?"

Das Problem, wenn eine Engine zu viele Funktionen zusammen hat, besteht darin, dass die Entwicklung mit dieser Engine zu einer enorm ermüdenden Erfahrung wird. Ja, es ist schön, alle Funktionen zu haben, die Sie brauchen, aber es ist ein gigantischer Schmerz, sie alle durchzugehen, um herauszufinden, was Sie tatsächlich brauchen. Das ist aufgebläht. Und deshalb schlagen wir vor, gut integrierte Funktionen auf Abruf zu haben.

Fügen Sie eine ordnungsgemäße Abhängigkeitsverwaltung mit systemweiten Installationen von Assets hinzu. Verschieben Sie Addons aus dem Projekt selbst mit einer Möglichkeit, sie zur Änderung zurückzubringen.

Dies ist dasselbe wie der Verlust der Portabilität. Meine Plugins sind Teil meines Projekts, ich brauche das auf jedem Computer, an dem ich arbeite, und ich brauche die konkrete Modifikation jedes Plugins für jedes Projekt ... Ich sehe keinen Vorteil darin, meine Plugins in .local/whatever zu speichern . Das ist eine Art Verschleierung meiner Projekte.

Das aktuelle System von res://addons ist gut ... kostenlos für den Benutzer und tragbar auf Computern. Wenn es keine Beschwerden über dieses System gibt, ist es notwendig, das zu ändern? Es gibt viele andere Dinge, über die sich Benutzer wirklich beschweren ...

@Ranoller Sie könnten das Plugin jederzeit in Ihren Spieleordner kopieren.
Wie auch immer, in diesem Fall würde Ihre project.godot Ihr Plugin als Abhängigkeit auflisten und es würde mit der richtigen Version auf Ihren neuen Computer heruntergeladen

Heruntergeladen? Meine Plugins befinden sich in dem Projekt, das sich im USB-Stick befindet, und sind Teil des Git-Repository ... Ich verstehe den Vorschlag nicht ... Plugins ändern sich genauso wie der andere Code ... Ich ändere mehr Code von Plugins als Gamecode, Ich möchte Plugins nicht nach Version nummerieren und außerhalb des Projekts arbeiten ... Jede Änderung des Zeilencodes muss jedes Plugin auf jedem Computer manuell ändern? ... Plugins fühlen sich wirklich wie ein Teil des Projekts an ... Plugins aus dem Git-Repository herauszugeben ist für mich Unsinn, aber ich glaube wirklich, dass ich etwas davon nicht verstehe ...

@Ranoller Die Idee ist, diese Plugins aus dem Projekt zu verschieben , die Sie nicht ändern müssen . Zum Beispiel ist InterpolatedCamera nur ein Knoten, den Sie so verwenden möchten, wie er ist, und nicht den Code davon ändern.

Dasselbe könnte bei Nur-Editor-Plugins wie TODO-Listen oder Git-Integration usw. der Fall sein. Das sind Dinge, die Sie verwenden, aber nicht ändern möchten.

Dies ähnelt einem Paketmanager und Bibliotheken funktionieren in jeder Sprache, die nicht C und C++ ist. Sie haben eine Datei, die alle Abhängigkeiten angibt, und dann ruft der Paketmanager diese Abhängigkeiten ab. Dies passiert auch, wenn Sie den PC wechseln - der Paketmanager lädt alle noch nicht vorhandenen Pakete herunter.

Wenn Sie etwas ändern möchten , dann bringen Sie den Code in das Projekt ein. Dann ist es in Ihrem Git und dem Projekt mit all seinem Quellcode usw. Aber das ist nicht immer der Fall.

Mein Vorschlag ist, Dinge standardmäßig außerhalb des Projekts zu haben, bis Sie tatsächlich etwas ändern müssen.

Derzeit sind viele Assets hauptsächlich Vorlagen, die Sie ändern müssen. Wenn ein solches System vorhanden ist, kann sich dies ändern, sodass die Dinge eher über APIs und nicht über Quelländerungen für allgemeine Zwecke verwendet werden.

@karroffel Aber wie funktioniert die sprachübergreifende Vererbung in jeder Sprache? Für GDScript, das eng mit der Engine gekoppelt ist, mag es einfach sein, aber für Allzwecksprachen wie C# oder andere Sprachen, die zusätzlich zu GDNative hinzugefügt werden, sieht es ganz anders aus.
Ich kann ernsthaft nicht sehen, wie dies erreicht werden könnte, noch weniger, wie es nicht mehr schlecht als recht tun könnte.

IMO ist es keine gute Idee, den Inhalt eines Addons zu ändern, von dem Ihr Projekt abhängt. Wenn eine Änderung erforderlich ist, kopieren Sie einfach den Inhalt außerhalb des Addon-Ordners und nehmen Sie dort Ihre Änderungen vor.

EDIT: oder das Addon "forken" 😜

@neikeq Was Sie ändern, befindet sich in Ihrem Projekt. Wenn Sie ein Addon ändern möchten, wird es in Ihr Projekt kopiert und nur lokal geändert.

@karroffel Möglicherweise ist eine Idee eines Projekt-Plugins und eines Editor-Plugins erforderlich, um Verwirrung zu vermeiden, mit einer klaren Trennung der beiden.

@QbieShay Was ist, wenn es ein Update gibt, das die von Ihnen geänderten Dateien ändert?

@neikeq Skriptvererbung ist nicht DIE LÖSUNG für dieses Problem, es wäre nur eine. Es gibt derzeit keine gute Möglichkeit, die Funktionalität eines Knotens mit einem angehängten Skript zu überschreiben, wenn Sie eine andere Programmiersprache verwenden möchten.

Wenn wir eine Option zum Überschreiben von Methoden in der Script -API hätten, wäre das auch gut! (grundsätzlich neue Methoden extern definieren und bestehende Methoden außer Kraft setzen).

@PLyczkowski , das ist ein Vorschlag, der auch nützlich wäre, aber was ich vorschlage, ist nicht darauf beschränkt - und das aus einem bestimmten Grund.

Nehmen wir noch einmal das Beispiel InterpolatedCamera . Ich werde niemals den Quellcode dafür anfassen, ich werde ihn nur verwenden. Die Quelle in meinem Projekt zu haben, wäre verschwendet. Außerdem sind die meisten Projekte, die ich mache, alle 3D, also würde ich diesen Code wahrscheinlich in alle meine Projekte kopieren lassen.

Auf der anderen Seite könnte eine Git-Integration sehr nützlich sein, um benutzerdefiniertes Verhalten hinzuzufügen, das mit Git-Hooks schwer auszudrücken ist, daher ist eine Anpassung dort erwünscht.

Es gibt keine schwarz/weiße Linie, wann etwas innerhalb des Projekts sein sollte und wann außerhalb, Editor oder nicht.

@neikeq

Was ist, wenn es ein Update gibt, das die von Ihnen geänderten Dateien ändert?

In diesem Fall würden Sie Versionsinformationen verlieren, sodass Sie nicht mehr einfach aktualisieren können. Sie sollten dann ein Tool wie Git für diese Fälle verwenden.

Die Idee ist

• außerhalb des Projekts: einfacher zu aktualisieren, einfacher projektübergreifend zu haben
• innerhalb des Projekts: anpassbar, verliert den Asset-Status, keine automatischen Updates

Im Grunde genommen werden sie zu normalen Dateien, sobald Sie sie in Ihr Projekt kopieren.

Wenn ich dies lese, kann ich sagen, dass es sinnvoll ist, Aufblähen zu vermeiden und die Dateigröße von Spielen zu minimieren. Erlauben Sie mir jedoch, hier ein paar Ideen einzubringen.

• Godot könnte ein System verwenden, das das Spiel des Codes entfernt, der von Knoten verwendet wird, die es nicht verwendet (dh die meisten 2D-Knoten mit vielen 3D-Spielen und die meisten 3D-Knoten mit vielen 2D-Spielen). Dies wird den Druck verringern, neue Knotentypen nicht zu akzeptieren, um die Spieldateigröße gering zu halten. Unity-Benutzer verwenden beispielsweise bereits etwas Ähnliches für großartige Ergebnisse.
• Godot könnte vielleicht einen eingebauten Asset-Browser haben, der eine Verbindung zu einer Plugin-Seite auf der Godot-Site herstellt. Sie wählen die gewünschten benutzerdefinierten Knoten aus und sie werden automatisch an der richtigen Stelle installiert. Nicht verwendete Plugins werden beim Packen des Spiels entfernt.
• Vielleicht könnten sogar beliebte benutzerdefinierte Knoten mit Godot-Builds gebündelt werden (wie es Blender mit Addons tut). Benutzerdefinierte Knoten sollten ebenfalls gekennzeichnet werden, da sie normalerweise auf einer höheren Ebene liegen und in gewissem Maße eher eine Black Box als die allgemeineren Knoten sein können.

Meine 2 Cent sowieso.

@Ace-Dragon

1. Ich denke, es wäre wirklich cool, Ihren ersten Punkt als Engine-weites Feature zu haben. Wenn Ihr exportiertes Spiel keinen Knoten verwendet oder wenn ein Knoten von keinem der Knoten verwendet wird, die Sie in Ihrem Projekt verwenden, wäre es cool, wenn es möglich wäre, sie automatisch aus der endgültigen Binärdatei auszuschließen. Abgesehen davon müssen Sie sich derzeit nur auf Schalter verlassen und die Engine neu kompilieren. :-/

2. Dies ist im Grunde das, was die Asset-Bibliothek bereits ist. Das Problem ist, dass es kein Konzept von Abhängigkeiten hat, Dinge direkt in Ihr Projektverzeichnis ablegt und keine Möglichkeit hat, einen bestimmten Satz von Plugins systemweit für jedes von Ihnen erstellte Projekt zu verwalten.

3. Benutzerdefinierte Knoten sind immer explizit gekennzeichnet, sodass Sie sich darüber keine Gedanken machen müssen (neben ihnen befindet sich ein Skriptsymbol, da Sie benutzerdefinierte Knoten mithilfe eines Skripts erstellen, um sie zu erweitern). Da es sich um Skripte handelt, werden sie niemals mit der Engine ausgeliefert. Sie wären Teil einer Art Plugin, also haben Sie vielleicht etwas mehr wie mein Godot-Next-Repo, das ein "Node Extensions" -Repository zum Sammeln von Sachen ist. Es wäre mehr als alles andere nur eine "offiziellere" Kapazität (dieses Repo könnte auch viel Arbeit verbrauchen, lol).

Ok, langsam aber gefangen ... Wenn ich die Addons innerhalb des Projekts behalte, könnte ich im Plugin-Code wie in anderen Skripten arbeiten, ohne die Git-Integration mit dem aktuellen Projekt zu verlieren und ohne die Portabilität zu verlieren ... Aber wenn ich eines der konvertieren möchte Plugins in einem Tool für andere Entwickler oder in einem allgemeinen Tool für alle meine Projekte teile ich es in Form eines externen Pakets, das mit dem externen Git-Repository des Tools aktualisiert und mit der Asset-Bibliothek an andere Personen geändert werden kann ... Wenn es ist, für mich ist es ok ... Wenn andere Entwickler das Tool verwenden und ihre persönliche Version benötigen, muss er / sie im Projekt speichern und in diesem Fall wird das Plugin nicht aktualisiert (verlieren Sie nicht ihre eigene Arbeit )... Es ist?

@Ranoller Ja, ich denke, Sie haben den Kern seines Vorschlags verstanden.

Einige Rückmeldungen zu dem, was ihr diskutiert

1) Wenn dies ein tatsächliches Problem war, das gelöst werden musste, bevorzuge ich die Unterstützung mehrerer Skripte pro Knoten (was nur ein paar Codezeilen sind) statt der sprachübergreifenden Vererbung (was Wahnsinn ist). Ich glaube immer noch nicht, dass dies ein Problem ist, das gelöst werden muss.

2) Ich mag die Idee eines Paketmanagers und der systemweiten Installation von Add-Ons nicht. Ich denke, es ist eine schreckliche Idee, und es bringt überhaupt nichts Sinnvolles. Ich habe gesehen, wie traumatisch es sogar für Unity-Entwickler ist, eine Version eines Assets in großen Projekten zu aktualisieren und zu sehen, wie alles kaputt geht, und Tage damit zu verbringen, es zu reparieren.

3) Ich mag die Idee der Paketverwaltung selbst nicht. Ich habe gesehen, wie Unity-Benutzer die meiste Zeit das, was sie aus dem Asset Store bekommen, ohne Ende hacken. Zu oft verwenden sie es nur als Basis, bearbeiten es dann und passen es an ihre eigenen Zwecke an, weil das Asset, das Sie erhalten, nur 60/70 % der gewünschten Position entspricht ... oder sie nur sehen wollten wie es gemacht wird und dann später ihr eigenes Ding machen.

Ich denke, im wirklichen Leben wird durch die diskutierten Vorschläge nicht wirklich gewonnen, daher habe ich nicht vor, dieser Diskussion selbst viel hinzuzufügen.

Wie viel Motorgröße können wir reduzieren, wenn wir den Leuten erlauben, ohne 3D-Kram auf einfache Weise zu exportieren? Viele Spiele (die Hälfte? mehr als die Hälfte?) benötigen keine 3D-Funktionen, aber sie befinden sich immer noch in derselben Binärdatei. Ich weiß, dass es theoretisch auf jeder Plattform mit einem Makro selbst neu kompiliert werden kann, mit ein bisschen Investition ...
Wenn Module nur "interne" dynamische Bibliotheken wären, die Teil der offiziellen Distributionen der Engine sind, wäre das Hinzufügen weiterer Funktionen zur Engine weniger problematisch in dem Sinne, dass sie ganz einfach deaktiviert werden können (genau das ), die Verwendung dynamischer Bibliotheken wie dieser kann jedoch für einige Plattformen (hauptsächlich Mobilgeräte und HTML5) etwas einschränkend sein. Für Module würde ich also verstehen, dass GDNative bevorzugt wird (oh warte ... es hat die gleichen Probleme ^^).

@reduz wie würden mehrere Skripte funktionieren? Und wie würde es zur Motorverlängerung beitragen? Haben Sie Ihre Idee in einer bestehenden Ausgabe erklärt? (frage, weil es wahrscheinlich zu viel ist, um es in diesem Thread zu erklären)

Fügen Sie eine ordnungsgemäße Abhängigkeitsverwaltung mit systemweiten Installationen von Assets hinzu. Verschieben Sie Addons aus dem Projekt selbst mit einer Möglichkeit, sie zur Änderung zurückzubringen

Nein. Ich möchte sie aus Gründen der Robustheit im Projektverzeichnis haben. Aber vielleicht mit einer Möglichkeit, ausgewählte manuell mit dem Paketmanager zu aktualisieren, und vielleicht mit systemweitem Caching von ihnen.

Was das Aufblähen betrifft, würde ich stattdessen mehr Kontrolle über _modules_ begrüßen, und dies wurde bereits in der Patreon-Umfrage im Januar 2018 abgestimmt:

Roadmap-Priorität: Mehr Optionen zum Deaktivieren der Kompilierung von Teilen der Engine, um kleinere Binärgrößen zu erstellen [Erwartet für 3.1]

Es ist schwierig, diesen Vorschlag zu kommentieren, da er eine Vielzahl von Dingen berührt und die Leute zu verschiedenen Aspekten Stellung nehmen und verschiedene Probleme ansprechen.

Insgesamt denke ich, dass der Vorschlag für den "Abhängigkeitsmanager" auf dem Papier gut klingt, aber ich denke, die Implementierung wird keine Vorteile bringen, die das einfache Bereitstellen von Addons im Projektordner nicht bringen würde. Es erfordert die Integration eines komplexen Mechanismus für das Abhängigkeitsmanagement, um 1 Fall von "einfacher zu installieren" zu lösen. Dieses Projekt hat bereits über 3000 offene Probleme mit einem kleinen Team von Mitwirkenden. Etwas so Komplexes wie das Abhängigkeitsmanagement einzuführen, ist meiner Meinung nach ein Kinderspiel.

Ich stimme @reduz zu, dass der Kern minimalistisch sein sollte. Meiner Meinung nach sollte alles, was nicht als "Kern" eingestuft werden kann, eigenständig aufgenommen werden. Als Benutzer erwarte ich von Godot, dass es eine plattformübergreifende Spiel-Engine ist. Wenn ich das Godot _Game Framework_ (Fahrzeuge, interpolierte Kameras, Terrain, Player-Controller usw.) haben möchte, sollte es als erstklassiges Add-On (oder Modul?) unabhängig vom Core verfügbar sein. Ich denke, die Verbesserung der Addon-Story hilft dabei, aber ein vollwertiger Abhängigkeitsmanager und ein automatisierter Addon-Manager scheinen es auf einen geringen Nettonutzen zu drängen.

Mein letzter Kommentar wäre, vorsichtig zu sein, wenn es darum geht, "Anfänger" zu bedienen und "Power"-Benutzer aufzugeben. Godot hat aufgrund seiner leistungsstarken Funktionen (Module, gdnative, gdscript, Editor usw.) und seiner Flexibilität die Aufmerksamkeit fortgeschrittener Benutzer auf sich gezogen. Es sind diese Art von Benutzern, die Godot auf die Probe stellen, seine Grenzen erweitern, seine API erkunden und oft zum Projekt beitragen. Dies sind die gleichen Benutzer, die Symlinks zu einem Verzeichnis in ihrem Dateisystem erstellen können, um ihre Add-Ons in mehreren Projekten wiederzuverwenden.

Wenn die Idee darin besteht, übergeordnete Knoten aus dem Kern zu entfernen, sollten diese Knoten leicht verfügbar und zum Herunterladen leicht zu finden sein. Idealerweise könnten wir sie als "offiziell" beibehalten, damit sie besser sichtbar sind (genau wie die Knoten in der Engine). Dann könnten offizielle Assets problemlos in Demos und Tutorials verwendet werden.

Diese auszulagern hat den Vorteil, dass sie verbessert und veröffentlicht werden können, ohne auf eine neue Engine-Version warten zu müssen. So konnten Fehler sofort behoben werden, da es für eine Erweiterung recht einfacher ist, ein neues Release zu packen.

Ich denke, am Ende wäre die Paketverwaltung die meiste Zeit ziemlich mühsam. Selbst im Fall einer neuen Version eines benutzerdefinierten Knotens, den Sie Ihrem Projekt hinzugefügt haben, kann die Aktualisierung viele andere Probleme verursachen (sogar mit semver, da Sie möglicherweise einen Fehler umgangen haben, der jetzt behoben ist).

OTOH für einige Editor-Plugins kann es sinnvoll sein, sie aus dem Projekt zu entfernen und sie häufig zu aktualisieren. Mein Tiled-Importer-Plugin ist ein Beispiel. Sie möchten höchstwahrscheinlich nicht, dass es mit dem Spiel geliefert wird, und möchten die neueste Version haben, die mehr Funktionen unterstützt und Bugfixes enthält.

Dies gilt umso mehr für andere Editor-Erweiterungen wie Git-Manager und Zeiterfassung. Vielleicht interessiert es Sie nicht einmal, ob Ihre Teamkollegen das Zeiterfassungs-Plugin haben oder nicht, es hat nichts mit dem Projekt zu tun. Sie müssen jedoch Ihren addons -Ordner einfügen und in den Projekteinstellungen aktivieren und dann darauf achten, dass Sie ihn nicht mit dem Rest des Spiels übertragen. Das ist wahrscheinlich die Minderheit der Plugins, aber immer noch systemweite Plugins zu haben, die nicht an das Projekt gebunden sind, haben einen echten Anwendungsfall.

Ich glaube, der Mittelweg wäre, einen Paketmanager als externes Tool zu erstellen und ihn nicht in Godot zu integrieren. Es muss nicht einmal offiziell sein (obwohl es "gebilligt" werden könnte). Wenn einige Änderungen in der Basis-Engine erforderlich sind, um dies zu unterstützen (z. B. das Vorhandensein globaler Plugins), wäre das Hinzufügen kein großes Problem, insbesondere wenn sie nur für den Editor bestimmt sind.

Dann können diejenigen, die es für nützlich halten, es verwenden. Wenn es weit verbreitet ist und jeder es verwendet, werden wir sowohl die Nutzungsstatistiken als auch das Feedback zur Benutzerfreundlichkeit haben, um zu entscheiden, ob und wie es vollständig in die Basis-Engine integriert werden soll.

Nun, Cross-Script-Vererbung ist für mich ein Nein-Nein (wenn das überhaupt möglich ist). Multiscript ist irgendwie seltsam, aber es würde die Cross-Script-Vererbung effektiv auf eine sauberere Weise ersetzen. Obwohl es einige Bedenken aufwirft, wie zum Beispiel: Wie ruft man die Funktion eines anderen Skripts im selben Objekt auf? Ich denke, das ist eine andere Diskussion.

Das Referenzieren von Skripten mit dem Namen OTOH klingt wirklich nett. Im Idealfall könnten alle Ressourcen namentlich referenziert werden, sodass Pfade kein Problem darstellen, wenn Sie sich entscheiden, Dinge zu verschieben.

@vnen Das einzige Problem, das ich immer noch sehe, ist die Inkompatibilität zwischen Addons und Projekten. Wie würden Sie dieses Problem angehen?
Denn wenn es eine offizielle Erweiterungsbibliothek gibt, die von Godot gepflegt wird, wird entweder jeder Knoten in jeder möglichen Sprache ausgeliefert, oder ich sehe sprachübergreifende Vererbung als einzige Möglichkeit, die Benutzerfreundlichkeit zu erhalten.

@vnen Wenn Sie alle Assets namentlich referenzieren, entsteht ein widersprüchliches Durcheinander. Das ist besser für Skripte geeignet, da nur Programmierer eindeutige Namen für ihre Klassen finden müssen, um sie (oder seltener Ressourcen) einzugeben und zu verwenden. Für die anderen Dinge, wenn wir Pfade loswerden, bräuchte es diese https://github.com/godotengine/godot/issues/15673 , es sei denn, Sie möchten, dass auch Künstler, Designer usw. alle ihre Assets eindeutig benennen müssen (was kommt immer noch mit dem Problem der Umbenennung).

@Zylann @vnen Die TypeDB, die ich schreibe, sollte es theoretisch ermöglichen, optional einen Namen für jedes Asset zu registrieren. Ich verwende es derzeit nur für Skripte und plane, es auch für benutzerdefinierte Typszenen zu tun, aber Sie könnten es auch ändern, um mit Ressourcen zu arbeiten. Die Logik hat derzeit nur jeweils eine HashMap für Skripte und Szenen, aber vielleicht könnte ich die Logik verallgemeinern, um jede Art von Asset zu verarbeiten, alles in kategorisierten HashMaps.

Ich kann die Bedenken von reduz in Bezug auf systemweite Dinge respektieren, und das sind sicherlich Bedenken in Bezug auf Plugins, die die Angebote der Engine modifizieren würden, aber wenn es speziell um Funktionen für den Editor geht, wie vnen es beschreibt, kann ich definitiv sehen, dass dies nützlich ist in ein relativ sicherer Weg. Wenn Leute Plugins hinzufügen, um dem Editor mehr Funktionen zu geben, sind das keine Dinge, die sie normalerweise aufbrechen und selbst modifizieren werden. Sie werden es einfach so verwenden, wie es ist, oder wenn sie Änderungen vornehmen, werden sie diese Änderungen öffentlich machen, um die Tools wahrscheinlich zu verbessern. Sie passen sie schließlich nicht an ein Spiel an. Wenn es sich also um ein Plugin wie dieses handelt, sollten wir eine Möglichkeit haben, diese Funktionen der Engine einfach zuzuweisen, wenn Sie (irgendwie) ein neues Projekt starten.

Eine mögliche Methode, die die Dinge einfacher machen könnte, ohne einen Abhängigkeitsmanager zu benötigen, wäre es, Abhängigkeiten einfach nicht zwischen Plugins zu teilen und sie stattdessen innerhalb des Projekts zu duplizieren, auf diese Weise ist die Versionierung kein Problem. Es würde ein einzelnes Projekt potenziell größer machen, aber wenn es sich um spielrelevante Inhalte handelt und die Leute sowieso daran herumbasteln, wie reduz sagt, dann können sie die Abhängigkeiten einfach verschieben. Was wir in diesem Fall brauchen, ist eine Möglichkeit für Plugins, zu deklarieren, WELCHE externen Plugin-Abhängigkeiten sie haben, und Benutzern die Möglichkeit zu geben, anzupassen, wo sie nach diesem abhängigen Plugin suchen. Wenn sie sich dafür entscheiden, ein Plugin zu verschieben und andere Plugins an derselben Stelle danach suchen, können sie dies anpassen. Aber dann würde standardmäßig alles einfach funktionieren, indem es seine eigenen Abhängigkeiten verwaltet. Dieser Fall wäre wahrscheinlich auch einfacher mit dem gesamten Plugins-als-Unterprojekte-Vorschlag (#19178) zu handhaben.

Dies würde uns davon abhalten, globale Abhängigkeiten zu haben, die überhaupt einen Abhängigkeitsmanager erfordern (Ausgabe Nummer 3 von reduz). Und wir könnten es mit einer Funktion koppeln, die es Benutzern ermöglicht, eine Favoritenliste von Assets aus der Asset-Bibliothek zu erstellen, die sie automatisch in ihre Projekte installieren können, wenn ein neues Projekt erstellt wird (also wird alles immer noch lokal gespeichert, aber es geschieht automatisch und sie müssen nicht manuell rausgehen, alle ihre bevorzugten Plugins finden und sie manuell herunterladen und installieren). Dies würde das Usability-Problem beheben, das @karroffel in Bezug auf die einfache Erweiterung der Engine mit identischen Assets beim Erstellen eines neuen Projekts lösen möchte.

Für mehr Editor-spezifische Plugins, die nicht dupliziert werden müssten, könnten die Leute diese "Favoriten"-Plugins vielleicht einfach markieren und sie würden automatisch symbolische Links für sie erstellen und die Plugins in einer Art Benutzerordner speichern. Also, vielleicht haben Sie "Editor-Favoriten" und "Projekt-Favoriten" für "Ich möchte dies in jedem Projekt, speichere es an einem gemeinsamen Ort und erstelle einen Symlink" und "Ich möchte dies in jedem Projekt, dupliziere es".

Kombinieren Sie das mit dem TypeDB-Zeug zum Benennen von Skripten / Anpassen benutzerdefinierter Typen, und ich glaube, es würde alle erwähnten Probleme richtig angehen, mit Ausnahme des Problems der sprachübergreifenden Skriptvererbung / des Multiscript-Problems, das etwas ganz anderes ist.

Also, vielleicht haben Sie "Editor-Favoriten" und "Projekt-Favoriten" für "Ich möchte dies in jedem Projekt, speichere es an einem gemeinsamen Ort und erstelle einen Symlink" und "Ich möchte dies in jedem Projekt, dupliziere es".

Vielleicht ist es dann bequemer, "Bündel" von Plugins zu haben - vom Benutzer erstellt, offiziell genehmigt + vom Benutzer erstellt, lokal. Anstelle von „Editor-Favoriten“ und „Projekt-Favoriten“ haben wir also „Ego-Shooter“, „Voxel-Block-Spiel“ oder einfach nur „Meine Sachen“. Ziemlich ähnlich wie z. B. Unity-Starter-Assets, aber keine Notwendigkeit, sie mit Texturen usw. aufzublähen, verschiedene Arten von Godot-Maskottchengesichtern sollten ausreichen: D

Dies funktioniert auch als Paketmanager, wobei der Paketmanager jetzt das menschliche Kuratieren von Plugin-Bundles ist.

@starry-abyss Die Plugins, die Leute jetzt erstellen, haben bereits das Potenzial, "Bündel" anderer Plugins zu sein (der Benutzer oder Plugin-Entwickler kann sie einfach selbst verschieben und zusammenführen). Das Ziel hier ist es, einen funktionalen Unterschied zwischen den Kategorien zu haben, bei dem der Editor tatsächlich Operationen zur Verbesserung der Benutzerfreundlichkeit im Namen des Benutzers durchführt, damit der Benutzer nichts manuell tun muss.

Insofern haben wir bereits das Feature „Humans Curating Plugin Bundles“. Das Problem besteht darin, mühsame Aufgaben zu automatisieren und sie gleichzeitig mit effizienter Produktivität in allen Anwendungsfällen anpassbar zu halten.

@ Zylan

Wenn Sie alle Assets namentlich referenzieren, entsteht ein widersprüchliches Durcheinander. Das ist besser für Skripte geeignet, da nur Programmierer eindeutige Namen für ihre Klassen finden müssen, um sie (oder seltener Ressourcen) einzugeben und zu verwenden.

Ist es so eine große Sache, Sachen richtig zu benennen? Aber es könnten UIDs sein, es spielt für mich keine Rolle, solange es nicht pfadabhängig ist. Sogar der Pfad ist nur wie ein Name, da Ressourcen ihrem importierten Gegenstück neu zugeordnet werden ...

@QbieShay

Das einzige Problem, das ich noch sehe, ist die Inkompatibilität zwischen Addons und Projekten. Wie würden Sie dieses Problem angehen?

Wenn dies wirklich ein Problem ist, dann ist Multi-Skript wahrscheinlich die einfachste Lösung. Es wurde hauptsächlich wegen der Diskussion in #8546 entfernt, aber ich denke, das lässt sich ohne großen Aufwand lösen.

Ich glaube, dass das Problem, dass mehrere Plugins dasselbe tun, virtuell ist. Wir haben bereits ein Sternsystem in der Assetlib, dieses System ist genau das, ein Indikator dafür, was häufig verwendet und bevorzugt wird.

Die Sache, die übersehen wird, aber meiner Meinung nach einer der Gründe ist, warum Leute nach Ergänzungen in der Kern-Engine fragen, ist folgende: Wer wird dieses Ding für alle Plattformen kompilieren?

Natürlich ist dies für ein GDScript-Plugin kein Problem, aber für ein CPP-Plugin ist dies ein riesiges Problem.

Wenn wir dieses Problem nicht lösen, wird sich die Diskussion darüber, was in der Kern-Engine enthalten sein wird, dahingehend ändern, welches Plugin als offiziell markiert wird, und durch das Markieren von Plugins als offiziell wird das Sternensystem ruiniert, weil die Leute gehen um ein Plugin einfach zu markieren, weil es nur ein offizielles ist.

Also meiner Meinung nach müssen wir dieses Problem zuerst lösen, und ich habe keine Ahnung wie. Ist es zum Beispiel möglich, für alle Plattformen über Linux zu kompilieren? Wenn ja, dann können wir etwas wie Ubuntu Imager verwenden: https://www.maketecheasier.com/create-linux-distro/ um eine bereits eingerichtete Linux-Umgebung für die Plugin-Hersteller und GDNative-Benutzer zu erstellen.

Ist es zum Beispiel möglich, für alle Plattformen über Linux zu kompilieren? Wenn ja, dann können wir etwas wie Ubuntu Imager verwenden: https://www.maketecheasier.com/create-linux-distro/ um eine bereits eingerichtete Linux-Umgebung für die Plugin-Hersteller und GDNative-Benutzer zu erstellen.

Nein (macOS- und iOS-Builds können nur wirklich von macOS kompiliert werden), und ich denke nicht, dass es eine gute Idee ist, Leute zu zwingen, ein Live-Linux-Betriebssystem zu booten, um GDNative-Bibliotheken in die Asset-Bibliothek hochladen zu können.

Es ist jedoch möglich, mit Travis CI und AppVeyor, die Sie kostenlos auf öffentlichen GitHub-Repositories einrichten können, für alle Plattformen zu kompilieren.

Wenn wir dieses Problem nicht lösen, wird sich die Diskussion darüber, was in der Kern-Engine enthalten sein wird, dahingehend ändern, welches Plugin als offiziell markiert wird, und durch das Markieren von Plugins als offiziell wird das Sternensystem ruiniert, weil die Leute gehen um ein Plugin einfach zu markieren, weil es nur ein offizielles ist.

Nun, das Sternensystem wurde nie implementiert, also kann man nichts bewerten. Bei den offiziellen Plugins ist es nicht so, dass wir eines auswählen und als offiziell markieren, wir sind diejenigen, die sie erstellen und pflegen.

Eingebaute Knoten für grundlegende Dinge sind eines der besten Dinge des Editors. Wenn wichtige Knoten oder Ressourcen entfernt werden sollen, benötigt der Projektmanager Vorlagen, um die gemeinsamen Knoten automatisch herunterzuladen.

Dieser Vorschlag birgt auch das Risiko, die Engine auf eine andere „Always Online“- und „Junk Store“-Engine umzuschalten. Wenn dies erledigt ist, müssen viele andere Dinge von offizieller Unterstützung (Fehlerbehebung) und Verfügbarkeit (Versionsaktualisierung) erhalten werden.

Und der Store muss offizielle Bundles für die Offline-Nutzung anbieten (mit Offline-Store-Unterstützung im Editor).

Wenn dies erledigt ist, müssen viele andere Dinge von offizieller Unterstützung (Fehlerbehebung) und Verfügbarkeit (Versionsaktualisierung) erhalten werden.

TBH, die Wartung von Dingen im Motor oder im Laden ist ziemlich gleich. Die Fahrzeugknoten haben zum Beispiel nur wenige Fehlerberichte, weil sie fast niemand verwendet, und selbst die gemeldeten Fehler wurden nie behoben. Ich finde es viel besser, solche Knoten auszulagern, weil es einfacher ist, Leute dazu zu bringen, Dinge zu reparieren, ohne sich mit der Engine-Quelle anlegen zu müssen, sodass es mehr potenzielle Mitwirkende gibt.

Wenn ein Engine-Knoten ein Problem hat, öffnen die Leute einen Fehlerbericht. Aber wenn es sich um ein Plugin mit GDScript-Code handelt, ist es für die Person ziemlich einfach, den Code zu ändern und zu testen, wobei sie wahrscheinlich die Fehlerbehebung an die Community zurückgibt. Ich sehe das wirklich als Gewinn. Aber nur, wenn diese externen Knoten einfach integriert werden können, was derzeit nicht der Fall ist. Dazu gehören eine gute Sichtbarkeit und eine integrierte Dokumentation.

Und der Store muss offizielle Bundles für die Offline-Nutzung anbieten (mit Offline-Store-Unterstützung im Editor).

Ja, und es sollte auch einfach sein, Offline-Pakete zu installieren.

@reduz

Ich mag die Idee eines Paketmanagers und der systemweiten Installation von Add-Ons nicht. Ich denke, es ist eine schreckliche Idee, und es bringt überhaupt nichts Sinnvolles. Ich habe gesehen, wie traumatisch es sogar für Unity-Entwickler ist, eine Version eines Assets in großen Projekten zu aktualisieren und zu sehen, wie alles kaputt geht, und Tage damit zu verbringen, es zu reparieren.

Gut, aber warum ? Was sind die tatsächlichen Einschränkungen und Probleme, die Sie daraus sehen? „Ich mag es nicht“ zu sagen, ohne zu sagen warum, wird die Leute nicht davon überzeugen, dass es keine gute Idee ist; Sie sollten zumindest eine andere Erklärung als die genannten vagen Gründe geben.

Gut, aber warum? Was sind die tatsächlichen Einschränkungen und Probleme, die Sie daraus sehen? „Ich mag es nicht“ zu sagen, ohne zu sagen warum, wird die Leute nicht davon überzeugen, dass es keine gute Idee ist; Sie sollten zumindest eine andere Erklärung als die genannten vagen Gründe geben.

Angenommen, die globale "Addon" -Registrierung auf dem System:

• Laden Sie das Add-on v1.3 vom Online-Add-on-System herunter. Addon ist auf ~/.godot oder was auch immer installiert
• Die Version wird meinem Projekt unter ~/my-project in einer Art lokalem Speicher (Datei, SQLite usw.) zugeordnet.
• Ich aktualisiere auf v1.4. Jetzt muss mein Addon-Manager wissen, dass 1.3 von keinem Projekt verwendet wird, und es bereinigen. Der Manager verfügt also über zusätzliche Funktionen zum Nachverfolgen von Abhängigkeiten und welche Projekte welche Abhängigkeiten haben. Alternativ fügt niemand diese Funktionalität hinzu, sodass mein lokaler Computer mit mehreren Versionen desselben Addons verschmutzt wird
• Ich beschließe, mein Projekt nach ~/big-project/game zu verschieben. Jetzt brauche ich eine Möglichkeit, den Verweis auf mein Projekt in der Addon-Registrierung zu aktualisieren. Wie mache ich das? Muss ich den Addon-Manager separat ausführen? Manager register new_proj_location ?
• Es wird nun entschieden, Abhängigkeiten lokal im requirements.txt Python-Stil zu speichern. Super, Problem gelöst. Abgesehen davon, dass ich wieder nicht weiß, welche Projekte von welchen globalen Paketen abhängen, muss ich das System nach Godot-Projekten durchsuchen oder jedes Projekt registrieren, um zu vermeiden, dass sich Versionen anhäufen.
• Gut, ich bearbeite das Problem einfach. Bereinigen Sie tote Pakete von Zeit zu Zeit manuell. Also arbeite ich an VehicleBodyAddon für mein Projekt mit v1.5. Ugh, es macht F * M für die Beschleunigungsberechnung, aber ich möchte F * M * 5 machen. Lassen Sie mich schnell den Code ändern ... Hoppla, da gehen alle meine anderen Projekte, die dieses Addon ausführen.
• Lassen Sie mich ein neues Addon erstellen, das von dem anderen Addon abhängt. Hmmm, jetzt muss ich registrieren, dass mein neues benutzerdefiniertes Addon von dem vorhandenen abhängt. Jetzt muss ich den Manager erweitern, um nicht nur Addons von einem entfernten Standort herunterzuladen, sondern auch mit lokalen Pfaden oder Git-Repositories oder so etwas zu arbeiten.

Angenommen, "verkaufte" Addons:

• Laden Sie das Addon in das Addon-Verzeichnis herunter
• Das Aktualisieren überschreibt das Addon im Verzeichnis

Der Manager verfügt also über zusätzliche Funktionen zum Nachverfolgen von Abhängigkeiten und welche Projekte welche Abhängigkeiten haben. Alternativ fügt niemand diese Funktionalität hinzu, sodass mein lokaler Computer mit mehreren Versionen desselben Addons verschmutzt wird

Das ist genau das, was der gem -Befehl von anderen Rubys tut, und niemand beschwert sich darüber, da sie einen Befehl haben, alte Versionen von Gems (Rubys Begriff für Addons) zu bereinigen, von denen keine anderen Gems abhängen. Außerdem, warum müssen wir die alte Version behalten, wenn die neue Version wahrscheinlich sowieso größtenteils kompatibel sein wird, wenn wir aktualisieren? Wenn es hart auf hart kommt, kann der Benutzer die alte Version wieder bekommen, wenn sein Programm unbedingt auf die alte Version angewiesen ist, was höchstwahrscheinlich nicht der Fall sein wird.

Ich beschließe, mein Projekt nach ~/big-project/game zu verschieben. Jetzt brauche ich eine Möglichkeit, den Verweis auf mein Projekt in der Addon-Registrierung zu aktualisieren.

Wirklich nicht. Sie denken viel zu tief darüber nach, wenn der Add-On-Manager einfach ... die Projektliste des Projektmanagers verwenden und alle nicht vorhandenen Pfade ignorieren könnte. Natürlich nur, wenn es absolut notwendig ist, Projekte und ihre Anforderungen im Auge zu behalten, wofür ich keine Notwendigkeit sehe, wenn wir einfach die neuesten Versionen aller Add-Ons behalten könnten, die wir heruntergeladen haben, wie buchstäblich jedes andere Add-On Manager da draußen.

Es wird nun entschieden, Abhängigkeiten lokal im requirements.txt Python-Stil zu speichern. Super, Problem gelöst. Abgesehen davon, dass ich wieder nicht weiß, welche Projekte von welchen globalen Paketen abhängen, muss ich das System nach Godot-Projekten durchsuchen oder jedes Projekt registrieren, um zu vermeiden, dass sich Versionen anhäufen.

Eine Requirements.txt im Python-Stil wäre eine großartige Option für diese Art von Add-on-System. Auf diese Weise können wir, wenn das Projekt unbedingt eine alte Version benötigt (aber oft möchten Sie sowieso die neueste Version haben), dies angeben, und wenn der Add-On-Manager diese alte Version schließlich löscht, kann er dies wissen um es später erneut herunterzuladen.

Also arbeite ich an VehicleBodyAddon für mein Projekt mit v1.5. Ugh, es macht F * M für die Beschleunigungsberechnung, aber ich möchte F * M * 5 machen. Lassen Sie mich schnell den Code ändern ... Hoppla, da gehen alle meine anderen Projekte, die dieses Addon ausführen.

Oder verwenden Sie eine lokale Kopie des Add-Ons für dieses Projekt? Wenn wirklich eine Änderung erforderlich ist, die nur für ein Projekt gilt, und Sie wirklich keine lokale Kopie des Projekts erstellen möchten, erstellen Sie einfach eine .gd-Datei, die sie erweitert und die Änderung(en) vornimmt, und verwenden Sie sie dann diese neue GD-Datei anstelle der aus dem Addon.

Lassen Sie mich ein neues Addon erstellen, das von dem anderen Addon abhängt. Hmmm, jetzt muss ich registrieren, dass mein neues benutzerdefiniertes Addon von dem vorhandenen abhängt. Jetzt muss ich den Manager erweitern, um nicht nur Addons von einem entfernten Standort herunterzuladen, sondern auch mit lokalen Pfaden oder Git-Repositories oder so etwas zu arbeiten.

Git-Untermodule. Eine weitere requirements.txt (wie das, was Python tut). Oder sagen Sie dem Benutzer einfach, dass Add-on X erforderlich ist. Es ist nicht so schwer, wie Sie es darstellen. Die meisten Benutzer von Godot sind nicht dumm. Sie wissen, was „Dieses Add-on erfordert: Add-on X Core, Add-on Y, Add-on Z“ bedeutet.

@rminderhoud Wenn Sie dann empfehlen, eine Kopie der Add-Ons eines Projekts nach Bedarf in jedem Projekt zu speichern (damit es nur die benötigte Version hat und es frei ändern kann, ohne Probleme zu verursachen), könnte sich mein früherer Vorschlag vielleicht mit dem Kern befassen Problem im Zusammenhang mit diesem Problem? Erstellen Sie nämlich ein Dienstprogramm innerhalb der EditorSettings, mit dem der Benutzer angeben kann, welche Addons automatisch installiert werden sollen, wenn er ein neues Projekt erstellt.

Wir könnten sogar ein ähnliches Dienstprogramm erstellen, mit dem Benutzer feste Links zu einem user://-Speicherort erstellen können, um bestimmte zu speichern (insbesondere für Add-Ons, die Editor-Funktionen hinzufügen). Wenn der Benutzer dies unverantwortlich tut und sein Projekt vermasselt, wäre es seine eigene Entscheidung. Die Standardmethode, bei der nur alle Assets während der Projekterstellung kopiert werden, könnte sehr nützlich sein.

Das Hinzufügen eines neuen Plugin-Systems sollte nicht inkompatibel mit res://addons sein, wie es jetzt ist ... Und das liegt daran:

Das eigentliche System ist großartig ...

Ich wiederhole:

Das eigentliche System ist großartig ...

Kein früherer beschwert sich über diesen Punkt.

Ich bin zu spät zu dieser Diskussion, hier sind einige Gedanken zu dem Vorschlag:

• Ich persönlich verwende noch nicht viele „Assets“ und finde, dass der Addon-Ordner so wie er ist einfach zu handhaben ist.
• Ich verstehe, was die sprachübergreifende Skriptvererbung tun würde und welches Problem sie lösen würde (ermöglichen Sie einem C#-Entwickler, ein GDScript-Skript zu erweitern, um benutzerdefinierte Funktionen mit C# hinzuzufügen) (nicht, dass ich den Wunsch hätte, es zu verwenden), aber ich bin mir nicht sicher was mehrere Skripte pro Knoten tun würden. Oh, also anstatt des C#-Skripts, das sich aus dem GDScript-Skript erstreckt, wäre es in der Lage, es aufzurufen? Welches Skript wäre das wichtigste? Wie würde der C#-Code ändern, was das GDScript-Skript tut?
• Es kann nützlich sein, Skripts zuzulassen, die nach Klassennamen / Namensraum (TypeDB) referenziert werden. Ich bin mit res://paths einverstanden , aber es stimmt, dass das Erben von etwas in Addons zu sehr langen Pfadnamen führt. Kein großes Problem, aber ein Nice-to-have - wäre jedoch wahrscheinlich für die sprachübergreifende Vererbung erforderlich (oder bevorzugt).

Ein einfacheres Design für die Vermögensverwaltung, das ich vorschlagen würde, ist

• Es ist nützlich, eine Datei „dependencies.json“ zu haben (oder einfach nur die Daten in den Projekteinstellungen zu speichern), nur damit ich weiß, welche Version des Assets ich heruntergeladen habe und ob es eine aktualisierte Version gibt. Ich denke, das sind notwendige Informationen.
• Nein, Assets dürfen keine Abhängigkeiten definieren. Ich glaube nicht, dass Godot-Assets so stark voneinander abhängig sein werden wie npm-Module. Lassen Sie den Asset-Entwickler in der Dokumentation angeben, ob es wirklich von einem anderen Asset abhängt, und lassen Sie den Benutzer manuell installieren. Dies wird die Dinge vereinfachen und wir müssen keine weitere Abhängigkeitsvalidierungssache erstellen, die Code-Bloat / mehr zu wartender Code ist.
• Nein, speichern Sie Assets nicht an einem „globalen“ Ort. Es ist schon gut, sie im Projekt-Addons-Ordner aufzubewahren. Es ermöglicht ihnen, mit der Quellcodeverwaltung mit dem Projekt festgeschrieben zu werden, und macht sie einfach zu verwalten. Sogar npm node_modules speichert die Module eines Projekts innerhalb des Projekts.
• Verbessern Sie jetzt den Asset-Browser, sodass er auflisten kann, welche der installierten Assets aktualisiert wurden, und Sie diese aktualisieren können, wenn Sie dies wünschen.
• Nun, es macht Sinn, „globale“ Addons für diejenigen Addons zu haben, die nur Editor-Verbesserungen sind. Normale Addons landen also immer noch im Projekt-Addons-Ordner, aber für Editor-bezogene Addons haben Sie die Möglichkeit, sie global zu installieren. Dadurch wird dieser Code auch außerhalb des Addons-Ordners des Projekts verschoben, sodass er nicht in das Release-Paket gelangt. (Dies ähnelt npm install -g für Entwicklungstools)

Also nur ein paar Verbesserungen, um aktualisierte Assets nachzuverfolgen und Editor-Add-Ons global installieren zu können.

Unter der Annahme, dass wir keine Abhängigkeiten handhaben, könnte es meiner Meinung nach ein Problem der Auffindbarkeit / Benutzerfreundlichkeit für Benutzer geben. Nehmen wir an, ein neuer Benutzer möchte ein Plugin oder "Asset-Paket" mit einer Abhängigkeit ausprobieren. Das Paket wird in Asset Lib angezeigt, lädt es herunter, dann funktioniert es nicht, wahrscheinlich mit einem "internen Skript konnte nicht geladen werden" oder so etwas. Das ist kryptisch.

• Entweder muss jeder Entwickler, der es wagt, mindestens eine Abhängigkeit zu haben, Boilerplate-Code einrichten, um dem Benutzer zu zeigen, dass er eine Abhängigkeit installieren muss (selbst wenn das Paket nur eine Demo für dieses Plugin ist!)
• Oder hat die Assetlib das zumindest angegeben?

Außerdem +1 für die einfache Aktualisierung von Assets, ohne dass Sie sie erneut in der Bibliothek durchsuchen müssen.

Es ist wahr, aber sobald der Benutzer sieht, dass es nicht funktioniert, wird er sofort die Dokumentation nachschlagen und feststellen, dass er die anderen Assets installieren muss.

An dieser Stelle ist es nur ein eingebildetes Problem. Und in der Denkweise der Projektbetreuer, die ich gesehen habe, ist es sinnvoll, es nicht zu implementieren, bis wir herausgefunden haben, dass es wirklich ein Problem ist. Dh. Es gibt viele Assets, die von anderen Assets abhängig sind, und Benutzer haben große Probleme damit.

Als ausgereifte Lösung stimme ich jedoch zu, dass es gut wäre, ein Ökosystem von Vermögenswerten zu haben und die Entwicklung eines Ökosystems von Vermögenswerten fördern könnte, das auf anderen Vermögenswerten aufbaut / von ihnen abhängt.

Fügen Sie oben aufbrechende Abhängigkeiten zwischen Assets hinzu, die aufgrund von Updates fällig sind (was bei Asset-abhängigen Engines von Drittanbietern üblich ist), sollten viele Versionen desselben Plugins in der Bibliothek aufbewahrt werden.

@eon-s Also so etwas wie der Vorschlag von @bojidar-bg?

Ich denke, das wichtigere Thema, das hier diskutiert wird, betrifft das Thema, Dinge in die Kern-Engine aufzunehmen oder sie als Erweiterungen oder offizielle Erweiterungen zu haben.

Ich persönlich mag die Idee sehr, die Engine anpassen zu können und alles zu entfernen, was ich eigentlich nicht benutze. [Kann mir jemand zeigen, wie ich zum Beispiel alle 3D-Sachen entfernen würde? Und kann ich die Kompilierung von Modulen, die ich nicht verwende, einfach deaktivieren? Wie?]

Die Sache ist, wenn jemand einen neuen Knotentyp vorschlägt, z. der erwähnte Federarm oder neue Klasse zB. eine bessere RNG-Klasse, oder wenn einige vorhandene Kernknoten entfernt werden sollen, z. der Fahrzeugcontroller ... das sind C++ Code. Wenn sie nicht im Kern enthalten sind, wie werden sie dann als Erweiterungen hinzugefügt? GDNative Assets? Das wären viele DLLs und gemeinsam genutzte Bibliotheken, die verwaltet/erstellt werden müssen.

Als jemand, der seinen eigenen Godot-Build erstellt, würde ich es vorziehen, sie in meinem Godot-Build-Ordner installieren zu können. Wenn sie beispielsweise Module wären, würde ich sie einfach in meinen Modulordner klonen, oder vielleicht gäbe es ein Tool, das das irgendwie automatisiert. Sie können alle Module, die Sie verwenden möchten, aus der Liste der offiziellen Module, offiziellen Erweiterungsmodule und auch von Benutzern auswählen. Laden Sie sie dann herunter (Git-Klon), und dann können Sie fortfahren und Ihren benutzerdefinierten Godot erstellen. Sie können auch sehen, welche aktualisiert wurden, und sie aktualisieren und später neue installieren. (Dies bezieht sich auf C++-Code.)

Ich denke also, dass wir zuerst eine bessere und flexiblere Asset-Bibliothek (Asset-Installation, Abhängigkeiten, Versionierung usw.) und eine einfachere Plugin-Integration/-Erweiterung (Editor-Tools, skriptfähige benutzerdefinierte Knoten usw.) benötigen, bevor wir versuchen, Funktionen aus der Engine zu entfernen .

Ich antworte hier auf @chanon .

Nein, Assets dürfen keine Abhängigkeiten definieren. Ich glaube nicht, dass Godot-Assets so stark voneinander abhängig sein werden wie npm-Module.

Aber warum eigentlich? Warum lassen Sie an diesem Punkt nicht einfach Assets diese Abhängigkeitsdatei haben, da dies nichts schadet? Der Grund, warum viele npm-Module Abhängigkeiten haben, ist, dass es allen den Ärger erspart und Code aus anderen Modulen wiederverwendet, die der Benutzer möglicherweise sogar bereits installiert hat. Gleiches gilt für Ruby Gems, Python über pip , sogar Paketmanager auf Linux-Distributionen erlauben es. Ich verstehe nicht, warum wir Abhängigkeiten von Assets nicht zulassen sollten, nur weil sie möglicherweise nicht so oft verwendet werden.

Es ist wahr, aber sobald der Benutzer sieht, dass es nicht funktioniert, wird er sofort die Dokumentation nachschlagen und feststellen, dass er die anderen Assets installieren muss.

Ich stimme dieser Stimmung nicht zu. Es wird sicher eine Menge Leute geben, die zuerst die Dokumentation nachschlagen werden, aber ich bin mir ziemlich sicher, dass sogar sie sich darüber ärgern werden, dass sie jedes einzelne benötigte Asset jedes Mal in der Asset-Bibliothek suchen müssen. Aber ich denke, es ist auch erwähnenswert, dass es immer eine Menge Leute gibt, die einfach nie Probleme vorher googeln und sich einfach bei dem/den Asset-Autor(en) beschweren, dass ihr Asset nicht funktioniert.

Ich bin nicht einmal mit der Idee einverstanden, Funktionen zu entfernen, nur weil sie in GDScript ausgeführt werden können. Einfach ausgedrückt, es ist das Gegenteil von Godots Ziel von „ Knoten für alle Ihre Bedürfnisse “, wenn Sie eine große Schar von Benutzern zwingen wollen, ein Tool/Feature/usw. herunterzuladen oder zu implementieren, das sie benötigen.

Tatsächlich fällt eine riesige Schar von Knoten unter die zweite Anforderung von @reduz , um in die Engine aufgenommen zu werden, einfach weil "Es ist schwierig, es selbst zu tun" völlig willkürlich ist. Was für manche einfach sein mag, ist für andere schwer.

Ich glaube nicht, dass ein offizielles Repository für Erweiterungen gegen die "Knoten für alle Ihre Bedürfnisse" verstößt. Nur weil sie nicht in den ausführbaren Download integriert sind, bedeutet das nicht, dass sie nicht bereitgestellt werden. Die Idee ist auch, dass die Grundbedürfnisse abgedeckt werden und die Möglichkeit, sie zu erweitern, für die spielspezifischen Bedürfnisse verfügbar ist.

Es ist schön, einen FPS-Charakter-Controller sofort einsatzbereit zu haben, aber es ist nutzlos für alle, die kein FPS-Spiel spielen. Und indem Sie solche Dinge hinzufügen, machen Sie im Wesentlichen jedes Spiel, das viele Funktionen enthält, die sie nicht benötigen, und erhöhen die endgültige Binärdatei (die für mobile und Web-Ziele sehr wichtig ist). Es sollte eine Möglichkeit geben, ungenutzte Dinge aus dem endgültigen Export zu entfernen, und sie bei Bedarf extern bereitzustellen, ist eine Möglichkeit (zumindest teilweise).

Ich stimme zu, dass Schwierigkeit subjektiv ist. Das Erstellen eines Federarmknotens ist nur dann einfach, wenn Sie bereits die Grundlagen zu seiner Implementierung kennen . Andernfalls verbringen Sie einige Zeit mit der Recherche, was den Zweck der Verwendung einer Engine mit vollem Funktionsumfang zunichte macht. Die bessere Metrik (wenn auch immer noch etwas subjektiv) ist "wie viel Low-Level" das Feature ist. Wenn es den Physik- oder visuellen Servern Funktionen hinzufügen muss, sollte es wahrscheinlich in der Engine bereitgestellt werden. Wenn es sich nur um eine Erweiterung eines bestehenden Knotens handelt, kann er möglicherweise ausgelagert werden.

Ich glaube immer noch, dass es vorteilhafter ist, offizielle Knoten zum Herunterladen bereitzustellen und den Kern zu trimmen. Damit können wir:

• Haben Sie eine kleine ausführbare Datei für Editor und Exporte.
• Bieten Sie offiziell mehr Funktionalität mit mehr spielspezifischen Helfern.
• Aktualisieren und beheben Sie Fehler in den Erweiterungen, ohne eine neue Engine-Version herauszugeben. Dies bedeutet, dass die ausgelagerten Knoten einen viel schnelleren Release-Zyklus haben und einen Patch veröffentlichen können, sobald ein Fehler behoben ist.

Aber dafür müssen wir die Addons immer noch zu höherklassigen Bürgern machen als die User-Land-Skripte. Die Verwendung von Erweiterungsknoten sollte sich anfühlen wie die Verwendung der Kernknoten, während dennoch klar ist, dass dies nicht der Fall ist.

Interessante Diskussion. Auch viele gute Vorschläge.

Ich muss zuerst sagen, dass ich die Kompaktheit der endgültigen Binärdatei schätze und dankbar bin, dass es eine Engine gibt, die mit diesem Ziel entwickelt wurde. Ich bin froh, dass die zentrale Vision hier darin besteht, Blähungen aktiv zu bekämpfen. Zumindest für mich ziehe ich es vor, nur die Werkzeuge zur Hand zu haben, die ich für die jeweilige Arbeit benötige.

Ich wollte nur eine Anspielung auf einige dieser interessanten Ideen weitergeben.

Vor allem die Tatsache, dass immer mehr Funktionalität in etwas exportiert wird, das die Form von so etwas wie offiziellen Modulen oder Plugins annimmt.

Von daher stelle ich mir vor, dass dies wie ein Kern und dann eine Bibliothek von Modulen ist, wobei die wesentlichen nur standardmäßig installiert sind. Vielleicht könnten viele über die Editoreinstellungen deaktiviert werden. (Ich glaube, Zylann hat erwähnt, 3D für ein 2D-Spiel auszuschließen.) Über die Standardeinstellungen hinaus konnten die anderen Module leicht gefunden und eingebunden werden.

Allerdings wundere ich mich über die Schwierigkeiten bei der Implementierung, denn man müsste sich überlegen, was passiert, wenn man vielleicht ein aktiv im Projekt befindliches Modul entfernen möchte. Es muss den Benutzer möglicherweise warnen, es aus diesen Szenen / Skripten zu entfernen, bevor es deaktiviert werden kann ... oder würden sie als veraltete Elemente im Projekt verbleiben, die wiederbelebt werden können, wenn das Modul wieder hinzugefügt wird?

Es ist wahrscheinlich keine Kleinigkeit zu implementieren, aber ich mag es, wann immer möglich die bereitgestellten Funktionen auszuwählen und auszuwählen, damit der Spielexport nur das enthält, was benötigt wird. Mehr Kontrolle darüber klingt für mich wertvoll.

Die anderen Gedanken von Vnen über Module mit einer speziellen Klassifizierung zwischen eingebauten und den Skripten waren ebenfalls nett. Es würde einige andere Arten von Partitionierungs- und Editorverhalten und -optionen ermöglichen, ohne die guten Seiten des bestehenden Designs zu beeinträchtigen.

Einige sagten ja und andere nein zu dieser Idee, Addons mehr wie Godot selbst aussehen zu lassen, aber es kann sich vorstellen, dass es vielleicht situationsbedingt ist. Ich könnte mir auch vorstellen, dass man das Konzept ein wenig aufspaltet. Beides bieten.

Ich wäre auch daran interessiert zu sehen, was getan werden könnte, um Editor-Tools aus dem endgültigen Build herauszuhalten. Ich habe mich sehr damit abmühen müssen, diese Dinge auseinander zu halten, weil Bugs und Verhaltensweisen, die für Tools vorgesehen sind, sich in das Spiel selbst einschleichen können. Manchmal destruktiv, wenn Sie etwas mit dem Ändern von Daten tun, die gespeichert werden.

Gleichzeitig finde ich es ziemlich fantastisch, die Funktionalität innerhalb des Editors mithilfe von Werkzeugskripten einfach zu ändern, also wäre mehr Aufmerksamkeit dort auch fantastisch.

Macht jedenfalls alle weiter so gute Arbeit.

Noch so eine verrückte Idee:

Vielleicht wäre es möglich, GDNative C++ irgendwie automatisch in ein Modul zu konvertieren (idealerweise durch Entfernen der von GDNative erstellten Umleitungsschichten)? Dann könnte es sowohl Befürworter des Ansatzes "alles in einer statischen ausführbaren Datei" als auch diejenigen des Ansatzes "Features entfernen, ohne den Compiler zu installieren" erfreuen

Für diejenigen, die gegen das Entfernen der Knoten sind, wäre es nicht besser als das, was wir derzeit haben, wenn die entfernten Knoten in GDScript als offizielle Plugins implementiert würden? Denn dann könnten Anfänger tatsächlich einen Blick in das Skript werfen, um zu sehen, wie es funktioniert.

Ich fürchte, das würde die Leistung beeinträchtigen, da GDScript einfach nicht sehr schnell ist.

Am Fr, 22. Juni 2018 um 23:10 Uhr, Alan North [email protected]
schrieb:

Für diejenigen, die gegen das Entfernen der Knoten sind, wenn die Knoten entfernt werden
in GDScript als offizielle Plugins implementiert, wäre es nicht besser als
was haben wir aktuell? Denn dann könnten Anfänger tatsächlich hineinschauen
das Skript, um zu sehen, wie es funktioniert.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/godotengine/godot/issues/19486#issuecomment-399628884 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AEJES-DWkzuyItQDPbOZgsuN_lA345z7ks5t_b_NgaJpZM4UhqDC
.

@AlansCodeLog Wenn sie unbedingt entfernt und in externe Erweiterungen umgewandelt werden müssen, wäre es schön, zumindest eine GDScript-Version zu haben, damit Benutzer die Engine nicht neu kompilieren müssen (wenn es sich um die ursprünglichen C++-Dateien handelt) oder Mono installieren müssen ( wenn es in GDNative konvertiert wird). Ein Teil meiner ursprünglichen Antwort (siehe den Abschnitt über ein offizielles Erweiterungs-Repository) beinhaltete jedoch meine Befürchtung, dass das Einbringen in Erweiterungen nur diese seltsame Art von Markt schaffen würde (mangels eines besseren Wortes), wenn Benutzer aufhören, sich daran zu erinnern, dass es ein Erweiterungs-Repository gibt die enthält, was sie brauchen, unabhängig davon, wie offiziell oder wie aktuell die offizielle Version ist. Neue Add-Ons würden in die Asset-Bibliothek kommen, die „Knoten X mit Feature X“, „Knoten X mit Feature Y“ usw. enthalten würden („Knoten X“ stellt den Knoten dar, der zu einer Erweiterung gemacht wurde) – was ein Durcheinander verursachte von Addons, die alle behaupten, bei Fahrzeugen zu helfen, aber nicht das Niveau oder die Kontrolle haben, die offiziellere Knoten bekommen könnten.

@LikeLakers2

Aber warum eigentlich? Warum lassen Sie an diesem Punkt nicht einfach Assets diese Abhängigkeitsdatei haben, da dies nichts schadet?

Ich bin nicht dagegen. Aber da reduz es nicht zu mögen scheint, schlage ich vor, eine einfache Verbesserung vorzunehmen, wie ich sie zuerst vorgeschlagen habe. Sehen Sie, wie es läuft, und könnten Sie später die Fähigkeit für Assets mit Abhängigkeiten hinzufügen. Nur ein Schritt nach dem anderen Vorschlag.

Ich bin jedoch gegen die Idee, Projekt-Addons an einem Ort außerhalb des Projektordners zu installieren, da dies die Verwaltung erschwert. Nur 'globale' Editor-Addons sollten sich außerhalb des Projektordners befinden.

Nach einigem Nachdenken, wenn Kernfunktionen entfernt werden und die Leute in all ihren Projekten Zugriff auf diese Kernfunktionen [das wären dann Erweiterungen] haben wollen, dann ist es sinnvoll, diese Erweiterungen unter installieren zu können ein globaler Standort mit Versionsverwaltung für sie. Aber auch in diesem Fall sollte die Möglichkeit erhalten bleiben, die Erweiterung direkt in den Projektordner herunterzuladen und zu installieren. (Auch hier ist es wie bei der npm-Option, lokal oder global mit -g zu installieren)

Wie eon-s oben sagte, ist es sinnvoll, ein besseres Asset-Management-System zu haben, wenn Dinge aus der Core-Engine entfernt und in Assets umgewandelt werden sollen. Andernfalls würde dies dazu führen, dass die Funktionalität der Engine verloren geht, da die Benutzer die entfernte Funktionalität nicht einfach entdecken könnten.

Ich dachte an dieses ideale Szenario für

• Neue Benutzer und Personen, die die Engine nicht kompilieren: Auf der Engine-Download-Seite haben sie die Möglichkeit, die Kern-Engine herunterzuladen und außerdem auszuwählen, welche offiziellen oder empfohlenen Erweiterungen sie in ihren Engine-Download aufnehmen möchten. ( Beachten Sie, dass dies nicht möglich wäre, wenn Erweiterungen nicht in einem globalen Ordner gespeichert werden können. Benutzer müssten stattdessen Erweiterungen finden, nachdem sie ein Projekt erstellt haben, was die Auffindbarkeit beeinträchtigt. ... In einer idealen [unmöglichen] Welt wäre dies jedoch der Fall Erstellen Sie vor Ort einen benutzerdefinierten C++-Build aus ausgewählten Erweiterungen/Komponenten.)
• Personen, die die Engine kompilieren: Ein Tool, das C++-Code-Downloads und -Versionen von Erweiterungen verwaltet und sie an der richtigen Stelle im Build-Ordner ablegt, sodass sie in Engine-Builds enthalten sind.

Als jemand, der die Engine kompiliert, möchte ich meine Erweiterungen als Module und nicht als GDNative (oder langsameres GDScript). Ich stelle mir das Maß an Modularität vor, dass ich bestimmte Knotentypen auswählen kann, die in meinen Build aufgenommen oder nicht aufgenommen werden sollen, oder sogar alle 3D-Sachen fallen lassen kann.

Wenn C++-Erweiterungen alle GDNativ sein werden, dann wird der Ersteller der Erweiterung damit belastet, für alle Plattformen bauen zu müssen – was meiner Meinung nach Leute davon abhalten könnte, es für einfache kleine Erweiterungen einzurichten, die nützlich sein könnten, da es sich übertrieben anfühlen würde tun Sie alles, was erforderlich ist, um es zu veröffentlichen - und rät auch davon ab, die Funktionalität in viele kleine Module aufzuteilen. Ich mag auch nicht die Tatsache, dass dem Ausgabeprojekt so viele DLL-/Shared-Library-Dateien hinzugefügt werden.

Andererseits ist GDNative für Leute, die die Engine nicht kompilieren, die einzige Lösung zum Hinzufügen von C++-Erweiterungen.

Wie von Starry-Abyss vorgeschlagen, wäre es großartig, wenn GDNative automatisch in ein normales Modul angepasst werden könnte.

Ok, ich habe meinen Standpunkt geändert. Ich mag die Idee eines aufblähfreien Motors mit Fähigkeiten in der gleichen Liga wie die Kraftpakete der Branche.

Wenn Sie alle zusätzlichen Knoten getrennt haben, haben Sie viele Vorteile, insbesondere die Möglichkeit, auszuwählen, was Sie wollen und was nicht.

Hier sind einige meiner Vorschläge, wie Sie es angehen können,

1. Zuerst können wir der Asset-Bibliothek die Möglichkeit hinzufügen, Assets zu haben, die in Teilen installiert werden können, in Git können sie durch Tags oder Branches getrennt werden.
   Wenn ich also jetzt nur die 2D-Feature-Knoten wollte, könnte ich genau das herunterladen, habe aber immer noch nur einen Ort, an dem ich nach Updates suchen kann.
2. Zweitens können wir die Möglichkeit hinzufügen, Labels zu Aktualisierungen von Assets hinzuzufügen, z. B. können einige Kernaktualisierungen sein, einige Funktionen und einige die Abwärtskompatibilität brechen.
   Dies kann dann vom Asset Manager automatisch verwendet werden, um Addons zu aktualisieren und Sie in dieser Angelegenheit um Aktualisierungen zu bitten. Als würde es Ihnen sagen, dass Sie auf Core-Updates warten, oder Ihr nächstes Update wird die Abwärtskompatibilität brechen. Möchten Sie aktualisieren oder nicht?
3. Drittens, um mehrere Versionen eines Assets zu ermöglichen, und wenn eine Version zu alt wird, kann der Entwickler des Add-Ons/Assets es als veraltet markieren, was sich beim Öffnen von Godot widerspiegelt und Sie auffordert, die ältere Version zu entfernen oder nicht .
4. Und zuletzt eine Möglichkeit für Addons, nach anderen Addons zu fragen, es wird wie eine Abhängigkeit sein, aber es wird Ihnen nur sagen, dass Sie dieses Addon benötigen, um dieses Addon auszuführen, und wenn Sie es nicht haben, installieren Sie es.
   Und wenn jemals das Addon selbst bemerkt, dass das Addon nicht mehr gefunden werden kann, fragen Sie, ob Sie es erneut hinzufügen möchten, oder zeigen Sie einfach eine Fehlermeldung an.

Mit dieser Methode benötigen wir keinen Abhängigkeitsmanager, aber die Entwickler wären für die Arbeit verantwortlich. Wenn ein Addon alt wird und ein veraltetes Asset/Addon verwendet, können beide Entwickler miteinander sprechen und der Entwickler kann entscheiden, was zu tun ist.
Er könnte sein Addon schnell portieren. Bei Bedarf oder in einigen Fällen kann das andere Addon veraltete Tags sogar entfernen lassen.

Und wie @chanon sagte, müssen wir dafür sorgen, dass die Assets als global heruntergeladen werden, die dann in das Projekt importiert werden können, wie es Unity getan hat.
Und ein besserer Vermögensverwalter als unsere aktuelle Implementierung mit viel Flexibilität bei der Installation von Addon-Prozessen sollte erlaubt sein.
Ich empfehle, die Möglichkeit zu haben, ein Addon sowohl als GDNative als auch als Modul hinzuzufügen, was die Addon-Entwickler etwas belastet, aber ich denke, das ist die einzig akzeptable Lösung, es sei denn, hier ändert sich etwas radikal.
Aber wir können GDNative immer noch einige Funktionen hinzufügen, um die Addon-Erstellung zu vereinfachen. Als wäre es viel besser, für alle Plattformen gleichzeitig bauen zu können.

Zum Problem von Abhängigkeiten und Assets, die aufgrund der Aktualisierung von Plugins beschädigt werden,
warum nicht (und entschuldigung, wenn ich jemanden übersehen habe, der dies bereits vorgeschlagen hat)

1. Lassen Sie den Server jede hochgeladene Version behalten

2. Plugins erlauben, eine bestimmte Version eines bestimmten Plugins anzugeben

3. versuchen Sie, ein vernünftiges Versionierungssystem für Plugins zu verwenden (Godot scheint das
   Major.Feature.BugFix-Versionsnummerierung, die mir gefällt)

4. Und am wichtigsten: Plugins nicht automatisch aktualisieren? (Oder zumindest erlauben
   Benutzer können auswählen, mit welcher Art von Updates sie einverstanden sind, z. B. Fehlerbehebungen und
   Feature-Updates, aber keine größeren Updates).

@Two-Tone Warum dann überhaupt das Ganze frei von Blähungen machen?

Wir haben diese Diskussion, um die Engine und das gesamte System so aufblähungsfrei wie möglich zu machen, damit nicht unnötige Versionen herumfliegen.

Sie haben Recht damit, Benutzern die Möglichkeit zu geben, sich für ein Update zu entscheiden, aber Fehlerbehebungen sollten standardmäßig automatisch erfolgen. Denn wenn ich hundert Addons habe, werde ich sie nicht einzeln auf Bugfix-Updates überprüfen.
Der Rest kann dem Benutzer überlassen werden, wir können eine Einstellung haben, die bei Bedarf deaktiviert werden kann.

Und der Store muss offizielle Bundles für die Offline-Nutzung anbieten (mit Offline-Store-Unterstützung im Editor).

Ich würde ein Offline-Paket mit einigen 10 MB vorschlagen, das die wichtigsten Demos und die wichtigsten Add-Ons enthält, die sehr leicht auffindbar sein sollten. Ein kleinerer Font-Link auf der offiziellen Download-Seite, wie der für die alten Godot-Versionen, wäre toll.

Wahrscheinlich ja, aber in einer Welt, in der Desktops nicht weniger als 256 GB SSD + 1 TB HDD zu verwenden scheinen und sogar Telefone Speicherplatz ab mindestens 16 GB haben, was sich höchstwahrscheinlich erhöht, wäre es das? SCHLECHT?

Im Segment der tragbaren und erschwinglichen Laptops lebt eMMC und eine Größe von 32 GB (mit weniger als 10 GB frei) ist keine Seltenheit.

Übrigens denke ich, dass auf dieser Klasse von Laptops das aktuelle Android-Exportsystem verwendbar ist, während das geplante (https://github.com/godotengine/godot/issues/18865) es nicht ist. Ich verstehe die Vorzüge des neuen Systems und hätte insgesamt wahrscheinlich selbst dafür gestimmt (als ich das Problem sah, gab es bereits keinen Wettbewerb), aber wir sollten uns bewusst sein, dass wir durch die Änderung einen wichtigen Anwendungsfall verlieren.

@swarnimarun Möglicherweise liegt ein Missverständnis vor. Wenn ich in diesem Kommentar „System“ sage, meinte ich den Server, der die Plugins bedient, nicht die Engine. Tut mir leid, wenn dich das gestolpert hat.

Wenn nicht, dann verstehe ich nicht, wie der Versuch, die Probleme der Menschen mit einem Abhängigkeitssystem für Plugins zu lösen, dem Versuch widerspricht, die Engine aufblähen zu lassen. Ein Plugin, das auf einem Server aufbewahrt wird, nur für den Fall, dass es jemand braucht, trägt nicht zum Aufblähen oder Wartungsaufwand bei und die meisten sind so klein, dass die Kosten für ihre Speicherung nicht so hoch sein sollten.

@Two-Tone Ja, ich dachte, du meinst auf dem Computer. Aber auf dem Server ist es in Ordnung und kann bereits durchgeführt werden, da Github Hashes zulässt, die auch nach Änderungen gespeichert werden können, sodass Sie im aktuellen System selbst nach dem Aktualisieren des Repos den Hash auf der Asset-Seite aktualisieren müssen.

Nicht nur github, auch gitlab und andere erlauben es. Falls es noch andere gibt. Git unterstützt das Speichern von Hashes als Commit-ID, sodass die Dinge so erledigt werden, wie sie gemacht werden.

Nur meine paar Cent, ich bin mir ziemlich sicher, dass das meiste davon schon gesagt wurde, also bezweifle ich, dass ich etwas Neues einbringe.

Ich glaube nicht daran, Dinge als Plugins zu machen, nur um Dinge als Plugins zu machen. Ich verstehe das Größenproblem, aber wir leben nicht mehr in den 80ern. Wir sprechen davon, dass die Engine 50 MB oder 55 MB groß ist, nicht zwischen 50 MB oder 500 MB. Die zusätzliche Größenzunahme der Funktion, die in ein Plugin verschoben werden soll, ist im Vergleich zur Größe der Assets eines ernsthaften Spiels vernachlässigbar. Wenn der Preis, den wir zahlen, eine mühsamere Integration ist, lohnt es sich nicht.

Es gibt viele Orte, an denen Plugins sinnvoller sind, und mit der Reifung der Architektur wie GDNative sollten wir uns definitiv die Frage stellen: „Ist es besser, ein Plugin zu sein?“ und in vielen Fällen würde ich sagen, dass die Antwort ja ist. Eine Sache, die ich an Plugins mag, ist, dass Sie als Entwickler in vielerlei Hinsicht mehr Freiheiten haben. Aber es gibt auch Grenzen.

Meine VR-Erfahrung entzieht sich einigen davon. Es gibt einen Grund, warum es länger dauert, als ich es auf dem Handy zum Laufen bringen möchte. Aufgrund der Anforderungen, insbesondere auf Mobilgeräten, die Displays auf verschiedene Arten einzurichten, müssen Sie die Funktionsweise des Kerns ändern, und es erweist sich als schwierig, dies in einem Plugin zu erfassen.
OpenVR und OpenHMD waren bisher die einfachen. Oculus Ich habe eine Problemumgehung durchlaufen, auf die herabgesehen wird, aber ich bin damit zufrieden.
ARKit muss im Kern sein, es ist nicht als Modul lösbar, zumindest nicht in unserer aktuellen Struktur (Apple erlaubt nicht einmal dynamische Bibliotheken auf iOS, also gibt es das auch).
GearVR und Daydream müssen wirklich im Kern sein, eine Unmöglichkeit für GearVR, da es proprietäre Bibliotheken verwendet.
Hololens/Microsoft MR Ich gehe den Weg, um zu sehen, ob ich dies zu einer Plattformwahl machen kann, Microsoft sieht sie so, weil Apps zwischen den beiden laufen sollen und auf der Hololens nur als holografische App installiert sind.

Jetzt sind AR und VR Nischenfunktionen, die nur sehr wenige Leute nutzen werden, also sind sie die Art von Dingen, die sich möglichst aus dem Kern heraushalten sollten, und ich stimme diesem Standpunkt voll und ganz zu. Aber für andere Dinge kann ich das nicht sagen.

Ich habe irgendwo eine Fahrzeugkarosserie erwähnt, im Ernst? Das Kilobyte Code, das Sie sparen, wenn Sie das in ein Plugin stecken? Physik ist die Art von Dingen, die meiner Meinung nach im Kern vollständig unterstützt werden sollten. Ich sehe eher eine vollständige Suite vollständig integrierter physikalischer Objekte im Kern, als dass ich nach diesen in Plugins suchen muss. Während ein Schnittstellenansatz ähnlich dem ARVRInterface, das wir in GDNative geschrieben haben, wahrscheinlich eine solide Integration schaffen würde, habe ich immer noch das Gefühl, dass wir uns das Leben nur unnötig schwer machen.

Im Gegensatz dazu, sagen wir, die Terrain-Editor-Komponenten, gibt es jetzt etwas, das ich als ideal geeignet sehe, um Plugin-basiert zu sein. Abhängig von der Art des Spiels, das Sie erstellen möchten, gibt es verschiedene Möglichkeiten, Terrains zu adressieren. Daher ist es sinnvoll, zwischen verschiedenen Addons zu wählen, und sich auf diesen unabhängig von der Entwicklung des Kerns entwickeln zu können, ist ein noch wichtigerer Grund.

Um es kurz zu machen, wo Plugins sinnvoll sind, Plugins unterstützen, aber nicht übertreiben.

Knoten, die es wert sein könnten, in Plugins umgewandelt zu werden, sind die Kontrollknoten, die von Kontrollknoten (den zusammengesetzten Knoten) erstellt werden und nur einfache Knoten übrig lassen, um andere zu konstruieren.

Knoten mit komplexer Logik wie Fahrzeug oder sogar einfache, aber nützliche wie Positionsknoten sind im Kern gut.

Meiner Meinung nach sollte nichts davon aus dem Motor entfernt werden. Steuerknoten, Physikknoten (wie Fahrzeug) und sogar derzeit nicht vorhandene Geländeunterstützung:

Ich verwende Godot, weil es eine ziemlich eigenständige, integrierte Anwendung ist.
Wenn ich in Zukunft Godot herunterladen muss und dann nach Fahrzeug, Kontrollknoten, Geländeunterstützung, einem Shader-Editor, einem anständigen Navmesh-Plugin und so weiter und weiter und weiter suchen muss - unter Verwendung des aktuellen Plugins und AssetLib-Systems - nein danke.

Wenn wir diesen Weg gehen, müssen sowohl die Plugin-Infrastruktur als auch die AssetLib überarbeitet werden.

Übrigens stört mich die große Installationsgröße von UE4 viel weniger als die Tatsache, dass es keine integrierte Unterstützung für Fahrzeuge, Gelände oder UI bietet – was es alles hat.

Ich bin mir nicht sicher, wie viel davon bereits gesagt wurde, große Threads wie dieser können schwer zu verfolgen sein, aber trotzdem:

Ich denke, wir sollten uns auf das beste Out-of-the-Box- Erlebnis konzentrieren. In die Asset-Bibliothek gehen zu müssen, selbst für "offiziell unterstützte" Plugins, ist ziemlich unhandlich.

Die Exportgröße sollte die Benutzerfreundlichkeit der Engine meiner Meinung nach nicht verschlechtern. Wenn wir die Exportgröße reduzieren müssen, dann machen Sie eine Funktion, um Teile der Engine wie 3D beim Export zu deaktivieren. Vor allem, weil ich persönlich Plattformen wie Mobile und insbesondere Web nicht schätze und es mich schmerzt zu sehen, wie der Motor in Diskussionen wie dieser von ihnen zurückgehalten wird. (Ich kann die Nachfrage nach ihnen sehen, verstehen Sie mich nicht falsch, obwohl Schraubennetz)

Hölle, wenn wir uns Sorgen um die Downloadgröße des Editors machen, dann sollte es getrennte Editor-Downloads für "Batterien enthalten" und "minimal" geben. Wie die Trennung umgesetzt wird, steht zur Debatte, aber sie sollte auf jeden Fall schön integriert werden.

Ich habe die ganze Diskussion nicht gründlich gelesen, aber ich möchte sie etwas korrigieren: Wir machen uns keine Sorgen um die Größe. Sicher, es ist wichtig, die Exportgröße auf einigen Plattformen klein zu halten, aber es ist kein entscheidender Faktor bei der Implementierung von Funktionen in der Engine. Wie bereits erwähnt, ist es trivial, wenn einige Funktionen an Bedingungen geknüpft werden müssen, um kleine Exportgrößen zu ermöglichen. Die Downloadgröße für die Engine selbst spielt keine Rolle.

Nun, das ist geklärt, die Hauptfaktoren, die uns dazu ermutigen, einige Dinge ("einige" zu bestimmen) aus dem Motor herauszuhalten, sind:

• Technische Schulden. Der gesamte Code muss gepflegt werden. Ein kaputter VehicleBody, wie wir ihn seit 2014 haben, ist nicht besonders nützlich, da er für echte Spiele nicht gut genug ist. Es wurde kürzlich mit Bullet verbessert, also wird es besser, aber in den letzten 4 Jahren war es effektiv toter Code und unnötiger Wartungsaufwand.
• Universalität: Godot ist eine Engine, mit der Sie jede Art von Spiel spielen können, und die Funktionen, die sie bietet, sollten es Ihnen ermöglichen, jede Art von Spiel zu spielen. Das bedeutet nicht, dass es exklusiv sein sollte (in den meisten Spielen braucht man nicht gleichzeitig 2D und 3D), aber die Funktionen sollten den allgemeinen Bedürfnissen der meisten Benutzer gerecht werden. Das bedeutet, dass die von uns bereitgestellten Features Low-Level-Features sein sollten und dass spielspezifische High-Level-Features meistens am besten extern bereitgestellt werden.
• Flexibilität: Dass High-Level-Features außerhalb des Kerns gepflegt werden, ermöglicht einen viel schnelleren Iterationsprozess, um sie zu verbessern, sie bei Bedarf zu forken usw.

Wenn wir diesen Weg gehen, müssen sowohl die Plugin-Infrastruktur als auch die AssetLib überarbeitet werden.

Nun, das ist die Daseinsberechtigung dieser Ausgabe, oder? :) Der springende Punkt ist, dass wir eine Überholung der Benutzerfreundlichkeit benötigen, um einen besseren Workflow zu ermöglichen, anstatt alle Eckfälle in der Kern-Engine zu bündeln.

Nun ... wenn jemand Ideen braucht, um die externen Funktionen zusätzlich zum so genannten VehicleBody zu starten, möchte ich mich an einige Knoten und Klassen erinnern, die von Godot 2 bis 3 verloren gegangen sind: ParticlesAttractor2D (Knoten) und EventStreamChibi (diese Klasse ist perfekt für ein externes Asset ), ich weiß, dass der Partikelattraktor mit dem tatsächlichen Partikelsystem nicht kompatibel ist, aber ... Was ist mit der Wiederherstellung der verlorenen Funktionalität von Godot in Form eines externen Vermögenswerts (Ej, altes Partikelsystem, das mit dem neuen koexistiert ....). Vielleicht möchte jemand diesen Code in separaten Repositories pflegen ...

@Ranoller neue Systeme entfernen immer altes Zeug, ist unvermeidlich.
CPU-Partikel sollen mit GLES2 zurückkommen (weil CPU-Partikel nicht unterstützt werden), aber Attraktoren auf der CPU, aber nicht auf der GPU zu haben, wird nicht gut sein.
EventStreamChibi war ein Modul, ich denke, das neue Audiosystem kann Tracker-Dateien besser unterstützen, wenn es flexibler wird.

Ich denke nicht, dass wir, selbst wenn wir uns um die Wartbarkeit kümmern, Dinge jetzt schon trennen sollten.
Wir könnten die Leute bitten, bei veralteten Sachen zu helfen, indem sie in einem speziellen Thread darüber posten, und dann können die Leute Features aktualisieren.
Ich bin mir sicher, dass wir mit dem enormen Wachstum der Godot-Benutzerbasis viele Leute finden werden, die bereit sind, Dinge zu aktualisieren und an Dingen zu arbeiten, die veraltet sind oder an wesentlichen Funktionen, die in Teilen der Engine fehlen, z. B. mehr Gelenke.

Wenn Sie denken, dass es einfacher ist, Leute dazu zu bringen, an separaten Codedateien zu arbeiten, dann ist das falsch. Die meisten werden diese Dateien einfach nicht kennen, da sie nie die gleiche Sichtbarkeit erhalten werden. Asset Manager müssen zwar bearbeitet werden, aber Funktionen als Plugins zu haben, funktioniert nicht gut .
Ich habe einige Leute gesehen, die von Unity zu Godot gewechselt sind, weil es so gut integriert ist und keine wesentlichen Funktionen als Plugins bietet.
Und Unity erkannte, dass es begann, daran zu arbeiten, die Dinge integrierter zu machen, und fügte die Addon-Entwickler dem Unity-Entwicklerteam hinzu.

Wenn wir eine 30-MB-Engine herunterladen müssen und dann Zeit damit verschwenden, separate Funktionen als Plugins herunterzuladen, die ich möglicherweise vergessen habe, meinem Projekt hinzuzufügen, verwende ich sie möglicherweise gar nicht erst. Was für einen Anfänger ein Problem ist.

In Bezug auf technische Schulden ist dies ein Problem, mit dem sich jedes Projekt (FOSS oder kommerziell) letztendlich auseinandersetzen muss. Die Wahrheit ist, dass einige Entwickler irgendwann gehen und ein Bereich nicht mehr viel Aufmerksamkeit erhält (also muss er in den "Wartungsmodus" versetzt werden, bis jemand interessiert ist). Wie ich bereits erwähnt habe, passiert dies sogar bei großen kommerziellen Apps. so wird es bei Godot unweigerlich passieren, egal wie stark der Motor getrimmt wird.

Die beste Lösung in diesem Bereich besteht einfach darin, eine Entwicklungsszene zu fördern, die die Menschen ermutigt, einen Beitrag zur Quelle zu leisten (und die Godot-Szene hat gute Arbeit geleistet, wenn man sich die Entwicklung der Freiwilligen ansieht, aber sie muss durchgehalten werden Dinge wie sicherzustellen, dass ein Patch-Mitwirkender nicht zu lange auf eine Überprüfung wartet). Das Entfernen von Features, weil der Entwickler gegangen ist, sollte jedoch nach Möglichkeit vermieden werden (denn eine ständig schwankende Feature-Liste wäre eine großartige Möglichkeit, Leute davon zu überzeugen, Godot _überhaupt nicht zu verwenden_). Vielmehr sollte die Feature-Entfernung hauptsächlich deshalb erfolgen, weil sie durch etwas Besseres ersetzt wird.

Das Entfernen von Features, weil der Entwickler gegangen ist, sollte jedoch nach Möglichkeit vermieden werden (denn eine ständig schwankende Feature-Liste wäre eine großartige Möglichkeit, Leute davon zu überzeugen, Godot überhaupt nicht zu verwenden). Vielmehr sollte die Feature-Entfernung hauptsächlich deshalb erfolgen, weil sie durch etwas Besseres ersetzt wird.

Wieder geht die Diskussion in die falsche Richtung, also werde ich versuchen, sie wieder in die richtige Richtung zu lenken. Bei dem Thema geht es nicht so sehr darum, Dinge zu entfernen , sondern darum, das Hinzufügen neuer Dinge zu verhindern, die wir möglicherweise entfernen möchten. Denn das Hinzufügen von Inhalten ist sehr einfach, aber wir können sie dann nicht entfernen, ohne die Kompatibilität zu beeinträchtigen.

Während Godot wächst, kommen immer mehr neue Mitwirkende mit Ergänzungen, die möglicherweise nicht zu der Architektur oder dem Design passen, denen wir die Engine folgen lassen wollen. Die Überprüfung all dieser Änderungen nimmt viel Zeit in Anspruch, und noch mehr die Entscheidung, ob sie unseren Wünschen entsprechen. Das Zusammenführen solcher neuer Funktionen durch neue Mitwirkende führt zu Code, den die Engine-Betreuer nicht gut kennen oder dem sie eventuell nicht vollständig zustimmen, und die ursprünglichen Mitwirkenden bleiben oft nicht da, um ihn umzugestalten und sicherzustellen, dass er unseren Wünschen entspricht (siehe zB der Tween-Knoten, der ein großartiges Feature ist, aber mit unterdurchschnittlichem Design, und der ursprüngliche Autor ist nicht mehr da, also liegt es an uns, ihn zu überdenken und neu zu schreiben, wobei die Kompatibilität auf dem Weg gebrochen wird).

Der ganze Sinn des Vorschlags von @reduz besteht also darin, dass die ständig wachsende Anzahl von Funktionen, die neue Mitwirkende in die Kern-Engine einbauen möchten, in den meisten Fällen besser als Assets in der Asset-Bibliothek geeignet wären. Der Punkt dieser Ausgabe hier ist, wie sichergestellt werden kann, dass dieser Arbeitsablauf so reibungslos wie möglich abläuft.

Wir versuchen nicht, Godots Codebasis zu verkleinern, wir denken darüber nach, wie wir uns davor schützen können, dass sie explodiert und außer Kontrolle gerät. (Weil einmalige Mitwirkende mit einer großen PR viel häufiger sind als Engine-Betreuer mit einem gründlichen Verständnis der gesamten Codebasis und der Vision, die wir für die Zukunft der Engine haben).

Der ganze Sinn des Vorschlags von @reduz besteht also darin, dass die ständig wachsende Anzahl von Funktionen, die neue Mitwirkende in die Kern-Engine einbauen möchten, in den meisten Fällen besser als Assets in der Asset-Bibliothek geeignet wären. Der Punkt dieser Ausgabe hier ist, wie sichergestellt werden kann, dass dieser Arbeitsablauf so reibungslos wie möglich abläuft.

Ich muss fragen, was wird es bewirken, diese zu Assets in der Asset-Bibliothek zu machen, außer das Problem einen Schritt zurück zu verschieben? Sie wechseln von Code, der mit Godot gebündelt ist und nicht mehr gewartet wird, zu Code in einem Godot-Asset, das nicht mehr gewartet wird. In jedem Fall wird der ursprüngliche Mitwirkende wahrscheinlich irgendwann aufhören, es zu warten, und es wird schließlich wieder kaputt gehen.

@LikeLakers2 Nun, der Zweck besteht darin, einen reibungslosen Weg für neue Beiträge zu schaffen, die für die Engine hinzugefügt werden können (da die meisten, die sich eher auf Assets beziehen, vorerst abgelehnt werden). Wenn ein Aspekt des Motors nicht gewartet wird, sollte er zu diesem Zeitpunkt nicht mit dem Motor gebündelt werden, da es sich um reines Aufblähen handelt. Solche Dinge eignen sich besonders als extern eingebundene/aktualisierte Plugins.

Wenn ich in Zukunft Godot herunterladen muss und dann nach Fahrzeug, Kontrollknoten, Geländeunterstützung, einem Shader-Editor, einem anständigen Navmesh-Plugin und so weiter und weiter und weiter suchen muss - unter Verwendung des aktuellen Plugins und AssetLib-Systems - nein danke.

Exakt. Die AssetLib/Add-Ons im Allgemeinen funktionieren dafür jetzt nicht gut, weshalb die Konversation dazu neigt, von diesen abzuweichen. Ich glaube nicht, dass irgendjemand in diesem Moment Sachen herausnehmen möchte, aber wie bereits erwähnt, geht es darum, nicht zu viele neue Sachen hinzuzufügen.

Ich muss fragen, was wird es bewirken, diese zu Assets in der Asset-Bibliothek zu machen, außer das Problem einen Schritt zurück zu verschieben? Sie wechseln von Code, der mit Godot gebündelt ist und nicht mehr gewartet wird, zu Code in einem Godot-Asset, das nicht mehr gewartet wird. In jedem Fall wird der ursprüngliche Mitwirkende wahrscheinlich irgendwann aufhören, es zu warten, und es wird schließlich wieder kaputt gehen.

Nun, ich gehe davon aus, dass es einfacher wäre, wenn sie vom Motor getrennter verwaltet werden könnten. Blender macht so etwas. Sie haben "offizielle" (nicht wirklich offizielle, nur vorinstallierte) Add-Ons, aber ihr Code wird in einem separaten Git-Submodul aufbewahrt, und wenn sie von den Leuten, die sie eingereicht haben, nicht mehr gepflegt werden (ich denke, Sie müssen sie erneut einreichen bei jeder großen Veröffentlichung) werden sie gelöscht. Obwohl ich diesen Ansatz ehrlich gesagt nicht wirklich mag, wünschte ich, sie hätten nur einen eingebauten Asset-Browser für 90 % der Dinge und den Rest einfach integriert (Dinge wie Exporter).

Ich denke, die Idee ist jedoch, dass die Engine nur die grundlegenden Bausteine ​​enthalten würde, dann könnten Dinge wie der Fahrzeugknoten offizielle Add-Ons sein, dann sollte alles andere, was groß ist und auf unterschiedliche Weise implementiert werden könnte, nur normale Add-Ons sein , rechts?

Was ich nicht verstehe, ist, wie die offiziellen Add-Ons implementiert würden. Ich dachte, derzeit könnten wir keine benutzerdefinierten Knoten schreiben, die so aussehen, als wären sie eingebaut, richtig, sie müssten ein Skript haben? Oder ist das mit einem C++-Modul oder so möglich (bin C++ Noob hier).

Und schließlich geraten wir auch in das Problem, wie man ein Add-On hat, das von den getrennten offiziellen Knoten abhängt. Ohne irgendeine Art von Abhängigkeitssystem klingt es wie die Hölle.

Spät zur Party, aber angesichts des Umfangs meines aktuellen Projekts habe ich festgestellt, dass ich _viele_ Plugins für Godot 3 entwickle und sehe, wie ich viele weitere entwickle, bevor das Projekt abgeschlossen ist. Bei jedem Plugin versuche ich, so viele wie möglich spielunabhängig zu entwickeln und sie unter der MIT-Lizenz für andere zur Nutzung zu öffnen. Ich werde nicht lügen. Das aktuelle Addon-System ist im Großen und Ganzen gar nicht so schlecht ... JEDOCH _gibt_ es ein paar fehlende Teile, die es in vielen Fällen grenzwertig unbrauchbar machen. Bevor ich jedoch zu diesen komme, möchte ich ein paar Dinge über @karroffel- Ideen sagen.

Zunächst einmal vielen Dank, dass Sie dieses Problem zusammengestellt haben. Ich denke, diese Diskussion ist wichtig – besonders kurzfristig. Trotzdem denke ich, dass jeder der Diskussionspunkte, die Sie im OP vorgestellt haben, größtenteils orthogonal ist und sich nur tangential überlappt. Ich denke, wir können hier sehr oft eine Lösung finden, ohne alle Bedenken auf einmal ansprechen zu müssen.

Das führt mich zu meinen _persönlichen_ Bedenken mit dem aktuellen Addon-System und was meiner Meinung nach zwei sehr gute Ausgangspunkte zu einer besseren Welt von jemandem wären, der tatsächlich regelmäßig Plugins entwickelt:

Das größte Problem mit dem aktuellen Addon-System ist das Fehlen von Abhängigkeitsmanagement.

Dies wurde bereits ausführlich diskutiert, aber die meisten Vorschläge sind ziemlich schwerfällig und nicht sehr kompatibel mit dem aktuellen System. Nun, ich habe mich noch nicht mit der Codebasis des Assetlib-Moduls vertraut gemacht, aber ich denke, dass es in dieser Abteilung einen leichten Gewinn geben _sollte_. Derzeit halten sich 3rd-Part-Addon-Repositories auf Github an die folgende Ordnerstruktur:

addons/
    addon_name/
        plugin.cfg
        ...other files

Was ich vorschlage, ist, das plugin.cfg-Schema zu erweitern und die Möglichkeit hinzuzufügen, einfach eine Liste von Abhängigkeitsversionen mit einer Option zu verwenden, die einen Commit-Hash (oder Zweig-/Tag-Namen) enthält. So etwas wie das Folgende würde funktionieren:

[plugin]
name="foo"
description="foobar"
author="blah"
version="1.0.0"
script="plugin.gd"

[dependency]
name="dep1"
path="github.com/foo/dep1"
hash="7fc2367508c41cfab86eaf7d84e04cd122978fdb"

[dependency]
name="dep2"
path="github.com/foo/dep2"
tag="v3.1.2"

[dependency]
name="dep3"
path="github.com/foo/dep3"
branch="big-refactor"

Wenn die Asset-Bibliothek dann das Asset installiert, lädt sie zunächst das Projekt in das Addons-Verzeichnis herunter, so wie es derzeit der Fall ist, lädt dann jede Abhängigkeit herunter (unter Verwendung des richtigen definierten Hashs oder Zweigs) und legt sie ebenfalls im Addons-Verzeichnis ab . Als erster Schritt können Abhängigkeitskonflikte entweder ignoriert werden oder dem Benutzer überlassen werden, welche verwendet werden soll. Dies ist keine _ideale_ Lösung, aber ich denke, sie wird in den meisten Fällen funktionieren und uns zumindest aufhalten, bis eine umfassendere Überarbeitung der Assetlib durchgeführt wird. (es sei denn, jemandem fällt auf Anhieb ein einfacher Weg ein, mit Abhängigkeitskonflikten umzugehen).

Als reales Beispiel,
Ich habe einen Vorteil für Godot-Verhaltensbäume. Teil dieses Systems ist ein UE4-ähnlicher Blackboard-Knoten zum Speichern beliebiger globaler oder knotenlokaler Daten, die über Knoten hinweg gemeinsam genutzt werden sollen. Dies wird im BT-System zum Teilen des Zustands zwischen Verhaltensknoten verwendet. Das ist alles schön und gut, aber dann entwickle ich gerade ein Dialogsystem und die dazugehörigen Tools, und ein Teil dieses Systems erfordert eine Art Datenbank mit Variablen, die für Bedingungen verwendet werden. Sehr gerne würde ich die Blackboard-Komponente aus dem BT-System auch für das Dialogsystem wiederverwenden. Tatsächlich ist die Blackboard-Komponente so generisch, wie sie nur sein kann, und globale Daten sind eine ziemlich verbreitete Redewendung in der Spieleentwicklung, also könnte dies selbst für sich genommen ein ziemlich nützliches Addon sein, da es ohnehin in praktisch jedem Projekt neu implementiert wird .

Mit einem geeigneten Abhängigkeitssystem könnte ich die Blackboard-Komponente in ein eigenes Add-On zerlegen und diese Komponente dann in allen BT-Add-Ons, dem Dialogsystem-Add-On und allen anderen spielspezifischen Anwendungen wiederverwenden, die ich dafür habe. Scheinen, was ich meine?

Die Notwendigkeit von Multi-Script-Knoten

Dies ist bereits ein weiteres heißes Thema in dieser Ausgabe, und ehrlich gesagt habe ich keine sehr gute Möglichkeit, dies anzugehen, ohne die grundlegende Ideologie zu ändern, wie Godot verwendet werden soll. Das mag in Ordnung sein oder auch nicht, aber ja... Wie auch immer, das ist weniger ein Problem für das Plugin _authors_ als für das Plugin _users_ (obwohl oft dieselbe Person ;).

Wenn wir diese beiden Probleme am Ende lösen können, werden wir meiner Meinung nach zu 90 % am Ziel sein. Die anderen 10 % sind meiner Meinung nach keine so große Sache und sollten wahrscheinlich aus der Perspektive der Überarbeitung der grundlegenden Architektur von Vermögenswerten angegangen werden, die meiner Meinung nach warten können, nachdem sie viel größere Fische gebraten haben.

Wenn nichts dagegen spricht, werde ich wohl in den nächsten Tagen versuchen, meinen Vorschlag bzgl. Dependency Management im Assetlib-Code umzusetzen

Das Abhängigkeitsmanagement klingt für mich cool. :smiley:

Das einzige, womit ich nicht einverstanden bin, ist die Version der Abhängigkeit
eine optionale Auflistung sein. Das wird die Probleme verursachen, die reduz erwähnt hat
passiert mit dem Plugin-System anderer Engines.

es sei denn, jemandem fällt auf Anhieb ein einfacher Weg ein, mit Abhängigkeitskonflikten umzugehen

Ich denke, die Lösung dafür würde davon abhängen, wie ein Plugin Code aufruft
ein anderes Plugin. Wenn wir es so einrichten, dass die Skripte des Plugins dies tun
extends "dep2/folder/script.gd" , bei der Installation könnten wir einfach dep2 ändern
zu dep2-v3.1.2 . Für Hashes könnten wir einfach die ersten 5 Ziffern verwenden (es sei denn
wir wollen Ordner mit Namen, die mindestens 42 Zeichen lang sind). Um 5
Ziffern ist die Wahrscheinlichkeit einer Kollision unglaublich gering.

Ich bin gerade etwas müde, also übersehe ich vielleicht etwas, aber ich sehe es nicht
irgendwelche Probleme.

@jonbonazza Wenn Sie dies tun, versuchen Sie bitte, die Git-Nutzung nicht fest zu codieren. Obwohl es sich hier wie selbstverständlich anhört, bevorzugen einige Leute möglicherweise andere VCS-Systeme (oder verwenden VCS überhaupt nicht), also sollte dies vielleicht ein Detail sein, das auf der Asset-Lib-Seite gehandhabt werden sollte.
Außerdem frage ich mich, ob wir in Betracht ziehen, etwas zu tun, um es einfacher zu machen, Plugins als VCS-Sub-Repos in einem Projekt zu haben? Es wurde irgendwann erwähnt, aber ich erinnere mich nicht, ob es eine Vereinbarung gab.

Ja, ich denke, nur die ID des Assets und die Version sollten ausreichen.

Die Angabe von Git-Repository/Branch/Tag/Hash könnte eine optionale Möglichkeit sein, Abhängigkeiten anzugeben, aber die Hauptmethode sollte die Asset-ID sein.

Ich bin mir nicht sicher, ob die Asset-Bibliothek eindeutige, vom Menschen lesbare IDs (Slugs) hat. Wenn nicht, sollte es. Beispielsweise haben npm-Module einen Textmodulnamen/-id, den Sie bei der Installation verwenden.

Abhängigkeitsspezifikation würde dann vielleicht so aussehen

[dependency]
asset_id="some_asset"
version="1.0.0"

@Two-Tone Ich habe versucht, damit nicht zu verrückt zu werden. Ich wollte nur etwas Einfaches, um uns aufzuhalten, bis wir uns für einen besseren Ansatz entschieden haben.

@Zylann Ich würde wahrscheinlich den gleichen Ansatz verwenden, der derzeit in der Asset-Bibliothek verwendet wird - Herunterladen und Extrahieren der ZIP-Datei von Github.

@chanon die Asset-Lib funktioniert direkt mit GitHub, sodass die einzige Identifikation, die wir für Versionen haben, Commit-Hash, Branch und Tag sind.

Welcher Teil ist zu verrückt? Abhängigkeitsversionen obligatorisch oder meine Lösung haben
für Abhängigkeitskonflikte? Einer ist an fast jedem Ort Standard, der hat
Abhängigkeitsverwaltung und die andere ist eine einfache Bearbeitung von Text und Ordner
genannt. Ich glaube nicht, dass beides verrückt ist.

Am Di, 3. Juli 2018, 11:23 Uhr schrieb Jon Bonazza [email protected] :

@Two-Tone https://github.com/Two-Tone Ich habe versucht, nicht zu verrückt zu werden
mit diesem. Ich wollte nur etwas Einfaches, um uns aufzuhalten, bis es besser wird
Vorgehensweise entschieden.

@Zylann https://github.com/Zylann Ich würde wahrscheinlich den gleichen Ansatz verwenden
die derzeit in der Asset-Bibliothek verwendet wird – Herunterladen und Extrahieren der ZIP-Datei
Datei von github.

@chanon https://github.com/chanon die Asset Lib arbeitet mit github
direkt, also ist die einzige Identifikation, die wir für Versionen haben, Commit-Hash,
verzweigen und taggen.

—
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/19486#issuecomment-402214905 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AEJES-_IJBjvj3ImvZnqdu-cIAunCp2gks5uC5qIgaJpZM4UhqDC
.

@Two-Tone Entschuldigung, aber "zu verrückt" meinte ich "zu kompliziert", da dies nur eine schnelle Lösung sein soll, um uns aufzuhalten. Ich stimme zu, dass langfristig eine angemessene Konfliktlösung notwendig ist, aber ich hatte gehofft, dass wir in der Zwischenzeit einfach ohne sie davonkommen.

Eine andere Möglichkeit besteht darin, einfach auf die gesamte Assetlib zu verzichten und die Deps einfach direkt in das Projekt zu klonen. Da die aktuelle De-facto-Plugin-Projektstruktur jedoch im Verzeichnis addons verwurzelt ist, wird dies nicht wirklich funktionieren. Wir brauchen, dass der Projektstamm eine Ebene tiefer liegt (dh ohne das Addons-Verzeichnis und mit dem Plugin-Namen gerootet). Ich denke ehrlich gesagt, dass dies trotzdem eine willkommene Änderung wäre, da Sie dann Git-Submodule für Abhängigkeiten verwenden könnten.

@jonbonazza Ich verstehe. Ihre Lösung könnte implementiert werden und sofort funktionieren, ohne dass die Asset-Bibliothek geändert werden müsste. Dann stimme ich zu, dass es ein guter erster Schritt ist. (Nicht, dass ich ein Kernbetreuer wäre, der irgendeine Autorität hätte ... nur, dass ich denke, dass es ein guter erster Schritt ist.)

Ich denke, wenn der Asset Library-Datenbank eine Textkennung (Slug) plus Versionsinformationen hinzugefügt wurde, dann könnte diese wie in meinem obigen Beispiel hinzugefügt werden.

Sie könnten Git-Submodule für Abhängigkeiten verwenden.

@jonbonazza und hier stellt sich meine letztere Frage erneut, da es anscheinend nicht möglich ist, Submodule mit einem Plugin-Repro zu verwenden, da dieses Repo die vollständige Dateihierarchie enthalten müsste, um zum Download geeignet zu sein, was .git erzwingt

@chanon genau. Es würde nur eine kleine Menge an zusätzlichem Code in ein paar Dateien erfordern. Ehrlich gesagt könnte wahrscheinlich ein Addon entwickelt werden, das dies für Sie tun könnte, anstatt es in die Assetlib einzubauen

@Zylann ja, darauf wollte ich in meinem Kommentar zu Submodulen hinaus. Dies ist derzeit aufgrund der aktuellen Einschränkungen der Projektstruktur nicht möglich, aber die Änderung der Asset-Bibliothek, um diesbezüglich flexibler zu sein, wäre trivial.

EDIT: Es könnte auch abwärtskompatibel gemacht werden.

Ich habe tatsächlich vor einiger Zeit einen Vorschlag zur Projektstruktur gemacht. Das ist eigentlich meine Hauptbeschwerde darüber, wie Plugins jetzt funktionieren. Es gibt keine schöne Art, sie zu verpacken. Siehe #18131. Das sollte wirklich zuerst geändert werden, imo, vor allem, und je früher, desto besser, damit wir weniger Leute haben, die ihre Plugins umstellen müssen.

Was ist daran kompliziert? Eine davon ist eine Anforderung, die erzwungen werden kann
eine einfache Überprüfung und die andere ist ein einfaches Anpassen und Ersetzen oder
anhängen/voranstellen. Dies ist einfacher als das tatsächliche Hinzufügen von Abhängigkeitsunterstützung.

Am Di, 3. Juli 2018, 12:11 Uhr schrieb Jon Bonazza [email protected] :

@Two-Tone https://github.com/Two-Tone Entschuldigung, aber "zu verrückt" meinte ich
"zu kompliziert", da dies nur eine schnelle Lösung sein soll, um uns aufzuhalten.
Ich stimme zu, dass langfristig eine angemessene Konfliktlösung notwendig ist, aber
Ich hatte gehofft, wir könnten in der Zwischenzeit einfach ohne davonkommen.

—
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/19486#issuecomment-402229111 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AEJES7c8ziwhXZirsTsLY0zWfI-jrBzmks5uC6XUgaJpZM4UhqDC
.

@Two-Tone Sie können Ordner nicht einfach umbenennen, da Skripte im Code des Plugins häufig den Pfad des Addons direkt verwenden. Z.B

extends "res://addons/foo/bar.gd"

@jonbonazza Ich würde hinzufügen, es sind nicht nur Skripte, die das tun, sondern jede Ressource, die auf eine andere verweist.

Dann muss die Add-on-Ordnerstruktur wie gesagt aber zwingend sein, dann an
Verwenden Sie zur Installationszeit einfach die Such- und Ersetzungsfunktionen der String-Klasse
hat auf jedem Skript zu suchen

'erweitert " res://addonname/ '

Und ersetzen Sie es durch

'erweitert " res://addonname-versionsnummer/ '

Dies sind keine schwierigen Probleme im Code. Dank c++ sind sie wirklich einfach.
Dies sind meist nur Benutzerprobleme, um sicherzustellen, dass diese Probleme behoben werden
Wir müssen einige Sachen beauftragen. Wenn sie ein Plug-in hochladen und die Benutzer das finden
Es ist völlig kaputt, weil der Entwickler diese unglaublich nicht befolgt hat
einfache Regeln, dann ist das Sache des Plug-in-Entwicklers.

Und wir werden zunächst Regeln erlassen müssen, also könnten wir das genauso gut
Fügen Sie diese oder irgendeine Form davon hinzu, um sicherzustellen, dass wir dies richtig machen
von Anfang an.

Am Mittwoch, 4. Juli 2018, 12:48 Uhr schrieb Marc [email protected] :

@jonbonazza https://github.com/jonbonazza Ich würde hinzufügen, es ist nicht nur
Skripte, die das tun, aber jedes Asset, das auf ein anderes verweist.

—
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/19486#issuecomment-402533781 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AEJESwoMKvVVXcllrQ4YQQO852oZ1v7rks5uDP_SgaJpZM4UhqDC
.

Ich denke, wenn das Plugin nach einem Update die Kompatibilität unterbricht, sollten sie entweder Verfalls-Fallbacks bereitstellen oder tun, was @Two-Tone sagt, indem sie absichtlich den Pfad brechen, indem sie entweder das Plugin oder einen Unterordner davon umbenennen (das wäre jedoch das schlimmste Szenario, weil keine schöne Situation). So verhält es sich mit dem Motor selbst und mit anderen. Das Schreiben eines Plugins kommt mit der ganz anderen Denkweise, dass andere Leute/Plugins, die Sie nicht kennen, davon abhängen werden.

Was dadurch gelöst wird, ist kein Abhängigkeitsproblem, sondern eine Lösung für Abhängigkeitskonflikte. Ein Plug-In kann von Version 1 eines anderen Add-Ons abhängen und ein anderes von Version 2, ohne dieses oder etwas Ähnliches hätten wir entweder Konflikte oder müssten den Benutzer daran hindern, Plug-ins zu verwenden, die dieses verwenden widersprüchliche Abhängigkeiten haben.

Und die Lösung, um zu verhindern, dass Updates die Kompatibilität beeinträchtigen, besteht darin, zu erzwingen, dass jedes Update eine eindeutige Versionsnummer haben muss . Das könnte jedoch in die Kategorie „zu komplex“ fallen, da Sie plugin.cfg parsen und dann den Assets-Server fragen müssten, ob es bereits ein Plug-in mit diesem Namen und dieser Versionsnummer gibt. Wenn ja, werfen Sie einen Fehler aus. Wenn nicht, sollte alles in Ordnung sein.

Und ich bin mir nicht sicher, ob Sie über Skripte im Plug-In oder Skripte sprechen, die der Benutzer schreibt, aber ich stimme so oder so zu, dass es ein bisschen unhandlich ist, aber es sollte kein so schwieriges Problem sein.

Die einzige Lösung, die mir einfällt, ist die Erweiterung von gdscript, sodass der Benutzer im Skript angeben kann, welche Version des Plugins er verwendet, und von diesem Punkt an machen sie einfach extends "res://addonname/etc und lassen die Engine selbst verwenden der richtige Weg. Das fällt jedoch definitiv in das "zu komplexe" Problem, das @jonbonazza erwähnt hat. Aber für kurze Zeit kann es übersprungen werden.

Es gibt andere Probleme, die schließlich gelöst werden müssen. Z. B. sollte der Benutzer wissen, welche Abhängigkeiten installiert werden, wie er mit den mehreren Ordnern im internen Dateisystembrowser umgeht, die aus der Lösung des Abhängigkeitskonfliktproblems resultieren, wie wir mit Plug-Ins umgehen, die eine Abhängigkeit sind, aber ein Update haben (tun wir dieselben Einstellungen anwenden, die für manuell installierte Plug-Ins verwendet werden, zB Fehlerkorrekturen automatisch installieren oder Updates nur installieren, wenn das Haupt-Plug-In seine Abhängigkeitsliste aktualisiert), und mehr, da bin ich mir sicher.

Ich kann absolut verstehen, warum @reduz der Meinung ist, dass das Abhängigkeitsmanagement nicht wichtig ist. Es gibt so viele Variablen, die berücksichtigt und gelöst werden müssen , damit es sich lohnt, sie in Godot aufzunehmen, oder wir haben am Ende ein System, das nicht besser ist als das, was andere Engines verwenden.

Ehrlich gesagt denke ich, dass die beste Vorgehensweise für eine kurzfristige Lösung darin besteht, die Asset-Bibliothek so zu ändern, dass sie die Fähigkeit unterstützt (obwohl sie wegen der Abwärtskompatibilität nicht _erforderlich_ ist), Projekte zu bedienen, die eine Ebene unter dem addons -Verzeichnis liegen. Z.B

godot-tools.level-streamer/
    project.cfg

Anstatt

addons/
    godot-tools.level-streamer/
        project.cfg

Auf diese Weise können wir einfach in der Beschreibung des Addons angeben, dass es ein anderes Addon benötigt.

Es würde uns auch ermöglichen, gitsubmodules in unserem Projekt stattdessen einfach für Addons zu verwenden, wenn wir wollen.

Was ist, wenn Sie das für die Deps (z. B. dep/ ) tun und dann die manuell installierten Plug-Ins im Stammverzeichnis oder in einem benutzerdefinierten Ordner haben? Auf diese Weise verstopfen Abhängigkeiten nicht das Stammverzeichnis und Addons können entweder in oder?

$UserSetLocation/
    godot-tools.level-streamer/
        project.cfg

deps/
    thing-level-streamer-uses/
        project.cfg

@Two-Tone Aber was ist, wenn Ihre Abhängigkeit eine Abhängigkeit hat? Sollte der deps-Ordner nicht stattdessen ein Unterordner des Plugins selbst sein, damit Sie bei Bedarf beliebig tief gehen können?

Ich habe das Gefühl, dass über dieses ganze Abhängigkeitsproblem viel zu viel nachgedacht wird. Vielleicht sollten wir uns ein paar einfache Systeme einfallen lassen und über jedes diskutieren oder abstimmen? Ich sehe nicht, dass dieses Gespräch so endet, wie es derzeit läuft.

Davon abgesehen...

@willnationsdev Das könnte funktionieren, aber wenn viele Plugins auf dieselbe Abhängigkeit angewiesen sind, haben Sie mehrere Kopien dieser Abhängigkeit, von denen möglicherweise nur zwei erforderlich sind.

Ja, das Abhängigkeitsmanagement ist keine einfache Sache. Andernfalls müsste npm nicht so komplex sein wie es ist und yarn hätte nicht erstellt werden müssen.

Ich denke nicht, dass es eine gute Idee ist, Abhängigkeiten als Unterordner von Assets zu platzieren, da dies zu einem sehr komplexen Pfad führt. Es wird Fälle geben, in denen 2 oder mehr Assets die gleiche Abhängigkeit haben und eine Art Deduplizierung erforderlich wäre. Außerdem denke ich, dass es für den Spieleentwickler besser ist, genau zu sehen, welche Abhängigkeiten das Projekt hat, anstatt Unterordner von Unterordnern durchsuchen zu müssen, um herauszufinden, welche Abhängigkeiten verwendet und/oder n-mal dupliziert werden, da es sich um eine gemeinsame Abhängigkeit handelt.

In node.js-Webentwicklern ist es beispielsweise in Ordnung, den Inhalt von node_modules zu ignorieren, solange es funktioniert, da es nur auf dem Server bereitgestellt wird. Für ein Spiel werden Sie all diesen Code/diese Assets in ein endgültiges App-Paket packen, und es ist ziemlich schlecht, dass dieselbe Abhängigkeit n-mal dupliziert wird.

Diese Probleme sind der Grund, warum meine ursprünglichen Vorschläge besagten, Assets noch keine Abhängigkeiten definieren zu lassen, sondern nur eine Möglichkeit zu haben, Abhängigkeiten des Projekts aufzulisten und den Benutzer Abhängigkeiten von Assets manuell installieren zu lassen:
https://github.com/godotengine/godot/issues/19486#issuecomment -399559419

Wenn wir Assets haben, die Abhängigkeiten definieren, sollten sie meiner Meinung nach alle auf derselben Ebene installiert werden (im Ordner res://addons ). Bei Abhängigkeitsversionskonflikten (zwei Assets hängen von demselben Asset, aber unterschiedlichen Versionen davon ab) denke ich, dass eine einfache Lösung am besten wäre, z. B. immer die neuere Version zu verwenden.

Wenn wir andererseits wirklich ein Abhängigkeitsmanagement mit Deduplizierung und Lösung von Versionskonflikten implementieren wollen, indem wir zulassen, dass mehrere Versionen desselben Assets installiert werden, dann ist das auch in Ordnung! Als ob es wirklich robust gemacht wäre, wird es in der Lage sein, die Erweiterung des Asset-Ökosystems langfristig zu unterstützen. Irgendwie mag ich die Idee nicht, mehrere Versionen desselben Assets in meinem Spielprojekt zu haben. Und es hat npm so viele Versionen gebraucht, bis sie es richtig hinbekommen haben (ich bevorzuge aber immer noch yarn ), also denke ich nicht, dass diese Aufgabe unterschätzt werden sollte.

Ich denke nicht, dass es eine gute Idee ist, Abhängigkeiten als Unterordner von Assets zu platzieren, da dies zu einem sehr komplexen Pfad führt.
Wenn wir Assets haben, die Abhängigkeiten definieren, sollten sie meiner Meinung nach alle auf derselben Ebene installiert werden (im Ordner res://addons

Ich stimme dem zu. Ich würde es auch vorziehen, wenn Addons einmal im Projekt an einem Standardort vorhanden sind, nicht so oft wie Versionen, die von verschiedenen anderen Quellen und in verschiedenen Ordnern benötigt werden. Abhängigkeiten sind eine Sache, aber wir können auch einen Mittelweg finden, anstatt maximal feinkörnig zu werden, um die Dinge relativ einfach zu halten.

Diese Probleme sind der Grund, warum meine anfänglichen Vorschläge besagten, Assets noch keine Abhängigkeiten definieren zu lassen, sondern nur eine Möglichkeit zu haben, Abhängigkeiten des Projekts aufzulisten und Benutzer Abhängigkeiten von Assets manuell installieren zu lassen.

Wenn Assets Abhängigkeiten definieren, wäre es für mich in erster Linie für den Benutzer, schneller informiert zu werden, als sich vor der Installation Dokumente ansehen oder alle Plugins überprüfen zu müssen. Und schließlich haben Sie die Möglichkeit, die Abhängigkeiten gleichzeitig herunterzuladen, aber nur der Einfachheit halber (besonders wenn Sie von Grund auf neu installieren, müssten Sie diese sowieso installieren). Wir müssen wahrscheinlich auch keine Abhängigkeitskonflikte lösen, zumindest könnte das Installationstool den Benutzer informieren, wenn es einen erkennt.

Ich habe das Gefühl, dass über dieses ganze Abhängigkeitsproblem viel zu viel nachgedacht wird

@LikeLakers2 Richtiges Abhängigkeitsmanagement und Konfliktvermeidung ist ein wichtiges und schwieriges Thema. Deswegen wird so viel darüber diskutiert

Ich sehe nicht, dass dieses Gespräch so endet, wie es derzeit läuft.

Zu versuchen, dies einfach durchzusetzen, ohne alle Probleme herauszufinden, die Abhängigkeit mit sich bringt, wäre eine sehr schlechte Idee und würde nur viel mehr Probleme verursachen. Das ist ein schwieriges Thema und es wird Zeit brauchen.

Bei Konflikten zwischen Abhängigkeitsversionen (zwei Assets hängen von demselben Asset ab, aber von unterschiedlichen Versionen) wäre eine einfache Lösung meiner Meinung nach am besten

@chanon Meine Ideen sind einfach. Was ist kompliziert daran, einen Ordner zu benennen und die entsprechenden Dateipfade in Textdokumenten zu ändern? Es ist eine einmalige Gebühr für den Benutzer, macht deutlich, welche Version von dem, was Sie installiert haben, und ist ziemlich einfach zu schreiben.

wie immer für die neuere Version zu gehen

Das führt dazu, dass Plug-Ins ohne Vorwarnung kaputt gehen, wenn ihre Abhängigkeiten aktualisiert werden und ihre Funktionsweise ändern. ZB Plugin 1 und 2 hängen beide von Dep 1 ab, aber unterschiedliche Versionen. Plugin 2 hängt von der aktuellen, neuesten Version ab, aber Plugin 1 hängt von einer älteren Version ab, die sich anders verhält als die neueste Version. Plug-in 1 funktioniert nicht mehr wie vorgesehen oder weist Fehler auf, mit denen es nicht ausgeliefert wurde.

Wir müssen wahrscheinlich auch keine Abhängigkeitskonflikte lösen, zumindest könnte das Installationstool den Benutzer informieren, wenn es einen erkennt.

@Zylann Dann haben wir das Problem, dass der Benutzer das x-Plugin nicht installieren kann, weil y eine andere Version derselben Abhängigkeit verwendet. Das wird von den Benutzern nicht als eine gute Sache angesehen

Ich stimme @willnationsdev und @LikeLakers2 zu

Ich habe das Gefühl, dass über dieses ganze Abhängigkeitsproblem viel zu viel nachgedacht wird. Vielleicht sollten wir uns ein paar einfache Systeme einfallen lassen und über jedes diskutieren oder abstimmen? Ich sehe nicht, dass dieses Gespräch so endet, wie es derzeit läuft.

Zu viel Fahrradabwurf. Dies ist eine Game-Engine, keine Game-Engine-Addon-Delivery-Plattform. Nur Herstellerabhängigkeiten in den Verzeichnissen jedes Addons und Schluss damit. Kein Stress wegen Versionskonflikten oder -verwaltung oder w/e auf Kosten einer gewissen Ineffizienz. Wenn der Benutzer des Addons Bedenken hinsichtlich der Leistung hat, sollte er in der Lage sein, ECHTE Leistungsoptimierungen wie GDNative oder Module in Betracht zu ziehen. Ich kann mir auch nicht vorstellen, warum irgendein Addon einen tiefen Abhängigkeitsgraphen haben sollte. Der einzige Grund, warum ich sehen kann, dass ein Addon eine Abhängigkeit von einem anderen hat, ist, wenn es es auf irgendeine Weise erweitert: SweetFpsController -> SweetFpsController w/ flying . In diesem Fall würde ich sagen, dass es Sache der beiden Projekte oder ihrer Benutzer ist, ihre Kopplung in Einklang zu bringen, anstatt die Verantwortung der Engine zu übertragen.

@Two-Tone Wenn Plugin A Version 1 von X und Plugin B Version 2 von X benötigt, würde ich sagen, dass Godot nicht versuchen sollte, es auf magische Weise zu beheben. Hier sind einfache Lösungen dafür:

• Normalerweise sollte Version 2 von X abwärtskompatibel mit Version 1 sein, und so sollten die Dinge sein, um es einfach zu halten (erinnern Sie sich, als ich die Denkweise bei der Entwicklung von Plugins erwähnte).
• Wenn Sie die neueste Version von X nicht verwenden können, warten Sie, bis Plugin A sie unterstützt, und laden Sie die vorherige Version herunter (wir benötigen die Assetlib-API, um verschiedene Versionen zu erhalten, nicht nur die neueste, das sollte nicht schwer sein). Es ist wie bei Mods, es muss nicht perfekt sein.
• Der Plugin-Hersteller von X lädt es als ein anderes Plugin hoch (weil die API die Kompatibilität unterbricht), genau wie wir es tun mussten, als Godot 3 herauskam. Dann haben Sie also zweimal dasselbe Plugin, aber es ist in Ordnung, weil sie sowieso zu unterschiedlich sind, um wirklich dieselben zu sein, und Dinge, die davon abhängen, werden auch funktionieren. Es kann sogar nur eine Ordnerumbenennung durch den Plugin-Entwickler sein, nicht einmal die Notwendigkeit, zwei Asset-Lib-Einträge zu haben.

Im schlimmsten Fall müssten Sie dies manuell zum Laufen bringen (und schließlich die PR-Kompatibilität mit dem Plugin-Hersteller).

Wenn dies nicht der Fall ist, würde dies bedeuten, dass jedes Mal zwei Versionen mit unterschiedlichen Pfaden installiert werden (vermasseln Sie alle Verweise bei jedem Update) oder dass der Engine Kernänderungen hinzugefügt werden, um die Funktionsweise von Pfaden zu ändern (kompliziert).
Ich denke, wenn wir nur ein einfaches Abhängigkeitsmanagement bekommen könnten, wäre das schon ganz nett, da es im Grunde die Funktionalität und Struktur verwenden würde, die Godot bereits hat (also wäre es auch ziemlich einfach zu implementieren), und automatisch Dinge zu tun, die der Benutzer gerade hat sowieso manuell zu machen.

Ich betrachte das Abhängigkeitsmanagement nicht als eine Sache, die immer funktionieren und in der gesamten Verantwortung der Engine liegen sollte (wie npm), denn das wäre eine Menge Arbeit. Ich betrachte es in erster Linie als Bequemlichkeit für Dinge, die Sie derzeit mit vorhandener Funktionalität von Hand erledigen müssen, und Plugin-Hersteller können ihre Arbeit auf der Grundlage dieses einfachen Systems veröffentlichen.
Wenn es jemandem gelingt, ein System zu implementieren, das weit darüber hinausgeht, kann dies später erfolgen, da das, was ich oben beschrieben habe, vorher praktikabel war und hauptsächlich nur einfache Verbesserungen an der Assetlib und dem Editor sind.

@Zylann Wie sind diese Optionen besser als das, was ich vorgeschlagen habe? Und es ist nichts Magisches, nach Text zu suchen und ihn an eine bestimmte Zeichenfolge anzuhängen.

Option 1 zwingt Entwickler dazu, sicherzustellen, dass ihre Versionsaktualisierungen keine anderen Plugins beschädigen, die davon abhängig sind, was eine Menge zusätzlicher Arbeit für sie bedeutet. Wer hat Lust, Plugins für so etwas zu entwickeln?

Option 2 zwingt Benutzer, das gewünschte Plugin nicht zu verwenden, da sie entweder warten müssen, bis das Plugin aktualisiert wird, wenn es überhaupt noch aktiv entwickelt wird, oder es überhaupt nicht verwenden.

Option 3 macht es den Plugin-Entwicklern noch einmal schwerer.

Zwei Versionen mit unterschiedlichen Pfaden sind kein großes Problem. Wenn sie jemals aktualisiert werden, überprüfen Sie, welche Installationspakete sie als Abhängigkeit haben, führen Sie das Suchen und Ersetzen (unter Berücksichtigung der alten Versionsnummer) für alle Skripte für diese Pakete erneut aus und entpacken Sie schließlich die neue Version.

Ich habe das Gefühl, dass die Leute versuchen, dies komplizierter darzustellen, als es sein muss.

Richtiges Abhängigkeitsmanagement und Konfliktvermeidung ist ein wichtiges und schwieriges Thema. Deswegen wird so viel darüber diskutiert

@Two-Tone Was ich meinte, ist, dass Sie viel zu intensiv über das Thema nachdenken, selbst wenn es sich um ein schwieriges Thema handelt. Bei vielen Gesprächen (zugegebenermaßen einschließlich meiner Antworten, entschuldigen Sie bitte, da dies heuchlerisch klingen wird) ging es darum, was an den vorgestellten Ideen nicht stimmt , und nicht so sehr darum, was getan werden kann, um sie zu ändern und zu verbessern planen. Die vorgeschlagenen Ideen können nicht nur Schattenseiten haben, oder? Es scheint, als ob jeder seinen Weg will und auch nur seinen Weg, was nicht gerade hilft.

Zu versuchen, dies einfach durchzusetzen, ohne alle Probleme herauszufinden, die Abhängigkeit mit sich bringt, wäre eine sehr schlechte Idee und würde nur viel mehr Probleme verursachen. Das ist ein schwieriges Thema und es wird Zeit brauchen.

Ich schlug vor, ein paar einfache Ideen zu entwickeln, mit der Implikation, dass wir sie ausbügeln und dann entscheiden, sobald wir das Gefühl haben, dass wir ein gutes System haben. Ich dachte nicht, dass ich das explizit erwähnen muss, aber los geht's.

Ich bin irgendwie verärgert darüber, wie lange dieses Gespräch ohne Fortschritt gedauert hat. Ernsthaft.

Zwei Versionen mit unterschiedlichen Pfaden sind kein großes Problem

Das allein ist es wahrscheinlich nicht. Aber zwei Versionen desselben Plugins zu einem bestimmten Zeitpunkt in Godot zu haben, impliziert andere Dinge, deren Lösung verwirrend wird.

• Ihre Pfade sind nicht mehr so, wie Sie denken, dass sie sind / Änderungen müssen am Kern vorgenommen werden, was hauptsächlich Kernentwickler betrifft
• Wenn das Plugin einen benutzerdefinierten Typ verfügbar macht, welchen zeigt der Editor an?
• Wenn das Plugin C# ist, wie kompilieren Sie es, ohne mit anderen Kopien in Konflikt zu geraten?
• Wenn das Plugin Autoloads registriert, wie unterscheiden Sie sie?
• Wenn der Benutzer Daten erstellt, die das Plugin verwenden, welches wird es verwenden?
• Welche zeigt die Benutzeroberfläche im Editor an?

Ich denke, bevor wir auch nur einfache Lösungen für diejenigen finden, die zur Engine passen (und vielleicht gibt es noch mehr, an die ich nicht gedacht habe), können wir bereits vorhandene Sachen im Editor und in der Asset-Bibliothek verbessern, ohne die Kompatibilität zu beeinträchtigen oder Kernänderungen einzuführen.

+1 für alles in diesem Thread - die Erweiterung des Plugin-Moduls und die verstärkte Nutzung der Asset-Bibliothek ist der richtige Weg

Nachdem ich Unity ausprobiert und gelernt habe, habe ich jetzt eine klarere Vorstellung davon, wie das aussehen sollte.

Erstens hat Unity jetzt einen „Package Manager“, mit dem Benutzer auswählen können, welche Komponenten der Engine sie installieren/deinstallieren möchten. Es sieht so aus, als würden sie dies in Zukunft auch für den Asset Store verwenden.

So etwas würde Godot wirklich helfen, "Blähungen zu reduzieren", während es "offizielle Addons" hat. Unity ist selbst mit ihrem Paketmanager immer noch super aufgebläht, während Godot noch kleiner werden könnte, wenn er einen hätte. Die Verteilungsmethode "eine Exe" muss jedoch möglicherweise aufgegeben werden.

Außerdem sollten normale "Module" vielleicht als gemeinsam genutzte Bibliotheken (dll/.so-Dateien) erstellt werden, damit sie im Paketmanager zur Installation/Deinstallation ausgewählt werden können.

Projekte und Pakete sollten Manifestdateien haben, die Pakete auflisten, von denen sie abhängen, und Godot / der Paketmanager würde sicherstellen, dass die erforderlichen Pakete installiert werden.

Eine öffentliche Registrierung von Paketen wäre erforderlich.

Dies würde es der Community ermöglichen, Godots Fähigkeiten einfach zu erweitern und einfach auf den Arbeiten der anderen aufzubauen. Ich denke, es würde die Entwicklung der Gemeinschaft sehr fördern.

Ich stimme dem Gesamtverdienst des Wechsels zum Package Manager-Ansatz nicht zu, ich habe mich noch nicht entschieden, aber ich möchte darauf hinweisen, dass er auch seine Schwächen hat - eine einzelne ausführbare Datei kann viel integrierter und besser sein. getestet, zumindest leichter.

Mit einem Paketmanager wächst die Testoberfläche exponentiell für jedes Plugin und jede Version. Das ist nicht so schlimm, wenn die Plugins meist kleine Ergänzungen sind (wie derzeit in der AssetLib), die sich nicht zu tief in den Engine-Kern einhaken, aber es wird schnell so, wenn Sie die Kernteile der Engine aufteilen.

Unity hat bereits Probleme, Abstürze und Kompatibilitätsprobleme mit verschiedenen Versionen ihrer Pakete, ihrer Editoren oder mit der Installation (oder Nichtinstallation) bestimmter Paketkombinationen oder sogar mit der Reihenfolge, in der sie installiert wurden.

Dies ist eine Menge zusätzlicher Komplexität, die gut verwaltet werden muss, damit wir nicht in der Abhängigkeitshölle landen :)

In Bezug auf die Abhängigkeitshölle, warum nicht eine Seite von etwas wie AppImage nehmen und versuchen, Abhängigkeitsprobleme zu vermeiden, indem Plugin-Distributoren für die Verwaltung von Asset-/Dateiabhängigkeiten verantwortlich gemacht werden? So sehe ich dieses Problem...

Plug-Ins sollten (idealerweise) eigenständige Elemente entweder von Logik (benutzerdefinierte Editoren, benutzerdefinierte Knoten, dynamisch verknüpfte Bibliotheken) oder Assets (Modelle, Materialien, Schriftarten, Texturen usw.) sein, die ihre eigenen Abhängigkeiten haben sollten. Der Versuch, gemeinsame Abhängigkeiten herauszufinden, ist ein Rätsel, das den Leuten zwar gefallen mag, aber viel mehr Aufwand bedeutet, um es zu pflegen. Wenn Sie tatsächlich gemeinsame Abhängigkeiten zulassen würden, müssten Sie dieses Problem ähnlich wie bei der Steam-Laufzeit angehen und eine Reihe verschiedener Bibliotheken, Plugins und Assets als ihre eigenen einzigartigen Pakete verwalten. Sie müssten auch mehrere der gleichen Pakete für mehrere Versionen auf einem Server speichern – es wäre ein Wartungsalbtraum und es ist keine Überraschung, dass moderne Linux-Distributionen sich mehr oder weniger von Paketmanagern entfernen.

Ein Plugin könnte im Wesentlichen ein einzelnes Tar-Archiv mit allen Elementen sein, die erforderlich sind, damit dieses Plugin isoliert funktioniert. Sie sollten nativ eigenständig funktionieren, wobei alle Abhängigkeiten ebenfalls archiviert sind. Wenn Godot diese Datei sieht, sucht es nach einer Manifest-Datei im Stammverzeichnis des archivierten Ordners. Dieses Manifest könnte grundlegende Informationen enthalten (Name, Beschreibung, Godot-Version, Symbol, Autoren), sollte aber auch Dinge enthalten wie: Update-Info (Link zum Herunterladen der neuesten Version, gepflegt von Plugin-Entwicklern), die Godot verwenden kann, um automatisch die plugin (mit Benutzererlaubnis), project_website (Link zu einem Repository oder einer Website, damit Benutzer schnell die Quelle eines Pakets finden können) und class_names (Liste von Klassen innerhalb dieses Addons, die erweitert werden können und für Skripte verwendet werden.) Es könnte auch darauf verweisen Die Addons, die es als Abhängigkeiten verwendet, verwenden einen relativen Pfad zu einer internen Plugin-Datei.

Wenn wir Plugins innerhalb von Plugins zulassen, werden die Abhängigkeitsprobleme (mehr oder weniger) gelöst. Unterschiedliche Versionen derselben Bibliothek befinden sich in unterschiedlichen Verzeichnispfaden und könnten auf einem bestimmten Fork als unterschiedliche „Pfade“ behandelt werden. Das Problem mit diesem System besteht natürlich darin, dass Sie am Ende viele doppelte Informationen auf einer bestimmten Festplatte haben. Beim Packen eines Spiels könnte Godot jedoch idealerweise alle Plugin-Verzeichnisse durchgehen und Dateireferenzen zusammenführen, die per Prüfsumme übereinstimmen (dies kann tar-repräsentierte Dateistrukturen enthalten?). Wenn zwei Dateien identisch sind, optimiert Godot auf diese Weise die endgültige Ausgabebinärdatei, indem es die Referenz zu einer einzigen Datei zusammenführt.

Ich bin mir sicher, dass dies eine viel zu naive Lösung für ein so kompliziertes Problem ist, aber ich habe in letzter Zeit aufgrund meines Patches für benutzerdefinierte Schriftarten über das Plugin-System nachgedacht. Ich denke, die beste Benutzererfahrung ist eine, bei der sie sich nicht um Abhängigkeiten kümmern müssen, und die Entwickler sollten sich um die Verwaltung ihrer eigenen Abhängigkeiten kümmern. Dies erleichtert dem Benutzer die Verwaltung: Die Addons eines Projekts können als einzelne Datei im Dateisystem-Dock dargestellt werden, Sie können mit der rechten Maustaste klicken und zusätzliche Optionen erhalten ( extract files (für Entwicklung), update plugin (für einfache Updates), gehen Sie zur Website ( for easy community organization )) und referenzieren Sie auch Klassen innerhalb eines bestimmten 'Containers' ( extends "[path-to-addon-tar]://ClassName" )

Nur meine 2 Cent zu diesem Thema, ich bin mir sicher, dass es auch einige Fehler in der Art und Weise gibt, wie ich darüber nachdenke, aber es könnte eine interessante Lösung sein und auch eine anständige Möglichkeit, den Wartungsbedarf für das zu reduzieren Godot-Team.

Nur 2 Cent basierend auf den vorherigen 2 Cent (macht das 4 Milles?):
Ich schätze, .tar -Archive wären für die meisten Benutzer (ähm, Windows-Benutzer) etwas ungewohnt, also könnte es besser sein, .zip -Archive zu verwenden, da sie eine etwas breitere Unterstützung haben.

Abgesehen davon, was ist mit der Verteilung von Plugins in Godots eigenem .pck -Format? Ich habe einige Nachteile (z. B. dass ich von den meisten Anwendungen nicht erkannt werde), aber das könnte eine Chance sein, es standardisierter und verwendeter zu machen.

Ich denke, .tar-Archive sind den meisten Benutzern (ähm, Windows-Benutzern) etwas ungewohnt, daher ist es möglicherweise besser, .zip-Archive zu verwenden, da sie eine etwas breitere Unterstützung haben.

Abgesehen davon, was ist mit der Verteilung von Plugins in Godots eigenem .pck-Format? Ich habe einige Nachteile (z. B. dass ich von den meisten Anwendungen nicht erkannt werde), aber das könnte eine Chance sein, es standardisierter und verwendeter zu machen.

Sicher, ich meinte hauptsächlich .tar als Beispiel für einen generischen gepackten Archivtyp. Es könnte und sollte wahrscheinlich das .pck-Format von Godot verwenden.

Warum nicht ZIP verwenden, da es Komprimierung bietet und ein Standardformat ist?

@Calinou Ich stimme zu. Wenn wir vorschreiben, dass .pck-Dateien verwendet werden müssen, müssen die Leute die Godot Engine verwenden, um Dinge zu packen, anstatt nur das von ihnen bevorzugte Packtool zu verwenden, um ihr Plugin für die Verwendung zu bündeln. GitHub lädt Repositories auch als .zip-Dateien herunter und beherbergt die bei weitem größte Sammlung von Godot-Plugins.

Ich stimme hier zu. Ich glaube nicht, dass ein anderer Dateityp erstellt werden muss. Zip-Dateien scheinen sehr gut zu funktionieren, und die Leute haben die Möglichkeit, sie über die Godot-Oberfläche über die Asset-Bibliothek zu installieren oder sie können sie selbst manuell herunterladen. eine .pck-Datei lässt diese Auswahl nicht zu.

In meiner idealen Welt hätte ich gerne zwei Download-Buttons unter https://godotengine.org/download :

• Ein schlanker, minimaler Download, der die drei Anforderungen von Reduz erfüllt, und
• Ein aufgeblähter Download mit allen genehmigten und regelmäßig gewarteten Plugins, die eine gewisse Qualitätskontrolle überstanden haben, sodass ich weiß, dass ihre API mindestens so gut mit dem Kern funktioniert wie die API der Mindestversion.

Noch idealer:
Auswählen und mischen. Nach dem Herunterladen des absoluten Minimums kann ich die Mindestversion + Plugin "Themen" auswählen. Dies sind Sammlungen gängiger Plugins, die für gängige Anwendungsfälle benötigt werden. (also zum Beispiel: 2DPixelart, 3D FirstPersonShooter, 3D ThirdPerson, RTS, RPG, 2.5D game, 2DCutout, Rougelike, ManagementSim, Sidescroller, Eventpackage, Shaderpackage, Scriptpackage, Assetpackace, ect). Wenn ich also die Engines starte, sind wichtige Plugins bereits installiert und einsatzbereit, und ich weiß, dass sie funktionieren, weil sie genehmigt wurden.
Fortgeschrittene Benutzer können einzelne Plugins innerhalb dieser Themensammlungen deaktivieren, wenn sie wissen, dass sie sie nicht benötigen, oder zwei oder mehr Plugin-Themen kombinieren oder zusätzliche einzelne Plugins zu Themen aus dem Pool genehmigter Plugins hinzufügen, um ein benutzerdefiniertes Paket zu erstellen.

Im Idealfall wäre das Ergebnis, dass https://godotengine.org/download aus diesen Auswahlmöglichkeiten _einen Download-Link on the fly_ erstellt.

Warum? Denn dies wäre eine enorme Zeitersparnis und Qualitätssicherung für Personen, die in Teams oder Gruppen arbeiten, für Pädagogen und Lehrer in Schulen, die auf mehreren Computern bereitstellen müssen, für Personen, die Tutorials folgen und dieselbe Konfiguration wie der Tutor wünschen, für Einzelpersonen die froh sind, dass es ein offiziell vom Entwicklerteam genehmigtes Plugin für etwas gibt, das häufig verwendet wird, aber nicht von allen, und so nicht tagelang Github und Reddit durchsuchen müssen, um das zu finden, was sie brauchen, ohne zu wissen, welches am meisten unterstützt wird Option aus den 6, die sie gefunden haben.

Für diejenigen, die die kleine Größe benötigen, sollte es immer noch einen Ein-Klick-Download mit minimalem Minimum geben, sowie einen Download mit maximalen Funktionen, die sich nicht um die Größe kümmern, aber maximale Funktionen wünschen, um zu sehen, was die Engine leisten kann.

Eine einfachere Lösung wäre, zu fragen, ob zusätzliche [nur offizielle?] Plugins installiert werden sollen, wenn der Editor zum ersten Mal ausgeführt wird. Derzeit haben wir die Möglichkeit, AssetLib zu öffnen, wenn die Projektliste leer ist; Warum nicht ein Dialog-Popup haben, um offizielle Plugins zu installieren, wenn Sie Godot zum ersten Mal ausführen?

Schluss zugunsten von https://github.com/godotengine/godot-proposals/issues/142 , https://github.com/godotengine/godot-proposals/issues/577 und https://github.com/godotengine/ godot-proposals/issues/607 , da Funktionsvorschläge jetzt im Godot-Proposals-Repository verfolgt werden.

Edit von aaronfranke: Siehe auch https://github.com/godotengine/godot-proposals/issues/554