Je mehr Möglichkeiten du dem Anwender gibst desto komplizierter wird das Programm. Der RPG Maker geht da schon einen guten Mittelweg.
...
Leider kann ich nicht zustimmen.
Der Maker geht meiner Meinung nach keinen wirklichen Weg. Die meisten Features scheinen zufällig gewählt worden zu sein und lassen in meinen Augen nicht auf überhaupt irgendein Muster schließen.
Auf der einen Seite kann man Variablen als Indizes auf andere Variablen nutzen, ähnlich zu Pointern in Arrays. Auf der anderen Seite ist dieses Feature allerdings nur in wenigen Bereichen möglich, zum Beispiel nicht für Pictures oder dergleichen.
Es ist inkonsistent ohne ersichtlichen Grund. Der Aufwand zum Implementieren wäre minimal, komplexer würde das Ganze dadurch auch nicht werden.
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. Zum Beispiel die Event-Seiten für Kampfspezifische Events. Dort gibt es nichteinmal nahezu ausreichend Möglichkeiten Auslöser zu definieren.
Für mich schließt das alles auf Unentschlossenheit und keine ausgereifte Planung der Software.
Zitat von Caine Luveno
Das Grundproblem, die Logik des Programmierens zu erlernen, bleibt aber bestehen. Je komplexer du die GUI also gestaltest, desto mehr komplizierte logische Abläufe erden möglich und desto schwieriger wird das ganze zu bedienen.
Daher ist die Lösung des XP und VX(Ace) sehr gut. Die einfache Bedienung des 2k/2k3 bleibt erhalten, aber dank Ruby hat man die Möglichkeit das Backend "dahinter" zu verändern, falls nötig.
...
Das Interessante daran ist, dass das Programmieren sehr sehr simpel ist sobald man das Grundgerüst und die kryptische Syntax von Programmiersprachen ignoriert.
Wie du selbst festgestellt hast ist es schon sehr einfach, auch für jemand unerfahrenen, simple Abläufe im Maker umzusetzen. Das ist bereits Programmierung.
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.
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.
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.".
Das sieht auf den ersten Blick zwar nach einer tollen Möglichkeit aus um allerlei mächtige Funktionalität einzubauen, in Wirklichkeit ist es meiner Meinung nach aber eine schlechte Unternehmenspolitik, welche sich versucht zu verbergen.
Es ist wie eine Waage: Wie viel Arbeit macht sich der Software-Entwickler und wie viel Arbeit muss der Endnutzer letzten Endes übernehmen. Enterbrain ging mit dem XP den Weg so gut wie alles auf den Endnutzer ab zu wälzen.
Ich stimme dieser Taktik schlichtweg nicht zu.
Zitat von Caine Luveno
Schon mal versucht im RM2k ein fremdes Menüscript einzubinden und anzupassen welches z.B. unendlich viele Itemslots bietet? Da kriegst du bedeutend mehr Inkompatiblitätsprobleme als mit einem Ruby-Script, vorallem wenn du mehrere Fremdscripte kombinieren möchtest. Das Argument zieht also eher schlecht.
Und eben da kann die Community helfen. Alleine schon wenn es darum geht zwei inkompatible Scripte zueinander kompatibel zu machen, was im RM2k per Definition, ohne das Zielprojekt selbst zu besitzen, nicht möglich ist.
...
Die RPG Maker 2k und 2k3 sind, meiner Meinung nach, von grundauf schlecht designed. Kompliziertere Systeme sind nur dann möglich, wenn man bereit ist wie ein Sklave zu arbeiten, für ein Ergebnis, welches mit einer ordentlichen Programmierung nur wenige Minuten gedauert hätte.
Das hat nichts damit zu tun, weil eine Scriptsprache nicht zur Verfügung steht. Das hat damit zu tun, dass Enterbrain eine schlechte Arbeit geleistet hat.
Wenn man ordentliche, typisierte Variablen definieren könnte, und zwar lokal und global, dann würde das ganz anders aussehen.
Zitat von Caine Luveno
Das was du beschreibst, Grafiken reinkloppen und am Code rumwerkeln ist genau dass was XP und VX(Ace) einem Entwickler in der einfachen Form erst ermöglichen. Eine Grafikengine bietet da deutlich weniger, nämlich nur grundlegende Funktionen welche auf beispielsweiße OpenGL oder DirectDraw(Direct3D) aufsetzen welche dir die Möglichkeit geben "zeichne Würfel an Position X und rotiere mit Geschwindigkeit S um Achse Y mit Textur C", sodass du nicht mehr 6 einzelne Quadrate selber zeichnen, positionieren und rotieren musst oder gar 12 Dreiecke, sondern in einem Aufrund deinen ganzen Würfel hast. Da ist nichts mit "Ressourcen reinkloppen" weil die Engine nicht einmal weiß was "Ressourcen" wären und dies gar nicht wissen kann.
Der RPG Maker geht da deutlich weiter. Vom komplett vorhandenem Editor, welchen dir auch keine Grafikengine (Unreal-Engine mal außen vor gelassen) bietet, will ich gar nicht anfangen.
...
Ich habe nicht gesagt, dass ein Programmierer sich lediglich eine Grafikengine nehmen soll.
Es gibt sehr gute Spieleengines zur kostenlosen (und auch kostenpflichtigen) Nutzung im Internet.
Jeder dürfte sich jederzeit eine dieser Engines nehmen und sofort anfangen das Spiel zu programmieren.
und viele weitere bekannte Namen. Alles kostenlos zu nutzen.
Das sind nicht nur Grafikengines. 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.
Zitat von Caine Luveno
@Topic
- Variable Auflösung (entweder mit Highres-Grafiken oder eben einer Skalierung über den sichtbaren Bildschirmbereich)
- "Echtes" Pixelmovement mit allem was dazu gehört (Pixelgenaue Kollision z.B.).
- Erweiterung der Maker-GUI, z.B. um eigene Event-Befehle für selbstgeschriebene Scripte (Plugin-System?)
Halt die Dinge welche selbst mit RGSS3 nahezu unmöglich zu realisieren sind, da man die halbe Engine umschreiben müsste.
...
Ein Plugin-System wäre vielleicht ganz interessant, möglicherweise aber schwer umzusetzen. Darüber muss ich ein wenig nachdenken.
Bei den Beispiel-Engines fehlen jetzt natürlich gerade die für uns interessanten, nämlich die für 2D-Retro-RPGs. Vielleicht könnte man die mit dem GameMaker umsetzen, aber das stelle ich mir viel aufwändiger als mit dem Maker vor. Man müsste wirklich mal schauen, wer weniger Aufwand hat: Ein Programmierer mit Spiel-Engine oder der Maker-Entwickler.
guck dir mal Unity3D an. Das hat seit neustem nen 2D Modus. Wie gut der ist, keine Ahnung, aber Unity ist von Haus aus sehr mächtig (und bietet portiertungen von Haus aus an.)
Bei den Beispiel-Engines fehlen jetzt natürlich gerade die für uns interessanten, nämlich die für 2D-Retro-RPGs. Vielleicht könnte man die mit dem GameMaker umsetzen, aber das stelle ich mir viel aufwändiger als mit dem Maker vor. Man müsste wirklich mal schauen, wer weniger Aufwand hat: Ein Programmierer mit Spiel-Engine oder der Maker-Entwickler.
...
Was mehr oder weniger Arbeit bedeutet kann man, denke ich, nicht beantworten.
Wenn man sich auf die Grundfunktionalität des Makers beschränkt ist die Art von Spielen, welche man erstellen kann, sehr begrenzt. Wenn man sich innerhalb dieser Grenzen bewegen will ist der Maker wahrscheinlich einfacher. Immerhin ist er bereits dafür ausgelegt.
Sobald man aber ein klein wenig von der Norm abweichen wird, wird es wohl sehr schnell einfacher eine "professionellere" Engine zu verwenden.
Außerdem: Jede 3D Engine bietet auch 2D Grafikmöglichkeiten.
Immerhin haben auch 3D Spiele ein 2D overlay und/oder HUD.
Das ist nicht viel anders als Sprites anzuzeigen. Außerdem gibt es soetwas wie 2D-Grafik für eine Grafikkarte garnicht mehr. Dort wird alles nurnoch mit der gleichen Technik wie für 3D realisiert. Es wird halt einfach nur "flach" gezeichnet.
Ich stimme auch dafür das man nur beim Eventcode bleibt, denn als RMXP Nutzer mit vielen RGSS Scripten, laufe ich ständig über Probleme, auch bzgl. Inkompatibilität.
Dafür ist es natürlich umso wichtiger das ich so ziemlich alles frei in einem mächtigen Event-Editor basteln kann. Beispiel: Ein Menü basteln, so wie ich es will. Mit flexiblen Fenstergrößen, Schriftarten, Einblendezeiten, Balken, Zahlen, Farben, Formen, Transparenzen, Sortierungen etc. Verstehst du wie ich meine?
Überhaupt alles im Eventeditor sollte dynamisch ansprechbar/änderbar sein. Keine festen Werte, die man nur fix im Editor einstellen kann.
Performance ist auch wichtig. Ich will 200 Zombies auf eine Map platzieren können, die von je 3 Schmetterlingen umzingelt werden und die alle mich jagen. Mit Schritt-, Flatter-, und Gröhlsounds...und Pathfinding.
Kurzum: Eigentlich sollte man nie das Gefühl haben, das man eine Scriptsprache bräuchte um XY umzusetzen. Es sollte theoretisch alles was per Script ginge, auch mit dem Event Editor umsetzbar sein. Und das mindestens genauso komfortabel.
Ich stimme auch dafür das man nur beim Eventcode bleibt, denn als RMXP Nutzer mit vielen RGSS Scripten, laufe ich ständig über Probleme, auch bzgl. Inkompatibilität.
Dafür ist es natürlich umso wichtiger das ich so ziemlich alles frei in einem mächtigen Event-Editor basteln kann. Beispiel: Ein Menü basteln, so wie ich es will. Mit flexiblen Fenstergrößen, Schriftarten, Einblendezeiten, Balken, Zahlen, Farben, Formen, Transparenzen, Sortierungen etc. Verstehst du wie ich meine?
Überhaupt alles im Eventeditor sollte dynamisch ansprechbar/änderbar sein. Keine festen Werte, die man nur fix im Editor einstellen kann.
...
Es wird so wenige Konstanten geben wie möglich. Idealerweise wird man während des Spiels eine Menge Werte ändern können.
Zitat von Ascare
Performance ist auch wichtig. Ich will 200 Zombies auf eine Map platzieren können, die von je 3 Schmetterlingen umzingelt werden und die alle mich jagen. Mit Schritt-, Flatter-, und Gröhlsounds...und Pathfinding.
...
Das wird überhaupt kein Problem sein. Auf meinem kleinen Laptop ohne dedizierte Grafikkarte komme ich immerhin auf 20 000 animierte Sprites + Tilemap.
Auf meinem PC sind es mehrere Millionen.
Eine 3D Landschaft ist etwas sehr kostspieliges für einen Computer. Eine Grafikkarte, welche soetwas problemlos anzeigen kann, kommt auch ohne Probleme mit nahezu beliebig vielen 2D Grafiken zurecht. Die kosten so gut wie garnichts.
Zitat von Ascare
Kurzum: Eigentlich sollte man nie das Gefühl haben, das man eine Scriptsprache bräuchte um XY umzusetzen. Es sollte theoretisch alles was per Script ginge, auch mit dem Event Editor umsetzbar sein. Und das mindestens genauso komfortabel.
...
Wie bereits angesprochen, ich denke nicht, dass ich eine Scriptsprache erlauben würde. Alleine wegen der Gefahr, dass sie jemand missbraucht um Viren zu übertragen oder andere Arten von Malware in einem Spiel zu verstecken.
Wie bereits angesprochen, ich denke nicht, dass ich eine Scriptsprache erlauben würde. Alleine wegen der Gefahr, dass sie jemand missbraucht um Viren zu übertragen oder andere Arten von Malware in einem Spiel zu verstecken.
...
Ich kann dir auch aus jeder X-beliebigen RPG.exe nen Virus bauen. Geht ganz einfach Ist für mich also eigentlich kein Argument, warum man auf die Macht einer Script- bzw. Hochsprache verzichten sollten (bei mir z.B. gebe ich dem User ein Projekt mit an die Hand, welches er mehr oder weniger beliebig beschreiben kann, als .DLL kompiliert und dann zum Start geladen wird).
Point&Click ist zwar echt eine nette Sache und erleichter auch mega viel, ist aber auch mega aufwändig, das halbwegs potent zu designen.
Die Projekte werden auch nicht als .Exe verbreitet.
Meine Idee wäre es eine Runtime-Enviroment und einen Maker separat zu veröffentlichen. Projekte können nur gespielt werden sofern die Runtime-Enviroment auf dem Computer vorhanden ist. Es handelt sich dabei um eine Art von virtueller Maschine, in welcher ein Spiel gespielt wird. Diese Runtime-Enviroment beeinflusst die Art und Weise wie das Spiel auf System-Resourcen zugreifen kann und diese beeinflusst. Der Spieler kann zum Beispiel in seiner Runtime-Enviroment festlegen in welchem Ordner Spielstände gespeichert werden oder temporäre Dateien erstellt werden dürfen; außerdem wird es auch weitere Optionen für den Spieler geben um das Verhalten von Spielen global zu beeinflussen.
Dadurch ist es so ziemlich unmöglich, oder zumindest extrem schwierig, die Spiele zu missbrauchen um schädliche Software zu verbreiten.
Ich kann es dir sagen, denn genau so wird es im XP getan. Erst sobald versucht wird die Musik ab zu spielen wird sie von der Festplatte geladen. Sofern man also vorher noch nicht versucht hat die Musik zu spielen wurde sie auch vorher noch nicht geladen. Wenn du bedenkst, dass diese Ladezeit nur eine oder zwei Sekunden beträgt, oder vielleicht noch weniger, ist es hoffentlich ersichtlich, dass es kein großes Problem ausmachen würde die Musik einfach bereits im Vorfeld zu laden. Dann gäbe es auch keine Probleme während des Abspielens mehr.
...
Generell kann man Ogg genauso wie MP3 streamen, also stückweise laden, während die Musik abgespielt wird. Der XP macht das nicht, richtig, aber man kann über RGSS sich nen externen Soundmanager machen um das Problem zu umgehen.
Wenn man nen eigenen Maker/Engine/sonstwas in der Richtung machen möchte, sollte man grundsätzlich ermöglichen Musikdaten zu streamen, unabhängig vom Format.
Was ich mir von einen Maker wünschen würde:
- Möglichkeit andere Maparten zu wählen (Isometrische Maps)
- Unterstützung mehrerer Videoformate (.mp4 und der ganze Kram. Ist natürlich eine Frage der Lizenzrechte)
- Ruby oder besser noch ne richtige Programmiersprache um auch Standardalgorithmen des Makers für das Spiel ändern zu können:
Was passiert wenn eine Map geladen wird?
Wann werden Objekte gelöscht?
Was sind die Standardeigenschaften für GUI-Elemente?
Was wird in ein Savefile gespeichert?
Ein Mappingsystem ähnlich dem XP
Partikelsystem
- Veränderbare Auflösung, Tastenbelegung, etc. im Spiel (der Entwickler sollte die Möglichkeit haben selbst ein Optionsmenü entsprechend des heutigen Spielstandards machen zu können)
Soll erstmal reichen, sonst Fallen mir noch zig Sachen ein die "nice to have" sind. Die obere Liste orientiert sich an dem, was andere Tools, wie Unity bsp. bieten.
Generell denke sich, dass ein Tool, was sich zwischen RPG Maker und Unity, CryEngine, UDK etc. befindet optimal wäre (Von den Aspekten der Flexibilität und Einsteigerfreundlichkeit her).
Die Projekte werden auch nicht als .Exe verbreitet.
Meine Idee wäre es eine Runtime-Enviroment und einen Maker separat zu veröffentlichen. Projekte können nur gespielt werden sofern die Runtime-Enviroment auf dem Computer vorhanden ist. Es handelt sich dabei um eine Art von virtueller Maschine, in welcher ein Spiel gespielt wird. Diese Runtime-Enviroment beeinflusst die Art und Weise wie das Spiel auf System-Resourcen zugreifen kann und diese beeinflusst. Der Spieler kann zum Beispiel in seiner Runtime-Enviroment festlegen in welchem Ordner Spielstände gespeichert werden oder temporäre Dateien erstellt werden dürfen; außerdem wird es auch weitere Optionen für den Spieler geben um das Verhalten von Spielen global zu beeinflussen.
Dadurch ist es so ziemlich unmöglich, oder zumindest extrem schwierig, die Spiele zu missbrauchen um schädliche Software zu verbreiten.
...
Hat aber wiederum das Problem, das alle Spiele, die mit deiner Engine gemacht werden auch auf allen späteren Engine Versionen laufen müssen. Diesen Schuh wollte ich mir nicht anziehen, zumal dann Private Änderungen an der Engine kaum möglich sind. Vielleicht habe ich dich auch nicht richtig verstanden, aber den Enduser eine Art RTP zu geben, dass dann wie in Java komplett abwärtskompatibel sein muss (und keine Custom Änderungen erlaubt*), halte ich für fatal! Gerade in der heutigen Zeit, wo OpenSource immer beliebter wird. Ich persönlich würde keine Engine nutzen wollen, die nicht Quelloffen ist und custom Änderungen nicht erlaubt
*Natürlich ist es bei einer gut gebauten Engine auch selten nötig, das er Nutzer etwas nachjustieren muss, aber möglich kann es sein.
Generell kann man Ogg genauso wie MP3 streamen, also stückweise laden, während die Musik abgespielt wird. Der XP macht das nicht, richtig, aber man kann über RGSS sich nen externen Soundmanager machen um das Problem zu umgehen.
Wenn man nen eigenen Maker/Engine/sonstwas in der Richtung machen möchte, sollte man grundsätzlich ermöglichen Musikdaten zu streamen, unabhängig vom Format.
...
Ja das stimmt wohl.
Zitat von Lares Yamoir
- Möglichkeit andere Maparten zu wählen (Isometrische Maps)
...
Sollte machbar sein, allerdings würde ich mich zunächst auf die "normalen" Maps beschränken und erst danach eine isometrische Alternative erstellen.
Zitat von Lares Yamoir
- Unterstützung mehrerer Videoformate (.mp4 und der ganze Kram. Ist natürlich eine Frage der Lizenzrechte)
...
Das ist schon schwieriger. Ich weis noch nicht recht was ich in dieser Richtung anbieten kann.
Zitat von Lares Yamoir
Was passiert wenn eine Map geladen wird?
...
Ist schon dabei.
Zitat von Lares Yamoir
Wann werden Objekte gelöscht?
...
Ist schon dabei.
Zitat von Lares Yamoir
Was sind die Standardeigenschaften für GUI-Elemente?
...
Ist schon dabei.
Zitat von Lares Yamoir
Was wird in ein Savefile gespeichert?
...
Der Entwickler soll die Möglichkeit haben selbstständig Dateien auf dem Computer des Spielers zu erstellen und zu speichern. Es können auch mehrere Dateien sein.
Allerdings kann der Entwickler sich nicht entscheiden wo er diese Dateien anlegt (der Ort wird von dem Spieler bestimmt) und der Spieler kann auch eine Obergrenze für die (kombinierte) Dateigröße festlegen.
Zitat von Lares Yamoir
Ein Mappingsystem ähnlich dem XP
...
Sogar noch ein Stückchen besser wenn es geht.
Zitat von Lares Yamoir
Partikelsystem
...
Darüber lässt sich reden. Wie genau stellst du dir das in 2D vor?
Zitat von Lares Yamoir
- Veränderbare Auflösung, Tastenbelegung, etc. im Spiel (der Entwickler sollte die Möglichkeit haben selbst ein Optionsmenü entsprechend des heutigen Spielstandards machen zu können)
...
Ist schon dabei.
Zitat von anti-freak
Hat aber wiederum das Problem, das alle Spiele, die mit deiner Engine gemacht werden auch auf allen späteren Engine Versionen laufen müssen. Diesen Schuh wollte ich mir nicht anziehen, zumal dann Private Änderungen an der Engine kaum möglich sind. Vielleicht habe ich dich auch nicht richtig verstanden, aber den Enduser eine Art RTP zu geben, dass dann wie in Java komplett abwärtskompatibel sein muss (und keine Custom Änderungen erlaubt*), halte ich für fatal! Gerade in der heutigen Zeit, wo OpenSource immer beliebter wird. Ich persönlich würde keine Engine nutzen wollen, die nicht Quelloffen ist und custom Änderungen nicht erlaubt
*Natürlich ist es bei einer gut gebauten Engine auch selten nötig, das er Nutzer etwas nachjustieren muss, aber möglich kann es sein.
...
Ja, dieses Problem existiert durchaus. Auf der anderen Seite gibt es dem Entwickler aber auch mehr Sicherheit und stabilität. Alle Versionen der Runtime-Enviroment werden vom Hersteller produziert und ihre Funktionalität wird garantiert. Wenn es auf einem Computer funktioniert, dann wird es auf jedem Computer funktionieren. (Sofern die Hardware ausreichend mächtig ist)
Es ist eine uralte Diskussion wie "sinnig" oder "unsinnig" eine virtuelle Maschine ist. Es ist allerdings die Herangehensweise, welche ich persönlich am sinnvollsten empfinde.
Immerhin soll das nicht das non-plus ultra der Spielerstellung werden. Es soll ein nettes kleines Programm für nette kleine Leute sein; Das Alter der (Haupt) Zielgruppe zwischen 10 und 20.
Wär mehr Macht will sollte programmieren lernen und sich nicht mit solchem Kinderspielzeug wie einem Maker befassen und seine Zeit damit verschwenden.
Darüber lässt sich reden. Wie genau stellst du dir das in 2D vor?
...
Man hat einen Spawner, der immer wieder die gleiche zuvor ausgewählte Textur als Sprites (wichtig Mehrzahl!) erstellt.Diesen Spawner kann man entweder an ein bestimmtes Game Objekt befestigen, oder frei positionieren. Die Textur, so wie die Attribute für die Sprites (Lebensdauer, RGBA-Werte-Veränderung, Bewegungsmuster, Menge der Sprites, ...) können vom Entwickler festgelegt werden. So etwas macht sich vor allem gut für Feuer, Bluteffekte, Fußspuren, aufgewühlten Staub, Wetter oder eben (Kampf-)Fähigkeiten und erleichtert für nicht so gute Pixler den Arbeitsaufwand erheblich.
"Alles!"
Also in markierten Scriptzeilen bestimmte Inhalte suchen und ersetzen, beispielsweise Variablen und auch Textzeilen.
...
suchen ist mit einem cherry-tool möglich, soweit ich verstehe, wie du das möchtest. ist äußerst praktisch, wenn man zB danach sucht, wo man einen befehl überall verwendet hat. ersetzen muss man dann trotzdem manuell.
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 von Cornix
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 von Cornix
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 von Cornix
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 von Cornix
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 von Cornix
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 von Cornix
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 von Cornix
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.
--
Aktuelles Projekt "Uns're Ordnung ist das Chaos!
Verändern heißt zerstör'n!
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.
Zitat von Caine Luveno
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.
Zitat von Caine Luveno
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:
dann wird dieses Programm wohl für jeden noch so grünen Anfänger verständlich sein.
Falls die Syntax jedoch wie folgt aussieht:
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.
Zitat von Caine Luveno
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.
Zitat von Caine Luveno
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.
Zitat von Caine Luveno
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.
Zitat von Caine Luveno
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.
Zitat von Caine Luveno
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.
Zitat von Caine Luveno
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.
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?
Zitat von Cornix
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*.
Zitat von Cornix
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.
Zitat von Cornix
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.
Zitat von Cornix
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.
Zitat von Cornix
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.
Zitat von Cornix
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.
Zitat von Cornix
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.
Zitat von Cornix
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.
Zitat von Cornix
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.
Zitat von Cornix
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.
Zitat von Cornix
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)
--
Aktuelles Projekt "Uns're Ordnung ist das Chaos!
Verändern heißt zerstör'n!
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.
Zitat von Caine Luveno
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.
Zitat von Caine Luveno
Englisch als Symbolbezeichner dient der Internationalisierung.
...
Sag bloß. Entschuldigung, das konnte ich mir nicht verkneifen.
Zitat von Caine Luveno
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.
Zitat von Caine Luveno
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.
Zitat von Caine Luveno
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.
Zitat von Caine Luveno
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.
Zitat von Caine Luveno
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.
Zitat von Caine Luveno
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.
Zitat von Caine Luveno
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.
Zitat von Caine Luveno
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.
Zitat von Caine Luveno
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.
Zitat von Caine Luveno
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.
Zitat von Caine Luveno
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.
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.
...
Schau dir mal z.B. Scratch an.
Das sind zwar Kindgerechte Programmiersprachen, aber die laufen komplett über die GUI. Die Kinder können sich durch Klicken und Schieben ganze Scripte Schreiben. Mitsamt Verzweigungen und Schleifen.
Zitat von Caine Luveno
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.
...
Das stimmt so nicht.
Eine Programmiersprache gibt dir nur sehr wenige Möglichkeiten. Die Digitaltechnik besteht auch nur aus UND, ODER und NICHT, und bietet dir alles, was du brauchst. Ja, dein ganzer PC basiert nur auf diesen drei Logik-Gattern. Das XOR besteht auch nur aus den drei Komponenten. Eine Programmiersprache bietet dir also nur eine gewisse Kontrollmöglichkeit. In den gängisten Programmiersprachen hast du lediglich nur Logische- und Bitoperatoren, Verzweigungen und Schleifen. Aus diesen Möglichkeiten werden dann ganze Frameworks gebastelt, die das Leben eines Programmierers erleichtern. Darunter z.B. der Garbage Collector oder Reflection.
Microsoft Access ist auch in vieler Hinsicht Gescheitert. Allein schon, dass Access mit großen Datenmengen nicht mehr arbeiten konnte. Beruflich arbeite ich an einer Software, in der die Kunden über 10 GB Daten in die Datenbank schreiben. Einige Tabellen weisen sogar über eine Million Datensätze auf. Vor ca. 10 Jahren hatte die Firma Access noch unterstützt. Diese Unterstützung wurde aber aufgrund der Unperformance aufgegeben.
Zitat von Caine Luveno
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.
...
Wie gesagt, eine Programmiersprache ist nich so komplex, wie sie aussieht. Ein Compiler ist auch nur ein paar Kilobytes groß, und ein Compiler übersetzt den gesamten Quellcode in Maschinensprache.
Einige Compiler sind sogar sehr rudimentär. Einige bestehen zum Großteil nur aus Verzweigungen.
Zitat von Caine Luveno
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.
...
Der Grund liegt eher in der Engstirnigkeit einiger Entwickler, die nicht über ihren Schatten springen können, und nur das für Gut befinden, was sie kennen.
In der Firma, wo ich arbeite, sind wir nun von VSS (Visual SourceSafe) auf TFS (Team Foundation Server) umgestiegen, und gerade die älteren Entwickler vertrauen z.B. das Auto-Merging von TFS nicht, und machen es stattdessen weiterhin manuell.
Es ist zwar richtig, dass man über eine Programmiersprache meist schneller zu einem Ergebnis kommt, aber das heißt lange nicht, dass eine GUI schlecht ist. Schaue dir z.B. die SPS-Programmierung an. Dort läuft es nämlich genau andersrum. Dort wird hauptsächlich nur über Drag'n'Drop entwickelt. Siemens hatte mit ihrer S7 erst Chancen auf dem Markt gehabt, nachdem sie den Kontaktplan uind Funktionsplan in ihre IDE integriert haben. Davor musste man die Befehle eintippen und die S7 war regelrecht ein Ladenhüter.
Zitat von Caine Luveno
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.
...
Hast du schon mal was von statischen Objekten/Klassen gehört?
Für viele Zwecke sind sie sehr hilfreich und je nach Sichtbarkeit können sie Global sein. In Java ist z.B. die Math-Klasse eine statische Klasse, die global verfügbar ist.
Zitat von Caine Luveno
Zitieren
