spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Treue Seele

20.02.2013, 11:14

Zitat von »Schorsch«

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.

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.

In vergangenen Projekten habe ich auch einen Skript-artigeren Ansatz ausprobiert, bei dem einzelne C# Code Files zur Laufzeit als Text geladen und von der Engine kompiliert werden, habe jedoch keinen Vorteil daraus ziehen können und im Vergleich weniger Möglichkeiten und eine längere Ladezeit in Kauf genommen. Würde dir also eher zu der Plugin-Variante raten.

Im Unity / Duality Ansatz ist der primäre Ansatzpunkt für Erweiterungen das Schreiben von eigenen Komponenten (Ableiten von einer Basisklasse der Engine) welche dann GameObjects hinzugefügt werden und so nahtlos mit dem Engine Code und anderem Plugin Code interagieren können. Ich habe selbst eine Weile das Internet nach Artikeln und Präsentationen zur Unity Engine und deren Interna durchsucht, bin jedoch nicht fündig geworden. Insbesondere das Prefab-System hätte mich sehr interessiert - aber es scheint so als wäre man da auf Reverse Enginering angewiesen.

Falls du einen Blick auf konkrete Implementierungen meinerseits werfen willst, kannst du gerne durch den Source Code von Duality stöbern. Interessant sein dürften hinsichtlich des Plugin Ansatzes GameObject.cs, Component.cs, CorePlugin.cs und DualityApp.cs. Am besten die entsprechenden Dateien oder das Projekt per SVN Checkout holen, der Online Reader von Google Code ist nicht so besonders und taugt höchstens zum schnellen überfliegen.

Zum Seitenanfang

Supermoderator

Wohnort: Wickede

Beruf: Softwareentwickler

20.02.2013, 15:13

Habe mal ein wenig in deinem Code von Duality geguckt und ein paar gute gedankliche Ansätze konnte ich mir schon abgucken. Jedoch habe ich da speziell zu deinem Projekt noch ein paar Fragen. Was ich bis jetzt gesehen habe, sah mir stark nach einem "einfachen" Plugin System aus. Soll heißen, ich möchte deine Engine um ein Plugin erweitern, öffne Visual Studio und schreibe den Code. Dann lade ich das Plugin in deine Engine. Liege ich damit soweit richtig?
Was ich aber eigentlich machen möchte, ist den Code des Spiels selbst in der Engine schreiben zu können. Auf Duality bezogen wäre es so, dass der Benutzer die Component Instanzen innerhalb der Engine entwickelt. Dabei wollte ich keine komplette IDE schreiben, sondern lediglich einen Editor anbieten, welcher dann Visual Studio aufrufen kann. So wie es bei Unity im Prinzip auch abläuft.
Bei Duality sehe ich bis jetzt keine Verbindung zwischen CorePlugin und Component. Ist natürlich gut möglich, dass ich das bei den vielen Klassen einfach übersehen habe.
Im Prinzip soll ja in meine Programm ein Objekt erstellt werden. In deinem Fall wäre das so ein GameObject. Diesem Objekt füge ich dann bestimmte Komponenten hinzu, welche Verhalten etc bestimmen. Die Klassen für die Komponenten schreibt der Benutzer selbst. Die Verbindung muss irgendwie vom Programm gegeben sein. Ich glaube immer noch, dass das über einfache Codegenerierung der einfachste Weg wäre. Ich bin mir aber auch gar nicht sicher wie ich das anders lösen können soll. Der Ansatz von dir und von Yannic ist ja im Prinzip der selbe. Nur sehe ich dadurch noch irgendwie keine Lösung.

Ich schreibe meine Idee noch mal kurz auf. Möglicherweise schreiben wir hier auch aneinander vorbei.
Ich erstelle im Editor ein Gameobjekt. Ich schreibe ein paar Komponenten und füge diese dem Gameobjekt hinzu. Das passiert auch im Editor. Möglicherweise Verknüpfe ich verschiedene Gameobjekte um Beziehungen herzustellen. Das Programm hat eine Klasse für so ein Gameobjekt und für die Komponenten werden Schnittstellen bereitgestellt. Das Programm erzeugt nun eine Factory oder Vergleichbares, welche diese Gameobjekte erstellen kann. Im Prinzip werden hier die Prefabs erstellt. Für die Factory gibt es auch ein Interface. Die neuen Komponenten, sowie das generierte Interface wird zu einer Library kompiliert. Für das Spiel gibt es eine vorgefertigte ausführbare Datei, welche diese DLL nun läd. Die Factory wird gesucht und darüber die einzelnen Objekte erstellt. Da jedes Spiel andere Prefabs hat, besitzt so jedes Spiel eine eigene Factory. Zusätzlich gibt es halt eine Komponente die den Grundzustand erstellt. Soll heißen, die Objekte anlegt, die beim starten des Spiels vorhanden sein sollen.

Worum es mir hierbei nun speziell ging, ist die Sache mit der Codegenerierung und der daraus erzeugten DLL. Haltet ihr das für sinnvoll? Die anderen Sachen sind natürlich auch wichtig, aber hauptsächlich geht es mir erst mal darum.

„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

Zum Seitenanfang

Treue Seele

20.02.2013, 17:10

Ich bin nicht ganz sicher, ob ich dich richtig verstanden habe, daher führe ich nochmal kurz auf, was ich deinem Text entnommen habe:

Du willst den Nutzer seinen Code innerhalb der Engine / des Editors schreiben lassen. Die Engine kümmert sich darum, den Nutzercode zu einem Plugin-Projekt zu verknüpfen und lässt Visual Studio das Ganze dann kompilieren
Prefabs sind in deinem Ansatz von der Engine automatisch generierte Klassen, basierend auf den vom Nutzer prototypisch erstellten Objekten. Ein Prefab erfüllt sozusagen die Aufgabe einer Factory, welches ein GameObject mitsamt Komponenten und Konfiguration erstellt.
Das endgültige Spiel verlässt sich auf die so generierte .dll Datei, Prefabs stellen also im Endprodukt den Knotenpunkt dar, über den Nutzercode aufgerufen wird.

Sofern ich das so richtig aufgenommen habe, würde ich dir eher davon abraten.

Zum einen halte ich es für keine gute Idee, den Nutzer Code innerhalb der Engine schreiben zu lassen, bzw. innerhalb des Editorsystems. In meinem Projekt Nullpunkt habe ich genau das getan, es erschien mir seinerzeit eine naheliegende Lösung zu sein, jedoch musste ich schnell feststellen dass die Nutzerfreundlichkeit in vieler Hinsicht darunter leiden musste. Ich verwendete eine .Net Library mit Scintilla Bindings um an einen im Gegensatz zur WinForms Variante halbwegs vernünftigen Texteditor zu gelangen, aber trotz aller so erkauften Annehmlichkeiten blieb der Editor Meilenweit hinter der Visual Studio IDE zurück. Es endete damit, dass ich größere Skripte per CopyPaste zwischen Visual Studio und meinem eigenen Editor hin und her kopierte, um wenigstens Intellisense zur Verfügung zu haben.
Wenn das Ergebnis mehr Ecken und Kanten haben wird als das Original, dann ist es besser, das Rad nicht neu zu erfinden. Auch innerhalb der Unity Engine arbeite ich persönlich lieber mit Visual Studio als mit deren IDE Neuschöpfung. Aus diesem Grund habe ich mich für Duality entschieden, mich ganz klar auf Visual Studio als externe IDE zu verlassen und anstatt etwas neu zu basteln lieber die Kommunikation zwischen beiden zu verbessern.

Was deine Ausprägung von Prefabs angeht würde ich sagen, dass du dazu keine Codegenerierung brauchst. Prefabs lassen sich wunderbar auf Datenebene abbilden, auch Duality hat ein Prefabsystem und tut genau das. Zum Instantiieren von Nutzerkomponenten brauchst du in .Net generell auch keine Factories wie man sie aus C++ kennt (falls du daran dachtest), da Reflection hier wirklich gute Dienste leistet. Die jeweilige Assembly nach den entsprechenden Typen durchsuchen und dann anschließend entweder einen Konstruktor aufrufen oder die statische Activator.CreateInstance Methode nutzen. Das Ergebnis dann noch in irgendwas casten, womit du was anfangen kannst und fertig

Natürlich kann man es genausogut auch anders machen. Soll nur heißen: Es wäre nicht notwendig, sich so viel Aufwand zu machen wie dein Ansatz den Anschein macht. Ausprobiert hab ichs aber nicht. Siehst du da bestimmte Vorteile, die man mit einem Ansatz auf Datenebene nicht hat?

In Duality läuft das ganze im Prinzip so ab wie du sagtest, allerdings spielt das Editorsystem dabei eine größere Rolle. Der Editor bereitet automatisch eine Visual Studio Solution vor und konfiguriert sie Projektspezifisch - so ist es beispielsweise möglich aus VS heraus die Plugin Dll per "Run and Debug" Button direkt aus Visual Studio heraus zu starten. In Wirklichkeit wird dabei natürlich das Spiel gestartet welches das Plugin im Hintergrund lädt und so für den am Spiel hängenden Debugger verfügbar macht. Darüber hinaus erkennt der Editor jederzeit, wenn Plugin Dlls neu gebaut werden und lädt die entsprechenden Plugins zur Laufzeit neu - man kann also auch am Code herumbasteln während das Spiel in der Editorsandbox läuft.
Für bestimmte Aktionen wie "Neues Projekt erstellen" kann der Editor auch auf Visual Studio zugreifen, um beispielsweise ein Solution File als Ganzes zu kompilieren. Dein eigener Ansatz klingt ein wenig so als hättest du genau das vor - falls du ein Codebeispiel dazu suchst, du findest ein paar Zeilen dazu in EditorHelper.cs, Methode "CreateNewProject" in etwa Zeile 340.

Dass CorePlugin und die Nutzerkomponenten bei Duality in keinem direkten Zusammenhang stehen hast du schon richtig gesehen.

Ersteres dient als Schnittstelle für die Implementierung globaler Logik (Initialisieren externer Libraries, etc.), letzteres erfüllt eher den Zweck objektlokaler Logik.

Zum Seitenanfang

Supermoderator

Wohnort: Wickede

Beruf: Softwareentwickler

20.02.2013, 18:03

Im Prinzip möchte ich nichts groß anderes als du beschreibst. Ich hatte nicht vor einen eigenen Code Editor zu schreiben, sondern hatte geplant wie Unity dafür einen externen zuzulassen. Normalerweise installiert Unity ja Monodevelop mit. Das ist vermutlich der Editor den du mit intern meintest. Dafür wollte ich mich zunächst einfach auf Visual Studio festlegen, so wie es bei dir ja wohl auch gemacht wurde. Ansonsten hast du eigentlich richtig verstanden was ich vor habe. Zu den Factories. Ich möchte ja möglichst im Editor ein Prefab erstellen können und diesen dort direkt zusammen bauen. Dafür möchte ich nicht selbst in den Code gehen. Soll heissen, die dll weiß erst mal nichts von diesem Prefab. Selbiges mit Szenen. Ich bastel im Editor eine Szene zusammen. Im Code steht davon ja noch nichts. 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. In Unity Begriffen gesprochen

Von mir aus könnte man auch sagen, womit das Spiel beginnen soll. Dafür könnte ich natürlich auch wieder eine Configdatei anlegen, da stellt sich mir nur die Frage wie aufwendig es ist diese ganzen Daten zu erstellen, zu verwalten und zu laden. Einfacher wäre ja an sich eine Klasse zu generieren die möglicherweise eine Funktion wie "GetStartScene()" oder sowas liefert. Darin ist dann der Code vorhanden, welcher die Szene zusammen baut und fertig stellt.
Mit solchen Daten musst du ja auch irgendwie umgehen. Wenn du keinen Code generierst, dann musst du ja irgendwelche anderen Dateien generieren, welche dann vom Spiel geladen und interpretiert werden können. 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

Wenn jetzt aber zum Beispiel jemand einen Client für ein Netzwerkspiel damit schreibt und die Spieler ohne weiteres auf Daten, Komponente, Skripte etc zugreifen können, dann kann das schon zu Problemen führen. 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.
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.

„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

Zum Seitenanfang

Treue Seele

20.02.2013, 18:35

Zitat von »Schorsch«

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.

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.
Stell dir vor, der Nutzer schreibt in seinem Plugin eine eigene Komponente, vielleicht zu Debugzwecken, bastelt einen Level und entfernt die Komponentenklasse wieder aus dem Plugin. Wäre jetzt schlecht, wenn plötzlich alles den Bach runter geht, weil eine Typreferenz nicht mehr aufgelöst werden kann. Selbes Problem ergibt sich wenn sich Objekte grundlegend verändern. Das eigene Datenformat hat den Zweck, genau solche Fälle abzufangen und sich insgesamt so robust wie möglich zu verhalten. Funktioniert nicht absolut immer - aber deutlich besser als es die .Net Serialisierungsmethoden anbieten konnten.
Wie würdest du mit deinem Factory-Ansatz und der dynamischen Codegenerierung auf solche Fälle reagieren? Ich stelle mir vor, dass du dann entweder Assembly Ladefehler oder aber Compilerfehler im generierten Code bekommst - vermutlich würde es dort ebenfalls einen gewissen Arbeitsaufwand bedeuten, darauf zu reagieren.

Achja: Die Startszene ist übrigens tatsächlich das einzige (wesentliche) Datum, was Duality in einer Configdatei abspeichert - als Dateipfad, von dem die zugehörige Ressource geladen wird. Mehr braucht man eigentlich nicht.

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

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

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.

Kannst es dir gerne angucken, nebenan ist auch ein etwas älterer Thread dazu. Zum selbst ausprobieren: Einmal SVN Checkout und kompilieren, DualityEditor-Projekt starten und im View-Menüpunkt einfach mal alles aufmachen und 'n bisschen anordnen. Die fertig gepackten Downloadversionen in der Google Code Downloadsektion sind leider etwas veraltet. Die würde ich nicht mehr empfehlen.

Ansonsten: Das ganze ist nicht umsonst Open Source, wenn dir der Source Code bei deinem eigenen Projekt weiterhilft um so besser.

Natürlich wärs für mich aber auch interessant auch andere oder modifizierte Ansätze in Aktion zu sehen. Fachliche Diskussionen können ja durchaus einen gewissen Lerneffekt haben.

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.

Im Kontext eines Netzwerkspiels oder Anti Cheat Vorkehrungen stimmt das - aber gleichzeitig legst du damit Moddern Steine in den Weg. Es gibt viele Spiele, die ohne die Möglichkeit des Moddings nur halb so gut gewesen wären. Insofern kann es durchaus eine gute Idee sein, wenn das Endprodukt die Möglichkeiten bietet, das Spiel in größerem Umfang zu bearbeiten. Ich muss klar sagen, ich bin kein Netzwerkprogrammierer, die meisten der sicherheitstechnischen Bedenken sind mir daher fremd - aber im Zweifel würde ich dem Nutzer lieber ein offenes System bieten, das ihn in der Entfaltung seiner Kreativität unterstützt als ein geschlossenes, das eben für Cheater im MP etwas schwerer zu knacken ist.

Zum Seitenanfang

Supermoderator

Wohnort: Wickede

Beruf: Softwareentwickler

20.02.2013, 18:59

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. Im Prinzip würde eine Factory bei mir in etwa so arbeiten:

C#-Quelltext

public GameObject CreateGameObject(String type)
{
    GameObject result = new GameObject();
    if(type == "type1")
    {
        result.AddComponent(Component1);
        result.AddComponent(Component2);
    }
    return result;
}

Das ist hier natürlich sehr sehr stark vereinfacht aber sollte das Prinzip erklären. Ich habe eine Methode über welche ich ein bestimmtes Objekt erstellen kann. Diese Methode fügt mir das Objekt zusammen. Mein Spiel(das ladende Programm) selbst muss nicht wissen wie dieses Objekt aussieht, oder dass es diese Art erst mal gibt.
Wenn der Entwickler sich nun entschließt dem Prefab "type1" "Component2" zu entziehen, dann wird beim erstellen der dll die Methode anders zusammen gesetzt. In diesem Fall würde dem GameObject halt nur noch Component1 angehangen. Was natürlich Probleme bereiten würde, wäre wenn ein anderes Skript nun auf diese Komponente des Prefabs zugreifen will. Aber wenn sowas einen Fehler wirft, ist das schon ok. Der Fehler wäre ja vorhanden.
Das Moddingargument ist schon richtig. Darüber habe ich auch schon nachgedacht. Jedoch finde ich auch, dass man den Leuten so etwas nicht aufzwingen soll. Wenn man das möchte kann man es ja immer noch selbst verfügbar machen indem man eine Skriptsprache einbinden oder was weiß ich. Theoretisch könnte man auch das Projekt selbst freigeben, sodass es direkt mit dem Editor verändert werden kann. Möchte ich meine Daten jedoch lieber geheim halten, habe ich dazu keine Möglichkeit.
An sich bin ich selbst niemand, welcher seine Spieldaten groß schützen möchte. Ich denke ich werde mir dazu allgemein noch mal Gedanken machen, den Nutzen abwägen und vor allem den Aufwand abschätzen.
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.

„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

Zum Seitenanfang

Treue Seele

20.02.2013, 19:22

Zitat von »Schorsch«

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.

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.

Wie machst du das konkret? Du musst ja irgendwie in Erfahrung bringen wie das Objekt aussieht. Indem du deine eigene .dll reverse engineerst, oder den automatisch generierten Code der Create Methode? Das klingt nicht besonders praktikabel, zumal Visual Studio das für seinen visuellen WinForms Editor macht und damit regelmäßig scheitert. Diesem Negativbeispiel ausweichend müsstest du also irgendwo einen Bauplan hinterlegen, mit dem du den Code für dein Prefab neu generieren kannst. Dieser Bauplan wird vermutlich irgendwie in Datenform vorliegen, damit du ihn einfach und verlässlich lesen kannst. Wenn du Prefabs nun aber ohnehin doppelt hast - als generierten Code und als Bauplan in Datenform.. warum dann nicht gleich direkt auf Datenebene ausweichen, um die entsprechende Redundanz zu vermeiden?

Zitat

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

Zum Seitenanfang

Supermoderator