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