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

[Caine Luveno]

Der einfache Nutzer, welcher nicht programmieren kann, hat diese Möglichkeit nicht. Für ihn bedeuten die meisten Fachwörter auch nicht viel, oder nichts konkretes. Er möchte eine Software, welche leicht zu lernen und zu verstehen ist, aber ihm trotzdem viele Möglichkeiten bietet.

...

Je mehr Möglichkeiten du dem Anwender gibst desto komplizierter wird das Programm. Der RPG Maker geht da schon einen guten Mittelweg.

Der Witz ist eigentlich das der Click-Code im Prinzip eine makereigene Programmiersprache darstellt. Das Ding hat Bedingungen, Schleifen, Variablen und diverse Befehle mit denen sich wer weiß was anstellen lässt. Der große Knackpunkt ist dass der Click-Code dem Anwender die Syntax abnimmt und ihm eine grafische Ansicht und Auswahl von Funktionsparametern ermöglicht.

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.

Features werden nichtmehr unterstützt, mit der Begründung, dass die Nutzer doch einfach ein Script selbst schreiben können. Soll sich die Community doch darum kümmern.
Das Ergebnis ist aber oftmals von minderer Qualität. Oder inkompatibel mit anderen Scripten. Außerdem für einige Mitglieder der Community schnell Teufelswerk.

...

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.

Ein Nutzer, welcher programmieren kann, braucht nicht solch eine kindische Software zu nutzen. Diese Personen sind garnicht Teil der Zielgruppe.
Sie können sich eine beliebige fertige Engine schnappen, ihre Resourcen dort einfügen, und dann an dem Code rumwerkeln bis das gewünschte Ergebnis erzielt wurde.

...

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.

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

[Cornix]

Vielen Dank für den Beitrag, sehr hilfreich.

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.

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.

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.

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.

Schau nur einmal hier:
http://de.wikipedia.org/wiki/Liste_von_Spiel-Engines

Dort findet sich unter anderem:
CryEngine
Unreal Engine
Quake-Engine

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.

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

[Kelven]

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.

[Caine Luveno]

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.

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.

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.

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.

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.

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.

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.

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.

[Lares Yamoir]

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