Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
Ich bin mir nicht ganz sicher, aber insgesamt klingt es als würdest du gerade in etwa das versuchen, was auch mein Ziel war, als ich angefangen hab, die Duality Engine zu entwickeln: Vorbild Unity, Nutzerseitiger Code via C#, Komponentnbasierte Ansätze. Mein Ansatz war es, das Ganze auf eine Plugin Architektur abzubilden, den nutzerseitigen "Script" Code also dynamisch aus einem Plugin zur Laufzeit nachzuladen, das Kompilieren des Plugins aber dem Nutzer zu überlassen. Damit habe ich ziemlich gute Erfahrungen gemacht und würde das auch direkt so weiterempfehlen. Du erlaubst es dem Nutzer auf diese Weise auch, eigene externe Projektreferenzen zu nutzen, die nicht von der Engine vorgesehen waren, um beispielsweise Libraries einzubinden und die Kernfunktionalität grundlegend zu erweitern.Unity wäre ja im Prinzip eins meiner Vorbilder. Du hast ja schon ein paar Sachen genannt und da werde ich mal weiter forschen. Du schreibst dass du dir das so bei Unity abgeschaut hast. Gibt es dazu selbst Informationen im Internet, oder hast du selbst irgendwie Informationen extrahiert? Oder ist es einfach der Weg den du dir vorstellst, wie es bei Unity gemacht wird? Wenn du dazu noch ein paar Informationen hast, wäre es fein wenn du sie mit mir teilen würdest. Aber wie gesagt, habe ich jetzt ja schon ein paar Stichpunkte bekommen. Werd das ganze mal ein wenig testen. Danke schon mal an alle beteiligten.
Ja, das ist mehr oder weniger der Ansatz den ich mit Duality verfolgt hab. Im Rahmen des Projekts hab ich ein eigenes, einheitliches Serialisierungsformat entworfen, das konsequent für Szenen, Prefabs und andere Ressourcen verwendet wird und wahlweise auf Binärdaten oder XML basiert. Das war eine Menge Arbeit und hat viele Nerven gekostet, arbeitet jetzt aber seit gut einem Jahr relativ verlässlich. Ein Vorteil und der Hauptgrund für diese Eigenentwicklung war eine Maximierung der Fehlertoleranz.Irgendwie muss ich dem Spiel die Szene ja übergeben. Ein Ansatz wäre natürlich diese Dinge komplett auszulagern. Ich könnte eigene Dateiformate dafür schreiben, welche dann an der jeweiligen Stelle geladen werden. Aber irgendwann kommt man zu dem Punkt, an welchem man dem Spiel doch bestimmte Sachen mitgeben muss. Zum Beispiel muss das Spiel wissen, mit welcher Szene es starten soll.
Na klar, das kann ich auch sehr gut nachvollziehen. Dachte mir seinerzeit ja ähnliches. Außerdem ist das ein sinnvoller Qualitätsstandard: Wenns gut genug ist, dass es jeder benutzen kann, dann hat man letztendlich ja auch was davon.Zitat
Ich denke mir halt, wenn ich mir den Aufwand schon mache, dann wäre es ja vielleicht schön wenn nicht nur ich davon profitiere, sondern auch andere damit arbeiten können. Natürlich unter der Voraussetzung, dass das ganze fertig wird und dabei so schön zu Handhaben ist, dass andere das überhaupt wollen
Zitat
Schon mal sehr genial, dass du da an ähnlichen Dingen sitzt. Durch den Code kann ich mir sicher einige Prinzipien abgucken. Wobei ich da auch gucken kann in wie fern ich da überhaupt an einer eigenen Engine arbeiten muss/soll. Vielleicht arbeitet Duality ja mehr nach meinen Vorstellungen, als ich bis jetzt dachte.
Zitat
Man möchte ja vielleicht, dass der Spieler bestimmte Dinge nicht ohne weiteres verändern kann. Was meiner Meinung nach auch völlig ok ist.
C#-Quelltext |
|
1 2 3 4 5 6 7 8 9 10 |
public GameObject CreateGameObject(String type) { GameObject result = new GameObject(); if(type == "type1") { result.AddComponent(Component1); result.AddComponent(Component2); } return result; } |
Hm, dann nochmal eine kurze Erläuterung zu meinem Beispiel gerade: Also Spieleentwicklung ist ja generell ein sehr dynamischer Prozess. Komponentenklassen werden vom Nutzer nach und nach erstellt und teilweise auch wieder gelöscht - oder umbenannt. Manchmal auch gedankenlos nebenbei. Überhaupt ist das Umbenennen von Dingen zur Entwicklungszeit ein großes Problem. Der Nutzer könnte also eine Komponentenklasse entfernen oder umbenennen und das Pluginprojekt neu kompilieren. Der Punkt ist, du musst die Factory / Prefab Codegenerierung neu durchlaufen lassen für Objekte, die der Nutzer aber schon vor einer Weile fertig gebaut und gespeichert hat. Das sollte ein automatisierter Prozess sein, damit der Nutzer nicht in allen 300 Prefabs seine Testkomponente vom Anfang rausnehmen muss, oder umbenennen. Du müsstest also quasi gucken wie das Objekt aufgebaut ist, das der Nutzer in seinem Prefab gebastelt hat und schauen ob alle Komponenten noch da sind und gegebenenfalls eben die fehlenden rausnehmen - und dann das Prefab neu generieren, damit es auch mit Sicherheit noch funktioniert.Das bringt doch schon mal viel Licht ins Dunkel bei mir. Das Beispiel mit der Debuggingklasse leuchtet mir nicht ganz ein. Ich wüsste nicht warum das unbedingt Probleme machen sollte.
Gut gut. Falls du Plugins zur Laufzeit neu laden willst und dabei auf Probleme stößt, sag Bescheid. Das ist so ein Kapitel für sich - hab da anfangs so die eine oder andere Erfahrung mit gemacht. Ansonsten bin ich mal gespannt was sich da entwickeltZitat
Wenn ich ein wenig weiter bin können wir ja mal ein bisschen quatschen. Noch ist vom Editor ja nichts zu sehen. Habe mir aber eben testweise ein Pluginsystem gebastelt, welchers dynamisch dlls läd und daraus Code ausführt. Damit bin ich schon mal einen Schritt weiter.
Gut gut. Falls du Plugins zur Laufzeit neu laden willst und dabei auf Probleme stößt, sag Bescheid. Das ist so ein Kapitel für sich - hab da anfangs so die eine oder andere Erfahrung mit gemacht. Ansonsten bin ich mal gespannt was sich da entwickelt
Werbeanzeige