From b5b3a963bf2458a9d15d8041159bb6c9ec9fb669 Mon Sep 17 00:00:00 2001 From: Cole Poirier Date: Thu, 13 Jan 2022 16:51:38 -0800 Subject: [PATCH 01/18] first draft of diverse-defaults rfc --- rfcs/diverse-defaults.md | 136 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 136 insertions(+) create mode 100644 rfcs/diverse-defaults.md diff --git a/rfcs/diverse-defaults.md b/rfcs/diverse-defaults.md new file mode 100644 index 00000000..c4100186 --- /dev/null +++ b/rfcs/diverse-defaults.md @@ -0,0 +1,136 @@ +# Feature Name: Different plugin groups to support different use cases (diverse-defaults for short) + +## Summary + +There are more than half a dozen different catagories of bevy 'Apps'. Each 'use case' has a sufficiently different 'common sense' default configuration to warrant different use case specific default plugins. The catagories I have been able to come up with @alice-i-cecile's help are: + +- minimal (current bevy DefaultPlugins) +- game + - 2D + - 3D +- TUI +- application + - 2D + - 3D +- simulation + +Each of which may have some combination of the following divergent platform configuration needs: + +- desktop + - native + - web +- tablet + - ios native + - android native + - web +- phone + - ios native + - android native + - web + + +Each of these use cases can be target in a custom manner by the user. 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 soemthing working in non-standard (i.e. minimial DefaultPlugins) very easily. This can also be highlighted by different book chapters per use case. + +THis also involves not-yet-implemented but planned bevy features that will have different implementations per use case. + +For example work-minimizing scheduling for low-power consumption web and mobile applications, or desktop productivity apps are a very different configuration from high performance gaming and high performance scientific simulation. + +2D vs 3D will have different built-in bevy selection methods/mechanisms and different cameras... Anything else? + +Building for touch vs mouse vs gamepad or other midi/advanced input controller are yet more very different use cases with very different requirements. + +I have run out of ideas? Any suggestions? + +## Motivation + +Bevy would be doing this to support easier an faster getting started in the major catagories of different use cases for bevy. It is particularly helpful to beginniers but would be a nice ergonomics/UX win for experienced bevy devs to not have to configure every minute detail manually when working in multiple 'use case' domains on different projects. Anything else you can think of? + +## User-facing explanation + +Explain the proposal as if it was already included in the engine and you were teaching it to another Bevy user. That generally means: + +- Introducing new named concepts. + - DefaultPlugins can become an enum with each usecase as a different enumerant? +- Explaining the feature, ideally through simple examples of solutions to concrete problems. + - Small book chapters would probably be the way to go? +- Explaining how Bevy users should *think* about the feature, and how it should impact the way they use Bevy. It should explain the impact as concretely as possible. + - What I would put here is identical to what I have written in the motivation section, is that ok? +- If applicable, provide sample error messages, deprecation warnings, or migration guidance. + - DefaultPlugins for the current minimal config would still work the same, IIUC this would be a purely additive feature. +- If applicable, explain how this feature compares to similar existing features, and in what situations the user would use each one. + - Currently users can create these configs manually, the change would be bevy providing more standard getting started configs/DefaultPlugins out of the box. + +## Implementation strategy + +I need others help/input with this. + +This is the technical portion of the RFC. +Try to capture the broad implementation strategy, +and then focus in on the tricky details so that: + +- Its interaction with other features is clear. +- It is reasonably clear how the feature would be implemented. +- Corner cases are dissected by example. + +When necessary, this section should return to the examples given in the previous section and explain the implementation details that make them work. + +When writing this section be mindful of the following [repo guidelines](https://github.com/bevyengine/rfcs): + +- **RFCs should be scoped:** Try to avoid creating RFCs for huge design spaces that span many features. Try to pick a specific feature slice and describe it in as much detail as possible. Feel free to create multiple RFCs if you need multiple features. +- **RFCs should avoid ambiguity:** Two developers implementing the same RFC should come up with nearly identical implementations. +- **RFCs should be "implementable":** Merged RFCs should only depend on features from other merged RFCs and existing Bevy features. It is ok to create multiple dependent RFCs, but they should either be merged at the same time or have a clear merge order that ensures the "implementable" rule is respected. + +## Drawbacks + +I need others help/input with this. + +Why should we *not* do this? + +## Rationale and alternatives + +I need others help/input with this. + +- Why is this design the best in the space of possible designs? +- What other designs have been considered and what is the rationale for not choosing them? +- What objections immediately spring to mind? How have you addressed them? +- What is the impact of not doing this? +- Why is this important to implement as a feature of Bevy itself, rather than an ecosystem crate? + +## \[Optional\] Prior art + +I need others help/input with this. + +Discuss prior art, both the good and the bad, in relation to this proposal. +This can include: + +- Does this feature exist in other libraries and what experiences have their community had? +- Papers: Are there any published papers or great posts that discuss this? + +This section is intended to encourage you as an author to think about the lessons from other tools and provide readers of your RFC with a fuller picture. + +Note that while precedent set by other engines is some motivation, it does not on its own motivate an RFC. + +## Unresolved questions + +I need others help/input with this. + +- What parts of the design do you expect to resolve through the RFC process before this gets merged? +- What parts of the design do you expect to resolve through the implementation of this feature before the feature PR is merged? +- What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC? + +## \[Optional\] Future possibilities + +I need others help/input with this. + +Think about what the natural extension and evolution of your proposal would +be and how it would affect Bevy as a whole in a holistic way. +Try to use this section as a tool to more fully consider other possible +interactions with the engine in your proposal. + +This is also a good place to "dump ideas", if they are out of scope for the +RFC you are writing but otherwise related. + +Note that having something written down in the future-possibilities section +is not a reason to accept the current or a future RFC; such notes should be +in the section on motivation or rationale in this or subsequent RFCs. +If a feature or change has no direct value on its own, expand your RFC to include the first valuable feature that would build on it. From b899209fcfdbc5e3bc46263baec0466434336854 Mon Sep 17 00:00:00 2001 From: Cole Poirier Date: Thu, 13 Jan 2022 17:19:40 -0800 Subject: [PATCH 02/18] fix spelling, rephrase things slightly, add TODOs --- rfcs/diverse-defaults.md | 91 ++++++---------------------------------- 1 file changed, 13 insertions(+), 78 deletions(-) diff --git a/rfcs/diverse-defaults.md b/rfcs/diverse-defaults.md index c4100186..a25347e8 100644 --- a/rfcs/diverse-defaults.md +++ b/rfcs/diverse-defaults.md @@ -2,7 +2,7 @@ ## Summary -There are more than half a dozen different catagories of bevy 'Apps'. Each 'use case' has a sufficiently different 'common sense' default configuration to warrant different use case specific default plugins. The catagories I have been able to come up with @alice-i-cecile's help are: +There are many different catagories of bevy applications. Each use case has a sufficiently different commonsense default configuration to warrant different use case specific default plugins. The catagories of bevy apps are at least the following: - minimal (current bevy DefaultPlugins) - game @@ -28,109 +28,44 @@ Each of which may have some combination of the following divergent platform conf - android native - web +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. -Each of these use cases can be target in a custom manner by the user. 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 soemthing working in non-standard (i.e. minimial DefaultPlugins) very easily. This can also be highlighted by different book chapters per use case. - -THis also involves not-yet-implemented but planned bevy features that will have different implementations per use case. +This feature also touches on not-yet-implemented but planned bevy features that will have different implementations per use case. For example work-minimizing scheduling for low-power consumption web and mobile applications, or desktop productivity apps are a very different configuration from high performance gaming and high performance scientific simulation. -2D vs 3D will have different built-in bevy selection methods/mechanisms and different cameras... Anything else? - -Building for touch vs mouse vs gamepad or other midi/advanced input controller are yet more very different use cases with very different requirements. +2D vs 3D will have different built-in bevy selection methods/mechanisms and different cameras. -I have run out of ideas? Any suggestions? +Building for touch vs mouse vs gamepad or other midi/advanced input controllers different use cases with very different requirements. ## Motivation -Bevy would be doing this to support easier an faster getting started in the major catagories of different use cases for bevy. It is particularly helpful to beginniers but would be a nice ergonomics/UX win for experienced bevy devs to not have to configure every minute detail manually when working in multiple 'use case' domains on different projects. Anything else you can think of? +Bevy would be doing this to support easier and faster 'getting started' user story for non-minimal bevy applications. It will be particularly helpful to 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 -Explain the proposal as if it was already included in the engine and you were teaching it to another Bevy user. That generally means: - -- Introducing new named concepts. - - DefaultPlugins can become an enum with each usecase as a different enumerant? -- Explaining the feature, ideally through simple examples of solutions to concrete problems. - - Small book chapters would probably be the way to go? -- Explaining how Bevy users should *think* about the feature, and how it should impact the way they use Bevy. It should explain the impact as concretely as possible. - - What I would put here is identical to what I have written in the motivation section, is that ok? -- If applicable, provide sample error messages, deprecation warnings, or migration guidance. - - DefaultPlugins for the current minimal config would still work the same, IIUC this would be a purely additive feature. -- If applicable, explain how this feature compares to similar existing features, and in what situations the user would use each one. - - Currently users can create these configs manually, the change would be bevy providing more standard getting started configs/DefaultPlugins out of the box. +TODO: ## Implementation strategy -I need others help/input with this. - -This is the technical portion of the RFC. -Try to capture the broad implementation strategy, -and then focus in on the tricky details so that: - -- Its interaction with other features is clear. -- It is reasonably clear how the feature would be implemented. -- Corner cases are dissected by example. - -When necessary, this section should return to the examples given in the previous section and explain the implementation details that make them work. - -When writing this section be mindful of the following [repo guidelines](https://github.com/bevyengine/rfcs): - -- **RFCs should be scoped:** Try to avoid creating RFCs for huge design spaces that span many features. Try to pick a specific feature slice and describe it in as much detail as possible. Feel free to create multiple RFCs if you need multiple features. -- **RFCs should avoid ambiguity:** Two developers implementing the same RFC should come up with nearly identical implementations. -- **RFCs should be "implementable":** Merged RFCs should only depend on features from other merged RFCs and existing Bevy features. It is ok to create multiple dependent RFCs, but they should either be merged at the same time or have a clear merge order that ensures the "implementable" rule is respected. +TODO: ## Drawbacks -I need others help/input with this. - -Why should we *not* do this? +TODO: ## Rationale and alternatives -I need others help/input with this. - -- Why is this design the best in the space of possible designs? -- What other designs have been considered and what is the rationale for not choosing them? -- What objections immediately spring to mind? How have you addressed them? -- What is the impact of not doing this? -- Why is this important to implement as a feature of Bevy itself, rather than an ecosystem crate? +TODO: ## \[Optional\] Prior art -I need others help/input with this. - -Discuss prior art, both the good and the bad, in relation to this proposal. -This can include: - -- Does this feature exist in other libraries and what experiences have their community had? -- Papers: Are there any published papers or great posts that discuss this? - -This section is intended to encourage you as an author to think about the lessons from other tools and provide readers of your RFC with a fuller picture. - -Note that while precedent set by other engines is some motivation, it does not on its own motivate an RFC. +TODO: ## Unresolved questions -I need others help/input with this. - -- What parts of the design do you expect to resolve through the RFC process before this gets merged? -- What parts of the design do you expect to resolve through the implementation of this feature before the feature PR is merged? -- What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC? +TODO: ## \[Optional\] Future possibilities -I need others help/input with this. - -Think about what the natural extension and evolution of your proposal would -be and how it would affect Bevy as a whole in a holistic way. -Try to use this section as a tool to more fully consider other possible -interactions with the engine in your proposal. - -This is also a good place to "dump ideas", if they are out of scope for the -RFC you are writing but otherwise related. - -Note that having something written down in the future-possibilities section -is not a reason to accept the current or a future RFC; such notes should be -in the section on motivation or rationale in this or subsequent RFCs. -If a feature or change has no direct value on its own, expand your RFC to include the first valuable feature that would build on it. +TODO: From d2811da4fcec0a1b514d34fa863382195f6a81b8 Mon Sep 17 00:00:00 2001 From: colepoirier <37318670+colepoirier@users.noreply.github.com> Date: Mon, 24 Jan 2022 15:13:04 -0800 Subject: [PATCH 03/18] Update rfc, filling the remaining sections Only 'unresolved questions is still TODO --- rfcs/diverse-defaults.md | 38 +++++++++++++++----------------------- 1 file changed, 15 insertions(+), 23 deletions(-) diff --git a/rfcs/diverse-defaults.md b/rfcs/diverse-defaults.md index a25347e8..7e4facc7 100644 --- a/rfcs/diverse-defaults.md +++ b/rfcs/diverse-defaults.md @@ -2,7 +2,19 @@ ## Summary -There are many different catagories of bevy applications. Each use case has a sufficiently different commonsense default configuration to warrant different use case specific default plugins. The catagories of bevy apps are at least the following: +There are many different catagories of bevy applications. Each use case has a sufficiently different commonsense default configuration to warrant different use case specific default plugins. + +## Motivation + +Bevy would be doing this to support easier and faster 'getting started' user story for non-minimal bevy applications. It will be particularly helpful to 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 + +Where there used to just be `DefaultPlugins` and `MiniminalPlugins` there will now be many different `DefaultPlugins` a user can choose from that exist for many common catagories of bevy applications. + +## Implementation strategy + +The catagories of bevy apps are at least the following: - minimal (current bevy DefaultPlugins) - game @@ -38,34 +50,14 @@ For example work-minimizing scheduling for low-power consumption web and mobile Building for touch vs mouse vs gamepad or other midi/advanced input controllers different use cases with very different requirements. -## Motivation - -Bevy would be doing this to support easier and faster 'getting started' user story for non-minimal bevy applications. It will be particularly helpful to 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 - -TODO: - -## Implementation strategy - -TODO: - ## Drawbacks -TODO: +The primary drawback I can see is the need for bevy to maintain the multiple `DefaultPlugins`, however, I forsee the mainenance burden of this to be exceedingly minimal. ## Rationale and alternatives -TODO: - -## \[Optional\] Prior art - -TODO: +The alternative to this proposal is for bevy to continue providing only `DefaultPlugins` and `MinimalPlugins` and for users to customize the plugins themselves through writitng their own or using 3rd-party plugins. ## Unresolved questions TODO: - -## \[Optional\] Future possibilities - -TODO: From ff5ac0ea65b908e8712e8041a78535bb42dbae61 Mon Sep 17 00:00:00 2001 From: colepoirier <37318670+colepoirier@users.noreply.github.com> Date: Mon, 24 Jan 2022 15:20:16 -0800 Subject: [PATCH 04/18] Move paragraph from implementation strategy to rationale --- rfcs/diverse-defaults.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rfcs/diverse-defaults.md b/rfcs/diverse-defaults.md index 7e4facc7..63978410 100644 --- a/rfcs/diverse-defaults.md +++ b/rfcs/diverse-defaults.md @@ -40,8 +40,6 @@ Each of which may have some combination of the following divergent platform conf - android native - web -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. - This feature also touches on not-yet-implemented but planned bevy features that will have different implementations per use case. For example work-minimizing scheduling for low-power consumption web and mobile applications, or desktop productivity apps are a very different configuration from high performance gaming and high performance scientific simulation. @@ -56,6 +54,8 @@ The primary drawback I can see is the need for bevy to maintain the multiple `De ## Rationale and alternatives +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 writitng their own or using 3rd-party plugins. ## Unresolved questions From da4bf988f885c0fabcceede6c54d2e12eb191d7e Mon Sep 17 00:00:00 2001 From: colepoirier <37318670+colepoirier@users.noreply.github.com> Date: Mon, 24 Jan 2022 15:29:01 -0800 Subject: [PATCH 05/18] Add edits and advice from @alice-i-cecile --- rfcs/diverse-defaults.md | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/rfcs/diverse-defaults.md b/rfcs/diverse-defaults.md index 63978410..7a104ca6 100644 --- a/rfcs/diverse-defaults.md +++ b/rfcs/diverse-defaults.md @@ -12,21 +12,19 @@ Bevy would be doing this to support easier and faster 'getting started' user sto Where there used to just be `DefaultPlugins` and `MiniminalPlugins` there will now be many different `DefaultPlugins` a user can choose from that exist for many common catagories of bevy applications. -## Implementation strategy +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: -The catagories of bevy apps are at least the following: +- MinimalPlugins: The very basic internal structure required to ensure things like Time function properly. +- GamePlugins: Suitable for making both 2D and 3D realtime 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. +- ApplicationPlugins: Suitable for making CAD applicaions or something like excel. +- SimulationPlugins: Plugins that make writing scientific simulations esiear like enhanced determinism and ordering guarantees. -- minimal (current bevy DefaultPlugins) -- game - - 2D - - 3D -- TUI -- application - - 2D - - 3D -- simulation +## Implementation strategy -Each of which may have some combination of the following divergent platform configuration needs: +Each of the above outlined `Plugins` may have some combination of the following divergent platform configuration needs: - desktop - native From d85bd7d87e8f9bfc3ded0a9f7a8c37a52642957e Mon Sep 17 00:00:00 2001 From: colepoirier <37318670+colepoirier@users.noreply.github.com> Date: Mon, 24 Jan 2022 15:36:28 -0800 Subject: [PATCH 06/18] Fill-in 'Unresolved Questions' --- rfcs/diverse-defaults.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/diverse-defaults.md b/rfcs/diverse-defaults.md index 7a104ca6..b75ebd66 100644 --- a/rfcs/diverse-defaults.md +++ b/rfcs/diverse-defaults.md @@ -58,4 +58,4 @@ The alternative to this proposal is for bevy to continue providing only `Default ## Unresolved questions -TODO: +Which default plugin sets do we want to include right now, and how precisely do they differ? From 5e129fcdc9e659b9cb1962c23f2132f46ae5b747 Mon Sep 17 00:00:00 2001 From: colepoirier <37318670+colepoirier@users.noreply.github.com> Date: Mon, 24 Jan 2022 15:45:28 -0800 Subject: [PATCH 07/18] Spell-check --- rfcs/diverse-defaults.md | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/rfcs/diverse-defaults.md b/rfcs/diverse-defaults.md index b75ebd66..f1af5904 100644 --- a/rfcs/diverse-defaults.md +++ b/rfcs/diverse-defaults.md @@ -2,7 +2,7 @@ ## Summary -There are many different catagories of bevy applications. Each use case has a sufficiently different commonsense default configuration to warrant different use case specific default plugins. +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. ## Motivation @@ -10,17 +10,16 @@ Bevy would be doing this to support easier and faster 'getting started' user sto ## User-facing explanation -Where there used to just be `DefaultPlugins` and `MiniminalPlugins` there will now be many different `DefaultPlugins` a user can choose from that exist for many common catagories of bevy applications. +Where there used to just be `DefaultPlugins` and `MiniminalPlugins` there will now be many different `DefaultPlugins` a user can choose from that exist for many common categories of bevy applications. -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: +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 realtime 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. -- ApplicationPlugins: Suitable for making CAD applicaions or something like excel. -- SimulationPlugins: Plugins that make writing scientific simulations esiear like enhanced determinism and ordering guarantees. +- `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. +- `ApplicationPlugins`: Suitable for making CAD applicaions or something like excel. +- `SimulationPlugins`: Plugins that make writing scientific simulations easier like enhanced determinism and ordering guarantees. ## Implementation strategy @@ -48,13 +47,13 @@ Building for touch vs mouse vs gamepad or other midi/advanced input controllers ## Drawbacks -The primary drawback I can see is the need for bevy to maintain the multiple `DefaultPlugins`, however, I forsee the mainenance burden of this to be exceedingly minimal. +The primary drawback I can see is the need for bevy to maintain the multiple `DefaultPlugins`, however, I foresee the maintenance burden of this to be exceedingly minimal. ## Rationale and alternatives -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. +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 writitng their own or using 3rd-party plugins. +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 From d69d94278bf5d3258a9e4bbd6b4ceb87dd4b92da Mon Sep 17 00:00:00 2001 From: colepoirier <37318670+colepoirier@users.noreply.github.com> Date: Mon, 24 Jan 2022 15:48:57 -0800 Subject: [PATCH 08/18] Update with PR number --- rfcs/{diverse-defaults.md => 48-diverse-defaults.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename rfcs/{diverse-defaults.md => 48-diverse-defaults.md} (100%) diff --git a/rfcs/diverse-defaults.md b/rfcs/48-diverse-defaults.md similarity index 100% rename from rfcs/diverse-defaults.md rename to rfcs/48-diverse-defaults.md From 52f5629bd099899deca2f4ea5ce05e6077cebc92 Mon Sep 17 00:00:00 2001 From: colepoirier <37318670+colepoirier@users.noreply.github.com> Date: Mon, 24 Jan 2022 16:35:51 -0800 Subject: [PATCH 09/18] Update rfcs/48-diverse-defaults.md Co-authored-by: Alice Cecile --- rfcs/48-diverse-defaults.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/48-diverse-defaults.md b/rfcs/48-diverse-defaults.md index f1af5904..89a99136 100644 --- a/rfcs/48-diverse-defaults.md +++ b/rfcs/48-diverse-defaults.md @@ -2,7 +2,7 @@ ## Summary -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. +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 From 3a5d01ea3ec1e734900e6a5b107a9236f436aa30 Mon Sep 17 00:00:00 2001 From: colepoirier <37318670+colepoirier@users.noreply.github.com> Date: Mon, 24 Jan 2022 16:36:27 -0800 Subject: [PATCH 10/18] Update rfcs/48-diverse-defaults.md Co-authored-by: Alice Cecile --- rfcs/48-diverse-defaults.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/48-diverse-defaults.md b/rfcs/48-diverse-defaults.md index 89a99136..dbfb0574 100644 --- a/rfcs/48-diverse-defaults.md +++ b/rfcs/48-diverse-defaults.md @@ -18,7 +18,7 @@ Bevy now provides you a number of convenient `PluginGroups` to help you get your - `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. -- `ApplicationPlugins`: Suitable for making CAD applicaions or something like excel. +- `ApplicationPlugins`: Suitable for making relatively static non-game applications. - `SimulationPlugins`: Plugins that make writing scientific simulations easier like enhanced determinism and ordering guarantees. ## Implementation strategy From bd59230d0681d5a0ebeed7011f300a85ae61edd4 Mon Sep 17 00:00:00 2001 From: colepoirier <37318670+colepoirier@users.noreply.github.com> Date: Mon, 24 Jan 2022 16:37:00 -0800 Subject: [PATCH 11/18] Update rfcs/48-diverse-defaults.md Co-authored-by: Alice Cecile --- rfcs/48-diverse-defaults.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/48-diverse-defaults.md b/rfcs/48-diverse-defaults.md index dbfb0574..a9d652c7 100644 --- a/rfcs/48-diverse-defaults.md +++ b/rfcs/48-diverse-defaults.md @@ -39,7 +39,7 @@ Each of the above outlined `Plugins` may have some combination of the following This feature also touches on not-yet-implemented but planned bevy features that will have different implementations per use case. -For example work-minimizing scheduling for low-power consumption web and mobile applications, or desktop productivity apps are a very different configuration from high performance gaming and high performance scientific simulation. +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. From 23b0f469bd4d4125fdd1b2f6bf868d64463e2287 Mon Sep 17 00:00:00 2001 From: colepoirier <37318670+colepoirier@users.noreply.github.com> Date: Mon, 24 Jan 2022 16:40:33 -0800 Subject: [PATCH 12/18] Update rfcs/48-diverse-defaults.md Co-authored-by: Alice Cecile --- rfcs/48-diverse-defaults.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/48-diverse-defaults.md b/rfcs/48-diverse-defaults.md index a9d652c7..89c530d9 100644 --- a/rfcs/48-diverse-defaults.md +++ b/rfcs/48-diverse-defaults.md @@ -47,7 +47,7 @@ Building for touch vs mouse vs gamepad or other midi/advanced input controllers ## Drawbacks -The primary drawback I can see is the need for bevy to maintain the multiple `DefaultPlugins`, however, I foresee the maintenance burden of this to be exceedingly minimal. +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 From 4161491d0051d1644b3919f037feaf7752316d3b Mon Sep 17 00:00:00 2001 From: colepoirier <37318670+colepoirier@users.noreply.github.com> Date: Mon, 24 Jan 2022 16:46:49 -0800 Subject: [PATCH 13/18] Remove line per https://github.com/bevyengine/rfcs/pull/48/files/d69d94278bf5d3258a9e4bbd6b4ceb87dd4b92da#r791250583 --- rfcs/48-diverse-defaults.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/rfcs/48-diverse-defaults.md b/rfcs/48-diverse-defaults.md index 89c530d9..b7a2c7a6 100644 --- a/rfcs/48-diverse-defaults.md +++ b/rfcs/48-diverse-defaults.md @@ -10,8 +10,6 @@ Bevy would be doing this to support easier and faster 'getting started' user sto ## User-facing explanation -Where there used to just be `DefaultPlugins` and `MiniminalPlugins` there will now be many different `DefaultPlugins` a user can choose from that exist for many common categories of bevy applications. - 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. From 0cf2756a1d7396076ad061721f04001295d07f95 Mon Sep 17 00:00:00 2001 From: colepoirier <37318670+colepoirier@users.noreply.github.com> Date: Mon, 24 Jan 2022 16:51:17 -0800 Subject: [PATCH 14/18] Clarity pass per https://github.com/bevyengine/rfcs/pull/48/files/d69d94278bf5d3258a9e4bbd6b4ceb87dd4b92da#r791250272 --- rfcs/48-diverse-defaults.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/48-diverse-defaults.md b/rfcs/48-diverse-defaults.md index b7a2c7a6..e646540c 100644 --- a/rfcs/48-diverse-defaults.md +++ b/rfcs/48-diverse-defaults.md @@ -6,7 +6,7 @@ There are many different categories of Bevy applications. Each use case has dist ## Motivation -Bevy would be doing this to support easier and faster 'getting started' user story for non-minimal bevy applications. It will be particularly helpful to 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. +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 From 30cfe09257c88bcc4c6642bfb74dc1bddcfdf697 Mon Sep 17 00:00:00 2001 From: colepoirier <37318670+colepoirier@users.noreply.github.com> Date: Mon, 24 Jan 2022 17:23:48 -0800 Subject: [PATCH 15/18] Add a few more potential 'Plugins' --- rfcs/48-diverse-defaults.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/rfcs/48-diverse-defaults.md b/rfcs/48-diverse-defaults.md index e646540c..e5df7afd 100644 --- a/rfcs/48-diverse-defaults.md +++ b/rfcs/48-diverse-defaults.md @@ -18,6 +18,9 @@ Bevy now provides you a number of convenient `PluginGroups` to help you get your - `TuiPlugins`: Suitable for making TUI applications. - `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 MinimalPlugins but with no rendering or windowing. +- `HeadlessIntegrationTestPlugins`: Suitable for running Bevy's integration tests as rapidly as possible. +- `RenderTestPlugins`: The minimal plugins necessary for testing the Bevy renderer. ## Implementation strategy From 62e6d1a45ef7a559d80dd71a4e144de5b1b60ea0 Mon Sep 17 00:00:00 2001 From: colepoirier <37318670+colepoirier@users.noreply.github.com> Date: Tue, 25 Jan 2022 16:36:10 -0800 Subject: [PATCH 16/18] Update rfcs/48-diverse-defaults.md Co-authored-by: Alice Cecile --- rfcs/48-diverse-defaults.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/48-diverse-defaults.md b/rfcs/48-diverse-defaults.md index e5df7afd..d5b78b3e 100644 --- a/rfcs/48-diverse-defaults.md +++ b/rfcs/48-diverse-defaults.md @@ -18,7 +18,7 @@ Bevy now provides you a number of convenient `PluginGroups` to help you get your - `TuiPlugins`: Suitable for making TUI applications. - `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 MinimalPlugins but with no rendering or windowing. +- `HeadlessServerPlugins`: Like `GamePlugins`, but without rendering, input handling, audio or windowing. - `HeadlessIntegrationTestPlugins`: Suitable for running Bevy's integration tests as rapidly as possible. - `RenderTestPlugins`: The minimal plugins necessary for testing the Bevy renderer. From 02700319653edef4ed725712a59f51279307d266 Mon Sep 17 00:00:00 2001 From: colepoirier <37318670+colepoirier@users.noreply.github.com> Date: Tue, 25 Jan 2022 16:36:55 -0800 Subject: [PATCH 17/18] Update rfcs/48-diverse-defaults.md Co-authored-by: Alice Cecile --- rfcs/48-diverse-defaults.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/48-diverse-defaults.md b/rfcs/48-diverse-defaults.md index d5b78b3e..dee3c193 100644 --- a/rfcs/48-diverse-defaults.md +++ b/rfcs/48-diverse-defaults.md @@ -19,7 +19,7 @@ Bevy now provides you a number of convenient `PluginGroups` to help you get your - `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's integration tests as rapidly as possible. +- `HeadlessIntegrationTestPlugins`: Suitable for running Bevy integration tests as rapidly as possible. - `RenderTestPlugins`: The minimal plugins necessary for testing the Bevy renderer. ## Implementation strategy From a3171885e71c29d59d162b3f5f4d49d202fb404e Mon Sep 17 00:00:00 2001 From: colepoirier <37318670+colepoirier@users.noreply.github.com> Date: Tue, 25 Jan 2022 16:37:06 -0800 Subject: [PATCH 18/18] Update rfcs/48-diverse-defaults.md Co-authored-by: Alice Cecile --- rfcs/48-diverse-defaults.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/48-diverse-defaults.md b/rfcs/48-diverse-defaults.md index dee3c193..49c7c30d 100644 --- a/rfcs/48-diverse-defaults.md +++ b/rfcs/48-diverse-defaults.md @@ -20,7 +20,7 @@ Bevy now provides you a number of convenient `PluginGroups` to help you get your - `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 the Bevy renderer. +- `RenderTestPlugins`: The minimal plugins necessary for testing that Bevy is rendering objects as expected. ## Implementation strategy