rfcs
rfcs copied to clipboard
Different plugin groups to support different use cases (diverse-defaults for short)
There are many different categories of bevy applications. Each use case has a sufficiently different commonsense default configuration to warrant different use case specific default plugins. This RFC is a proposal to consider making such a change.
Instead of having different PluginGroups
, I think this would be better suited for compilation features:
- they reduce compile time
- they guarantee that the code won't be present
- they are the only way to have different
const
values - they work well with compilation target, which is what you call "divergent platform"
- they are already present and mostly usable that way in Bevy
For example, for a 2d game that won't use UI but will still display text in the 2d world, I use only those features: "bevy_core_pipeline", "bevy_sprite", "bevy_winit", "bevy_render", "bevy_text", "png"
.
Features are probably not documented enough and not really friendly, Bevy could add meta features to group them into logical groups like you describe here.
Instead of having different
PluginGroups
, I think this would be better suited for compilation features:* they reduce compile time * they guarantee that the code won't be present * they are the only way to have different `const` values * they work well with compilation target, which is what you call "divergent platform" * they are already present and mostly usable that way in Bevy
For example, for a 2d game that won't use UI but will still display text in the 2d world, I use only those features:
"bevy_core_pipeline", "bevy_sprite", "bevy_winit", "bevy_render", "bevy_text", "png"
.Features are probably not documented enough and not really friendly, Bevy could add meta features to group them into logical groups like you describe here.
That's a really nice idea @mockersf and I think this solves the problem I am seeking to address in an even nicer way with the additional benefits you outlined!! :) :100: