Was wäre euch wichtig an dem "perfekten" Maker?

[Caine Luveno]

ich will sie gezielt weniger mächtig machen damit gewisse Funktionen nicht missbraucht werden können.

...

Damit limitierst du die mögliche Zielgruppe deines Produktes. Deswegen finde ich die Entscheidung Pro-Scriptsprache von Enterbrain eben gut. Das erklärte Ziel des RPG Makers dürfte es gewesen sein jedem ohne Programmierkenntnisse das Erstellen eines Spiels zu ermöglichen.

Dies ist, sowohl mit den alten als auch den neuen Makern, unbestreitbar gelungen. Regelmäßig taucht hier die ein oder andere Perle auf, von Menschen welche mehr als if-then-else nicht verstehen. Zeitgleich ist aber auch das Gegenteil möglich. EB gewinnt, die Spieler gewinnen, die Community gewinnt. Wo ist das Problem?

Da muss ich auch entschieden wiedersprechen.

...

Englisch als Symbolbezeichner dient der Internationalisierung. Die Bezeichnung von Symbolen hat aber nichts mit Syntax zu tun, womit deine Beispiele sowieso komplett obsolet sind. Ich würde gerne mal ein komplexes Map-Transition oder Pixelmovmeentscript in deinem Beispiel 1 verfasstem Code sehen *hust*.

Es geht nicht um Möglichkeiten beim Programmieren, es geht darum, dass man das tun kann was man will.
Alles was man nicht will braucht man auch nicht tun zu können. Kannst du zufälligerweise mit diesem Programm nicht das tun was du willst, dann hast du schlichtweg das falsche Programm gewählt.

...

Realitätsfremd. Für kommerzielle Produkte ist eine Philosophie a la "dir fehlt ein Feature? Pech gehabt" der Todesstoß. Selbst kostenlose Produkte werden versuchen "ihrer" Community im Rahmen des angestrebten Ziels entgegen zu kommen. Um absolute Featureüberlastung zu vermeiden bedient man sich dann eben der Scriptsprache.

Wenn es danach ginge ob ein Programm 100% alles exakt so macht wie gewünscht bleibt nur: selber machen oder für teuer Geld Individualsoftware in Auftrag geben. Selbst bei professioneller Software muss man Abstriche machen, so ziemlich immer und überall. Und sogar größere Konzerne (Microsoft und der Start-Button) müssen auf Ihre Konsumenten hören und im Zweifel nachbessern.

Ich glaube ein GUI-Code hat eine einfachere Möglichkeit sich selbst zu erklären als der einer interpretierten Scriptsprache.

...

Alleine die vielen Begrifflichkeiten welche du mit Alltagswörtern erklären musst machen das Ding schon unverständlich.

Ich kann bei dem GUI-Code zu jedem Befehl eine Beschreibung hinzufügen, welche automatisch angezeigt wird, sobald der Nutzer mit der Maus drüber fährt.

...

Professionelle IDEs haben dafür Shortcuts welche das Selbe leisten. Mouseover ist beim Entwickeln wohl die größte Hölle die du jemandem beim Code-Lesen antun kannst.

Sobald man dem Nutzer erlaubt eigenen Code zu schreiben verliert man die Möglichkeit ihn dazu zu zwingen alles ausreichend zu dokumentieren und mit Kommentaren zu versehen.

...

Vielleicht gebe ich dir mal eins meiner alten Menüscripte aus dem 2k3 welches nicht einen Kommentar enthält und mehr als 1000 Zeilen Code benötigt. Ggf. siehst du dann was ich meine warum GUI-Code die von dir genannten Vorteile eben nicht hat. Alternativ schau dir Lachsens Scripte in Velsarbor an.

Das heist nicht, dass es unmöglich ist ein Script zu schreiben, welches sich selbst erklärt; es heist lediglich, dass ich der Meinung bin, dass es mit einem GUI-Code einfacher ist ihn selbsterklärend zu machen.

...

Dann hast du noch nie wirklich komplexen Code gesehen, Sorry.

Ich habe vor kurzem eine sehr interessante Vorlesung von einem renommierten Soziologieprofessor hören dürfen, in welcher eine These angesprochen wurde die besagt, wie die Gesellschaft sich heutzutage immer weiter in die Richtung bewegt, dass der Kunde zu einem unbezahlten Arbeiter für den Produzenten wird.
Möbel von Ikea selbst zusammenbauen, automatische Kassen im Supermarkt, online Feedback und Reviews erstellen, etc.

...

Das ganze ist ein zweischneidiges Schwert. Die Balance ist wichtig, und eine Opt-Out Möglichkeit für Leute die das nicht wollen, und das ist gegeben.

Im gleichen Sinne entwickelt Enterbrain die Maker immer weiter in die Richtung lediglich ein Grafik/Audio-Bündel zu sein, welches mit einer Ruby basierten Game-Engine mit kommt. Dabei werden die eingebauten Features immer weiter abgebaut, und dafür mehr flexibilität für trainierte Nutzer ermöglicht.

...

Ich sehe im VX Ace einen deutlichen Zugewinn an Built-In Features im Vergleich zum 2k/2k3.

Aber globale Variablen haben damit nichts zu tun. Soetwas gibt es seit je her und zwar in jeder Programmiersprache. Es ist nunmal so, dass ein Programm komplett ohne globale Elemente nicht (oder nur schwer) auskommt.

...

Da irrst du dich. In vielen Sprachen ist es dank OOP möglich Code zu schreiben welcher nicht eine globale Variable benötigt, sondern lediglich einen globalen Einsprungspunkt, welcher sowieso nur einmal aufgerufen wird. Und selbst in prozedualen Sprachen ist es für geübte Programmierer kein Problem globale Variablen zu vermeiden.

Es führt allerdings, bei korrekter Handhabung, auch bei weitem nicht zu so vielen Problemen wie man denken mag. Jeder Entwickler verwendet seinen eigenen Namespace und Kollisionen sind so gut wie dahin sofern jeder ordentlich arbeitet.

...

Namespacing kaschiert das Problem und ist primär dafür gedacht doppelte Klassennamen/Funktionsnamen in modularen Anwendungen zu vermeiden und nicht schlechte um Programmierung zu unterstützen.

Es ist einfach eine lieb gemeinte kleine Diskussionsrunde zu eurem Traumfeatures.

...

Wenns danach geht:
- Ein voll anpassbares AKS (nahezu unmöglich da den "richtigen" Nerv zu treffen ohne Anpassungen des Codes durch den Nutzer)