On Day 022, Casey mentioned that there is a way to support hot reloading across data structure changes.
In broad strokes, what is the basic idea behind achieving this?
I imagine the objective is to make the game data structures "unbreakable" - that is, invariant across schema changes. How would Casey achieve this? Perhaps, he would do something like this:
(1) Append all game state updates and changes in a linear fashion to an in-memory "log file" arena (perhaps some sort of preallocated wrap-around buffer), with unique ID's for each property.
(2) On each frame update, reset the game state memory arena.
(3) Next, have the platform layer pass a pointer to the "log file" arena to a "rematerialize" function in the hot-loaded DLL.
(3) Have the "rematerialize" function parse the "log file" memory arena and repopulate the game state memory arena.
(4) Proceed as usual.
Am I on the right track, or is there a better way of supporting hot reloading across data structure changes?
Thanks!
In broad strokes, what is the basic idea behind achieving this?
I imagine the objective is to make the game data structures "unbreakable" - that is, invariant across schema changes. How would Casey achieve this? Perhaps, he would do something like this:
(1) Append all game state updates and changes in a linear fashion to an in-memory "log file" arena (perhaps some sort of preallocated wrap-around buffer), with unique ID's for each property.
(2) On each frame update, reset the game state memory arena.
(3) Next, have the platform layer pass a pointer to the "log file" arena to a "rematerialize" function in the hot-loaded DLL.
(3) Have the "rematerialize" function parse the "log file" memory arena and repopulate the game state memory arena.
(4) Proceed as usual.
Am I on the right track, or is there a better way of supporting hot reloading across data structure changes?
Thanks!
You don't actually need the log file. You just need to store descriptions of all the structs, and then you walk them from the base pointers after loading and mutate them into the new format.
It's just a lot more work, so that's why I'm not going that route for this game. It is definitely a downside of C/C++, because writing something like this is not difficult in languages that support introspection/reflection/etc.
- Casey
It's just a lot more work, so that's why I'm not going that route for this game. It is definitely a downside of C/C++, because writing something like this is not difficult in languages that support introspection/reflection/etc.
- Casey