Bevy synonym code#

These allow you to group systems together, then specify metadata that applies to all the systems within that set. This increases the severity of this problem, and, as part of those changes, SystemSets were introduced.

This added another critical, but relatively complex piece of metadata to our systems: dependencies (which specify that a system must run before)

Bevy synonym code#

Some of this metadata was also handled on a per-stage basis, as seen with SystemStage::serial.Įxplicit system ordering was introduced in #1144, to resolve issues around implicit magical behavior that violate least-surprise and make refactoring code bases very dangerous in non-obvious ways. I believe has a PR in the works to address this for single systems, by using the builder pattern to specify metadata.

See #1060 for a previous discussion of this problem. This was initially handled by a proliferation of AppBuilder methods, such as add_startup_system_to_stage, but this has obvious limitations due to the exponential number of combinations as we add metadata. Whether they are only functional during a certain State or not.Whether they're an exclusive ('thread-local' in 0.4 parlance) system or not.Whether they have any run criteria attached.Whether they're a startup system or not.The ProblemĪs Bevy's needs grow, there's been an increasing demand for ways to elegantly add 'metadata' to systems (which describe how and when a system should execute, rather than what it does). Credit for the original seed of this idea belongs to approach discussed here shouldn't be seriously attempted until 0.5 has been released, in order to make sure the fundamentals of #1144 and Cart's ECS storage overhaul are solidified (see further discussion here). This post is an attempt to capture conversation between and myself around more ergonomic ways to organize systems.