You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hot reloading of binaries seems to be a tricky topic (not only in Rust), but the massive iteration time reductions would be worth it.
My idea would be to take advantage of the ECS architecture here. When working with bevy, I noticed that most of my changes would involve systems. My plan would be to separate a bevy project into two different parts/binaries:
* bevy + user components + runner
* main + user systems (hot re loadable)
With this design, all entities, assets, states, etc. would be persistent across sessions. I also think that this wouldn't cause much problems on system side, since they are (mostly?) stateless. Only if the user changes component code, he would need to restart. For release builds, both parts could be statically linked.
After some discussions on the discord, I figured that systems indeed could have (important) states within them (entity change detection, event reader). That would make my initial idea far more difficult.
But the question remains: can we offer any support for hot reloading?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hot reloading of binaries seems to be a tricky topic (not only in Rust), but the massive iteration time reductions would be worth it.
My idea would be to take advantage of the ECS architecture here. When working with bevy, I noticed that most of my changes would involve systems. My plan would be to separate a bevy project into two different parts/binaries:* bevy + user components + runner
* main + user systems (hot re loadable)
With this design, all entities, assets, states, etc. would be persistent across sessions. I also think that this wouldn't cause much problems on system side, since they are (mostly?) stateless. Only if the user changes component code, he would need to restart. For release builds, both parts could be statically linked.After some discussions on the discord, I figured that systems indeed could have (important) states within them (entity change detection, event reader). That would make my initial idea far more difficult.
But the question remains: can we offer any support for hot reloading?
Happy to hear your comments!
Beta Was this translation helpful? Give feedback.
All reactions