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

[Cornix]

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.

[Lares Yamoir]

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.

[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.

[Cornix]

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.

[Lares Yamoir]

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.

[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.

[Lares Yamoir]

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.

[Kelven]

@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?

[Cornix]

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.

[Whiz-zarD]

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.

[Cornix]

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?

[Whiz-zarD]

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.

[Cornix]

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.

[Lares Yamoir]

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.