Skip to content
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

Bevy and Crux similarities #167

Open
pjankiewicz opened this issue Dec 22, 2023 · 1 comment
Open

Bevy and Crux similarities #167

pjankiewicz opened this issue Dec 22, 2023 · 1 comment

Comments

@pjankiewicz
Copy link

Hi again! I see a lot of similarities between Bevy and Crux if I squint my eyes really hard.

One example are capabilities both Bevy and Crux are meant to be running in different environments.
For example the Multi-platform Key Value store implementation is written by someone in the bevy community - https://github.com/johanhelsing/bevy_pkv. It depends on bevy ecs so it is not a perfect dependency for Crux but it almost can be.

Perhaps Crux can also draw inspiration from the way Bevy defines plugins. Plugins in Bevy are almost standalone apps with their own systems and data. I feel that capabilities are very similar to plugins and a capability that is defined and used in the Core can also have a bundled implementation in the Shell. So Rust can provide not only compiled Core library but also compiled capabilities implementations that live outside the Core in the Shell.

@charypar
Copy link
Member

Hi! There's quite a few projects following this kind of pattern, loosely based around the idea of ports and adapters. Bevy, like most game engines, adds the open composition of the ECS architecture, useful for games with many independent entities and systems evolving over time. There are no new ideas 😄

You're absolutely right that capabilities could bundle implementations for the shell, we have that on our roadmap (not explicitly, but it's a whole lane in https://github.com/orgs/redbadger/projects/11/views/1), but there are quite a few things to work out, especially the distribution mechanism, and how to make implementations available, but not necessarily force them. Needs quite a bit of thinking.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants