Replies: 1 comment
-
For now I'm just using var packedSceneToSave: PackedScene = PackedScene.new()
packedSceneToSave.pack(sceneTree.get_current_scene())
ResourceSaver.save(packedSceneToSave, Settings.saveFilePath) but it doesn't seem to capture all the exact state. I wish Godot had a way to take full runtime "snapshots" like emulator save states 🥲 BUT, capturing the runtime state would cause issues with different versions of the game: Older save files won't work on newer versions. I think I have to figure out a way to "formalize" the concept of "game state" then maybe make a "GameStateComponent" or something that rebuilds/reconfigures its entity based on the save file etc. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Description of Issue
Comedot supports dynamically adding and removing components (and adjusting parameters) to modify entity behavior. There is currently no formal approach to save and persist runtime changes that occur to an entity. I wanted to start brainstorming ideas of how to approach this.
Considerations
Security
Official docs of Godot now recommend serialization of data for saving purposes. Other file formats like resources can be modified with malicious code [see discussion here].
Selective Saving
Users may not want to save every change to an entity. Allowing the persistence of only certain changes would be advantageous. Storing the entire entity could be problematic.
Scope
There may be different scopes to which a user wants to save a particular change to an entity—for example, adding a component for just the current scene versus having it persist across the entire game, etc. It would likely be advantageous to be able to specify the scope to which you'd like to store a particular change.
Existing Methods of Modifying Entities
Comedot has existing approaches for modifying entities, such as
ComponentPayload
, that need to be accounted for.Component Dependencies and Order
If Comedot programatically applies changes from serialized data at runtime, it could run into issues based on the order in which the components are added (see
Entity.createNewComponents
)Unique Identifier for Entity
Changes to entities that persist across multiple scenes would need a unique identifier if there are multiple instances of the entity.
????
What else am I missing?
Idea: Handle Persistence When Modifying an Entity
This might make sense. Handling it during modification makes it clear when and how to store a change and then theoretically there could be some code to automatically take care of serializing the change into the gamestate or some other persistent structure. This would result in diffs/deltas that could be applied at runtime or when needed. For example, a method could build upon
Entity.createNewComponent
and take an optional argument (like scope) and serialize and store that change during execution. Then some additional code or a component could read saved data and apply those changes.Anyway thats my idea, share your own or any feedback
Beta Was this translation helpful? Give feedback.
All reactions