Bevy strategy pre-planning for 0.7

[alice-i-cecile]

As we wrap up the main work of 0.6 (see #2535 for progress), we're starting to approach the time where we take a look at priorities going forward 🎉

The goal of this discussion is not to decide all these things now, but instead to create an agenda and meeting strategy so we can have a proper conversation despite the large number of interested participants :) If there are subtopics here that you would like to be considered that I have not covered, please comment in the appropriate thread and I'll edit it into the parent reply to keep track of topics to discuss.

There's quite a few things to cover, so I'm going to split this into top-level replies by topic:

• META: Discussion format
• PLANNING: Work to complete before 0.6 launch
• PLANNING: Focus area(s) for 0.7
• PLANNING: Engine development process improvements

[alice-i-cecile]

Discussion format

There are several questions to answer here:

• Scheduled voice chat, Discord chat, or Github Discussions?
• How many meetings?
• If voice or Discord chat, how can we moderate this to reduce chaos?

For those new to the dev-side of the community, decisions are ultimately made by @cart in a fashion that's responsive to community feedback and capacity. If you have comments, concerns or ideas, please chime in!

[RustyStriker]

if you schedule a voice meeting(or any kind of not too long of a meeting) timezones will pose a big problem. So instead of making the "community vote" in the meeting itself, maybe someone can sum it up(or a bunch of people) and post a poll so more people could voice themselves(esp for the 0.7 meeting)

[afonsolage]

But discussing it using Discord or GH Discussion will lead to tons of texts, which makes me wonder: The main goal is to discuss some points between the community and some core/main contributors and Cart, or is to generate rich docs about the discussion and let more people interact with it?

If the focus is to have a better and deep understanding between some main people, the meeting is better and we can even record and publish it on YT.

But if the focus is to have a open and broad discussion (like we already have for some topics) so the text channels are better (I think GH discussion should be prioritized).

[alice-i-cecile]

If the focus is to have a better and deep understanding between some main people, the meeting is better and we can even record and publish it on YT.

The challenge with this is that we have core contributors across all time zones. We also have spoken English proficiency / comfort to worry about.

[Nilirad]

Unfortunately real time communication via voice chat or Discord threads pose various problems, first of all timezone difference. On the other hand these formats are very useful to exchange information in a very short amount of time. Therefore I think that a hybrid approach may be appropriate.

I see it this way:

1. A preliminary GitHub discussion that poses an issue where the opinion of the community is needed. This discussion will be relevant for at least a couple of days to give as many people as possible time to express their thoughts on the matter.
2. A cart-timezone-centered real time meeting. Here collaborators present to cart a digest of the preliminary discussion. From this, further discussion with present devs is made and a final decision is made. Since some devs cannot attend, they can lay out their submissions in detail in the preliminary discussion and charge who will be present to take their place.
3. The final decision is then laid out as one or more RFCs (if applicable) and on the #announcements-dev Discord channel and bevy blog.

Note: Discussion material should be archived, linked to or tagged in a way that it is easier to find later.

Note 2: Maybe a short meeting to decide the argument of the preliminary discussion and the subsequent meeting can be done. Or maybe not.

Note 3: For the sake of order, if the meeting is made in the form of voice/video chat, it's better to limit the amount of people who can talk at the same time (e.g. by taking turns or by "raising hand"to comment). For Discord chats, slow mode can be applied, except for people charged to speak.

[Supermath101]

I have an idea: What if we can have a "Regional Meetings Moderator/Coordinator" for most major timezones. The idea would be to have multiple meetings, a couple per region based on timezone. Then, record the meetings, and discuss what was talked about on the previous meeting during the next one. Finally, after a few days of cycling around the world having meetings in different timezones, we'll hopefully have reached a global consensus on any major decisions needing to be made.

Note: I already asked this on Discord, but I feel it needs to be more formally discussed and recorded. Also, sorry if that sounded a little confusing, I'll be happy to clarify.

[alice-i-cecile]

Work to complete before 0.6 launch

Current things that we know must be completed:

1. Renderer Rework: Initial Merge Tracking Issue #2535
2. [Merged by Bors] - Implement and require #[derive(Component)] on all component structs #2254
3. Migration guide (Start 0.5 -> 0.6 Migration guide bevy-website#185)
4. Release checklist.
5. Other items from https://github.com/bevyengine/bevy/milestone/3

The following PRs are things that I think we should consider adding to the milestone:

1. New book (Welcome chapter bevy-website#176 and friends)
2. [Merged by Bors] - ParamSet for conflicting SystemParam:s #2765
3. Create a System Builder Syntax instead of using System Descriptors #2736, blocked on System Lifecycle Rework: all Systems are initialized by definition #2777
4. [Merged by Bors] - Implement WorldQuery derive macro #2713
5. Add SystemGraph as a handle-based method for explicitly creating system dependency graphs #2381
6. [Merged by Bors] - Improve bevy_ecs and bevy_app API docs where referenced by the new Bevy Book #2365

When selecting this list I tried to prioritize a combination of:

• high user impact
• heavily breaking changes
• nearly ready to merge
• not likely to be immediately obsoleted

If there are other open PRs / issues that you think are worth including here, please mention them below. We should also aim to do a quick review (and hopefully merge) of all open ready-for-final-review PRs to avoid small fixes going stale.

[alice-i-cecile]

Right, good call. Most of the remaining items on the list are small-but-important fixes that I don't think need to be discussed.

[alice-i-cecile]

There we go; splitting the "stuff we've already agreed on" from "stuff we need to debate" is a much cleaner organization.

[hymm]

should 2777 be on this list too? I thought it was blocking 2736.

[alice-i-cecile]

IMO #2777 is too complex to push for in time, has no direct end-user benefit and is overall too tied up in the broader work being planned #2801. That said, the judgement call from @cart and @Ratysz was that #2777 should be done before #2736, like you said.

So I think that we can rule out #2736 for now, as nice as it would be to have :(

[TheRawMeatball]

Eh, I think there's hope for #2777. It's a purely internal change with clear design, and #2736 could be considered it's "direct end-user benefit".

[alice-i-cecile]

Focus area(s) for 0.7

There are several candidates that have been discussed:

• UI
  • needs heavy-handed decision-making to cut through paralysis
  • some serious open design questions, particularly around the data flow model
  • heavy user impact: this is one of the most serious challenges with making Bevy games right now
• System schedule and states (follow ECS Mad Science Lab, stageless-ish R&D #2801 for this planning)
  • move to a stageless design
  • clean up tangle of abstractions
  • simplify States to provide a better user experience
  • fix the "states don't play nice with other run criteria" issues
  • requires a large degree of coordination
  • more system scheduling API improvements: as_if_before from System scheduling #2747, extended variants of system graphs from Add SystemGraph as a handle-based method for explicitly creating system dependency graphs #2381
  • not very user-visible :(
  • may be able to complete in parallel with another focus area (led by @Ratysz and @TheRawMeatball)
• Scenes and reflection
  • currently limited and underdocumented
  • critical if we want a data-driven UI design
• Assets
  • Distill integration is finally unblocked
  • this area requires lots of expert feedback
  • asset pipelines are important and missing
• Hierarchy clean-up (see Project planning: UI hierarchies and the current Parent-Child implementation #2572)
  • slow, buggy and full of rough edges
  • cannot easily be extended
  • could prioritize incremental improvements before relations prototypes are complete
• Ray-casting, picking and geometric primitives
  • solidly useful, well-scoped
  • critical for potential physics and advanced rendering topics
  • will lean heavily on prototypes and expertise by @aevyrie
  • could include Transform-adjacent topics like Ability to set Transform fundamental native type to f64 or fixed-point types #1680, splitting Transform or changing the coordinate directions
• Canvas API
  • Very useful for prototyping and making 2D games
  • Solid third-party crate exists: reduces need to prioritize, but also reduces uncertainty
  • Could tie in wire-frame / debug-lines to improve visual prototyping / debugging further
  • Some elements of the UI (e.g. control over screen vs world coordinates) could be tackled incrementally to help this

There are some other areas that I don't think are appropriate candidates at this stage:

• Relations
  • fundamentally a research problem still; dedicated collaboration won't help this at this stage
  • we need a solid prototype before moving forward
• Audio
  • our audio is badly lacking
  • bevy_kira_audio is a solid stop-gap for now; we should watch to see how the space develops
• Documentation
  • can be done in parallel
  • comprehensive tutorials are not feasible with major areas of the engine still deficient
  • docs have a maintenance cost
• Advanced PBR and rendering performance optimizations
  • important and makes for pretty graphics
  • not nearly as blocking for creation of games
  • can continue largely independently from contributors interested in the area
• Input mapping
  • needs more design work
  • not pressing enough yet
• XR (Virtual, augmented and mixed reality) support
  • hard for many to contribute
  • only relevant to a small subset of users
  • can continue in parallel
• Mobile and web support
  • requires tight UI integration to test usability on mobile
  • lifecycle management and stability fixes are important, but need design from experts
  • can continue in parallel
• Animation
  • Full featured property based Animation System #1429 (and perhaps Add access to pressed/just_pressed/just_released to Input<T> #428) needs more user experience reports, docs and testing
  • these should be prototyped in a third-party plugin with MIT + Apache licenses and then brought in-stream once they're more mature
• Networking
  • Bevy is too immature
  • Networked Replication rfcs#19 is the first step towards this

[colepoirier]

@djeedai I think you are misunderstanding a bit. The immediate mode debugging tooling is just that, its not official bevy UI, there is no investment in it by the bevy project whatsoever. I’m not sure how “exploring with an Editor-focused UI plugin would unblock” the editor or the UI, could you expand on what you mean? The heavy handed decision making has to be made by cart, we’re waiting on cart for the big UI rewrite and the editor will come after that, it can’t happen in parallel because it requires the UI solution to exist first.

[Barugon]

• UI
  • needs heavy-handed decision-making to cut through paralysis
  • some serious open design questions, particularly around the data flow model
  • heavy user impact: this is one of the most serious challenges with making Bevy games right now

This.

[colepoirier]

What about ‘this’ @Barugon?

[Barugon]

What about ‘this’ @Barugon?

My vote for what should be a primary focus for 0.7.

[colepoirier]

Ah gotcha thanks for this!

[alice-i-cecile]

Engine development process improvements

Again, topics for discussion. A lot of this follows up on the work started by @NathanSWard in #2256.

1. Project roadmap: how do we want to communicate this?
2. Issue and PR lifecycle management using Github boards.
3. More granular PR status labels: needs-review in particular would be very useful.
4. PR review process changes to reduce merge latency?
5. Minor releases for Bevy?
6. Focus areas meta-discussion: how do we set, stick to and communicate priorities?

[Nilirad]

Minor releases for Bevy?

Assuming that we will adopt a shorter release cycle for the next versions, I don't think it is a good idea. Even small improvements to the user experience should be a new major release, just like the first versions of Bevy. It will be a different story once we hit 1.0, but it's too early to talk about it now.

Focus areas meta-discussion: how do we set, stick to and communicate priorities?

I think Cart should have the exclusive right to ultimately define the focus areas of Bevy. Obviously anyone can express their thoughts but this has to happen naturally, without meetings or discussions about what the next focus area should be. The communication can happen through the #dev-announcements channel and/or as a GitHub tracker issue (like the current three focus areas are already defined). I think we're already sticking to the focus areas, by giving merge priority to pertinent PRs.

[Weibye]

3. A S-Needs-Review would indeed be helpful. Do we also need a S-Need-Author-Feedback / Response ?

[alice-i-cecile]

There's a bit of justified concern about how actionable that would be. The label is mostly useless to everyone but the single author.

[colepoirier]

Building on your comments @alice-i-cecile, I’d like to suggest that there are three primary focus areas that need to be worked on before UI, and three smaller, more independent areas that can proceed entirely in parallel. I’ve identified what I think can be led primarily by community members, ones where I think @cart need to be equally involved, and the ones which I predict cart should be the primary driver.

Primary

1. Ray-casting, picking and geometric primitives (more community, less cart)
2. Scenes, reflection, assets (cart)
3. Animation (cart)

Smaller, secondary, parallel tasks

1. Mobile and web support (mostly community)
2. Hierarchy clean-up (Cart)
3. System schedule and states (@Ratysz and/or @TheRawMeatball and some Cart)

I would also like to suggest that Cart start working on UI, primarily participating in discussion starting after 0.6 is released, in parallel with whatever his main focus is for the next 3-4 releases to start building out plans and implementing prototypes of foundational UI components. I think that this needs to happen in order for us to have any hope of actually “getting to UI” because it is simply too huge a domain to do all at once. I think if cart starts working lightly on UI at first by just participating in discussions, and builds up his involvement/focus/efforts on ui over the releases of the other focus areas, that this will be the best way to slowly work up to doing the full UI focus eventually.

What do you think?

[alice-i-cecile]

The hierarchy cleanup can comfortably be tackled without much Cart involvement. Relations would be one approach to solve it, but the scope is too large and uncertain for me to recommend it as a prerequisite.

But doing a code quality / API pass would fix enough to make it usable for UI and is fundamentally mundane engineering work.

[alice-i-cecile]

I don't think the first item is necessary for UI.

A canvas API would be more useful for it, but not essential immediately: rectangles go a long way. Geometric primitives would probably be useful for that, but as seen in 'bevy_prototype_lyon`, not truly needed.

[colepoirier]

I should clarify that I don’t think all of these are prerequisites for UI, but that it seems like in terms of timeframes they could be completed before the big UI focus especially since a lot of them can be done without cart. I think that the UI discussion and early development process could take a long time so it should start with low but regular time commitments from cart.

I agree that animation and canvas would be a great thing to get done together because of how useful I’m assuming that will be to 2D. And I would say getting 2D capabilities like that implemented would be a big win for the engines maturity overall.

[inodentry]

I quite like this list, though not necessarily as "a list of prerequisites for UI", but rather "a list of other foundational work with big user impact that would be nice to complete first regardless of UI". It would do wonders for the maturity of the engine and enabling people to work on more different kinds of games and more ambitious projects. (yes, arguably UI itself is more of a blocker for many projects, but it would also take a much longer time to get ready)

[afonsolage]

I quite like this list, though not necessarily as "a list of prerequisites for UI", but rather "a list of other foundational work with big user impact that would be nice to complete first regardless of UI". It would do wonders for the maturity of the engine and enabling people to work on more different kinds of games and more ambitious projects. (yes, arguably UI itself is more of a blocker for many projects, but it would also take a much longer time to get ready)

Sorry if I misunderstood, but what's the point of having people to work on more different kinds of games and more ambitious projects, if there is no UI?

[Joe23232]

I was thinking we had a similar UI like DearPyGUI

And we use similar syntax as to theirs as it is quite simple by the looks of things.

What do you guys say?

[colepoirier]

I have good news for you, we have this already, it is called bevy_egui!

[Joe23232]

@colepoirier But that is immediate, not retained unlike Dear PyGui.

[colepoirier]

The api is the same regardless.