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

[Cornix]

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.

...

Das kannst du ruhig anders sehen, dagegen habe ich nichts. Deine Meinung entspricht dann in diesem Fall lediglich nicht meiner.

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.

...

Nun, man könnte lediglich eine Turing vollständige GUI-Code sprache erstellen, welche es erlaubt native Funktionen aufzurufen und schon hätte man es geschafft eine GUI-Programmierung zu ermöglichen, welche exakt genau so mächtig ist wie Ruby.
Das ist aber überhaupt nicht mein Ziel, ich will sie gezielt weniger mächtig machen damit gewisse Funktionen nicht missbraucht werden können.

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.

...

Da muss ich auch entschieden wiedersprechen.
Ein gewisser Grad an Logik ist jedem Menschen in die Wiege gelegt, dafür braucht man nichts zu lernen. Falls die Syntax wie folgt aussieht:

Code:

Falls Button A gedrückt
dann
öffne menü

dann wird dieses Programm wohl für jeden noch so grünen Anfänger verständlich sein.
Falls die Syntax jedoch wie folgt aussieht:

Code:

if ( keyboard.press?(0x66) )
{
    goto 42
}

Dann wird da wohl der ein oder andere seine schwierigkeiten haben damit klar zu kommen.
Du siehst, beide Code-schnipsel könnten möglicherweise das selbe machen, doch der erste Fall benutzt intuitive (und in diesem Fall auch deutsche) Sprache und Konstanten.
Das ist ein reiner Unterschied in Syntax und Programmierstil; die Logik bei beiden Fällen ist gleichsam trivial.

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.

...

Wie schon gesagt, ich habe nicht vor die gleichen Möglichkeiten zu bieten. C++ bietet weniger Möglichkeiten als Assembly, trotzdem benutzt niemand letzteres.
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.

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.

...

Ich glaube ein GUI-Code hat eine einfachere Möglichkeit sich selbst zu erklären als der einer interpretierten Scriptsprache.
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. 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.

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.

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 will ich zwar nicht ganz genau so, wie du es hier sagst, aber man sollte doch immer nach den Sternen greifen, wenn man sich schon die Mühe und Zeit nimmt.

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.

...

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.

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.
Wie ich schon sagte, mann kann das natürlich als etwas positives betrachten. Ich persönlich sehe es allerdings nicht als etwas positives.

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.

...

Ja, die Scripte von Enterbrain in den neueren Makern lassen manchmal zu wünschen übrig. Bei dem Ace ist es schon sichtlich besser geworden als es noch zu XP Zeiten war; das war ein ziemlicher Alptraum.
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.
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.

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.

...

Eigentlich gibt es keine Engine Diskussion, zumindest nicht in diesem Thread. Die ursprüngliche Idee scheint langsam abhanden zu kommen; meine Frage ist es, was ihr gerne an Features sehen möchtet.
Das bedeutet jedoch nicht, dass ich auch alles genannte umsetzen werde. (oder dass ich überhaupt irgendetwas umsetzen werde letzten Endes)
Es ist einfach eine lieb gemeinte kleine Diskussionsrunde zu eurem Traumfeatures.

[DNKpp]

Ich verweise dich mal hier drauf.
Hatte vor einiger Zeit selbst mal danach gefragt, vll bringt dich das ja weiter

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

[Cornix]

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.

...

Ich habe auch bereits gesagt, dass ich die Zielgruppe limitiere; ich sehe da kein Problem.

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?

...

Unbestreitbar ist wohl, dass man ein Spiel erstellen kann, aber sehr wohl bestreitbar ist, dass man nicht gerade das Spiel erstellen kann was man gerne erstellen will.

Englisch als Symbolbezeichner dient der Internationalisierung.

...

Sag bloß. Entschuldigung, das konnte ich mir nicht verkneifen.

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

...

Die Bezeichnung von Symbolen hat alles mit Syntax zu tun. Das ist die Bedeutung von Syntax.
Beim Programmieren gibt es gewisse Schlüsselwörter und Symbole; wie diese aussehen wird durch die Syntax festgelegt.

Ein größeres Beispiel würde ich auch gerne sehen. Wer weis, vielleicht wird es das eines Tages geben.

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.

...

Doppelmoral. Im Maker wird eben diese Schiene gegangen. Dir fehlt ein Feature im GUI-Code? Pech gehabt, lerne mit Ruby zu programmieren oder frag jemanden der es kann damit dieser es für dich tut.
Es ist niemals gut zu versuchen es jedem recht zu machen. Definiere zuerst deine Zielgruppe und dann erstelle ein Produkt für eben jene; das ist meine Devise hierbei.

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 erkenne keinen Kontext zur Diskussion.

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

...

Du hast es ja noch nicht gesehen, dann kannst du auch kaum zu diesem Zeitpunkt eine Aussage zu treffen. Dennoch lässt du die Frage offen wie es verständlicher wird wenn man eigene Scripte schreibt.

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.

...

Das finde ich auch. Zu schade, dass der Maker soetwas nicht bietet. Wenn der Script-Editor des Makers ein wenig besser wäre hätte ich wohl länger damit gearbeitet, aber es wurde auf Zeit schon grob lästig.

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.

...

Ich wüsste nicht wo hier der Zusammenhang besteht.
Ich habe ja nie behauptet, dass der GUI-Code genau so aussehen würde wie der Maker code.

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.

...

Das ist sogar ein sehr kompliziertes und kontroverses Thema. Ich wünschte es würden mehr Vorlesungen wie diese gehalten werden; zumindest hier in meiner Nähe.

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

...

Das mag sein; ich habe mir den Ace kaum mehr angeguckt nachdem ich von dem XP und VX ziemlich enttäuscht gewesen war.
Aber die alten Maker haben einen eigenen Haufen an Problemen unter denen sie leiden.

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.

...

Womit irre ich mich? Kannst du die Textpassage vielleicht einmal zitieren?
Ich erkenne nicht, an welcher Stelle ich etwas derartiges behauptet habe.

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.

...

Ich wüsste nicht, welches Feature jemals dafür gedacht gewesen ist schlechte Programmierung zu unterstützen. Das klingt höchst fragwürdig für mich, dass jemand soetwas überhaupt tun will.
Auf der anderen Seite ist Namespacing genau das was überall dafür verwendet wird.
In einer objekt orientierten Programmiersprache besitzt jede Klasse ihren eigenen Namespace an globalen Variablen, jedes Objekt seinen eigenen Namespace für private Variablen und jede Methode ihren eigenen Namespace für lokale Variablen. Das ist so ziemlich die einzige Lösung, welche dafür verwendet wird.

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

...

"Voll anpassbar" ist schwer zu definieren. Aber anpassbar sollte möglich sein.