Die Angst vor dem XP

[Kelven]

@Byakuya
Ich sehe das ähnlich wie Stööö. Die Spiele waren früher nett. SoM hat mir auch lange Zeit Spass gemacht, aber heute würde ich so ein Spiel allenfalls als Freeware akzeptieren. Dafür fehlt den Spielen zu viel, was die aktuellen Spiele haben. Damit meine ich nicht nur bessere Grafik, sondern auch eine packende und gut ausgearbeitete Story mit interessanten Charaktern und zeitgemässem Gameplay. Bei deinem Beispiel sind einige Spiele dabei, die mMn eine Story haben, die in jedem Maker-Newbiespiel zerrissen werden würde. Auch die Kampfsysteme ( waren sie zu ihrer Zeit auch wirklich gut ) können mit den aktuellen Spielen aus meiner Sicht nicht mithalten.

Die Balance von Grafik / Story / Spielspass war bei den SNES RPGs [...]

...

Die qualitativ hochwertigen Spiele sind heutzutage auch gut ausbalanciert.

[Dennis]

Tja, wieso benutze ich den XP nicht und werde ihn wohl auch nie benutzen...

ganz einfach eigentlich, hat einige Gründe.

1. Der Altersstarrsinn!
Ich habe vor 4 Jahren mit dem 2k begonnen, inzwischen kenn ich mich gut mit ihm aus, kann genug damit machen und finde mich zurecht. Ich muss längst nichtmehr überlegen, wie ich etweas mache, ich kann einfach ganz routiniert makern.
Es ist wie mit dem Lesen in der Grundschule verglichen mit dem eigentlichen Lesen: Mit etwas Übung liest man auch nciht mehr jeden einzelnen Buchstaben, sondern nur noch das Wort, gegen später ganze Satzteile als solche.

2. Die Grafik
Schön und gut, der XP hat die höhere Auflösung, aber ich finde, dass so die Nostalgie komplett flöten geht. Man könnte zwar mit aufgeplusterten Grafiken die Grafik des 2k simulieren, dann brauche ich den XP aber nicht benutzen. Was ich bisher an Screens vom XP gesehen habe, so sahen diese zwar grafisch besser aus, aber sie hatten für mich einfach nicht mehr den RPG-Touch, den ich einst am SNES so geliebt habe´und noch immer liebe.

3. Die Grenzenlosigkeit
Tja. Wieso das jetzt? Sagen wirs mal so: Durch seine Ruby-Element hat der XP AFAIK kaum noch Grenzen, die es zu brechen gibt. Der 2k hat diese noch. Und es ist mein großes Hobby am Maker, eben diese Grenzen zu brechen, etwas erfrischend neues zu erschaffen und etwas zu fertigen, wo sich wenigstens ein paar Leute fragen, wie das denn jetzt bitteschön funktioniert. Es ist für mich der letzte große Spaß am Maker zu skripten und zwar mit den denkbar einfachsten Mitteln.
Wenn man ein kommerzielles Spiel spielt denkt man heutzutage selten, wie etwas denn so funktionieren kann, da beeindruckt ein neues Element ganz einfach nicht in dem Maße, in dem es etwas Neuartiges tut, von dem man weiß, dass es auf Mitteln basiert, die das eigentlich gar nicht zulassen.

4. Der Startfaktor
Ich habe eigentlich nicht wirklich was neues angefangen, seit der XP in deutschen Communities einigermaßen eine Lobby hat. Insofern mach ich die angefangenen Sachen auch auf dem 2k fertig.

Also: Wer will, der soll, ich will nicht!

[Ryo Saeba 1000]

Meine Gründe den XP nicht zu nutzen:
Ehe ich eine beschnittene Programmiersprache lerne, lerne ich lieber Blitz oder C++ oder meinetwegen noch Gamemaker, Tools die um einiges leistungsfähiger sind.
Den XP aber zu nutzen ohne Ruby zu erlernen/ zu beherrschen finde ich sinnlos, da:
-mir einige Dinge des 2k/2k3 fehlen würden wie zB: Facesets, Keypatch
-die Performance des 2k/2k3 wesentlich besser ist
-die neuen Funktinen des XP (höhere Auflösung, größere Chipsets) zwar die Optik verbessern würden, aber mir nicht soo wichtig erscheinen
-der Preis von 50€mir viel zu überzogen erscheint, der Gamemaker (ein viel mächtigeres Spielerstellungstool) kostet nur 15€

Ich denke, ich würde mich höchstens näher mit dem XP befassen, wenn es ein wirklich ausführliches ebook, das alle wichtigen Funktionen des Makers und alle Rubyfunktionen haarklein erklärt, gäbe.

Der XP bietet mir vergleichsweise zu wenig, für einen zu hohen Preis.

[Stööö]

Was viele hier aber meiner Meinung nach falsch sehen ist die Tatsache, dass es immer wieder lustige Samariter gibt, die Scripts machen.
Man denke nur mal an das Advanced Message Script, das ist ja wohl der Hammer. Und um das einzubauen muss man lediglich ein neues Script einfügen, der Rest haben die Jungs (und Mädels? =p) schon für mich erledigt.
Wenn das mal nicht bequem ist!?
Und ob ich jetzt ein \f[namedesfacesets] oder einen eigenen Befehl mache - darauf kommts nun wirklich nicht an, finde ich ^^
Dass der Gamemaker stärker ist mag sein, nur ist es wohl unendlich mühsam mit ihm ein RPG zu machen, ehrlich. Mit dem XP hat man die grundlegende Kraft der 2k-Generation mit neuen, tollen Möglichkeiten. Schier unbegrenze Möglichkeiten gar.
Dass die Performance beim 2K besser ist, das kann sein, das gebe ich ohne Probleme zu, doch gibts selbst DAFÜR mittlerweile Scripts, die Ruckeln bis auf ein Minimum beim XP reduziert.
Hey, ich arbeite immer noch mit beiden und meine Fähigkeiten mit dem XP halten sich wirklich in Grenzen. Aber ich sehe in beiden Programmen eine Zukunft. Und sie sollten doch lieber nebeneinander existieren ^^
Verstehes ja auch, wenn Leute sagen, dass dabei der 'SNES-Charme' verlorengeht. Das liegt aber wohl eher daran, dass es noch kein RICHTIGES Spiele für den XP gibt, das allen ein "WOAH WTF!!1" entlocken kann. Zumindest hätte ich davon noch nichts gehört

[Der Drake]

Ehe ich eine beschnittene Programmiersprache lerne, lerne ich lieber Blitz oder C++ oder meinetwegen noch Gamemaker, Tools die um einiges leistungsfähiger sind.

...

Du missverstehst da irgendwas...
Was ist wohl Leistungsfähiger: Eine bekannte OO Programmiersprache die sich seit über zehn Jahren ständig weiterentwickelt hat, oder irgendeine wirklich beschränkte Skriptsprache, die dazu noch auf irgendwelchen Altlasten aufbaut? (Blitz BASIC. Selbst Blitz Max mit all den Modernisierungen ist immernoch im Prinzip ein BASIC Dialekt. Ruby hingegen ist eine wirklich moderne Sprache, mit konsistentem OOP...)
Die Skriptsprache beim Gamemaker kann aus ähnlichen Gründen als Sprache nicht mithalten.

Allerdings muss man an dieser Stelle vielleicht noch erwähnen das beide Sprachen (wie Ruby auch) die Möglichkeit haben externe .dlls einzubinden, die in einer nativen Sprache geschrieben sind. Einschränkungen gibt es also keine, bei allen drei Sprachen. Es geht nur um komfort und produktivität, wo Ruby doch ein paar Vorteile hat...

C++ ist imo auch nicht so geeignet. Es ist schon sehr performant und absolut nicht beschränkt, aber nur sofern du die 5 Jahre Zeit hast.

Ruby ist im XP auch nicht irgendwie beschnitten, das ist nur ein dämliches Gerücht von Leuten die keine Ahnung haben, und nicht wissen warum xyz nicht so funktioniert wie sie es wollen. (letztends hatte mal jemand das Argument vorgebracht das "gets" nicht funktioniert im XP... ist zwar nicht umbedingt ne Konsolenanwendung, aber das lassen wir mal außer Acht...)

Ich mach jetzt die Leistungsfähigkeit des Tools absichtlich an der Sprache fest... schau dir die Anzahl Skripte an die für den XP in kürzester Zeit(!) geschrieben wurden, und du weißt warum. ^^°

-mir einige Dinge des 2k/2k3 fehlen würden wie zB: Facesets, Keypatch

...

Du könntest auch alles von Events aus Steuern... der Keypatch ist auch nicht im Maker selbst geschrieben, und dennoch kannst du ihn benutzen.

[Kelven]

Ehe ich eine beschnittene Programmiersprache lerne, lerne ich lieber Blitz oder C++ oder meinetwegen noch Gamemaker, Tools die um einiges leistungsfähiger sind.

...

Aber es geht bei uns ja nicht um Programmiersprachen, sondern um das Entwickeln von Spielen. Zumindest ich möchte Spiele nicht programmieren, sondern designen. Aus dem Grunde bringen mir Programmiersprachen ohne fertige Spielengine nichts. Gerade das ist ja der Vorteil der Maker. Sie nehmen einen die Arbeit ab, so eine Engine erst zu programmieren. Die Maker reduzieren die Arbeit auf das Wesentliche und da kommen mMn weder andere Tools ( zumindest die, die ich kenne ) noch Programmiersprachen ran.

Den Gamemaker hab ich mir früher nur kurz angeschaut, aber er wirkte nicht so, als ob er sich besonders gut für RPGs eignet.

[Ascare]

Der Gamemaker ist an sich kein schlechtes Tool, nur müsste man für ein RPG fast alles von Grund auf selbst machen (zumeist sogar scripten), da es im Gegensatz zum RPG Maker ja kein genretypisches System als Vorlage hat. Ausserdem ist die Ressourcenverwaltung sehr unbequem gelöst. Es wird alles in die exe gestopft und wenn man mal Ressourcen im Nachhinein editieren will muss man viele Einstellungen nochmal machen. Für den XP zahlt man zwar mehr, dafür hat man aber diese Probleme schon gelöst. Das einzige Manko beim XP sehe ich immer noch bei der Performance und die wird man auch nicht wegscripten können, da die Spiele im Software Modus gerendert werden (CPU Last), noch dazu wird Ruby und die eigene Audio Engine afaik in Echtzeit berechnet. Toll wäre, wenn die Spiele von der Hardware (GFX Karte) gerendert wären, Ruby compiled und eine alternative Audio Engine. Dann hätten man wirklich einen enormen Performanceschub der wahrscheinlich locker mit dem 2k mithalten könnte.

[Ryo Saeba 1000]

Ich mach jetzt die Leistungsfähigkeit des Tools absichtlich an der Sprache fest... schau dir die Anzahl Skripte an die für den XP in kürzester Zeit(!) geschrieben wurden, und du weißt warum. ^^°

...

Ihr redet hier alle von zig Scripten die man einbauen soll... hab ich nicht letztens noch gelesen, dass es da Kombatibilitätsprobleme der Scripte untereinander gibt?
Dass wirklich alle Ruby Funktionen im RPG Maker XP uneingeschränkt nutzbar sind, ist mir neu.. freut mich aber.. ich dachte wirklich, dass es für den XP in gewisser Hinsicht beschnitten wurde.

[Der Drake]

Ihr redet hier alle von zig Scripten die man einbauen soll... hab ich nicht letztens noch gelesen, dass es da Kombatibilitätsprobleme der Scripte untereinander gibt?

...

Lass mich das kurz erklären... Die ganzen Skripte sind möglichst Idiotensicher geschrieben, sodass man wirklich nur kopieren und einfügen muss. Das wird erreicht, indem die Skripte Standardklassen überschreiben und erweitern.

Wenn du nun versuchst, sagen wir ein Kampfsystem, ein Menü, ein Message System, ein Skript für Pixelmovement, und ein Tag-Nacht System einzubauen, sollte es keine Probleme geben - trotz der offensichtlichen Menge an Skripten.
Diese Skripte sollten normalerweise nur ein paar wenige Passagen modifizieren, und sich so nicht überschneiden.

Wenn du auf der anderen Seite versuchst, sagen wir, zwei verschiedene Modifikationen an einem Kampfsystem einzubauen, könnte das Probleme geben sofern die Skripte sich irgendwo im inneren überschneiden.
Die Probleme die dabei auftreten sind meistens aus programmiertechnischer Sicht lachhaft (es sei denn jemand versucht z.B. eine Erweiterung für das Standard-Kampfsystem in einem eigenen einzubauen... hat's alles schon gegeben Oo), allerdings haben die meisten Skripter auch keine Lust sich um die Skripte anderer Leute zu kümmern, weshalb sowas für nicht-Skripter durchaus zum Problem werden kann.

Sofern du dein Spiel nicht mit allem möglichen Zeug zu den immer gleichen Themen zuknallst sollte es eigentlich keine Probleme geben. Von daher ist es meistens eher ein Problem für Newbies, die denken ihr Skript wird exponentiell besser mit der Anzahl der verwendeten Skripte - während sie selbst kein bisschen Ruby können.


@Ascare, was Performance angeht:
Der XP wird genaugenommen mit GDI gerendert, was auf den ersten Blick absolut hirnrissig ist. Auf der anderen Seite sehen viele bei dem Begriff "Hardware Beschleunigt" nur die Vorteile die das mit sich bringt. (enorme geschwindigkeit, CPU entlastung, etc.)
Wenn ich mir auf der anderen Seite die Ressourcen anschaue die einige XPler so erstellen, muss ich sagen, dass Hardware Beschleunigung ihnen sehr schnell einen Strich durch die Rechnung gemacht hätte. Ein Chipset mit den Maßen 256x38496 ist für eine Grafikkarte wie ein Buch mit sieben Siegeln.

Texturen (das heißt, Hardwarebeschleunigte Grafiken) müssen eine Größe von 2^n x 2^n haben, bei moderneren Karten auch 2^n x 2^m.
Um nun eine Grafik mit den Maßen 640x480 anzuzeigen, müsste man sie zuerst auf eine Zwischengrafik mit den Maßen 1024x512 bringen*, was die Anzahl der Pixel von 307200 auf 524288 erhöht, das heißt dein neues Bild hätte 217088 total unnötige Pixel!

Zusätzlich können Grafik Karten keine unendlich großen Texturen anzeigen, normalerweise sollte man keine Grafiken benutzen die größer als 1024x1024 pixel sind, und am besten sollte das ganze noch ein gutes Stück kleiner sein.

Und das waren nun bei weitem noch nicht alle technischen Einschränkungen. Sicher, es gibt hier und da Tricks um das zu umgehen, aber die Implementierung wird schnell sehr aufwändig, und komfortabler als Software Rendering wird es sowieso nie. Da der Maker aber dafür konzipiert ist einfach zu sein, hat Enterbrain sich wohl für Software Rendering entschieden, das keine dieser Einschränkungen hat.
Ich will sie zwar nicht verteidigen, die Performanz ist in meinen Augen immernoch schrecklich (Direct Draw wäre ähnlich komfortabel gewesen, aber immernoch viel schneller, wenn auch veraltet), aber das Programm an sich finde ich wirklich toll, und außerdem macht die Performanz auf aktuellen Rechnern schon praktisch keinen Unterschied mehr... und in ein paar Jahren wird das wohl überall so sein.

*)
Die offensichtliche Lösung wäre, das Bild in viele kleine Bilder aufzuteilen. (in diesem Fall könnte man es in 8 Bilder aufspalten, die exakt die Kriterien einer Graka erfüllen) Das klingt zwar sehr nett, aber wird leider das gesamte Geschehen verlangsamen. Ist mir jetzt zu viel Arbeit, zu erklären warum, aber das ist auch keine Lösung...
Eine Lösung wäre 2D Bin Packing, was extrem komplex wird wenn man einen möglichst optimalen Algorhytmus verwenden will. (was man auch tun sollte)

[Raiden]

Ich nutze den XP weil das Projekt sonst nicht ernst genug rüberkommt, leider ist hier das größte Manko des Makers, es fehlen realistische Resourcen. Ansonsten kann man wenig sagen, was daran schlechter sein soll. Wer kein Ruby kann, kann dennoch seine Spiele gestalten wie früher, schade ist nur, dass die Framerate bei Animationen von vielen Bildern in wenigen Millisekunden drastisch in den Boden sinkt - Videos sind ja ohne Programmierung nicht mehr erlaubt. Schade also, dass das Teil auf 'nem 3Ghz PC, 512 MB Ram, 6600 GT Grafik (NVidia-Chip) anfängt zu ruckeln, nur wegen ein paar lächerlichen Bildern.

[Stööö]

Klick mich
Könnte helfen.
Btw sind auch Partikeleffekte einbindbar, gab da 'n sehr schönes Script zu...

[~Jack~]

Das Script hab ich auch ma probiert aber nach dem einbauen is das Game immer abgestürzt und da ich kaum Ahnung von Ruby hab konnte ich es auch nich zum laufen bringen.

[Raiden]

Klick mich
Könnte helfen.
Btw sind auch Partikeleffekte einbindbar, gab da 'n sehr schönes Script zu...

...

Events sind ja nicht DAS Problem, aber die Anreihung vieler Pictures während einer Sekunde (wait 0,1 sec. - wenn ich da 20 Bilder setze, sodass eine Animation (halbwegs flüssig) ensteht, geht die Framerate in den Keller - kann doch nicht sein).

[Ryo Saeba 1000]

Also eigentlich bleiben jetzt von meinen Argumenten gegen den XP nur noch zwei übrig und zwar die Performance und der Preis..

Wenn man das mit der Performance in den Griff kriegen würde, dann würde ich den Preis allerdings verschmerzen können^^

Da Raiden es ebenfalls nochmal anspricht: Wie ist dass denn nun?
Okay, der XP verbraucht mehr Leistung wenn's darum geht irgendwelche dinge darzustellen (Events, Pictures) aber bei RICHTIG komplizierten und anspruchsvollen Berechnungen wie zB. Pathfinding und Pixelmovement dürfte er doch dank Ruby, dem RPG Maker 2k/2k3 meilenweit vorraus sein oder?

Ich hätte nähmlich schon vor, ein AKS mit Pixelmovement und ordentlichem Pathfinding zu scripten, aber habe wenig Lust dann zu merken, dass ein paar Berechnungen alles lahm legen.
Gleicht der RPG Maker XP vielleicht gar sein Geschwindigkeitsdefizit bei komplexen Berechnungen, dank Ruby wieder aus? Oder eignet sich Ruby nicht für solcherlei anspruchsvolle Berechnungsdinge?

[jwiechers]

Definiere komplexe Berechnungen.

Auch wenn ich jetzt keine genauen Zahlen dazu habe und auch definitiv zu faul bin das ganze auf Hardwareebene zu analysieren, garantiere ich dir, dass der XP bei komplexen Skripten (d.h. viele Schleifen und verschachtelte Konditionalien) um ein vielfaches schneller sein wird, als das proprietäre Maker-Skript, was im RPG-Maker 2000 und RPG-Maker 2003 verwendet wurde.

Was die Eignung von Ruby für Berechnungen angeht, da musst du wieder trennen und fragen: Im Vergleich zu was?
Klar, es gibt Sprachen die sind darauf optimiert mathematische Berechnugnen zu vereinfachen und eine solche ist Ruby in dem Sinne nicht, aber im Vergleich zu einer komplexen Berechnung im Maker-Skript ist es simpler, es in Ruby zu machen und garantiert auch schneller.
Ob das den Performance-Unterschied ausgleicht ist wiederum schwer zu sagen, denn dieser ist auf modernen PCs (und zur Not mittels eines beim Start der Game.exe angefügten /priority:high-Schalters) wohl kaum wahrnehmbar, außer es geht um außergewöhnlich komplexe Systeme, ich würde pauschal aber sagen, ja.

[Ryo Saeba 1000]

Komplexe Berechnungen die ich gerne durchführen würde, wären zB. A*Pathfinding im großen Rahmen -> mit großen Entfernungen (100+Tiles) und mehreren Einheiten gleichzeitig.. beim alten RPG Maker dauerte das bei einer einzigen Einheit schonmal einige Sekunden.. dank Ruby werd ich das hoffentlich enorm optimieren können.


Ich denke dass muss ich aber wohl selbst herausfinden, ob der RPG Maker XP das kann, was ich von ihm will.. mit einer "herkömmlichen" Programmiersprache wäre ich zwar auf der sichererern Seite, aber man kann's ja mal ausprobieren, wie weit ich damit komme, auch wenn mein Spiel dann nur auf einem 2GHz Rechner flüssig läuft.. solange es die Performance des alten RPG Makers schlägt, hat sich's gelohnt.

Ihr habt's geschafft und einen weiteren 2k/2k3 User konvertiert xD ich werde mit dem RPG Maker XP arbeiten, wobei ich jetzt natürlich zuerst ein paar Ruby Tutorials lesen werde.

[ani-kun]

das einzige was beim XP (nach meiner erfahrung^^) performance frisst, ist das laden von ressourcen > dem kann mit einem einfachen script, dass die ressourcen in den cache lädt abgeholfen werden ...

[jwiechers]

Naja, das und das grafische Rendering halt. Das könnte man allerdings auch wieder optimieren wenn man Grafiken entsprechend standardisiert und, wie du sagst, Caching einbaut.
Man könnte mal schauen, ob man sich nicht zusammen hinsetzt und z.B. ein Animationsformat auf PNG oder MNG-Basis für den RPG-Maker XP entwickelt und "standardisiert", sobald dafür die Zeit zur Verfügung stünde.

[ani-kun]

nyu, das caching hätte ich ja schon fertig, als schönes allgemeines script, wo man alles mögliche cachen kann (also je nach ressourcen-art, alle dieser resourcen, eine bestimmte oder alle die mit nem definierten text anfangen ...) > durch intelligenteres ressourcenmanagement kann man das dann super im spiel einsetzen (zb. alle ressourcen beim betreten des dorfes mit einem simplen scriptbefehl in den cache geben > lädt dann zwar beim betreten kurz, aber bringt imho doch ne gewaltige verbesserung^^)

meinst du beim standardisieren jetzt die quelldatei oder im maker selber?

[jwiechers]

Oh, wenn du das schon fertig hast, Drake und ich haben eben ein wenig darüber gesponnen; kannst du etwas zum Speicherverbrauch bei einem solchen Caching sagen?

meinst du beim standardisieren jetzt die quelldatei oder im maker selber?

...

Man kann ja in dem Sinne nur dei Quelldatei "standardisieren", bzw halt ausarbeiten. Es wäre aber in meinen Augen weniger der Code, der relativ simpel sein sollte, als viel eher die Strukturierung der Grafik die Frage.