Kehom
commented
2 years ago OK. There are several things that must be mentioned about this PR, both in "general terms" and in code details. I do like the idea of having a replay system and I did consider it in the past. Although never got to work on it.
Now, to the "general" things that I must mention:
1 - I know the replay system will work a lot better by using data obtained from the network system. However I would prefer the replay thing to be separated, having a dependency on the networking addon. The reason? Not everything needs a replay system, so having it separated means that it can be enabled/installed only if there is any desire in the project. Unfortunately for projects that would want the replay system but not the networking one, well... there isn't much that can be done. The network system contains a lot of stuff to help take the entire game state. So, yeah.
2 - If a replay system is to be implemented, it should also provide means to playback that stuff. In this regard, I would probably have some code repeating what the replication system does, however it can be greatly simplified since there is no need to deal with player input (other than interacting with the UI itself), nor further replicating any other data.
3 - Usually speaking I don't like hard coded things. Only when it makes sense. That said, the location where the replay data is stored should not be hard coded. In here either the functions that save/load the replays should have additional arguments that indicate the path to the file or those are added as project settings. Requesting extra arguments means slightly harder to use functions but with greatly added flexibility. I believe this is a very good trade of. As an example, with this it becomes possible for the game to provide the possibility for the player to save the replay wherever he/she wants to.
4 - There are a few details regarding the code itself, which I will use the code commenting system to do so.
snapshotdata.gd:
Now has a separate "lifetime history" of stored snapshots and EncDecBuffer.
New function, _add_to_lifetime_history, that accepts a snapshot, encodes it and appends it to to the end of the lifetime history before clearing the lifetime history buffer's buffer
New function, _convert_replay_to_snapshots grabs a replay of encoded snapshot data and decodes it through the lifetime history buffer, replacing each index of the replay with a snapshot before clearing the lifetime history buffer and returning the replay itself.
New function, _convert_replay_to_lifetime_history, which is the same as the previous function, but instead of modifying the replay array and returning it, the snapshots are decoded and deposited directly in the _lifetime_history array.
replay.gd:
stores gzip compressed "replays" of serialized snapshot data to files. If the game is running out of the editor (even if project is not opened specifically), replays are saved to res://replays/ . Otherwise, replays are saved to a replay directory in Godot's userdata folder.
gitignore
updated to not include .REPLAY files or the replays/ folder.