Been working on a combat system with a LOT of tunable numbers: enemy stats, ability costs, damage falloff curves, all of it. Tired of recompiling every time a designer (me, it's me, I'm the designer) tweaks a value. So I've been trying to set up proper hot reloading for game data at runtime and it's been a journey.
The approach I landed on: separate your data definitions from your runtime instances. Sounds obvious in retrospect. My mistake was binding ScriptableObject values directly to live game objects, so when you reload the SO, there's no clean way to propagate changes without restarting the scene or writing a ton of refresh logic scattered everywhere.
What actually worked: treat config data as a source of truth read at construction time, not a persistent live reference. Then a hot reload becomes:
fileWatcher.OnChanged += (path) => {
var newData = JsonLoader.Load<EnemyConfig>(path);
ConfigRegistry.Replace(path, newData);
// existing instances don't auto-update — signal them instead
EventBus.Emit(new ConfigReloadedEvent { Path = path });
};
The catch is now you're managing two things: the definition reload and notifying whatever live objects care about it. Gets messy fast once configs have dependencies on other configs.
I've seen people use Odin Inspector + ScriptableObjects with custom refresh buttons as a lighter shortcut, which honestly might be good enough for most projects. Full file-watcher hot reload only seems worth the architecture cost if you're iterating on balance data constantly throughout the day.
Is anyone running proper runtime hot reload in a Unity or Godot project, or is everyone just living with the compile-reload cycle?
