Search Unity

ECS save state and replays

Discussion in 'Data Oriented Technology Stack' started by CodeKiwi, Mar 26, 2018.

  1. CodeKiwi

    CodeKiwi

    Joined:
    Oct 27, 2016
    Posts:
    56
    I was checking out the Two-stick shooter pure sample and it talks about keeping data out of the system and having it in the states to help with replays and saving. Does this mean that the current or maybe future version will support something like world.Save() / Load() / Record() / Playback()? Or do I just manually record and load the entities I need?

    I haven’t really used a system like this but I’m guessing there are three main ways to handle replays manually for now.

    1: Record the state each frame. Uses a lot of memory but would be deterministic on all devices even if the ingame stats changed e.g doubled weapon damage still plays original damage in old replay. I could also easily move forward/backward or skip time. I’d probably have to ignore the update commands.
    2: Similar to 1 but just save the first state then record the changes. Uses less data but would only play forward.
    3: Record commands as if it was a multiplayer game. Uses the least amount of data but it might be harder to code. Could only play forward.

    I’d appreciate any suggestions for saving states and replays.

    I’m really enjoying the ECS, at first I only wanted to use it for the speed increase but now I really like the code style. I’d probably still use it even if it was slower than standard components.
     
  2. rastlin

    rastlin

    Joined:
    Jun 5, 2017
    Posts:
    105
    Generally, when working with ECS systems, save/load is done by persisting the entity state.

    I would say the lightest approach is to do this on demand, and the way would be to just pause all systems, cycle through all your entities, which defines your "world" and dump their components/other data state somewhere, like a file.

    For a load, you again pause all the systems, recreate all the entities and their components from dumped state, and resume.

    Your systems should be stateless, and should not generally relay on any create/destroy sequence to operate correctly. If you achieve this, your load will be really easy and seamless.

    I don't think having a generic Save() / Load() routines delivered by Unity will be a good idea, the variance numbers on how the state can be save is just to big.
     
    CodeKiwi likes this.
  3. pvloon

    pvloon

    Joined:
    Oct 5, 2011
    Posts:
    586
    It's kind of an interesting idea. This normally would be way out of scope, but since all data is blittable it would not be too bad. I remember Jonathan Blow did something similar for Braid. It was easiest to just save literal memory of (almost all) state and compress it. I don't think unity could ever do a full Load/Save, but maybe could build some tools to make it easier (or I'm sure the asset store will)
     
  4. CodeKiwi

    CodeKiwi

    Joined:
    Oct 27, 2016
    Posts:
    56
    Thanks, not having a common Save/Load does make a lot of sense now that I think about it. In the case where I just want a standard replay I can probably just record the position and heading and ignore any AI or input. Then change the archetypes for a basic replay mode.

    For a full game state save and reversing time like in Braid I’ll probably try saving most of the state data. I might try having one world for the simulation and another for the view. I thought it might be cool to have a bullet hell game where time rewinds back a few seconds when you die so you can try to avoid what killed you.