Ich finde es traurig, dass man im XP alles über RGSS lösen muss. So ganz normale Sachen wie KampfSysteme und Menüs kann man im XP, selbst wenn man wollte, gar nicht mehr ohne Ruby machen, weil er dann, wie besagt, sofort mit Ruckeln anfangen würde. Ich persönlich würde mir keinen Maker kaufen, für den ich extra noch eine Scriptsprache lernen muss. Da kann ich gleich zu einer echten Programmiersprache greifen.
Das ist echt das größte Manko - und auch nur weil es anders nur ruckeln würde.
Ninja
--
Immer auf dem neuesten Stand sein: Der Blog von RosaArts
Lust auf eine Runde Smalltalk in gemütlicher Runde: RosaArts - Das Unterforum des RPG-Atelier
Hallelujah! Endlich gibt es meine Bücher auch auf AMAZON!
Ne, das stimmt nicht. Ich hab zu Anfang beim XP das Menü genauso wie beim 2K gemacht und es hat nicht stärker gelaggt als dort (geruckelt sowieso nicht). Beide Maker haben Probleme damit viele Pictures und Charsets zu aktualisieren, ich hatte im schlimmste Fall Wartezeiten von einer gefühlten Sekunde bis der Cursor weitersprang; wie gesagt auch auf dem 2k. Ich kann aber nur für ein normales Custom-Menü auf einer eigenen Map sprechen, keine Ahnung wie es mit einem HUD aussieht. Bei einem KS sollte man übrigens noch weniger Probleme haben, da dort weniger Grafiken aktualisiert werden müssen.
Also das ist einfach nur falsch. Viele übertreiben es einfach mit ihrer "xp ruckelt, ohne rgss keine chance" Einstellung. Ich selbst habe ein HUD und ein eigenes SkillMenü mit Events aufgebaut und da ist wirklich nix am ruckeln! RGSS dient da wirklich nur als Hilfe und um diverse Sachen leichter umzusetzen. Z.B. läuft für mein HUD die Berechnung von HP und MP über 4 RGSS (2 für die Berechnung und 2 für die Anzeige der Balken) Zeilen in einem Parallel CE. Ist übersichtlicher, man könnte es aber genau so gut über Events machen. Das Skill Menü ist komplett mit Events gelöst.Zitat von Makerninja
Auch muss man nicht für jede kleine Sache gleich ein neues Picture haben und anzeigen lassen. Da ist auch der Ersteller gefragt, durchdachte Pictures zu erstellen und anzeigen zu lassen. Mit etwas Geschick kommt man da mit weniger als 40 pics (was ja schon an sich ziemlich viel ist) mit sicherheit zu Recht.
Außerdem, was heißt "beim XP"? Beim neuen VX ist es auch nicht gerade viel besser bzgl. Lagging, auch wenn die FPS jetzt bei 60 liegt.
greetz
Es macht keinen Unterschied, ob man ein Picture über ein Event-Befehl, oder über die API (RGSS) anzeigt, die verbrauchten Ressourcen sind identisch.
Du vergleichst hier Welten miteinander. Es ist ein enormer Unterschied, ob man die eingebettete Skriptsprache und die API verwendet, oder ob man von Grund auf eine neue Engine mit einer Hochsprache wie C++ programmiert. Und selbst wenn du dich an einer eigenen Engine versuchst, wirst du um eine Skriptsprache nicht herum kommen, weil eben der Sinn hinter dieser eine Erleichterung beim eigentlichen Game Development ist.
Eine Skriptsprache zu erlernen benötigt nicht viel, denn im Grunde musst du nur die Syntax einzusetzen wissen. Die Kommunikation zwischen Skript und Engine läuft sowieso über die API, so dass die API eigentlich das ist, womit du dich eine Zeit lang auseinandersetzen wirst.
Der Maker bietet so schon mehr Vereinfachung per Drag&Drop-Prinzip, als es irgendeine andere Engine tun würde, mehr geht in meinen Augen nicht.
Mit RGSS und Ruby hast du nun aber auch die Möglichkeit diese Vereinfachungen - die deine Möglichkeiten stark limitieren - zu umgehen und wie ein echter Spiele-Entwickler an die Sache heranzugehen.
Zweitens mag ja stimmen.
Aber erstens stimmt so gar nicht. Es macht schon einen Unterschied aus, ob ich ein KS in einem einzigen Rubyscript aufbaue oder ob ich das KS aus Events, mit zig paralellen Ereignissen und ganz vielen statischen (HP Zahlen etc) aufbaue. Das es afaik über Events fast unmöglich ist, sehe ich am KS eines Freundes. Bei ihm läuft der XP ruckelfrei, doch sein selbstgeskriptetes KS (mit Events) ruckelt wie die Sau (und er hat keine Fehler wie vergessene Waits oder ähnliches drin). Auf meinem Rechner läuft der XP serh schlecht, ein RubyKS wie z.B. das von Cybersam läuft aber selbst bei mir ruckelfrei.
Und das dürfte keine Ausnahme sein.
Ninja
--
Immer auf dem neuesten Stand sein: Der Blog von RosaArts
Lust auf eine Runde Smalltalk in gemütlicher Runde: RosaArts - Das Unterforum des RPG-Atelier
Hallelujah! Endlich gibt es meine Bücher auch auf AMAZON!
Wieso stimmt ersteres nicht? Ich habe von reinem Picture-Anzeigen geredet.
Naja, dass viele Events den Maker in die Knie zwingen ist ja bekannt und wurde u.a. hier auch schon einige Posts oben von Kelven bestätigt. Die Schuld dafür trägt entweder schlechte Programmierung oder ein langsamer Ruby-Interpreter.
Wenn man die Anzahl der Events niedrig hält, ist sicher auch ein, nur auf Event-Commands aufbauendes KS möglich. Ich möchte auch offen halten, dass dein Freund womöglich auch nicht gerade effizient an die Sache rangegangen ist, Waits sind nicht das Einzige worauf man achten sollte.
Edit:
Gibt es eigentlich Geschwindigkeitsunterschiede in der Ausführung von Common Events und Map Events?
Geändert von Kyuu (06.02.2008 um 13:10 Uhr)
Es ist sein drittes KS, und nur weil er nicht im Internet bekannt ist, heißt das nicht, dass er zu doof ist ein KS zu proggen -.-* Sein KS reduziert schon alles auf ein Minimum um eine möglichst gute Leistung zu erzielen. Ruckeln tuts bei mir wie gesagt trotzdem, während diverse RubyKS einwandfrei und ruckelfrei laufen.
Wobei ich jetzt mal behaupte, dass auch der gute Lachsen kein (auf 1,6Ghz und 768MB Ram) 100% ruckelfreies eventbasiertes KS mit dem XP hinbekommen kann.
Ich verstehe nicht, warum du behauptest, dass RubyKampfsysteme genauso viel Leistung ziehen, wie eigene eventbasierende Kampfsysteme. Teste es doch einfach mal selber -.-*
Ninja
Zu deiner Frage: Ich glaube, das CommonEvents einen Tick schneller waren, lege dafür aber nicht meine Hand ins Feuer.
--
Immer auf dem neuesten Stand sein: Der Blog von RosaArts
Lust auf eine Runde Smalltalk in gemütlicher Runde: RosaArts - Das Unterforum des RPG-Atelier
Hallelujah! Endlich gibt es meine Bücher auch auf AMAZON!
Map Events haben eine höhere Priorität, aber ich denke nicht, dass sich die Geschwindigkeit unterscheidet.
@Makerninja
Wann bzw. bei was tritt denn das Ruckeln auf? Evtl. wird ja der Bildschirminhalt zu oft aktualisiert oder es wird unnötig viel Eventcode ausgeführt. Die Probleme, die ich im Menü mit dem laggen hatte, kamen alleine durch die Länge des Eventcodes (das Parsen der Befehle kostet halt auch Zeit). Dann könnte auch das rekursive Aufrufen der KS-Routinen Schwierigkeiten machen, so was wird ja oft in Maker-Kampfsystemen gemacht.
@Kelven:
Darum drehte sich mein Post eigentlich nicht. Ich wollte nur darauf hinweisen, dass eigene Kampfsystem (auch selbst gemachte oder ganz einfach gehaltene) bei mir ruckeln, während die RGSS-Scripte für Kampfsystem aus dem Netz, die in etwa das gleiche boten, ruckelfrei liefen.
Wenns bei dir nicht ruckelt: Glück gehabt, dann hast du einen guten Rechner.
Und das ewig lange Fork-Abfragen zu Rucklern (oder laggen -.-) führen können ist mir durchaus bewusst. Das hab ich schnell selber gemerkt.
Ninja
--
Immer auf dem neuesten Stand sein: Der Blog von RosaArts
Lust auf eine Runde Smalltalk in gemütlicher Runde: RosaArts - Das Unterforum des RPG-Atelier
Hallelujah! Endlich gibt es meine Bücher auch auf AMAZON!
Hör auf zu pauschalisieren.
Ich habe nie behauptet, dass Ruby-Kampfsysteme gleiche Leistung bringen wie Event-Kampfsysteme, sondern nur dass es keinen Unterschied macht, ob man ein Picture in einem Event oder in einem Ruby-Skript anzeigt.
Daraus folgt nämlich, dass die Schuld für Performanceverluste bei Event-Kampfsystemen in der Menge (und wie Kelven sagte, in der Länge) der Events zu suchen ist, die so ein Kampfsystem verschlingt. Jedes Event auf einer Map muss durchlaufen und interpretiert werden, egal ob es nur Zahlen-Events oder sonst welche sind. Im Vergleich kommt ein Ruby-Kampfsystem mit vielleicht zwei, drei Skripten weg. Hinzu kommt noch, dass Event-Kampfsysteme auf Map-Events basieren, die natürlich die Map Engine voraussetzen und diese wiederum Ressourcen frisst.
Und ich behaupte immernoch, dass man ein Event-Kampfsystem auf die Beine stellen kann, das wenig Events verschlingt und flüssig läuft. Alles eine Sache der Optimierung.
Berechtigungen
Zitieren