Sehe ich anders. Ich schätze bei den alten Makern 2k/2k3 wurde lediglich die Resonanz und der Erfindungsgeist der Community unterschätzt.Zitat von Cornix
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.
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.
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.
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.
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.
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.
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.
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.
Zitieren