Zitat Zitat von Cornix Beitrag anzeigen
Der Maker geht meiner Meinung nach keinen wirklichen Weg.
[...]
Es ist inkonsistent ohne ersichtlichen Grund. Der Aufwand zum Implementieren wäre minimal, komplexer würde das Ganze dadurch auch nicht werden.
Sehe ich anders. Ich schätze bei den alten Makern 2k/2k3 wurde lediglich die Resonanz und der Erfindungsgeist der Community unterschätzt.

Die Entwickler gingen ursprünglich wohl nicht davon aus das jemand "show picture" für ein Menü missbrauchen würde. Ist aber auch relativ egal, da diese Maker schlichtweg veraltet sind, und zumindest für den 2k3 dank Cherrys DynPatch einiges möglich wurde.

Zitat Zitat von Cornix Beitrag anzeigen
Dann gibt es wiederum Event-Code mit gewissen Bedingungen und Aktionen, die allerdings bei weitem nicht alles abdecken, auch wenn es sehr einfach geworden wäre dies zu ermöglichen.
Ich glaube nicht dass es möglich ist alles was z.B. Ruby kann in eine GUI zu quetschen welche gleichermaßen die Programmierung vereinfacht und eine schnellere und flexiblere Arbeit ermöglicht als der Texteditor.

Zitat Zitat von Cornix Beitrag anzeigen
Das Interessante daran ist, dass das Programmieren sehr sehr simpel ist sobald man das Grundgerüst und die kryptische Syntax von Programmiersprachen ignoriert.
Da muss ich entschieden widersprechen. Die Syntax ist dass einfachste am Programmieren da man diese einfach auswendig lernen kann. Die Schwierigkeit liegt in der Logik, was sich sehr gut auch hier im Technikforum für den RM2k zeigt.

Zitat Zitat von Cornix Beitrag anzeigen
Die Idee hinter dem GUI-Code ist es, die komplizierten Gegebenheiten von Programmiersprachen sauber und ordentlich nach Außen an den Anwender zu bringen und die Hässlichkeiten zu verstecken. Außerdem werden alle Möglichkeiten aufgelistet und kategorisiert und direkt mit einer Beschreibung versehen.
Zudem wird die Möglichkeit für Programmfehler vermindert.
Die Möglichkeiten welche dir eine Script/Programmiersprache bietet sind aber zu viele als dass du sie in einer GUI unterbringen könntest ohne diese komplizierter als die eigentliche Scriptsprache zu machen. Microsoft hat das in Access versucht und ist (meiner Meinung nach) glorreich gescheitert.

Dazu kommt dass eine GUI sich auch nicht selbst erklärt, vor allem wenn sie so komplex ist dass sie eine ganze Scriptsprache ersetzen kann.

Zitat Zitat von Cornix Beitrag anzeigen
Wie leicht oder kompliziert das Endprodukt wird hängt stark davon ab wie viel Mühe man sich damit macht es "ordentlich" zu gestalten. Es sollte möglichst intuitiv und selbsterklärend sein. Dann können auch Anfänger sehr schnell lernen damit umzugehen.
Dein Wunsch wäre also folgendes:

Eine GUI welche eine komplette Scriptsprache ersetzt, die Entwicklung dabei vereinfacht und dennoch intuitiv und unkompliziert bedienbar bleibt? Dazu kann ich nur ganz ehrlich sagen: Wenn du das hinbekommst würde ich an deiner Stelle sofort mit der Entwicklung anfangen, denn damit könntest du einen Haufen Geld verdienen. Es hat schon seine Gründe warum auf Script bzw. Interpretersprachen zurückgegriffen wird um dynamische Aspekte in Programmen/Spielen zu realisieren.

Zitat Zitat von Cornix Beitrag anzeigen
Was die RPG-Maker machen ist es Features in Form von Event-Commands abzulösen und die Arbeit auf den Endnutzer zu überwälzen. Die Entwickler von Enterbrain sind nicht motiviert genug um tiefergehende Event-Commands zu implementieren und geben daher dem nutzer den Source-Code und sagen ihm "da, mach dir selbst.".
[...]
Ich stimme dieser Taktik schlichtweg nicht zu.
Das klingt nun arg nach Ich-Bin-Dagegen-Stammtischgerede, vor allem der letzte Absatz.

Ich mag so etwas nicht weil Diskussionen dazu neigen sich dran aufzuhängen wenn die Argumente dünn werden aber: Nehmen wir mal Pixelmovement als Beispiel. Du könntest nun hingehen und eine GUI entwerfen welche es dem Entwickler ermöglicht Schrittweite, Tilegröße und Frameanzahl der Laufanimation sowie den Multiplikator nach wie viel Spiel-Frames die Animation zum nächsten Frame wechselt einzustellen. Dazu kommt natürlich ein Hit-Box Editor für jedes popelige Tile, da dir die Schrittweite ja unbekannt ist. Lässt du auch nur ein Element davon weg kann deine GUI nicht mehr dass leisten was irgendeiner von hunderten Entwicklern irgendwann brauchen könnte.

Du gewinnst an Flexibilität aber erhöhst die Komplexität und den Arbeitsaufwand enorm, und bist dennoch nicht in der Lage alle möglichen Ideen der Entwickler abzudecken, da deine GUI eben nur die Optionen bietet an welche du als Entwickler gedacht hast.

Die Alternative wäre ein GUI Editor welcher es dir ermöglicht ein Ruby-Script genau so zu schreiben wie mit einem Texteditor. Das Problem was dann entsteht: Wozu noch die GUI? Um eine Syntax zu verstecken deren Lernaufwand den der GUI kaum übersteigt und dazu noch Geschwindigkeitseinbußen durch diverse Mausklickerei hinzunehmen? Ähm, nö. Würde ich als Entwickler niemals anrühren.

Zitat Zitat von Cornix Beitrag anzeigen
Wenn man ordentliche, typisierte Variablen definieren könnte, und zwar lokal und global, dann würde das ganz anders aussehen.
Das ändert an Kompatiblitätsproblemen gar nichts. Ganz besonders "globale Variablen" machen es nur noch schlimmer. Die Rubyscripte von EB sind auch voll davon, was mich regelmäßig zur Weißglut treibt.

Zitat Zitat von Cornix Beitrag anzeigen
Ich habe nicht gesagt, dass ein Programmierer sich lediglich eine Grafikengine nehmen soll.
[...]
Du hast bereits ein komplettes fertiges Spiel in manchen Fällen. Dieses kannst du dann ganz einfach mit neuen Resourcen und zusätzlichem Code bearbeiten.
Du sagtest warum ein "richtiger" Programmierer zum Maker greifen sollte wenn es doch die Top-Level-Programmiersprachen-Engines gibt, als Gegenargument zur Implementierung einer Scriptsprache, kommst nun aber mit kompletten Spiele-Engines um die Ecke. Wenn ich mir deine Beispiele so ansehe, insbesondere dieses mit "ein fertiges Spiel welches nur noch angepasst werden muss" fällt der Maker selbst in den Bereich der Spiele-Engines, womit die Diskussion arg in eine Engine-Diskussion abzudriften droht.