Indie 2D-Game-Maker (Arbeitstitel: Brickwork)

Hallo zusammen.

Nachdem ich schon zuvor 2 Threads erstellt hatte um ein wenig die Bereitschaft der Community aus zu loten habe ich mich nun schlussendlich entschieden mit einem Projekt zu beginnen um einen eigenen Game-Maker zu erstellen.

Der bisherige Arbeitstitel des ganzen lautet Brickwork und befindet sich zu diesem Zeitpunkt noch in einem sehr frühen Stadium. Das bedeutet allerdings auch, dass ihr im Moment noch viel Gelegenheit dazu habt die zukünftige Entwicklung der Software maßgeblich zu beeinflussen.
Ich habe im Moment bereits einiges an Konzepten zusammen geschustert und begonnen sie detailliert auf zu schreiben. Eigens dafür habe ich eine öffentliche Gruppe hier im Forum erstellt: http://www.multimediaxis.de/group.php?groupid=416
Alle die an diesem Projekt interessiert sind sind herzlich dazu eingeladen der Gruppe beizutreten und Kommentare und Anregungen zu den diversen Themen abzugeben.

Ich werde im Laufe der Entwicklung die Inhalte in der Gruppe ergänzen und den Fortschritt dokumentieren. Alle Änderungen und Meilensteine werden dort in passenden Themen festgehalten und veröffentlicht werden.
Zu diesem Zeitpunkt gibt es auch bereits einiges zu lesen; ich habe in der Gruppe bereits Auskünfte zu Spielobjekten und Scripten sowie dem Grundgerüst des Programms gegeben. Es wäre wirklich hilfreich falls ein paar Personen sich ein bisschen Zeit nehmen könnten diese Informationen zu lesen und mir Feedback zu geben.
Solch ein Projekt lebt von einer Community und der Mithilfe von Nutzern. Ich hoffe hier eine kleine Nutzerschaft finden zu können um dem Projekt ein Fundament zu geben.

Ich hoffe auf rege Teilnahme und bedanke mich für die Aufmerksamkeit.

Ich hab mir mal die Sachen durchgelesen. Im großen und ganzen hört sich das ok an, aber bei einen Punkt sehe ich Diskussionsbedarf:
Du möchtest sämtliche Makerdateien als Klartext speichern, mit der Begründung, dass es plattformunabhängig ist. Das ist aber als Grund nicht zutreffend, da auch Textdateien plattformabhängig sind (Zeilenumbrüche werden wahlweise mit \n,\r oder einer Kombination aus beiden signalisiert). Auf der anderen Seite können auch Binärdaten auf verschiedenen Platformen genutzt werden, solange man das Programm hat, welches diese interpretieren kann.
In dem Zusammenhang wäre es auch sinnvoll zu überlegen, ob man nicht xml für die Datenstruktur benutzen sollte, wenn man unbedingt Klartextdateien benutzen möchte. XML ist standardisiert und relativ schnell erlernbar. Das Problem bei einer eigenen Datenstruktur ist der Designaufwand und die Tatsache, dass sich wirklich jeder diese Struktur selbst beibrigen muss (bzw. du dafür extra lange Dokumentationen erstellen musst). Bei XML können sich zumindest Leute mit Programmiererfahrung schnell darin einfinden.

Soweit ich weiß möchte Cornix seinen Maker ja gerade den Entwicklern ohne Programmiererfahrung zugänglich machen. Da wäre XML nicht so praktisch, wobei die Entwickler die zugrunde liegenden Strukturen natürlich auch nicht unbedingt kennen müssen.

Exakt wie Kelven es sagt.
XML ist ein anständiges und ordentliches Dateiformat, und als solches sehr kompliziert für Menschen, die sich nicht mit all den Klammern und Pfeilen und schrägen Strichen auseinandersetzen wollen.
Die Textdateien, welche ich verwende, sind sehr simple key-value Dateien oder einfach nur Token-Strings. Sehr viel einfacher kann man es eigentlich nicht machen.

Aber natürlich sind diese Textdateien nur Alternativen für das Editor GUI. Alles, was man mit den Textdateien einstellen kann, kann man auch direkt im Editor tun. Die Textdateien stellen lediglich die Möglichkeit zur Verfügung ein eigenes GUI dran zu hängen, beziehungsweise mit simpelsten Werkzeugen zu arbeiten wenn man es bevorzugen sollte.

Zitat:

---

Zitat von Kelven

Soweit ich weiß möchte Cornix seinen Maker ja gerade den Entwicklern ohne Programmiererfahrung zugänglich machen. Da wäre XML nicht so praktisch, wobei die Entwickler die zugrunde liegenden Strukturen natürlich auch nicht unbedingt kennen müssen.

---

Nein, du hast mich nicht verstanden. Wenn er eine eigene Datenstruktur schreibt, muss jeder diese Datenstruktur lernen. Bei XML haben zumindest Leute mit Vorkenntnissen weniger einarbeitungsprobleme. Und ganz ehrlich: XML ist nicht schwer. Man hat vielleicht keine Übrung drinne, aber selbst jemand ohne Programmiererfahrung kann eine XML verstehen. Dazu kommt, dass es bereits zahlreiche XML Tools gibt, die man dann auch als Alternative für den Maker benutzen könnte (was ja auch ein Argument von Cornix ist). Ich möchte hier vorsichtshalber auch nochmal betonen: Mir geht es um die Datenstruktur, nicht um die Sprache der Scripte. Ergo, Kelven, ein Entwickler der mit dem Tool arbeiten, wird sich auch nicht mit XML auseinandersetzen müssen.

Du hast natürlich vollkommen Recht, dass XML sehr wohl angebracht wäre an dieser Stelle. Aber nocheinmal, bei dem Umfang an Daten von dem wir hier reden sehe ich es im Moment nicht als nötig.
Wenn eine Datei aus 10 Wörtern (oder weniger) besteht, dann wäre XML an dieser Stelle ein wenig übertrieben. XML ist ein sehr gutes Werkzeug, aber ich werde nicht einen Bulldozer kaufen um einen Kieselstein zu beseitigen.
Vielleicht werde ich am Ende noch wechseln, vielleicht wird es sich ja herausstellen, dass die Dateien in ihrem Umfang wachsen werden; vielleicht kann man auch einfach beides als Alternativen zur Wahl stellen. Das muss sich alles noch zeigen.

Zitat:

---

Zitat von Cornix

Du hast natürlich vollkommen Recht, dass XML sehr wohl angebracht wäre an dieser Stelle. Aber nocheinmal, bei dem Umfang an Daten von dem wir hier reden sehe ich es im Moment nicht als nötig.
Wenn eine Datei aus 10 Wörtern (oder weniger) besteht, dann wäre XML an dieser Stelle ein wenig übertrieben. XML ist ein sehr gutes Werkzeug, aber ich werde nicht einen Bulldozer kaufen um einen Kieselstein zu beseitigen.
Vielleicht werde ich am Ende noch wechseln, vielleicht wird es sich ja herausstellen, dass die Dateien in ihrem Umfang wachsen werden; vielleicht kann man auch einfach beides als Alternativen zur Wahl stellen. Das muss sich alles noch zeigen.

---

Gut, das ist ein nachvollziehbares Argument. Ich ging eher von wenigen, komplexen Daten für den Maker aus.

@Lares Yamoir
Ja, ich hab unter dem Speichern etwas anderes verstanden, als gemeint war, nämlich dass ein Klickcode von der Engine in Klartext übersetzt und abgespeichert wird, aber so wie ich jetzt Cornix' Postings verstehe, ist die Scriptsprache der eigentliche Code.

@Cornix
In welcher Sprache möchtest du deinen Maker eigentlich schreiben?

Sowohl Editor als auch RE werden in Java geschieben. Für Grafik wird ein OpenGL-Binding verwendet (wahrscheinlich LWJGL) und für Musik und Sound ein OpenAL-Binding (auch LWJGL).

Die Scripte werden tatsächlich als Klartext gespeichert, zumindest für den Editor. Damit das Ganze dann gespielt werden kann müssen die Scripte in einen Byte-Code übersetzt werden wofür dem Editor ein Compiler beiliegt. Das hat nicht nur offensichtliche Performance- und Speicherplatzvorteile, sondern hilft auch dabei Fehler in den Scripten frühzeitig zu entdecken und darauf hinzuweisen, als auch als Form der Kryptografie für all diejenigen, welche ihre Scripte nicht mit der Welt teilen wollen.

Nur als kleine Information am Rande: Ich habe diesem Beitrag ein .zip-Paket hinzugefügt. Dieses .zip Paket enthält einige Beispiel-Daten, welche ich zum Testen des Systems verwende.
Alle Komponenten, Objekt-Typen und Scripte in diesem Paket können bereits korrekt von dem Editor geparst werden. Die Syntax ist selbstverständlich noch nicht final.
Die Ordner können beliebige Namen haben, die Dateien dürfen in beliebigen Ordnern liegen. Der Editor erkennt alle Dateien (in der gesamten Ordnerhierarchie des Projekts) automatisch anhand ihrer Dateiendung.
Alle Dateien sind simple Text-Dateien, unabhängig von der Endung. Alle Dateien mit einer Endung, die der Editor nicht erkennen kann, werden ignoriert. Alle Dateien können Kommentare beinhalten, welche mit dem Hash-Zeichen (#) beginnen. Jede Form von Whitespace wird ebenfalls ignoriert.

Zitat:

---

Zitat von Cornix

Nur als kleine Information am Rande: Ich habe diesem Beitrag ein .zip-Paket hinzugefügt. Dieses .zip Paket enthält einige Beispiel-Daten, welche ich zum Testen des Systems verwende.
Alle Komponenten, Objekt-Typen und Scripte in diesem Paket können bereits korrekt von dem Editor geparst werden. Die Syntax ist selbstverständlich noch nicht final.
Die Ordner können beliebige Namen haben, die Dateien dürfen in beliebigen Ordnern liegen. Der Editor erkennt alle Dateien (in der gesamten Ordnerhierarchie des Projekts) automatisch anhand ihrer Dateiendung.
Alle Dateien sind simple Text-Dateien, unabhängig von der Endung. Alle Dateien mit einer Endung, die der Editor nicht erkennen kann, werden ignoriert. Alle Dateien können Kommentare beinhalten, welche mit dem Hash-Zeichen (#) beginnen. Jede Form von Whitespace wird ebenfalls ignoriert.

---

Und was ist, wenn eine Datei korrupt ist?
Das ist ja grad der Vorteil von XML, dass man die Dateien validieren kann.

Ich versteh sowieso nicht, wieso nicht XML verwendet wird? Wieso wird immer wieder das Rad neu erfunden, anstatt bestehende Techniken zu nutzen? Muss der Entwickler dann die Textdateien selber schreiben?
Wenn die über eine GUI erzeugt werden, es ist für den Entwickler doch eh egal, welches Format die Dateien haben, da er nie in diese Dateien reinschauen wird.
Ich mein selbst das Open Ofice XML Format von Microsoft ist nichts weiter, als XML-Dateien, die in ein Zip-File zusammengepackt werden, und man braucht dennoch keine Kenntnisse über XML, um Word oder Excel bedienen zu können. Oder musste jemals einer, der mit Excel oder Word gearbeitet hat, erstmal ein Tutorial über XML-Dateien lesen? Und ganz ehrlich, die paar Bytes, die die Dateien nun größer werden, machen den Kohl nun auch nicht fett. Dafür hast du ein mächtiges Werkzeug zur Hand.

Man kann auch Objekte direkt in ein Stream umleiten und speichern. Dann würde man sich sogar das Konvertieren in ein anderes Format sparen, und man könnte es direkt mit einem Ein-Zeiler laden.

Zitat:

---

Zitat von Whiz-zarD

Wenn die über eine GUI erzeugt werden, es ist für den Entwickler doch eh egal, welches Format die Dateien haben, da er nie in diese Dateien reinschauen wird.

---

In dem Fall brauchen wir dann auch hier nicht darüber reden. Immerhin geht es bei der Software nicht um einen hübschen GUI-Texteditor sondern um eine Software zur Spieleentwicklung.
Das nächste Thema wäre also?

Zitat:

---

Zitat von Cornix

In dem Fall braucht man dann auch hier nicht darüber reden. Immerhin geht es bei der Software nicht um einen hübschen GUI-Texteditor sondern um eine Software zur Spieleentwicklung.

---

Ja und? Sollen sie dann nun die Dateien selbst erzeugen, oder nicht?
Wenn sie von einer Software generiert werden, dann ist das Format für den Nutzer scheißegal, und dann kann man auch auf Standards zurückgreifen, die schon erprobt und getestet worden sind.
Falls die Nutzer diese Dateien tatsächlich selbst erstellen müssen, dann verfehlst du schon die Zielgruppe, die du eigens festgelegt hast.

Zitat:

---

Zitat von Whiz-zarD

Ja und? Sollen sie dann nun die Dateien selbst erzeugen, oder nicht?
Wenn sie von einer Software generiert werden, dann ist das Format für den Nutzer scheißegal, und dann kann man auch auf Standards zurückgreifen, die schon erprobt und getestet worden sind.
Falls die Nutzer diese Dateien tatsächlich selbst erstellen müssen, dann verfehlst du schon die Zielgruppe, die du eigens festgelegt hast.

---

Sollen tut man garnichts. Die Frage geht dabei nicht um das Sollen, die Frage geht um das Können. Es geht nichteinmal so sehr darum mehr Möglichkeiten zu schaffen sondern eher weniger Restriktionen auf zu erlegen.
Niemand muss das Dateiformat lernen und niemand muss diese Dateien erstellen. Aber jeder der will der kann, und nichts soll diese Person davon abhalten.

Zitat:

---

Zitat von Cornix

Sollen tut man garnichts. Die Frage geht dabei nicht um das Sollen, die Frage geht um das Können. Es geht nichteinmal so sehr darum mehr Möglichkeiten zu schaffen sondern eher weniger Restriktionen auf zu erlegen.
Niemand muss das Dateiformat lernen und niemand muss diese Dateien erstellen. Aber jeder der will der kann, und nichts soll diese Person davon abhalten.

---

Und dann kann man auch gleich was vernünftiges nehmen, anstatt sich da wieder selbst was auszudenken, was wohl möglich so flexibel wie eine Betonwand ist, und gewisse Fehler nicht abfängt.

Du musst bedenken, dass XML den Code wirklich ziemlich aufblähen kann, wenn es um viele kleinere Daten geht. Zum Validieren brauchst du auch wieder ein Schema, welches von der XML Datei referenziert wird. Wenn du jetzt also viele kleine Dateien hast, wo selbst im Falle eines Fehlers relativ schnell die Lösung innerhalb der entsprechenden Datei gefunden werden kann, profitierst du nicht ganz so stark von eben diesem Validierungsvorteil. Dem gegenüber hast du aber eine Datei die locker doppelt so groß ist. In den anderen Themen die Cornix zum Tool eröffnet hat, wurde ja bereits angesprochen, dass die Spiele relativ klein sein sollten. Für den Maker ist das auch sinnvoll, da man auf mobilen Geräten nicht ganz so viel Platz hat, wie auf dem PC. D.h. die Projektgröße sollte möglichst nur von den verwendeten Ressourcen des Entwicklers, nicht aber von den Tooldaten selbst abhängen. Hier macht sich ein eigenes Format dann natürlich besser, als XML.

Zitat:

---

Zitat von Lares Yamoir

Du musst bedenken, dass XML den Code wirklich ziemlich aufblähen kann, wenn es um viele kleinere Daten geht.

---

Ja, wow ... Dann ist vielleicht das Projekt 2 MB größer. Und nun? Muss man heute immer noch um jeden Byte kämpfen?

Zitat:

---

Zitat von Lares Yamoir

Für den Maker ist das auch sinnvoll, da man auf mobilen Geräten nicht ganz so viel Platz hat, wie auf dem PC. D.h. die Projektgröße sollte möglichst nur von den verwendeten Ressourcen des Entwicklers, nicht aber von den Tooldaten selbst abhängen. Hier macht sich ein eigenes Format dann natürlich besser, als XML.

---

Wofür gibt es SD-Karten mit mehreren GB speicher?
Sorry, aber sich um die Dateigröße sorgen zu machen, ist vollkommen irrelevant und drittrangig. Die Geräte haben heute massig Platz, und selbst die App-Stores sind voll von Spielen, die voll von XML-Dateien und sonstigen gedöns sind ... Meinst du, da macht sich irgendeiner Gedanken drum, dass seine XML-Dateien zu groß sind? An oberster Stelle sollte die Stabilität stehen, und nicht die Dateigröße.

Und meinst du, dass der Bytecode für die Interpretation seines Dateiformats 0 Bytes beträgt? Der Bytecode muss auch irgendwo gespeichert werden. Das muss man auch mit dazu rechnen.
Auch hier muss eine Validierung entwickelt werden, ansonsten wird es knallen, da man nicht davon ausgehen kann, dass die Dateien immer zu 100% korrekt sind.

Ich verstehe nicht ganz woher dieser Kreuzzug entsprungen ist. Immerhin wird hier gerade über eine völlig banale Bagatelle geredet. Wie genau der Editor die internen Daten auf der Festplatte speichert ist für 70% der Nutzer wohl recht uninteressant und in 99% der Fälle völlig belanglos.
Das ganze hat ja nichteinmal etwas mit der Funktionalität des Programms zu tun, sondern nur mit einem kleinen Feature-Am-Rande für die ausgefuchsten Nutzer mit besonders großer Neugierde.

Mir geht es bei der Wahl des Datenformates weder um die Größe, noch um die Komplexität des Codes auf meiner Seite. Mir geht es hierbei darum für eine völlig banale Angelegenheit eine Lösung zu wählen und mit der Entwicklung fort zu fahren. Ob das nun XML ist oder eine Key-Value Paarung ist für mich als Entwickler der Engine vorne und hinten das gleiche. Bei den Daten mit denen hier zu tun ist macht es auch wirklich keinen Unterschied.

Zitat:

---

Zitat von Whiz-zarD

Und dann kann man auch gleich was vernünftiges nehmen, anstatt sich da wieder selbst was auszudenken, was wohl möglich so flexibel wie eine Betonwand ist, und gewisse Fehler nicht abfängt.

---

Key-Value Paarungen sind ganz sicher nicht etwas, was ich mir ausgedacht habe. Das ist ein sehr vernünftiges und etabliertes Vorgehen, wie man es in vielen professionellen Anwendungen findet.
Es mag vielleicht nicht die Lösung deiner Wahl sein, das bedeutet aber nicht, dass jeder deiner Persönlichen Meinung zustimmt.

Wie ich schon vorher gesagt habe, XML ist ein gutes Format, und es wäre auch in diesem Fall angebracht. Das heist aber nicht, dass es die einzige oder beste Wahl ist. Und das heist auch nicht, dass es meine Wahl ist.
Es ist aber auf jedenfall nicht die Wahl, welche ich in diesem Moment getroffen habe.


Vielleicht gibt es aber noch Gesprächsbedarf in einem der eigentlichen Themen? Immerhin habe ich bei der Vorstellung über sehr viel mehr gesprochen als Klartext-Dateien.
Gibt es vielleicht Kommentare zum Objekt-System oder der Objekt-Typ / Objekt-Typ-Komponenten Datenbank?
Zu dem Aufbau der Scripte vielleicht?
Immerhin wollen wir uns hier nicht auf etwas so unwichtiges verkrampfen.

Zitat:

---

Zitat von Whiz-zarD

An oberster Stelle sollte die Stabilität stehen, und nicht die Dateigröße.

---

Hat auch nie jemand anderes behauptet. XML ist zwar eine sichere und einfach zu implementierende Lösung, das heißt aber nicht, dass eine speziell angefertigte Lösung schlechter sein muss. Klar sie ist aufwendiger, aber wenn man sich die Arbeit machen möchte...
Cornix hat sich anscheinend schon einige Gedanken zu dem Ganzen gemacht, und da er das Ganze entwickelt, kann er auch entscheiden wo er seinen Fokus drauf legt.
Ich denke es is eher sinnvoll, Alternativen aufzulisten, damit er sich selbst Gedanken darüber machen kann, als ihn von einer bestimmten Umsetzung zu überzeugen.

Zitat:

---

Zitat von Cornix

Gibt es vielleicht Kommentare zum Objekt-System oder der Objekt-Typ / Objekt-Typ-Komponenten Datenbank?

---

Finde ich nicht gut gelöst.
Die Komponenten und Typen sind ein und das selbe. Warum werden die in zwei unterschiedlichen Dingen unterteilt?

Bei deinem Beispiel mit:

Code:

---

Komponente: Person
Text name
Int alter

Komponente: Kämpfer
Int hp
Int mp
Int atk
Int def

Objekt-Typ: Held
Komponente Person
Komponente Kämpfer

---

Kann man Held nicht mehr weitervererben. Wenn ich jetzt unterschiedliche Typen von Helden z.B. HeldMensch und HeldZwerg haben möchte, dann muss ich jedes Mal für jeden Held auch eine neuen Typ anlegen, den ich alle Komponenten zuweisen muss. Möchte ich aber später allen Helden eine neue Komponente hinzufügen, dann ist Fleißarbeit angesagt, weil ich nun in jedem Helden-Typ die Komponente hinzufügen muss.
Es macht daher Sinn, es so zu vereinfachen, dass man nur mit Typen arbeitet, oder zumindest so, dass man auch Objekte erben kann, nur dann wären wir wieder beim Punkt, dass Komponenten und Objekten das selbe sind.

Komponenten sind einfache Klassifizierungen von Objekten; Typen sind konkrete Vorlagen.
Ich würde sicher nicht zustimmen, dass Komponenten und Typen das selbe sind. Wenn man als Vergleich eine Programmiersprache wie Java heranzieht würden Komponenten den Interfaces entsprechen und Typen den Klassen. Das ist zwar eng beeinander, aber nicht wirklich das selbe.

Was allerdings in meinem Aufbau wirklich (relativ) überflüssig ist sind die Typen.
Rein theoretisch könnte man Typen aus der Hierarchie entfernen und jedes Objekt würde Komponenten und Scripte enthalten.

Typen sind aber extra eingefügt um als eine Art Template zu dienen. Sie initialisieren Variablen (was Komponenten nicht können) und binden Scripte ein (auch wenn ein Script ohne ein Objekt keinen Sinn macht).

Man könnte natürlich die klassische Vererbung von alt bekannten Programmiersprachen einführen und erlauben, dass ein Typ einen anderen Typen erweitert. Das sollte in diesem Fall sogar mit Mehrfach-Vererbung funktionieren.
Das ganze könnte im Editor aber vielleicht ein wenig unübersichtlich werden und für Anfänger eher verwirrend, aber ich werde mir die Option offen lassen.
Danke für das Feedback.

Zitat:

---

Zitat von Cornix

Man könnte natürlich die klassische Vererbung von alt bekannten Programmiersprachen einführen und erlauben, dass ein Typ einen anderen Typen erweitert. Das sollte in diesem Fall sogar mit Mehrfach-Vererbung funktionieren.

---

Du weißt aber hoffentlich auch, was das Problem bei Mehrfachvererbung ist, und wieso dies auch fast keine Programmiersprache unterstützt, oder?
Das Implementieren von Interfaces ist nur ein Workaround, um so was ähnliches, wie eine Mehrfachvererbung realisieren zu können. Auch wenn man immer wieder Interfaces mit Mehrfachvererbung in Verbindung bringt (besonders in der deutschen Literatur), haben Interfaces primär nichts mit Mehrfachvererbung zu tun. Sie dienen dafür, Klassen klar zu definieren. Angenommen wir möchten Klassen entwickeln, die Daten in unterschiedliche Dateiformate speichert. Eine Klasse speichert die Daten ins XML-Format und eine andere Klasse ins CSV-Format. Mit einem Interface legen wir dann die Methoden fest, die beide Klassen implementieren sollen, damit wir beide Klassen auf die selbe Art und Weise ansprechen können. Klar kann dabei eine Klasse mehrere Interfaces implementieren, aber selbst das hat so seine Tücken. Angenommen wir haben zwei Interfaces, die den selben Methodenamen definieren, aber beide Methoden was anderes machen. In der Klasse selber steht uns aber nur eine einzige Methode zur Verfügung. Um der Sache noch eine Krone aufzusetzen, geht man noch einen kleinen Schritt weiter, und nennt dies das Diamond-Problem.

Es ist also falsch, ein Java-Beispiel für Mehrfachvererbung zu zeigen, weil Java so was überhaupt nicht kann, und auch kein Konzept dafür vorsieht. Wie gesagt, das Implementieren von Interfaces ist nur ein Workaround, und führt sogar zu Codeverdoppelung, die man aufgrund von Objektorientierung vermeiden möchte. Im Schlimmsten Fall führt diese Art von Mehrfachvererbung sogar zu Inkonsistenzen, wenn man anfängt die Methoden zu ändern. Dann müssen diese Methoden wieder überall geradegebogen werden, was je nach Komplexität schwierig werden kann.

Wenn ich sowas wie Mehrfachvererbung brauche (was aber bis jetzt noch nie vorgekommen ist), würde ich es wohl so realisieren:

Code:

---

public interface A
{
    void MethodeA();
}

public interface B
{
    void MethodeB();
}

public class AImpl implements A
{
    public void MethodeA()
    {
        ...
    }
}

public class BImpl implements B
{
    public void MethodeB()
    {
        ...
    }
}

public class C implements A, B
{
    private AImpl a = new AImpl();
    private BImpl b = new BImpl();

    public void MethodeA()
    {
      this.a.MethodeA();
    }

    public void MethodeB()
    {
      this.b.MethodeB();
    }
}

---

So kann ich wenigstens sicher sein, dass eine Methodenänderung in AImpl oder BImpl auch in C greift, da C hauptsächlich nur noch aus Wrapper-Methoden besteht. Das Diamond-Problem besteht aber weiterhin.

Ich bin mal gespannt, wie du diese Probleme lösen willst.

Edit:
Wenn man mein Beispiel für eine Mehrfachvererbung nun fortführt, dann kann man für C auch ein Interface bauen. In Java ist es z.B. möglich Interfaces zu erweitern:

Code:

---

public interface C extends A, B
{
    void MethodeC();
}

public class CImpl implements C
{
    private AImpl a = new AImpl();
    private BImpl b = new BImpl();

    public void MethodeA()
    {
      this.a.MethodeA();
    }

    public void MethodeB()
    {
      this.b.MethodeB();
    }

    public void MethodeC()
    {
      // tu was
    }
}

---

Wenn du deine Typen und Komponenten so implementierst, wie in meinen Code-Schnipseln, dann wirst du erkennen, dass die Typen und Komponenten das selbe sind. Beide haben ein Interface und eine Klasse, die das Interface implementieren, und du fügst die Klassen mittels Wrapper-Methoden zusammen.

Zitat:

---

Zitat von Whiz-zarD

Du weißt aber hoffentlich auch, was das Problem bei Mehrfachvererbung ist, und wieso dies auch fast keine Programmiersprache unterstützt, oder?

---

Mehrfachvererbung wird von sehr vielen Programmiersprachen unterstützt und das Problem der Mehrfachvererbung hat in meiner Datenstruktur keine Relevanz.
Da Objekt-Typen lediglich Attribute besitzen und keine Methoden gibt es auch kein Problem der Mehrfachvererbung.

Zitat:

---

Zitat von Whiz-zarD

Es ist also falsch, ein Java-Beispiel für Mehrfachvererbung zu zeigen, weil Java so was überhaupt nicht kann, und auch kein Konzept dafür vorsieht. Wie gesagt, das Implementieren von Interfaces ist nur ein Workaround, und führt sogar zu Codeverdoppelung, die man aufgrund von Objektorientierung vermeiden möchte.

---

Ich habe nirgends ein Java-Beispiel für Mehrfachvererbung gezeigt, wie kommst du darauf?
Außerdem glaube ich nicht, dass du Interfaces korrekt verstanden hast, zumindest nicht in dem Sinne wie sie allgemein üblich verstanden werden.
Interfaces sind genau was ihr Name aussagt, eine Schnittstelle in einem Programm. Wenn du versuchst sie für Mehrfachvererbung zu verwenden, dann machst du etwas falsch.
Wenn du eine Hierarchie einbauen willst, welche equivalent zur Mehrfachvererbung in Java wäre, dann musst du das Delegations-Pattern verwenden. Aber das driftet jetzt doch sehr stark in den Bereich des Off-Topic.

Zitat:

---

Zitat von Cornix

Ich habe nirgends ein Java-Beispiel für Mehrfachvererbung gezeigt, wie kommst du darauf?

---

http://www.multimediaxis.de/group.ph...576&do=discuss

Zitat:

---

Zitat von Cornix

Interfaces sind genau was ihr Name aussagt, eine Schnittstelle in einem Programm. Wenn du versuchst sie für Mehrfachvererbung zu verwenden, dann machst du etwas falsch.

---

Und wieso benutzt du sie für Mehrfachvererbung?

Zitat:

---

Zitat von Whiz-zarD

http://www.multimediaxis.de/group.ph...576&do=discuss

---

Wo ist hier ein Beispiel für Mehrfachvererbung? Ich sehe keines, und das Wort taucht auch nicht auf der Seite auf.

Zitat:

---

Zitat von Whiz-zarD

Und wieso benutzt du sie für Mehrfachvererbung?

---

Das tue ich auch nicht. Ich benutze keine Interfaces, ich benutze Objekt-Typ-Komponenten. Ich sagte lediglich, dass man ein equivalentes Java-Programm schreiben könnte, welches gleich funktioniert, falls man Komponenten mit Interfaces gleichsetzt. Außerdem werden sie dort auch nicht zur Mehrfachvererbung verwendet sondern als implizite Attribute.

Ich verstehe die einzelnen Komponenten bisher auch weniger als Klassen denn als Vorlagen, die den Zweck haben, dass der Entwickler den Code für ein bestimmtes Objekt oder Script nicht immer komplett neu schreiben muss. Oder hab ich das falsch verstanden?

Zitat:

---

Zitat von Kelven

Ich verstehe die einzelnen Komponenten bisher auch weniger als Klassen denn als Vorlagen, die den Zweck haben, dass der Entwickler den Code für ein bestimmtes Objekt oder Script nicht immer komplett neu schreiben muss. Oder hab ich das falsch verstanden?

---

Naja, nur irgendwas muss mit diesen Daten später geschehen, und da würde es sich anbieten, aus diesen Daten Klassen zu generieren, die dann in Bytecode übersetzt werden.
Oder wie soll das hinterher von statten gehen?

Das kann ich dir nicht sagen, ich hab noch nie einen Compiler gebaut.

Compiler? Ich dachte es geht um Java?

Der Übersetzer in Bytecode nennt sich auch Compiler ;)
http://de.wikipedia.org/wiki/Java_Development_Kit

Zitat:

---

Zitat von Kelven

Ich verstehe die einzelnen Komponenten bisher auch weniger als Klassen denn als Vorlagen, die den Zweck haben, dass der Entwickler den Code für ein bestimmtes Objekt oder Script nicht immer komplett neu schreiben muss. Oder hab ich das falsch verstanden?

---

Das ist so schon richtig. Komponenten sind lediglich gewisse Vorlagen zur Datenhaltung.

Zitat:

---

Zitat von Whiz-zarD

Naja, nur irgendwas muss mit diesen Daten später geschehen, und da würde es sich anbieten, aus diesen Daten Klassen zu generieren, die dann in Bytecode übersetzt werden.
Oder wie soll das hinterher von statten gehen?

---

Das bietet sich eher nicht an. Für diesen sehr limitierten Nutzen wäre es zwar auch möglich, aber aus meiner Sicht nicht sinnvoll soetwas zu tun. Nicht nur wegen dem überproportionalen Overhead, sondern vor allem auch wegen gängigen Design Paradigmen.
Die Daten werden auf andere Art und Weise verarbeitet.

Zitat:

---

Zitat von tuxtuxtux

Compiler? Ich dachte es geht um Java?

---

Java verwendet einen Compiler. Meistens sogar zwei: Einen um den Java-Code zu Java-Byte-Code zu kompillieren, und dann in der JVM einen Just-In-Time Compiler um den Java-Byte-Code in Maschinen-Code zu kompillieren. Der zweite ist zwar gängig aber optional da der Java-Byte-Code auch interpretiert werden kann.

Zu dem ganzen Java-Kram will ich mich jetzt eigentlich nicht äußern, aber ich will dir einfach viel Erfolg bei der ganzen Sachen wünschen. So ein "Game Maker" ist bei weitem nichts leichtes und Bedarf viel Überlegung und Refactoring imho. Schau dir auch andere Engines an, was die machen (Unity3D, Contruct, Game Maker etc). Ist immer gut wenn du dir praktisch Sachen abgucken kannst. Das Rad neu zu erfinden auch sehr schwer. Und da wir ja selber unsere eigene Engine gemacht haben und verwenden, hier ein kleiner Tipp: "Schau dir ruhig einige Sachen vom Maker ab". Der Maker hat einige tolle Sachen gemacht, die du eben beim Spiele entwickeln immer mal brauchst (Events with multiple pages, Storage of Values via Key/Value etc.).

Bin gespannt wie weit sich das entwickelt :)

Ich hab mir jetzt nicht den ganzen Thread genau durchgelesen, aber um das problem der mehrfachvererbung zu umgehen könnte man auch ein Entity-Component-System benützen.

Zitat:

---

Zitat von R.D.

Zu dem ganzen Java-Kram will ich mich jetzt eigentlich nicht äußern, aber ich will dir einfach viel Erfolg bei der ganzen Sachen wünschen. So ein "Game Maker" ist bei weitem nichts leichtes und Bedarf viel Überlegung und Refactoring imho. Schau dir auch andere Engines an, was die machen (Unity3D, Contruct, Game Maker etc). Ist immer gut wenn du dir praktisch Sachen abgucken kannst. Das Rad neu zu erfinden auch sehr schwer. Und da wir ja selber unsere eigene Engine gemacht haben und verwenden, hier ein kleiner Tipp: "Schau dir ruhig einige Sachen vom Maker ab". Der Maker hat einige tolle Sachen gemacht, die du eben beim Spiele entwickeln immer mal brauchst (Events with multiple pages, Storage of Values via Key/Value etc.).

---

Ja, das ist sicher ein sehr kompliziertes und schwieriges Unterfangen. Ich habe es mir auch vorher sehr sehr genau überlegt, ob ich mir wirklich all diese Arbeit machen möchte.
Aber ich denke, dass solch ein Projekt eine ganze Menge Potential hat; besonders wenn man bedenkt, dass sich ein ordentliches Produkt sogar international vermarkten lassen könnte.

Was den Vergleich zum RPG-Maker angeht so muss ich sagen, dass ich mit vielen "Features" des RPG-Maker sehr unzufrieden bin. Meiner Meinung nach wurde an mehreren Stellen nicht so sorgfältig gearbeitet wie es hätte getan werden können. Ich versuche vor allem eine sehr offene und dynamische Engine zu bauen und es den Entwicklern leicht zu machen auch andere Spiele als simple RPG's leicht zu erstellen.

Zitat:

---

Zitat von R.D.

Bin gespannt wie weit sich das entwickelt :)

---

Das bin ich auch.

Zitat:

---

Zitat von LordAntrax

Ich hab mir jetzt nicht den ganzen Thread genau durchgelesen, aber um das problem der mehrfachvererbung zu umgehen könnte man auch ein Entity-Component-System benützen.

---

Es gibt gottseidank kein Problem der Mehrfachvererbung in meiner Datenstruktur. Mehrfachvererbung ist in der Programmierung nur dann ein Problem, wenn eigene Methoden geschrieben werden können; das kann bei mir aber nicht passieren. Es werden nur Datenhaltungs-Container geschrieben, selbst die Scripte sind im Grunde nur delegierte Methoden-Objekte, ein Strategie-Muster wenn man so will.
Damit wird eine ganze Menge Ärger vermieden und die gesamte Struktur des Programms bleibt immer stabil.

Oh eine Sache die ich auch noch für wichtig halte. Falls du es noch nicht getan hast, würde ich dir raten ma ein richtiges Spiel zumachen. Nicht nur theoretisch sondern tatsächlich. Dadurch siehst du erst was so eine Engine braucht und was Ballast ist. Wie zeichnest du Teile einer Grafik? Welche Render Technologie will du verwenden (Ganz Ehrlich, wenn du nicht libGDX als Basis nutzt, wäre ich fast schon enttäuscht), wie verarbeite ich Sound (Midis in Java sind z.B. kein Ding das man mal eben "sich aus denken und gut vorplanen kann"). Wie speichere ich Werte damit sie global verfügbar sind? Wie sende ich Informationen über Veränderungen an verschiedene Modelle (Ja, MVC ist ein tolles Format für Spieleentwicklung, besonders weil man View und Control zusammenfassen kann). usw. usw.
Wie gesagt, sich das auszudenken ala: "Mh, wenn ich ein Spiel machen, brauche ich das und das..." kommt man nie auf die Sachen die man wirklich braucht. Auch wird das noch erschwert durch die Tatsache, das die Engine ja für 2D Spiele allgemein gelten soll. Kein leichtes Unterfangen sowas... :/
Viele Sachen kannst du abererledigen indem du dir einfach andere Engine anguckst. Auch am besten nicht nur Drag-and-Drop-Engines sondern auch, solche die nur als Render Engines oder minimaler Startpunkt dienen. Die haben oft Konzepte die ziemlich Klasse sind (impact.js *hust*).

@Maker
Für was der Maker wollte (2D RPGs erstellen), war er sehr gut in vielen Dingen. Klar war er nicht offen, aber er war dynamisch und ist es auch (und eigentlich in gewissen Maße auch offen, siehe XP usw.). Wie gesagt, sollte man immer das mitnehmen, was gut funktioniert hat. Und der Maker hat zumindest meiner Meinung nach einer tolle Sachen, die ich auch in anderen Engines immer mal wieder finde.

Das alles sind natürlich nur Tipps und Hinweiße, was du am Ende machst, sei dir überlassen :)