Liste von Objekten (Speichern, Laden, usw.)

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Liste von Objekten (Speichern, Laden, usw.)

    Hallo,

    Mein Spiel erfordert ein speicherbares Inventar (bzw. mehrere), welches unterschiedliche Gegenstände beinhalten soll. Jeden dieser Gegenstände würde ich gerne als eigenes Objekt im Game Maker speichern. So weit, so gut. Jetzt stellt sich mir allerdings die Frage, wie ich diese Speicher- und Recheneffizient anlege.

    Mein erster Versuch war eine ds_list mit allen Objekten als eigene Instanz. Zum Speichern wird jeder object_index in eine ini geschrieben. Beim Laden werden diese Objekte wieder in der Liste instanziert (damit ich auf die gespeicherten Werte zugreifen kann). Diese Lösung funktioniert zwar, allerdings bin ich nicht ganz zufrieden damit, permanent alle Inventar-Objekte im Speicher zu haben, da das bei größerer Anzahl an Gegenständen möglicherweise zum Problem führen könnte (Speicherintensiv).

    Meine zweite Idee wäre diese Gegenstände erst, wenn ich auf die Werte des Gegenstandes zugreifen will, zu instanzieren und danach wieder zu zerstören (Rechenintensiv).

    Die erste Methode hat zusätzlich das Problem, dass mehrere gleiche Gegenstände mehrfach instanziert werden, obwohl eine Instanz völlig reichen würde, wäre meiner Meinung nach aber trotzdem besser, da Speicher eher vorhanden ist als Rechenleistung.

    Hat jemand eine Idee, wie ich das möglichst effizient umsetzte bzw. ob meine oben genannten Zweifel an der Performance meiner bisherigen Lösungen überhaupt gerechtfertigt sind, das Spiel sollte letzten Endes auch auf schwachen Smartphones laufen (habe zurzeit allerdings kein (schwaches) Gerät zum Testen). Bin für alle Vorschläge offen. Ich spiele auch mit dem Gedanken, alle Gegenstände extern als ini bzw. Binärdatei zu erstellen und sie wie eine Datenbank zu laden.

    Ich bedanke mich für jede Hilfe im voraus.

    PS.: Wie verhält sich der object_index eigentlich genau? Kann es sein, dass dieser sich ändert, wenn ich neue Objekte anlege? Kann es gerade nicht testen, aber wäre ja nicht sehr optimal zum speichern.
  • Ich denke, ich würde die speicherintensivere Methode wählen, da ich nicht glaube, dass du mit der INI Datei an Grenzen stößt. Auch nicht auf mobilen Plattformen.

    Der object_index konnte sich zumindest in älteren GM Versionen ändern. Da entsprach der index der Position im resourcen-tree, wenn ich mich recht erinnere..
  • Der object_index konnte sich zumindest in älteren GM Versionen ändern. Da entsprach der index der Position im resourcen-tree, wenn ich mich recht erinnere..


    Bringt auch in GM:S immernoch Probleme mit sich. Wenn man die Reihenfolge der Objekte im Tree verändert ändern sich auch die ids.
    Sorm ist Schuld

    Edit: Doch ist er
  • Ok, danke.
    Ich werde mir wohl noch etwas anderes überlegen müssen.
    Alerdings ging es mir nicht um die Größe der ini, sondern, dass alle Gegenstände instanziert sein müssen um auf die Werte zuzugreifen, was natürlich im Arbeitsspeicher abgelegt werden muss. Das könnte bei nehmen wir an 1000 Gegenständen im Inventar (ist natürlich nur ein Extremfall) möglicherweise zum Problem werden.


    Ich habe jetzt ein paar Tests durchgeführt. Der Arbeitsspeicher scheint nicht das Problem zu sein allerdings die Rechenzeit (keine Ahnung warum, hat wohl mit der Engine zu tun, da die Objekte weder Step- noch Draw-Events besitzen, werden aber wohl trotzdem irgendwo aufgerufen).
    Mit 1000 Objekten im Inventar sinkt die (reale) Framerate am PC von 3000-4000 auf ungefähr 2000. Mit 10000 Objekten sinkt sie auf ca. 400.
    An meinem, etwas betagteren Android-Tablet sinkt sie mit 1000 Objekten von 400-600 auf 200.
    Das ist zwar nur ein Grenzfall, aber wirklich zufrieden stellt es mich nicht.

    Und den object_index werde ich mit der asset_get_index() Funktion umgehen. Solange ich nichts an den Namen der Objekte ändere, sollten sich dabei auch bei neueren Versionen des Spieles keine Probleme ergeben, die Objekte zu laden.