-
Notifications
You must be signed in to change notification settings - Fork 66
Different plugin groups to support different use cases (diverse-defaults for short) #48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
b5b3a96
b899209
d2811da
ff5ac0e
da4bf98
d85bd7d
5e129fc
d69d942
52f5629
3a5d01e
bd59230
23b0f46
4161491
0cf2756
30cfe09
62e6d1a
0270031
a317188
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,61 @@ | ||
# Feature Name: Different plugin groups to support different use cases (diverse-defaults for short) | ||
|
||
## Summary | ||
|
||
There are many different categories of Bevy applications. Each use case has distinct needs, and so we should provide a collection of `PluginGroups` to give our users good defaults. | ||
|
||
## Motivation | ||
|
||
Bevy would benefit from an improved 'getting started' user story for non-minimal bevy applications. This is particularly helpful for beginners, but would also be a nice ergonomics/UX win for experienced bevy devs to not have to configure every minute detail manually when setting up a new project that is in one of the above outlined application domains. | ||
|
||
## User-facing explanation | ||
|
||
Bevy now provides you a number of convenient `PluginGroups` to help you get your application started with sensible defaults for your use case. The current list is: | ||
|
||
- `MinimalPlugins`: The very basic internal structure required to ensure things like `Time` function properly. | ||
- `GamePlugins`: Suitable for making both 2D and 3D real-time games with input handling, audio and rendering (note: previously `DefaultPlugins`). | ||
- `2dGamePlugins`: Like `GamePlugins`, but limited to the systems and resources needed in a 2D game. | ||
- `TuiPlugins`: Suitable for making TUI applications. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This needs a note in implementation details on what we should include to get this working. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What exactly would we need to include to get this working? I don't understand the details of the bevy There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also would probably prefer to just migrate my initial proposal to the one @mockersf suggested which I think addresses the problem area even better! :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The bigger problem is "I don't know how to make a terminal game in Bevy 0.6" at all. There were a few ecosystem crates, but they're no longer up to date. |
||
- `ApplicationPlugins`: Suitable for making relatively static non-game applications. | ||
- `SimulationPlugins`: Plugins that make writing scientific simulations easier like enhanced determinism and ordering guarantees. | ||
- `HeadlessServerPlugins`: Like `GamePlugins`, but without rendering, input handling, audio or windowing. | ||
- `HeadlessIntegrationTestPlugins`: Suitable for running Bevy integration tests as rapidly as possible. | ||
- `RenderTestPlugins`: The minimal plugins necessary for testing that Bevy is rendering objects as expected. | ||
|
||
## Implementation strategy | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it would be helpful hear to identify "axes of variation"; ways that each of the use cases commonly vary, so we can think about how to structure them. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I very much agree, though I don't know how to flesh this out. |
||
|
||
Each of the above outlined `Plugins` may have some combination of the following divergent platform configuration needs: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's not clear how exactly this interacts with the "use case" plugins groups above 🤔 I agree that we want both, but they seem mostly orthogonal. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think @mockersf proposal enables use to meld the two in a sensible way! |
||
|
||
- desktop | ||
- native | ||
- web | ||
- tablet | ||
- ios native | ||
- android native | ||
- web | ||
- phone | ||
- ios native | ||
- android native | ||
- web | ||
|
||
This feature also touches on not-yet-implemented but planned bevy features that will have different implementations per use case. | ||
|
||
For example, using making low-power consumption web and mobile applications, desktop productivity apps and high performance games will all have very different scheduling needs. | ||
|
||
2D vs 3D will have different built-in bevy selection methods/mechanisms and different cameras. | ||
|
||
Building for touch vs mouse vs gamepad or other midi/advanced input controllers different use cases with very different requirements. | ||
|
||
## Drawbacks | ||
|
||
The primary drawback I can see is the need for Bevy to maintain the multiple `PluginGroups`, however, I foresee the maintenance burden of this to be exceedingly minimal. | ||
|
||
## Rationale and alternatives | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think you should discuss the pros and cons of plugin groups vs. feature groups in this section. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How would you define There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Rust features can enable other features, allowing users to toggle them on and off as needed. We can also See: https://doc.rust-lang.org/cargo/reference/features.html for a basic introduction. |
||
|
||
Each of these use cases can be currently be targeted in a custom manner by the application developer. This is fine for advanced users, but is less than an ideal user story for bevy beginners who just want to get something working as fast as possible lest they decide to try a different easier to use engine/framework. Were bevy to provide sane defaults for each use case, new users would be able to get something working in non-standard (i.e. not minimal `DefaultPlugins`) different scenarios very easily. This can also be highlighted by different book chapters per use case for the purposes of user education and better documentation of this feature. | ||
|
||
The alternative to this proposal is for bevy to continue providing only `DefaultPlugins` and `MinimalPlugins` and for users to customize the plugins themselves through writing their own or using 3rd-party plugins. | ||
|
||
## Unresolved questions | ||
|
||
Which default plugin sets do we want to include right now, and how precisely do they differ? |
Uh oh!
There was an error while loading. Please reload this page.