(Reale) Ladezeiten in Makerspielen

Dann auch hier einmal:

Hallo Leute,
da ich aktuell an einem kleineren Riesenprojekt arbeite (RMMV) und gerade mit der technischen Umsetzung beschäftigt bin, wollte ich mal ein paar allgemeine Meinungen zu dem Thema einholen.
(Ich beziehe mich hierbei vorrangig auf tatsächliche Ladezeiten, welche bei größeren Karten in Verbindung mit Overlaymapping auftreten können.)

Aktuell schaut es bei mir so aus, dass ich ca. 6 Sekunden warten muss, bevor das Stadtviertel mit den Maßen 220x143 geladen ist. Die Karte ließe sich grundsätzlich natürlich zerteilen, jedoch werden die allgemeinen FPS von der enormen Größe (abgesehen von einem Teil der Karte mit animierten Autotiles) nicht beeinflusst.
Für mich würde außerdem dagegen sprechen, dass ich so Events bequemer kontrollieren und eher eine Art "Open-World"-Atmosphäre erzeugen kann.

Von Haus aus ist man bei Makerspielen ja doch sehr knappe Ladezeiten gewöhnt. Deswegen meine Frage:
"Wen würde es stören, wenn man für die Hauptkarte tatsächlich mal eine kleine Ladepause einlegen muss?"

Ich hoffe natürlich auf vielfältige Antworten, welche im Idealfall eine anregende Diskussion begünstigen. :)

Ich würde im RPG-Maker auf große Maps verzichten, noch mögen deine FPS davon nicht beeinflusst werden, spätestens wenn du aber paar NPCs und Events reinpackst, geht es schlagartig in den Keller. Das war einer der Gründe, warum ich damals die Engine gewechselt habe. Durch geschickte Teleportevents kannst du dem Spieler vorgaukeln, dass alles auf einer großen Map stattfindet.

Zitat:

---

Zitat von ChimaereJade

Die Karte ließe sich grundsätzlich natürlich zerteilen, jedoch werden die allgemeinen FPS von der enormen Größe (abgesehen von einem Teil der Karte mit animierten Autotiles) nicht beeinflusst.

---

Mit "allgemeine FPS" meinst du also, dass es da schon Probleme gibt, oder? Und da du bereits erwähnst, dass es bei Autotiles Komplikationen gibt, würde ich mir überlegen, die Maps nicht doch zu zerteilen. Und als Ersteller solltest du immer bedenken, dass deine Spieler auch deutlich leistungsschwächere Systeme verwenden als du. Riesige Maps macht man meist ja auch eher, weil man riesige Maps will, nicht weil es sinnvoll ist. Kleinere Maps helfen dem Spieler auch eher, sich nicht so verloren zu fühlen und Anhaltspunkte zu haben. Eine einzelne riesige Map muss nicht sein, wenn es sich vermeiden lässt. Sofern es vom Levelaufbau nicht verlangt wird und es schmalere Durchgänge gibt, ist es immer möglich und empfehlenswert auch mal einen Teleport zu einer anderen Map zu setzen. Wenn du die Maps viertelst, sind diese immer noch gewaltig genug und bewahrt dich davor unnötig viel Raum ausfüllen zu müssen. Kommt natürlich darauf an, wie du deine Maps aufbaust.

Ladezeiten sind natürlich immer so eine Sache. Hatte auch mal welche, aber eher unnötig. Also künstlcih durch schlechtes Eventen hervorgerfen und daher nicht "real". Würde Ladezeiten auch in einem Makerspiel verschmerzen. Aber wenn ich das Gefühl habe, dass der Ersteller einfach nur Mist gebaut hat oder ich nicht nachvollziehen kann, warum ich da bei jedem Mapwechsel warten muss, dann beschert das einen bitteren Beigeschmack. Das wäre für mich kein Grund das Spiel zu beenden, aber wie gesagt ein Dorn im Auge, da viele ja selber entwickeln und sich auch mal schnell ein Urteil bilden, das nicht aus Spielersicht kommt.

Und wie bei Schotti kann es vorkommen, dass man einen wechsel der Engine in Betracht ziehen sollte, wenn sich herausstellt, dass diese nicht die richtige Plattform für die eigene Spielidee ist. Bin selber auch eher der Gewohnheitsmensch, der beim Maker bleibt, selbst wenn man sich dadurch vieles erschwert und Kompromisse eingehen muss. Einfach aus Bequemlichkeit undso, wobei es am Ende aber auch weniger effizient ist.


Und was bitteschön ist "Overlaymapping"?

Wenn ich häufiger in die und aus der Stadt gehen muss, würden mich 6 Sekunden Ladezeit schon störend. Das größere Problem sind aber die von Nagasaki angesprochenen Lags. Selbst auf den alten Makern könnte eine so große Map voller Events schon laggen, auf den neuen erst recht.

Zitat:

---

Zitat von Nagasaki

Und was bitteschön ist "Overlaymapping"?

---

Grob gesagt, nutzt man per Script alternative Layer, um das Mappingsystem des VX/-Ace und MV zu umgehen und beliebig viele und vom Raster unabhängige Ebenen auf der Map zu nutzen (stellst du dann meist eher im Grafikprogramm zusammen). Der Vorteil ist, dass du diese Ebenen über dem Spieler, Events und "normal" gesetzte Tiles, aber auch darunter legen kannst. Quasi wie Pictures, die du umfangreicher (und auf einer Map gebunden) nutzen kannst.

MfG Sorata

@Sorata:
Ah, danke für die Aufklärung. =)
Also im Prinzip Parallax-Mapping und Pictures, wenn man das auf den alten Makern machen will. Kann man das nicht einfach aufteilen und erst in kleineren Häppchen dazuschalten, wenn man sich über die Map bewegt? So würde ich es zumindest auf dem 2k3 bei der Verwendung von Pictures umsetzen. Sollte durch javascript sicher bedeutend einfacher sein. Generell mehr Aufwand, aber ressourcensparender.

Theoretischerweise schon, wenn man es entsprechend programmiert. Die mir bekannten Scripte, lösen das aber halt beim Laden der jeweiligen Map.
Abgesehen von Overlay-/Parallax-Mapping sollte man mMn bei etwas größeren Maps aber auch auf Antilag-Scripte zurückgreifen.
Für den XP verwende ich da jedenfalls ein Script, das nur Events updatet/abarbeitet, die im Blickfeld des Spielers sind. Außer, es handelt sich um ein Parallel Process-, ein Autostart- oder von mir markiertes Event. Ist zumindest sinnvoller, nur Events zu updaten, die auch im Moment für den Spieler relevant sind.

MfG Sorata

Hey Leute,
vielen Dank erst einmal für die rege Teilnahme! :)

@Schotti:
Mit einem Enginewechsel hatte ich auch schon geliebäugelt, aber bleib dann doch der von Nagasaki bereits erwähnte Gewohnheitsmensch, da ich all die Jahre mit dem Maker nicht vollkommen unproduktiv beenden wollte. Ein richtig gutes AKS mit Pixelmovement kann ich mir ohne JS-Kenntnisse jedenfalls abschmieren. x)

@Nagasaki:
Die Lags bezogen sich wirklich nur auf die Orte, wo viel animiertes Gewässer zu sehen ist. Wenn ich mich recht entsinne, traten diese Performanceeinbußen aber auch auf der Beispielweltkarte des MV auf, wenn man die Auflösung leicht erhöht hatte. Ansonsten läuft das Spiel durchgehend mit 58-60FPS. :)

@Kelven:
Das kann ich gut nachvollziehen - vorallem wenn es viel Backtracking geben würde und einzelne Orte keinen großen Mehrwert aufweisen...

Allgemein:
Events dürfte es nicht soo viele geben, da ich eine sehr verlassene Gegend darstellen möchte. Mein einziges Problem mit dem Splitten wäre jetzt nur, dass ich noch eine einblendbare Minimap einbauen wollte, welche dann die Illusion einer großen Karte wieder zunichte machen würde. :/

6 Sekunden jedes mal wenn ich aus einem Haus oder so wieder raus gehe? Klingt furchtbar.

( 220 * 48) x ( 143 * 48 ) = 10560 x 6864 px Grafik. 72483840 Pixel pro Bild. Also in der Größe ein Panorama und eine Overlay-Grafik.

Die MV Grafiken sind 32 Bit, 8 Bit je Farbkanal und 8 für den Alphawert.

72483840 Pixel pro Bild * 32 Bit / Pixel =
2319482880 Bit pro Bild / 8 =
289935360 Byte pro Bild / 1024 =
283140 KByte pro Bild / 1024 =
276,5 MByte pro Bild

Und davon zwei, Panorama und Overlay. Also grob ein halbes Gigabyte an Daten, was da bei jedem Betreten der Map reingeladen wird.
Natürlich sind deine Dateien im Projektordner nicht so groß weil sie dort komprimiert sind. Das macht sie zwar kleiner, aber sie müssen auch entpackt werden, um sie anzeigen zu können. Was der Maker da intern macht, kann ich dir nicht sagen, ob die als Bitmapdaten entpackt rumliegen wie bei älteren Makern, oder ob da irgendwelche Daten draus geschnibbelt werden, die über einen Grafikbeschleuniger dargestellt werden.

Wenn dein Spiel vor allem an dem Ort spielt, könntest du eine Art Caching einbauen, dass die Grafiken dieses Ortes vorhält, man kann in den neuen Makern ja tief in die Organe greifen. Mit dem Nebeneffekt, dass dein Spiel die 550MB RAM besetzt selbst wenn man nicht auf der Map wäre.

Zitat:

---

Zitat von Corti

Mit dem Nebeneffekt, dass dein Spiel die 550MB RAM besetzt selbst wenn man nicht auf der Map wäre.

---

Wayne, jeder Laptop hat heute 16gigs und ein paar Tabs im Chrome wiegen schon mehr.

Kanns mir gar nicht vorstellen 6 sek. Delay zu haben...
"Damals" hatte ich auch eine worldmap mit einer 300x300 map und einigen events. Mein kleiner Laptop hatte da aber keine Ladezeiten... Nur der Charakter hat gelagt ;)

Vielleicht liegt es bereits an deinem PC?

Zitat:

---

Zitat von Tako

Wayne, jeder Laptop hat heute 16gigs und ein paar Tabs im Chrome wiegen schon mehr.

---

Erzähle dies mal der "Java ist Kacke, weil Minecraft mehr als 1 GB RAM braucht!!!!"-Fraktion ;)
Ist der RPG-Maker auch 64-Bit tauglich? Bei 550 MB allein nur für eine Map kann es durchaus bei einer 32-Bit Anwendung zu Problemen kommen.

@Corti:
Als grobe Rechnung klingt da ja schon abschreckend, aber ich gehe jetzt mal von max. 200MB für beide Bilder aus, da sie sich ja pixelgenau ergänzen und nicht mehrfach überlagern sollen. Außerdem strebe ich eine relativ entsättigte Farbpalette an, was vllt den Großteil der Fläche simpler halten könnte. Aber da muss ich gestehen, dass ich kein Fachmann bin. x)

Wahrscheinlich werde ich dann aber wirklich den Weg der Stückelung gehen, wobei mich da natürlich interessieren würde, ob 4 kleinere Karten mit derselben Dateninformation mehr RAM und Speicherplatz verbrauchen würden, als eine einzige, unfassende Datei.


@Tako/Whiz-zard:
Das klingt jetzt aber schon leicht überspitzt. Im Durchschnitt würde ich eher von 4GB RAM bei Laptops ausgehen, da sich die Wenigstens einen "Highend-Laptop" kaufen dürften, wenn ein Tower-PC wesentlich günstiger ist.

@Memorazer:
Ich weiss ja jetzt nicht, auf welche Makerengine Du Dich beziehst, da der MV standardmässig auch nur 256×256 zuzulassen scheint.
Mein Rechner hat zwar noch einen älteren Quadcore (Q9950), aber daran und dem Rest (GTX770), 8GB DDR2 sollte es nicht liegen. Ich tippe da eher auf die bereits vielfach angesprochenen Performanceprobleme des MVs bei einer zu großen Anzahl an Autotiles, welche evtl dem aktuell noch vorkommenden Memory Leak anzurechnen sind. :/

Zitat:

---

Zitat von ChimaereJade

@Corti:
Als grobe Rechnung klingt da ja schon abschreckend, aber ich gehe jetzt mal von max. 200MB für beide Bilder aus, da sie sich ja pixelgenau ergänzen und nicht mehrfach überlagern sollen. Außerdem strebe ich eine relativ entsättigte Farbpalette an, was vllt den Großteil der Fläche simpler halten könnte. Aber da muss ich gestehen, dass ich kein Fachmann bin. x)

---

Deine entsättigten Farben sind für die Datenmenge völlig egal.
Ob die sich überlagern oder nebeneinander liegen, ist völlig egal.
Ob der Großteil davon Transparenz dargestellt wird, ist völlig egal.
Auf welche Größe die PNG auf der Festplatte runterkomprimiert wurde, ist völlig egal.

Zitat:

---

Wahrscheinlich werde ich dann aber wirklich den Weg der Stückelung gehen, wobei mich da natürlich interessieren würde, ob 4 kleinere Karten mit derselben Dateninformation mehr RAM und Speicherplatz verbrauchen würden, als eine einzige, unfassende Datei.

---

Durch eine Stückelung erreichst du, dass für eine der Maps dann weniger Daten benötigt werden und somit auch die Ladezeit geringer ist. Dafür muss man dann öfter Laden beim Mapwechsel zwischen den Teilen.

@RAM:
Für moderne PCs und Laptops würde ich mir keine Sorgen machen. Aber man kann MV Spiele auch auf Smartphones und im Web spielen.

Ok, diese Ansage war deutlich. Ich hätte jetzt gedacht, dass Bilder ressourcenschonender sind, wenn sich die Farbinformationen stark ähneln (entsättigt in meinem Falle). Ich bin auf jeden Fall mal gespannt, wo die Reise hingehen wird.

Der zweite Abschnitt bezog sich darauf, was beste "Kosten/Nutzen-Verhältnis" wäre, aber ist im kleinsten Detail wohl wirklich irrelevant, sodass die einfache Ausführung (weniger Auslastung, häufiger laden) auch reicht.

Vielen Dank jedenfalls an alle, ich bin in meiner Entscheidung schon deutlich weiter gekommen. (Stückelung) :)

Zitat:

---

Zitat von Corti

Deine entsättigten Farben sind für die Datenmenge völlig egal.
Ob die sich überlagern oder nebeneinander liegen, ist völlig egal.
Ob der Großteil davon Transparenz dargestellt wird, ist völlig egal.
Auf welche Größe die PNG auf der Festplatte runterkomprimiert wurde, ist völlig egal.

---

Naja, es ist ja nicht so, als würden Grafikkarten nichts von Kompressionen verstehen.
Auch innerhalb des Grafikspeichers werden Texturen komprimiert. z.B. mit dem S3TC- oder in Smartphones mit dem ETC-Verfahren.

Zitat:

---

Zitat von ChimaereJade

Ok, diese Ansage war deutlich. Ich hätte jetzt gedacht, dass Bilder ressourcenschonender sind, wenn sich die Farbinformationen stark ähneln (entsättigt in meinem Falle).

---

Ja und Nein.
Im allgemeinen können Bilder sparend abgespeichert werden (kompression), das wird auch vielseits so gemacht. Das bedeutet aber nicht, dass der RPG-Maker das macht. Ich habe den MV nicht aber ich weis, dass die älteren Maker die Bilder unkomprimiert verwendet haben.
Moderne Anwendungen, welche mit OpenGL oder DirectX arbeiten sind allerdings in der Lage sehr viel weniger Speicherplatz zu verwenden, falls das Bild große einfarbige oder Transparente Flächen besitzt oder nur eine reduzierte Farbpalette benutzt. Ich glaube aber nicht, dass der RPG-Maker soetwas tut.

Grafikkarten ja, moderne Grafik-APIs auch. Aus für Nichtprofi-Entwickler pragmatischen Gründen benutzt der Maker PNGs als Datenformat, kommerzielle Spiele haben ihre Texturen bereits in für die Hardware günstigem Format vorliegen, dxt1 bis dxt5, dds etc. sind ja alles S3TC-varianten. Wenn der MV sowas kann, dann könnte man auch den Weg gehen die Bilddaten in einem solchen Format bereit zu stellen.

Der MV benutzt als Grafikausgabe Pixi.js das benutzt WebGL. WebGL -> OpenGL ES. Müsste es also können. Was davon bereits genutzt wird und was man optimieren könnte, kann ich natürlich nicht sagen. Eine Grafik von 10560 * 6864 px wird man auf jeden Fall nicht im PNG Format als eine Textur in die Grafikpileline schieben können. Diese Grafikdaten müssen also noch irgendwie bearbeitet werden.

PNG ist sowieso kein Format, was eine Grafikpipeline kennt. Die Bilddaten müssen auch nicht im RAM gehalten werden wenn man sie anzeigen will. Man kann die PNG laden; muss sie dann umwandeln in ein Format, welches die Grafikkarte mag; diese Daten dann auf die Grafikkarte übertragen und die Daten im RAM löschen. Das Format, in welchem die Daten auf der Festplatte liegen ist irrelevant für die Grafikausgabe. Was bei dem RPG-Maker jedoch ist, ist dass man (zumindest beim XP und VX) mit dem Ruby Code auf die Farbwerte der einzelnen Pixel zugreifen kann. Damit soetwas möglich ist müssen die Bilddaten natürlich im RAM gehalten werden.

Komprimierte Texturen auf Mobilsystem sind eh so ne Sache. iirc hat man bei OpenGLES 2.0, worauf WebGL 1 basiert, dort nur eine Garantie auf ETC1, was keinen Alphakanal unterstützt. Alle anderen Formate in der Generation sind herstellerspezifisch und können wahrscheinlich nicht einmal zur Laufzeit generiert werden (zumindest für PVRC gibt's nichts dergleichen).

Zumal sich nebenbei auch die Frage stellt: Verlustbehaftete Texturkompression für 2D Pixelart? Resourcensparen ist schön und selektiv macht das noch Sinn. Automatisch auf jede Grafik wäre es aber wohl eher kontraproduktiv für die Optik, so minimal der Effekt auch sein möge.