RPG-Maker Quartier

Für Anfänger eignet sich der RPG-Maker 2000, zusammen mit diesem Buch zum Herunterladen. Du kannst es auch mit dem RPG-Maker 2003 versuchen, dann aber ohne Tutorial. Der RPG-Maker XP und der VX haben eine Skriptsprache und sind nichts für Anfänger.

_________________

Man kann auch mit dem XP rein mit Events arbeiten. Nicht jeder der die neuen
Maker verwendet kann auch Ruby.

_________________

Die meisten Funktionen sind eh gleich, beim 2k3 gibts noch ein paar Befehle mehr, das einzige was wirklich anders ist, ist das Kamfsystem (und selbst das ist ziemlich ähnllich, von der Darstellung abgesehen und dass es halt ein ATB-KS ist)
Die Übersetzungen sind teilweise anders, d.h. manche Funktionen heißen anders, das ist für Anfänger ebenfalls von belang denke ich. (Ist auch der Hauptgrund warum ich den 2k empfehlen würde, damit man nicht durcheinander kommt)

_________________

Wie sieht es beim XP eigentlich mit so Sachen aus wie z.B. einem Schuss-AKS? Beim 2k/3 lässt sich das easy und funktionabel mit Events coden. Geht das beim XP ebenso oder MUSS man es dort mit Ruby scripten? Und ist es beim VX genauso?

_________________

Prinzipiell lässt sich auch im XP alles mit Events machen. Und im VX wahrscheinlich
auch.

_________________

Durch Ruby-Scripts hast du durch ein Schuss-AKS allerdings mehr Möglichkeiten - unter Umständen wäre auch eine höhere Performance möglich.

_________________

Unter Umständen würde ich meinen, du hast keine Ahnung.

_________________

(D)eine Meinung ist kein objektiver Befund.

Wenn ich ein Schuss-AKS auf Basis von Events erstelle, dann reagiert es träger und ist langsamer als ein Script, dass ich quasi "nativ", also eine Ebene näher an der Engine programmiert habe. Es ist also denkbar, dass ein Schuss-AKS auf Ruby-Script-Basis "unter Umständen performanter" läuft als ein Schuss-AKS mit Events.

Unter Umständen würde ich dir also Unrecht geben mit deiner Behauptung. Und wäre es nicht ein Stereotyp menschlichen Handelns, würde ich sie sogar auf dich umkehren.

_________________

Also im 2k/3 läuft ein standardmäßiges gut funktionierendes Schuss-AKs, so wie ich es imemr benutze, laggfrei ab. Es reichen 2 parallele Prozesse: einer fragt den Treffer am möglichen Gegner ab, der andere wartet darauf, dass du schießt.
Was du meinst, ist womöglich, dass du mit Scripten im XP und VX soetwas wie Pixelabfrage anstatt Koordinatenabfrage machen kannst, also das AKS präziser ist hinsichtlich der Treffer.
Ich hab mal ein simples Schuss-AKs auf dem VX erlebt. Mal ganz abgesehen davon, dass VX und XP auf meinem Rechner eh langsamer laufen als 2k/3, hat dieses VX-AKS das Spiel noch langsamer gemacht. Und es hatte afaik Pixelkollisionsabfrage, kam mir zumindest so vor.

_________________

Ich würde denken, dass dann der Script-Interpreter die eigentliche Performance-Bremse ist. Im RPG-Maker 2k3 waren alle Befehle nativ in die Engine implementiert, aber im XP/VX werden alle Befehle, ob nun Events oder Ruby-Scripts, durch den Script-Interpreter interpretiert.

Dennoch: auch wenn ein Schuss-AKS auf dem RPG-Maker 2k3 am schnellsten laufen würde, wäre das gleiche, eventbasierte AKS auf XP/VX langsamer als die Script-Variante, da die Events erst in Scripts umgewandelt werden müssen*, während Ruby-Scripts direkt ausgeführt werden.


*) Der tatsächliche Prozess ist wahrscheinlich viel komplizierter. Die Befehle aus den RPG-Maker-Events werden erst in Einzelbefehle an die Script-Engine aufgeschlüsselt oder sind in den vorgefertigten Scripts eines Spiels schon parametrisiert, liegen aber dann immer noch eine Systemebene mehr zurück und sind damit langsamer.

_________________

Ob jetzt ein Rubyscript interpretiert wird oder die Eventbefehle ist egal. Fakt ist,
dass die RGSS selbst afaik nicht sehr performant ist.

_________________

Das spielt denke ich nur eine untergeordnete Rolle. Ob die Eventbefehle nun direkt ausgeführt werden, oder erst den Umweg über den Interpreter nehmen dürfte von der Performance eher egal sein (wenn man nicht gerade tausende Variablen pro Frame beschreiben will).

Ich bin immer noch der Meinung das die schlechte Grafik-Engine des Makers die Hauptbremse ist. Und der veraltete Rubyinterpreter trägt sicherlich auch einiges zur schlechten Performance bei. Dazu kommt das manche Prozesse im Maker auch nicht wirklich performant gescriptet sind (z.B. Kollissionsabfragen bei Bewegungen, Update der Events etc.)

_________________

Öhm... die Events "sind" im Grunde RGSS (schaut euch nur einmal im XP im Script-Editor die Einträge "Interpreter 1" bis "Interpreter 7" an... da findet ihr sie allesamt. Auch ists irgendwo... naja... hab beim Suchen 3x den Eintrag "result = eval(irgendwas)" gefunden und zwei davon stehen in der Interpreter-Klasse ("Interpreter 1" bis "Interpreter 7") und... wer mal mit Google nach dem Begriff "eval" sucht, findet u.a. das hier, wo "eval" als "nicht performant" aus Sicht einiger Programmierer betitelt wird.

Dein Eindruck bezüglich der Grafik-Engine, den KD da äußerte, kann ich nur unterstreichen, allerdings hängts hier nicht minderstark davon ab, wie viele Grafiken dargestellt werden und wie oft diese "aktualisiert" (also "gelöscht" und "neu geschrieben" werden).

Also klar, die RGSS ist nicht unbedingt performant... habe auch vielmehr die Vermutung, dass so ziemlich "ALLES", was an Ruby-Code im Maker geschrieben ist und ausgeführt wird, noch einmal durch "eval" gejagt wird, nur hab ich bislang noch keinen entsprechenden Eintrag gefunden (auch nicht in der Hilfedatei, die ja auch die nicht im Script-Editor gelisteten Scripte aufführt). Vllt. weiß da ja jemand mehr...?

_________________
Der einzige Held, der dich aus tiefster Finsternis erretten kann, wohnt in dir selbst.

Das eval ist nur um Rubycode in Eventscripten auszuführen (entweder über Conditional Branch oder über Script...). Die Performance ist dabei denke ich weniger das Problem, da es sich hierbei nur um kleine Codesnippets handelt die sich schnell parsen lassen. Außerdem werden die Befehle ohnehin nicht so häufig eingesetzt.

Ansonsten wird natürlich der gesamte Scripteditor einmal durch eval gejagt. Das ist aber normal. Irgendwie muss das Script ja eingelesen werden.

_________________

Allerdings hab ich auf mehreren über Google gefundenen Seiten gelesen, dass "eval" nicht so wirklich performant sein soll... obs Stimmt kann ich auch nicht 100%ig sagen, was mit dem im Scripteditor angelegtem Code so alles passiert, wenn das Spiel läuft und wie oft "eval" während des Spielverlaufs auf den gesamten Code angewendet wird (also obs mehrmals für den gerade aktiven Codeteil passiert oder nicht).

Was es auch sein "könnte": Der "Ruby-Interpreter" selbst, der (in gewisser Weise) eine Art "Kompilierung erst während der Laufzeit" durchführt, statt - wie beispielsweise bei c++ bekannt - eine Vorabkompilierung durchzuführen.


Im Grunde können wir da nur mutmaßen irgendwie...

_________________
Der einzige Held, der dich aus tiefster Finsternis erretten kann, wohnt in dir selbst.