diff --git a/content/news/2023-07-07-bevy-0.11/index.md b/content/news/2023-07-07-bevy-0.11/index.md index 3d0bc99389..2571a3c0c9 100644 --- a/content/news/2023-07-07-bevy-0.11/index.md +++ b/content/news/2023-07-07-bevy-0.11/index.md @@ -17,11 +17,146 @@ Since our last release a few months ago we've added a _ton_ of new features, bug * **Feature**: description -## Feature - -
- -Description +## Schedule-First ECS APIs + + + +In **Bevy 0.10** we introduced [ECS Schedule V3](/news/bevy-0-10/#ecs-schedule-v3), which _vastly_ improved the capabilities of Bevy ECS system scheduling: scheduler API ergonomics, system chaining, the ability to run exclusive systems and apply deferred system operations at any point in a schedule, a single unified schedule, configurable System Sets, run conditions, and a better State system. + +However it pretty quickly became clear that the new system still had some areas to improve: + +* **Base Sets were hard to understand and error prone**: What _is_ a Base Set? When do I use them? Why do they exist? Why is my ordering implicitly invalid due to incompatible Base Set ordering? Why do some schedules have a default Base Set while others don't? [Base Sets were confusing!](https://github.com/bevyengine/bevy/pull/8079#base-set-confusion) +* **There were too many ways to schedule a System**: We've accumulated too many scheduling APIs. As of Bevy **0.10**, we had [_SIX_ different ways to add a system to the "startup" schedule](https://github.com/bevyengine/bevy/pull/8079#unify-system-apis). Thats too many ways! +* **Too much implicit configuration**: There were both default Schedules and default Base Sets. In some cases systems had default schedules or default base sets, but in other cases they didn't! [A system's schedule and configuration should be explicit and clear](https://github.com/bevyengine/bevy/pull/8079#schedule-should-be-clear). +* **Adding Systems to Schedules wasn't ergonomic**: Things like `add_system(foo.in_schedule(CoreSchedule::Startup))` were not fun to type or read. We created special-case helpers, such as `add_startup_system(foo)`, but [this required more internal code, user-defined schedules didn't benefit from the special casing, and it completely hid the `CoreSchedule::Startup` symbol!](https://github.com/bevyengine/bevy/pull/8079#ergonomic-system-adding). + +### Unraveling the Complexity + +If your eyes started to glaze over as you tried to wrap your head around this, or phrases like "implicitly added to the `Update` Base Set" filled you with dread ... don't worry. After [a lot of careful thought](https://github.com/bevyengine/bevy/pull/8079) we've unraveled the complexity and built something clear and simple. + +In **Bevy 0.11** the "scheduling mental model" is _much_ simpler thanks to **Schedule-First ECS APIs**: + +```rust +app + .add_systems(Startup, (a, b)) + .add_systems(Update, (c, d, e)) + .add_systems(FixedUpdate, (f, g)) + .add_systems(PostUpdate, h) + .add_systems(OnEnter(AppState::Menu), enter_menu) + .add_systems(OnExit(AppState::Menu), exit_menu) +``` + +* **There is _exactly_ one way to schedule systems** + * Call `add_systems`, state the schedule name, and specify one or more systems +* **Base Sets have been entirely removed in favor of Schedules, which have friendly / short names** + * Ex: The `CoreSet::Update` Base Set has become `Update` +* **There is no implicit or implied configuration** + * Default Schedules and default Base Sets don't exist +* **The syntax is easy on the eyes and ergonomic** + * Schedules are first so they "line up" when formatted + +