Wie funktionieren die Slots der SaveGame Nodes?

  • Hallo


    Es gibt ja die folgenden Nodes zum Speichern und Laden:



    Unter "Slot Name" kann man ja irgendeinen Namen eintragen.

    Weiß aber jemand wie und wo diese Slots dann abgespeichert werden? Weil ich finde es ein wenig merkwürdig dass es nur darüber bestimmt wird welchen Namen wir dort eintragen.


    Weil ich hatte vorhin folgenden Bug / Problem. Ich habe ein System in dem ich die Audiosettings abspeichern kann. Dies klappte aber aufeinmal nicht mehr. Wahrscheinlich weil ich das Projekt von einer Engine Version auf die Nächste gelegt habe. (4.26)

    Naja, jedenfalls sagte er mir ständig dass es den benannten Slot gibt, aber das "Cast to" zum SaveGame BP schlug immer fehl. Ich musste erst umständlich durch "Delete Game in Slot" den vorhandenen Slot löschen damit keiner existiert und dadurch mein SaveGameBP created wird und somit wird der Slot erstellt usw..


    Ganz Kurz: es war alles sehr umständlich.



    2. Ich habe zB für meine AudioSettings eine eigene Funktion zum Speichern und Laden und einen eigenen Slot benannt. Dies wollte ich dann auch für die VideoSettings usw machen. Die eigentlichen SaveGames werden dann auch extra abgespeichert.

    Macht das so Sinn? Die Slots für die Settings sind quasi global für jeden. Die werden halt beim Starten geladen und bei Änderungen gespeichert, fertig.

    Oder macht ihr es so dass ihr tatsächlich einen riesen großen Struct habt wo einfach alles reingeballert wird und nur auf einen einzigen Slot gespeichert wird?

  • Weiß aber jemand wie und wo diese Slots dann abgespeichert werden?

    Wenn ichs noch richtig weiß, dann wird das Savegame solang du das Spiel als "Development" entwickelst, im Spiel-Ordner abgelegt.
    Wenn du es dann irgendwann als "Shipping" weiter machst, werden die Savegames unter "AppData" abgelegt ^^



    Der Ordner "AppData" ist unter Windoof standardmäßig ausgeblendet.

    Hier ne Anleitung zum sichtbar machen:



    Macht das so Sinn?

    Hatte ich bei meinem ersten fertigen Projekt auch so, dass alles einzeln ist ... waren dann 3 Savegames, eins für Audio, eins für Video und eins für die gespeicherten Character.


    Da man in den Savegames aber ziemlich einfach cheaten kann, würde es schon Sinn machen, das alles komplizierter aufzubauen indem alles in nem einzigen Struct liegt, oder sogar nur Strings ^^


    Evtl. auch bestimmte Dinge doppelt an verschiedenen Stellen speichern, um im Spiel dann zu checken, ob es die gleichen Werte hat und wenn nicht, ne Meldung anzuzeigen, dass das Savegame "corrupted" ist, hehe

  • ok danke.


    Und hast Du oder jemand eine Idee wie ich das anstellen kann, dass wenn ich Items aufgesammelt habe, diese beim erneuten starten nicht mehr spawnen?

    Gibt es da einen einfachen Weg? Oder muss man tatsächlich jedes einzelne Item abspeichern, dass es aufgesammelt wurde? Und dies dann beim Start abfragen ob schon eingesammelt oder noch nicht und falls ja dann einfach nicht spawnen oder destroyen?

    Stelle ich mir halt bei etlichen Items sehr mühsam vor.


    Ich möchte halt natürlich nicht, dass wenn ein Spieler ein Item aufsammeln, danach speichert und neu lädt, dass das Item aufeinmal wieder da ist! :D

    Bei mir sind auch alle Items einmalig, also wird nichts nach einer Zeit neu gespawnt etc.

  • Gibt es da einen einfachen Weg?

    Wenn du jedem Item ne eindeutige ID gegeben hast, machst einfach ein Int-Array im Savegame und wenn was aufgehoben wurde, wird die ID hinzugefügt.
    Sollte nun das Level neu geladen werden, werden die IDs durch gecheckt und das jeweilige Item destroyed bzw. nicht gespawnt...

    Alternativ zur ID kannst auch die Location im Array speichern, was aber evtl. fehlerbehaftet sein könnte ^^

  • Puh, OK.
    Muss ich dann mal ausprobieren wie ich dies am besten anstelle. Weil die meisten Items sind halt einmalig, aber bestimmte Verbrauchsgegenstände kommen halt öfters vor. Da kann es dann auch bei der ID vergabe eskalieren. :D
    Dann muss ich evtl. bei 3 stelligen Zahlen anfangen. Beispiel die erste Munitionsschachtel hat die ID 100, die zweite 101, dritte 103 usw. Damit quasi die 100er nur für die Munition reserviert ist..


    Eine Frage hab ich noch:

    Wenn man alles mit diesen Save Game Slots macht, braucht man dann noch eine GameInstance? Weil soweit ich weiß kann man damit auch speichern, oder ist diese für etwas anderes gedacht?

  • Die GameInstace merkt sich alles - auch bei einem Wechsel der Map. Sie überlebt es aber nicht wenn du das Spiel beendest. EIn SaveGame wird auf der Festplatte abgelegt und überlebt ausser Plattencrash oder mutwilligem löschen fast alles.


    Sehr viele Objekte, Werte, Variablen usw. zu speichern ist viel Arbeit, es kommt immer auf das Spiel an, aber oft ist es sinnig in einem Loop durch alles mögliche durchzugehen und es einfach als Array zu speichern. Nicht ganz ohne Grund haben sich dutzende Save Game plugins auf dem Market Place breit gemacht. Inzwischen gibt es aber mit "Save Extension" auch ein "Save whole world" fähiges plugin mit vielen anderen sinnvollen Features umsonst.

  • Vielen Dank.

    Jetzt erinnere ich mich auch, dass heut zu tage bei einigen Spielen die SaveGames mehrere GB groß sind.
    Wird wohl seine Gründe haben bei dem all möglichen was so gespeichert werden soll.

    Wenn man sich zB ein Open World spiel vorstellt mit etlichen Quests.. Das muss ja auch irgendwie abgespeichert werden, dass man diese schon gemacht hat.

  • 2. Ich habe zB für meine AudioSettings eine eigene Funktion zum Speichern und Laden und einen eigenen Slot benannt. Dies wollte ich dann auch für die VideoSettings usw machen. Die eigentlichen SaveGames werden dann auch extra abgespeichert.

    Macht das so Sinn? Die Slots für die Settings sind quasi global für jeden. Die werden halt beim Starten geladen und bei Änderungen gespeichert, fertig.


    kyodai

    Da bisher nur Butterfly was zu gesagt hat, wollte ich dich gern direkt auch noch fragen.
    Was ist deine Meinung dazu? Oder hättest du es auch alles in einen "mega" Slot gepackt wo einfach alles drin ist?

  • Hey zusammen


    Das Thema hatten wir schonmal. Dort hast du gemeint das SaveGame da besser ist.

    Bin nachwievor der Meinung, dass das in eine Settingsdatei gehört und nicht in ein SaveGame.

    Im Grunde genau gleich wie es bei Input Bindings und Grafik Settings auch gemacht wird.



    Gruss

  • kyodai

    Da bisher nur Butterfly was zu gesagt hat, wollte ich dich gern direkt auch noch fragen.
    Was ist deine Meinung dazu? Oder hättest du es auch alles in einen "mega" Slot gepackt wo einfach alles drin ist?


    Ich speichere grundsätzlich alle Settings in einem SaveGame. Wenn du aber einem user ermöglichen willst z.B. verschiedene Audio Profile einzeln zu speichern dann wirst du da wohl aufbohren müssen.

  • Das Thema hatten wir schonmal. Dort hast du gemeint das SaveGame da besser ist.

    stimmt da war ja was. Mensch, dass du dich da eher dran erinnerst als ich selbst. :D

    Habe den alten Post extra gesucht.




    Alternativ zur ID kannst auch die Location im Array speichern, was aber evtl. fehlerbehaftet sein könnte

    Ich würde es jetzt so machen dass ich ein Actor-Array anlege. Wenn ich dann ein Item aufsammle, schreibt er den Actor in das Array.

    Dann beim Laden einmal durch checken und alle zerstören.

    Ich denke das ist sinnvoller und einfacher anstatt jedem Item im Level eine eigene ID zu geben, weil wie erwähnt sind Verbrauchsgegenstände auch mehrfach vorhanden.


    Ich werde es mal testen. Der Denkanstoß hat schonmal sehr geholfen! :thumbup:




    Angefangen habe ich schon. Aber da alles über Widgets gesteuert werden soll, muss ich erstmal diese noch machen. Allein durch die Widgets ist es gefühlt immer 3x so viel Arbeit.

  • Jetzt erinnere ich mich auch, dass heut zu tage bei einigen Spielen die SaveGames mehrere GB groß sind.

    Kann ich mir irgendwie nicht vorstellen, außer die speichern nicht nur ItemIDs und die Anzahl, sondern das komplette Struct inklusive Texturen und Meshes...


    Meiner Meinung nach haben Texturen und Meshes, nichts in nem Savegame zu suchen, ist aber natürlich ein Aufwand, extra fürs Savegame ein eigenes Struct anzulegen, da große AAAs aber so schon mehrere Jahre in der Entwicklung sind, sollte man die paar Minuten vielleicht doch investieren ^^


    Wieso nur paar Minuten?
    Altes Struct kopieren, alles unnötige raus löschen, fertig...


    Wenn man sich zB ein Open World spiel vorstellt mit etlichen Quests.. Das muss ja auch irgendwie abgespeichert werden, dass man diese schon gemacht hat.

    Da würd ich auch einfach nur die IDs der Quests in nem Array abspeichern.

    Evtl. auch in nem Struct, wo dann die ID drin ist, ob angenommen/abgeschlossen und wieviele Gegner man schon gekillt hat.


    Bin nachwievor der Meinung, dass das in eine Settingsdatei gehört und nicht in ein SaveGame.

    So wie GameUserSettings?

    Ich hab das auch anfangs benutzt, aber dann schnell gemerkt, dass ich andere Einstellungen anbieten will, als die was standardmäßig dort drin sind ^^


    Es gäbe zwar noch die Möglichkeit, ne Variable in nem BP in ner Config zu speichern, aber das macht für mich eher bei nem Server Sinn, wo der Admin einstellen kann, wie schnell Gegner respawnen, wieviele maximal, usw.


    Ich mag Savegames lieber, aber ich bin auch zu 100% nur auf Steam unterwegs und der Vorteil dort liegt darin, dass man die Einstellungen nicht immer und immer wieder neu auf sich selbst anpassen muss, wenn man das Spiel zwischendurch deinstalliert hatte.


    Selbst wenn man die Savegames mit löscht, durch die Steam-Cloud, muss ich mir das nicht immer wieder antun, dass das Spiel zum Start extrem laut ist, hehe


    Ich denke das ist sinnvoller und einfacher anstatt jedem Item im Level eine eigene ID zu geben, weil wie erwähnt sind Verbrauchsgegenstände auch mehrfach vorhanden.

    Wenn dein Savegame dann am Ende ein gb groß ist, weißt ja an was es liegt ^^

  • Geloscht Danke dir für deine Erklärung und ja, genau so meinte ich das.

    Also Input.ini, GameUserSettings.ini und sonstige relevante .ini files und du kannst doch aber auch .ini files in der Steamcloud speichern. Du musst die Video settings ja sowieso aus dem Savegame holen und dann über die Gameusersettings anwenden, wodurch diese sowieso wiederum in den GameUserSettings oder Inputsettings oder was auch immer landen. Einfach schon etwas früher.
    Bralligator Will natürlich nicht dein Thema kapern, wünsche viel Erfolg.

  • Und hast Du oder jemand eine Idee wie ich das anstellen kann, dass wenn ich Items aufgesammelt habe, diese beim erneuten starten nicht mehr spawnen?

    Gibt es da einen einfachen Weg? Oder muss man tatsächlich jedes einzelne Item abspeichern, dass es aufgesammelt wurde? Und dies dann beim Start abfragen ob schon eingesammelt oder noch nicht und falls ja dann einfach nicht spawnen oder destroyen?

    Stelle ich mir halt bei etlichen Items sehr mühsam vor.

    Wenn du mal drüber nachdenkst... so kompliziert ist das nicht. Wenn es für ein Item funktioniert und richtig aufgebaut ist, funktioniert es auch für 100 oder 1000 items :)

    Für größere Projekte kann man auch ein eigenes Save-System bauen, das Abspeichern und Laden aller Dinge regelt. Dann könnte man in einer Parent-Class oder einem Component ein Interface benutzen und in unterschiedlichen Objekten, die verschieden reagieren einbauen.
    Manche Objekte werden vielleicht verschoben und müssen einen Transform speichern. Andere müssen vielleicht einen Float oder String speichern und andere nur einen Bool. Wenn man ein gutes System hat, lässt sich das alles regeln.

    Es gibt ja auch wie erwähnt Plugins, die gute Lösungen anbieten.