Recall player inventory (Time reversal mechanic)

● ARCHIVED · READ-ONLY
Started by NegativeZZ 6 posts View original ↗
  1. So I have this idea for a story and game mechanic, and I'm not sure if its possible within the realms of the program itself.

    Without eluding to too much of my game, I want to have a portion of the game that is similar to a time travel. At some point in the game the player will "travel back in time" to key story points in the game, except there will be additional choices available to them (hidden paths, dialogue options, etc.) that will allow the player to fight optional secret bosses. After the boss is defeated, they would return to where the player is currently at in the game, but with some type of trophy or item for the boss fight they did.

    What I want to accomplish from the game, is for it to make a "save state" or something similar, of what the players inventory, stats, character levels, etc., at the time of the save state are, so that it would be truly, going back in time. You'd have the same number of potions, same gear, even the same experience right down to the point. I then need the game to be able to recall back to where it was at prior to that. This could probably be accomplished with another "save state" and just loading from that point, however the next challenge then is how to implement this in the middle of a dialogue screen.

    I suppose there could be a convoluted way to do what I want to accomplish, but I'm not sure how, as I'm very new to MV (having came from XP). Maybe there's a way to snapshot specific variables (like player level) and then I could just write that script for EVERY variable that I want to carry over (so a line of script for each character, their level and stats, each inventory item, etc.) Even if that takes a billion years the payoff would be worth it to me for all the tedious work that would be.

    Any help is appreciated
  2. The easiest solution by far is to create a plugin for that if you know how to code, or request or commission a plugin.
  3. I'm planning to include something similar in my game, but so far I haven't put myself to design it.
    it is very much possible to do, but I guess the trick would be to be able to store the state of the player in one single variable or checksum.
    that way it'll only occupy ONE instruction.

    managing the back and forth shouldn't be hard, *EXCEPT* if you mean to send the player to a previous map (disconnected from the present one), where that map might have been altered since the moment the player walked into it for the very first time in all the game.
    map is at state A, player enters, interacts with the environment, map is at state B, time passes, player is sent back, map should be at state B, which can't happen because all maps reset to state A when reloaded, UNLESS you have a manager structure that takes care of that and rebuilds it.
    THAT is the tricky part of the build.

    you can (maybe) copy the premise over to maps: read the state of the map, save it, and then replicate it.
    *that* IS possible (I've done the on-the-fly replication part before), but I don't know about saving it (file size, processing time, complications with plugins, etc)
  4. I don't know how to code, so what I'm going to say may be worthless, but wouldn't it be possible for a script to use the savegame feature to store those datas? The script could produce an "invisible" saved game from which it could retrieve the needed data.
  5. technically yes, it would be the same procedure.
    but save games only store the party data, the system variables, and the ID of whatever map the player is currently in.... they don't save *the whole map* or *the whole record of actions*.

    (but yes, you can dump the whole thing onto a file.... the question is how big the file might end up being, or how reliable the process is)
  6. Another way to do this I just thought about... Himeworks already offers a plugin for multiple inventories. Maybe it allows in some way to save an inventory to get back to it later. For the maps, though, you may have to produce different maps per see.