Ergebnis 1 bis 20 von 20

Thema: (Reale) Ladezeiten in Makerspielen

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Zitat Zitat von ChimaereJade Beitrag anzeigen
    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"?

    Geändert von Nagasaki (20.06.2016 um 03:31 Uhr)

  2. #2
    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.

  3. #3
    Zitat Zitat von Nagasaki Beitrag anzeigen
    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

  4. #4
    @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.

  5. #5
    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

  6. #6
    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. :/

  7. #7
    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.

  8. #8
    Zitat Zitat von Corti Beitrag anzeigen
    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.

  9. #9
    Zitat Zitat von Tako Beitrag anzeigen
    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.

    Geändert von Whiz-zarD (20.06.2016 um 16:38 Uhr)

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •