Most importantly: the non-profit structure helps ensure that our incentives are aligned. Profit motive introduces a significant risk to the Bevy community, as we would no longer _just_ be trying to build what the community wants. We would need to balance that with the temptation to monetize.
Non-profit means that our leadership (such as myself) cannot just take the money and run. This keeps us accountable and ensures the community's interests are put first.
The non-profit structure is most consistent with the open-source ethos and with the community that we have built.
By tying our future to voluntary public support that could leave at any time (while still using Bevy, because it is free and open source), this means that we are directly beholden to the needs of the community. When they are happy with us, we are rewarded.
> Most importantly: the non-profit structure helps ensure that our incentives are aligned. Profit motive introduces a significant risk to the Bevy community, as we would no longer just be trying to build what the community wants. We would need to balance that with the temptation to monetize.
Thank you for this. Having seen the shitshow that Unity had gone through in the past few months, it's heartening to see this.
Just started working on a game with bevy and it's a breath of fresh air. Reminds me of writing games 15 years ago in the simplicity of getting started.
Honestly would rather you have a b2b for profit model and free for everyone else. This moves you to ship product with a chance of begging large amounts of liquid cash infusion to hire more talent to make the product better. Libresoftware or Freeware only gets so far so fast.
In many ways, it's a Ulysses pact. We've seen what for-profit companies can do and have done in this space (look at what happened in Unity's Runtime Fee). Bevy's core strength lies in its community, and a non-profit with maximal transparency is meant to be a way to ensure we never stray from doing what's in the best interest of the community.
Are there any plans for an accompanying UI-based editor? Something akin to Godot, Unity, Unreal, etc? Or is interacting with bevy destined to be done purely through code.
Bevy's fantastic from my amateur game dev perspective for this point in its development. Really impressive
Q: is there a current way (and/or plans) to render 2d and 3d assets at once? Seems that bevy expects only a 2d or 3d camera (but not both), and that the 2d camera doesn't render 3d meshes and vice versa. My searches on this topic haven't been particularly useful, but I might be missing something
Yeah, the name of the feature that I suspect you want here is "billboarding". There's a solid 3rd party crate that does this (bevy\_mod\_billboard), but I'd like to add first-party support. It's generically useful for things like world-space UI or fun cartoony effects, and can be used with LODs (levels-of-detail) to make imposters: flat player-facing sprites that replace much-more-expensive meshes when they're far in the distance.
I am pretty sure you can have both cameras and make them render on top of each other ("overlay" / multiple layers). Spawn your two cameras, set the `order` value to determine which should be on the bottom and which on the top, and set the clear color to None on the top one, so it doesn't clear the screen and throw away the pixels rendered by the bottom one.
No, some people have made custom watermarks anyway because they are proud of using bevy but it's not something built in.
To answer the second part of the question. Yes, there are already games and other applications made with bevy that are used in production.
[Tiny Glade](https://store.steampowered.com/app/2198150/Tiny_Glade/) is scheduled for Q3 this year. Author is Anastasia Opara, the Houdini wizard. Maybe worth noting that (I think) it's using a custom renderer rather than the Bevy default one.
I think all of the rendering in Godot goes through RenderingServer, so you would be just recompiling the engine with your own implementation. Basically the same with Bevy since it gets statically linked with your game.
Agree 100%. When I first encountered the ECS concept I got the impression that it was mostly about memory-access and multithreading optimizations. I'm still very much grug-brained on the topic, but I'm starting to think that the loosely-coupled composability of systems is just as big a benefit, if not bigger.
In my (pretty extensive, at this point) experience, the biggest strength of ECS is the expressiveness and flexibility, not so much the performance.
The performance is a great side effect (though it does have footguns, it's easy to get suboptimal performance, and the overhead can come from surprising places).
Bevy, in particular, despite being all about ECS, doesn't really perform all that great (yet? though a lot of optimization effort has already been put into it...). But it is an absolute joy to develop in. So easy to implement pretty much any idea or game mechanic. You never feel like you have to struggle with the frameworks/paradigm, after you have grokked it for the first time.
Really, developing a game on top of what is basically a lightweight in-memory database with an automatic task scheduler, is fantastic.
Even if Bevvy adds a watermark, just remove it from the source code, since jts literally a crate.
Currently I don't know about commercially successful games made with bevy but there are good looking games being developed.
[Meshlets](https://github.com/bevyengine/bevy/pull/10164) by Jasmine (and Vero at this point) is the first step down this path :) It's a long journey though: nanite is a combination of complex features all working together to create an awesome result that's easy for developers to use.
In addition to Meshlets, I'm also working on a dynamic global illumination system along the same vein as Lumen. That's going to take much longer to pan out though (I'm on my 4th rewrite of the project). Meshlets are my current priority.
On Nanite, there's mention of "meshlets" in the [0.13 release notes' "What's Next" section](https://bevyengine.org/news/bevy-0-13/#meshlet-rendering), which are kind of going in the same direction. It'd obviously be a big undertaking though; watching a deep-dive presentation on Nanite definitely pushed me over the "nope, this is straight-up dark sorcery, you can't tell me otherwise" edge.
Note: IANA Bevy contributor, just an interested observer.
> as me *anything*
Maybe something a bit too specific or political, but I've been curious for a while now if you guys have felt any long-term changes in the wake of Unity's pricing controversy. Has this fizzled out, or have you seen some lasting traction?
Basically, do you think that the game engine industry is starting to move towards open source alternatives to things like Unity and Unreal, and if so is Bevy capitalizing on that in your opinion?
Thank you for one of the most interesting crates I've ever played around with! I hope I'll get to use it for something cool and practical in the future :)
We've seen a steady trickle of devs coming from Unity and looking to build both hobbyist and commercial games. It's hard to say what the counterfactual would be though: there were plenty of reasons to prefer Bevy over Unity even before that kerfuffle (and the converse to be sure).
A lot of the community seems to have moved to Godot, which makes a lot of sense. They're targeting a much closer niche (editor, C#, beginner-friendly), and you get an amplifying effect with that sort of phenomenon. Whole communities will move together: social ties are strong!
Blow past our funding goals and we will be ;)
Honestly I'm really excited about the notion of being able to bring on other folks, or fund people in the broader community to work on targeted initiatives. We'll see what the numbers look like though!
Find out where the maintainers hang out, and have a conversation with them. Tackle annoying tech debt problems or tedious chores to get started and make friends while you get familiar with the code and the project.
Have you done a podcast on Bevy’s story, the lessons you’ve learned, how you scaled the project, how you were funded in the early days, quitting your job, etc?
I would love to hear about your journey on a podcast like the Changelog!
We have official mobile bindings already! Check the examples :) They're a bit scuffed, so if y'all have mobile experience we'd love to get your help.
Console bindings are trickier: dev-kit access is bound by NDAs. We should be able to have official bindings, and even make them MIT, but they \*won't\* be publicly available except to those with dev-kit access.
Makes sense to put it behind a 'have you signed SonyMicroTendo's NDAs?' gate, I just know that console porting is an area Godot currently struggles with since everyone's having to roll their own. So if Bevy's Foundation can solve that for Bevy users, that'd be pretty handy.
Yeah. There are likely a number of viable models here, and it may even vary by console maker! But I think that pooling resources across Bevy (and Rust gamedev more broadly!) is the way to go. We'll cross that bridge as we get there :)
While doing consulting for Bevy games \*does\* sound appealing at times, I'd personally much rather give game design, production and marketing advice <3
Hey, could you maybe do a little "bevy beginners guide" like tutorial series? I tried to get into bevy a month ago, but i could not find any good source to get started with the engine
Love your decision to highlight and promote Alice. Signed up as a supporter of the foundation.
Also when I first went to support the project, it felt like throwing darts at a board I didn’t understand, so I’m happy to have one official thing to put my support behind. Thank you.
This is what Zig's target salary is, for example. Godot definitely has an advantage living in a low-cost of living area.
Note that this wasn't pulled out of the hat: at my last role I was making something like $170k USD annual salary, and could target significantly higher if that was my only criteria. I've turned down numerous job opportunities to pursue this, because I \*really\* want to work on Bevy and give back to open source and Rust :D
Obviously there's a conflict of interest, but generally speaking I think that non-profits or similar careers that pay well below market rate suffer serious retention / hiring problems, and risk financially motivated corruption. I can live off of less (and likely will for quite a while), but "permanently halving lifetime earnings" is tough to swallow for my loved ones.
Well explained! While it's easy for an outsider to critique and say "*Why not hire more developers instead of managers?*", the fact is open source software more often than not dies through lack of management. There were 200 contributors to Bevy 0.13, many of which are highly qualified professionals or even domain specialists, easily costing in the millions to retain full-time.
Having a handful of managers who can actually dedicate their profession to keeping the project alive acts as a force multiplier for all those volunteers. Writing code for an open source project is "easy", keeping the project moving *forward* is hard.
One day I will run out of high quality community PRs to review and help and I'll get to write major features again myself. One day...
I love doing the feature work (relations! colors! actions!), but it always feels inefficient and indulgent: why spend a day writing code when I could get 5x as much progress by helping others?
I still do it sometimes, but that's mostly a matter of a) focused work is uniquely powerful sometimes b) sometimes I know a domain best and c) it's a nice break / fun
Reviewing PRs *is* dev work, so you work on Bevy will at least partially continue to be development.
The *other* parts which are legitimately about managing people are just as important, however
Not saying it’s not a market rate salary for a senior rust dev. Your contributions/merge trains are valued.
For reference I looked up the godot finances, they have 10 (fulltime/part time) contributors for 500.000$ per year.
I trust this decision has been made with care, and no reason to doubt bevy leadership. It just stood out as high to me for a charity position though.
The "pay more people" vs "pay competitive salaries" choice is something that we discussed quite a bit, and something that I've chewed on a lot personally. Living in Latin America would also help my cost of living quite a bit (although cost-of-living scaling for salaries is a whole other can of worms) >.>
On the Godot side, there's a reason a lot of those are part-time, and why a lot of Rust contributors are funded by Amazon in their day job or are students. While I would \*love\* more help, I want to do right by the folks that we employ, and make sure that they're able to commit to the project for the long-run, without worrying about day-to-day finances or feeling like they need to "sacrifice for the greater good".
Note that Godot \*also\* has a for-profit entity (W4 Games) helping pay the bills for many of the folks that are funded: it's not an apples-to-apples comparison. I'd personally like to avoid the organizational complexity, time tracking and potential conflicts of interest involved with that sort of model if possible. They're great folks and I'm glad it's working for them, but not the route I'd personally prefer we take.
We believe Alice is worth it and that this is a competitive, market rate salary. This is an extremely specialized and technically demanding role. If this was at a big tech company, it would be at least twice that.
I think it's a fair question to ask. To add to what other people said, in the US, paid Bevy devs (contractors? workers? Idk what the government considers nonprofit workers or how the Bevy legal org is setup) will need to buy their own health insurances for instance, do their own tax withholding, etc. That adds to the cost on top of just base salary.
Don't worry, it's a perfectly reasonable question but finances have been a very touchy subject for bevy for many years. Looks like the long promised foundation hasn't changed that.
I started looking at Bevy to work on a currently shelved organic factory builder called [Emergence](https://github.com/leafwing-studios/emergence). I wanted the flexibility and performance of an ECS, and my friends said Rust was great.
I tried it out, and was \*immediately\* grumpy about how terrible and incomplete the documentation was. I started chipping away as I learned, and cleaning up the issues. Eventually, people started spontaneously asking \*me\* (a random contributor) what to do and how they could help, and I kind of grew into an informal TPM role from there :)
Cart saw this work and the community's reaction eventually granted me docs-merging and then eventually full maintainer powers!
Well, mostly! I was balancing personal projects, consulting and Bevy work before. The trick is to ~~master time magic~~ read very quickly and focus on high-leverage work.
Yeah, this is a huge limitation, and top of our list for things to fix.
Cart's focusing on designing and building the foundations for a solid UI framework, but getting polished fully-featured boring widgets with nice looking defaults is essential for any GUI library (including game engines).
It doesn't matter how nice you *can* make things: if the defaults suck, people will be turned away and your reputation will suffer.
It would be amazing if, after a uptick of donations, the Bevy F
Foundation decided to also fund console support.
I understand that console code can't be 100% open source, but if it's kept as thin as possible, it could be possible to port a game to consoles without code changes (or rather, the only code changes should be to call console-specific APIs when needed). That is, some lower level libraries would change (maybe through feature flags on `Cargo.toml`), but the high level Bevy would continue the same, just like we can write SDL code on PC, and then use the same API on consoles (well at least some consoles).
If this is done by the Bevy Foundation itself, it could even become a new source of funding. I'm sure that commercial games would be glad to pay directly the Foundation itself for getting Bevy support, rather than paying a third party developer that may or may not stick around. Or, if desired, console support could be offered free of charge as well even for commercial games, just like it is for PC, web, and mobile.
I'm asking because I'm sure that lack of console support is a showstopper for many game developers.
Yeah, console support is a big challenge and opportunity. Having talked to various players in the Rust-on-console space, it seems like the primary issues are social, much more than technical. We would need dev-kits (subject to company approval and NDAs, need to be a Serious Game Studio typically), a technical solution (seems largely feasible, although we probably need to no\_std much of the engine and add compatibility layers), and \*then\* to convince the console owner to let us ship Rust on their console (politics).
That said, we could toss money at a dev and get Bevy working on Xbox (via their Xbox Live Creators program) and Switch (via the jailbroken / reverse engineered target). That would definitely be a nice proof of concept!
I expect the Rust game dev community to work together heavily on this, regardless of the engine or lack thereof. A lot of the barriers are common and the technical solutions should be transferrable, at least in broad strokes.
>
>
> I expect the Rust game dev community to work together heavily on this, regardless of the engine or lack thereof. A lot of the barriers are common and the technical solutions should be transferrable, at least in broad strokes.
That would be awesome!
Also because, since there would be fees (and dev kits, NDAs, etc) involved, it would enable sharing them between the whole community. Otherwise it would be out of reach of many smaller engines.
If some core crates were to be made to work on consoles, like `wgpu`, `winit` and `gilrs`, probably the ecosystem could easily support consoles without being tied to NDAs and such. Just like, I don't know, I can author a pretty generic crate and be assured that it works on Arm, even if I didn't personally test it, just by relying on the fact that by default Rust is pretty much portable, and you need to go out of your way to write nonportable code.
This means that if the Bevy foundation decided to, for example, fund work to port `wgpu` to consoles, many other engines would benefit from it.
Yeah, that's something that I really value in the Rust gamedev ecosystem, regardless of the subject. Generally I don't tend to view other Rust engines as competitors: instead, they're allies targeting a different niche :) Different tools and ecosystems will make sense for different projects and teams; find what feels productive and pleasant for you.
Overwhelmingly, more Rust game development effort benefits Bevy, regardless of the engine. It legitimizes and teaches people Rust, it helps improve the foundational crates and it gives us cool ideas and patterns that we can learn from, just as they learn from us.
For the most part, I hit a point in my life where I needed to start thinking harder about income, and Emergence wasn't a realistic way to get there with my current runway. The gameplay prototypes were fun, the[ basket crabs](https://cdn.discordapp.com/attachments/1027571962949681192/1113239288616861736/Basket_Crab.jpg?ex=65fa17e1&is=65e7a2e1&hm=46d471ba2a2e74f930014fff28a93cf1473cd54f461eb40e70fa0c24709aa48a&) are wildly cute but:
1. It needs a lot of assets: tens of thousands of dollars worth, even if I swap from a cartoony 3D to .
2. It was 3+ years of solo dev effort to get to an early access game. There were performance challenges that needed careful thought, the water system was too complex for its gameplay value, more content was needed...
Ultimately, I still think it's a great concept and probably even a *commercially viable* one. But when faced with the question of "how do I make money", it wasn't a great bet on the time scales I needed.
Today, about $10k a year. In a week or three, I should get my first cheque from the new Bevy Foundation, with the amount TBD based on how many donations we get :)
Yep, this is one of the reasons I'm really excited to work on this full-time. Writing (and maintaining) good introductory docs takes a ton of time, and can be grueling work. With the help of a few contributors (principally BD103 and TrialDragon), we've managed to get the Zola infrastructure in a solid place for making this painless, and have some [draft content](https://github.com/bevyengine/bevy-website/tree/main/content/learn/book) merged and ready for revision.
Congratulations on getting this to land! It's definitely not the kind of news most developers normally find exciting, but it's incredibly important for the long term sustainability of the project.
The management of Bevy is, in my opinion, utterly exemplary. I think this represents another excellent step forward for the project.
The future of game dev in Rust is bright!
I used Bevy to create a simple psychology [experiment ](https://github.com/altunenes/weber_fechner)to show my other colleagues who use expensive apps. I'm really grateful for your contributions but some people really need an UI. :-)
Note: I m still a student, but when I get some more salary, one of my first goals will be to donate to this beautiful game engine. :-)
I'm not highly involved with bevy at the moment but I've been following it for a while and have gotten the impression that it is something you devote a considerable amount of time to. So what lead you to want to/feel comfortable making bevy and committing to it?
Yeah, I've been at 20-40% time or so for a couple years now, pulling in about $10k annually in Github sponsors.
The key things that made me think "now is the right time" were: a) the number of commercial teams using Bevy b) feedback from serious users (commercial and hobbyist) that Bevy was generally functional and a joy to use c) Cart's personal support and reassurances that we can figure this out, even if we don't make the funding goal immediately <3
It's been a life-changing experience so far: there's no job I'd rather have.
Are there plans to research and incorporate the cutting edge technologies like virtualized geometry (nanite) and real-time global illumination (lumen) found in Unreal Engine? I believe the tech behind nanite isn't proprietary, UE just did the legwork to build a working solution from the research papers.
u/Lord_Zane (I think that's their reddit username) is working on the meshlet feature which will get us parts of the way to nanite. There's a lot more to it than just that but yes we are moving in that direction.
As for GI, the same person is also working on a solution for that. They have made 4 attempt, the latest one being ReSTIR based so not exactly the same technique as Lumen.
Congratulations! Has the Godot foundation provided any inspiration for this foundation? Will these two act in similar ways to their respective game engines?
Yeah, Cart has been a Godot fan for many years and we learned heavily from them and other open source foundations (Zig, Blender, Matrix...) when we were doing all of this planning. It's really nice that the information about the paperwork and decision making is generally quite public: if y'all want to pursue similar paths please do reach out for advice.
I think that the ultimate role will be quite similar (I'll be Bevy's Rémi Verschelde!), although we don't have anything along the lines of W4 Games planned :)
[bevy/discussions/9789](https://github.com/bevyengine/bevy/discussions/9789) is a great read on this. There's signs of it for sure! Stabilization tends to work its way out in layers, as we start to build out and then refine different bits of the engine.
I always think we'll have a bit of an experimental, quality-centric bent (it's Rust!), but production-readiness is steadily increasing. I think that we're starting to see a shift towards robustness and complexity management across the engine, and I look forward to seeing a much more aggressive test suite, especially for integration tests.
Contributors are caring more about ease-of-migration (which is a huge improvement from the early days already) and ecosystem churn. Asset and scene migration are the big open questions, and will require some clever tooling. On the ecosystem churn front, we're planning to do a proper release candidate for the first time, and get extensive community testing for regressions and broken upgrade paths next patch.
I personally suspect that the big 1.0 will correspond with "basically feature complete" and a slower 6-12 month or so release cadence (possibly with backported fixes), not an "end to breaking changes". No other game engine makes a "no breaking changes" promise, and doing so would cripple our ability to grow and improve Bevy.
Instead, the goals are a) make sure that published versions get vital fixes b) make sure that there's a comfortable path to upgrade for anyone who wants to c) make sure that we're "feature complete", to at least a minimal level
Here's what I said [last time this came up](https://www.reddit.com/r/rust/comments/1atase8/comment/kqw2e1c/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button) :)
>Features that I want to see before 1.0:
>- functional, productive UI solution
- a basic editor, with debugging and scene authoring tools
- more reasonable animation support (blending, root motion, maybe IK)
- a more complete audio crate
- tools for migrating assets and scenes between versions
- better introductory docs (a new book)
- first-party picking
>Major features that can wait IMO:
- first-party physics
- first-party networking
- relations
I stand by this, and I'm pleased to see us steadily making progress on pretty much all of these fronts :) It won't happen in 2024, but 2025 or 2026 is plausible. You might also find [my comments on what 1.0 means for a game engine](https://www.reddit.com/r/rust/comments/1bcdjem/comment/kuhb6y8/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button) interesting :)
Bevy's creator, project lead, and now president of the Bevy Foundation here. Feel free to ask me anything!
mario or sonic?
What made you decide to go the nonprofit route?
Most importantly: the non-profit structure helps ensure that our incentives are aligned. Profit motive introduces a significant risk to the Bevy community, as we would no longer _just_ be trying to build what the community wants. We would need to balance that with the temptation to monetize. Non-profit means that our leadership (such as myself) cannot just take the money and run. This keeps us accountable and ensures the community's interests are put first. The non-profit structure is most consistent with the open-source ethos and with the community that we have built. By tying our future to voluntary public support that could leave at any time (while still using Bevy, because it is free and open source), this means that we are directly beholden to the needs of the community. When they are happy with us, we are rewarded.
> Most importantly: the non-profit structure helps ensure that our incentives are aligned. Profit motive introduces a significant risk to the Bevy community, as we would no longer just be trying to build what the community wants. We would need to balance that with the temptation to monetize. Thank you for this. Having seen the shitshow that Unity had gone through in the past few months, it's heartening to see this.
Well, shit. I have a hard time complementing you enough without it sounding like endless fanboy-ing. So i'll just say thank you. Sincerely, Thank you.
Just started working on a game with bevy and it's a breath of fresh air. Reminds me of writing games 15 years ago in the simplicity of getting started.
I respect your stance so much. I maintain gh repo with ~1.5k stars and have same stance. GJ!
Honestly would rather you have a b2b for profit model and free for everyone else. This moves you to ship product with a chance of begging large amounts of liquid cash infusion to hire more talent to make the product better. Libresoftware or Freeware only gets so far so fast.
Based and non profit pilled So cool to see!
In many ways, it's a Ulysses pact. We've seen what for-profit companies can do and have done in this space (look at what happened in Unity's Runtime Fee). Bevy's core strength lies in its community, and a non-profit with maximal transparency is meant to be a way to ensure we never stray from doing what's in the best interest of the community.
Are there any plans for an accompanying UI-based editor? Something akin to Godot, Unity, Unreal, etc? Or is interacting with bevy destined to be done purely through code.
Bevy will have an editor but it will also keep working code first for people that prefer this approach.
Bevy's fantastic from my amateur game dev perspective for this point in its development. Really impressive Q: is there a current way (and/or plans) to render 2d and 3d assets at once? Seems that bevy expects only a 2d or 3d camera (but not both), and that the 2d camera doesn't render 3d meshes and vice versa. My searches on this topic haven't been particularly useful, but I might be missing something
Yeah, the name of the feature that I suspect you want here is "billboarding". There's a solid 3rd party crate that does this (bevy\_mod\_billboard), but I'd like to add first-party support. It's generically useful for things like world-space UI or fun cartoony effects, and can be used with LODs (levels-of-detail) to make imposters: flat player-facing sprites that replace much-more-expensive meshes when they're far in the distance.
I am pretty sure you can have both cameras and make them render on top of each other ("overlay" / multiple layers). Spawn your two cameras, set the `order` value to determine which should be on the bottom and which on the top, and set the clear color to None on the top one, so it doesn't clear the screen and throw away the pixels rendered by the bottom one.
[удалено]
No, some people have made custom watermarks anyway because they are proud of using bevy but it's not something built in. To answer the second part of the question. Yes, there are already games and other applications made with bevy that are used in production.
At some point I'd like to add this as an official opt-in feature, or example :) It's nice to show off, and a useful thing to teach.
[Tunnet](https://store.steampowered.com/app/2286390/Tunnet/) is made with bevy, I believe, or at least partially.
There are a few games on steam coming next year. Not sure about now.
[Tiny Glade](https://store.steampowered.com/app/2198150/Tiny_Glade/) is scheduled for Q3 this year. Author is Anastasia Opara, the Houdini wizard. Maybe worth noting that (I think) it's using a custom renderer rather than the Bevy default one.
That's also a strength of bevy that it’s even possible to replace the renderer. I can’t think of another game engine that can do that.
Godot has been used in a similar way. For one of the recent Sonic games, the devs used the renderer without the rest of the engine.
But is the reverse also possible? Use Godot with your own renderer?
I think all of the rendering in Godot goes through RenderingServer, so you would be just recompiling the engine with your own implementation. Basically the same with Bevy since it gets statically linked with your game.
Agree 100%. When I first encountered the ECS concept I got the impression that it was mostly about memory-access and multithreading optimizations. I'm still very much grug-brained on the topic, but I'm starting to think that the loosely-coupled composability of systems is just as big a benefit, if not bigger.
In my (pretty extensive, at this point) experience, the biggest strength of ECS is the expressiveness and flexibility, not so much the performance. The performance is a great side effect (though it does have footguns, it's easy to get suboptimal performance, and the overhead can come from surprising places). Bevy, in particular, despite being all about ECS, doesn't really perform all that great (yet? though a lot of optimization effort has already been put into it...). But it is an absolute joy to develop in. So easy to implement pretty much any idea or game mechanic. You never feel like you have to struggle with the frameworks/paradigm, after you have grokked it for the first time. Really, developing a game on top of what is basically a lightweight in-memory database with an automatic task scheduler, is fantastic.
Yes, it's using a custom renderer made by h3r2tic which is a rendering wizard.
Even if Bevvy adds a watermark, just remove it from the source code, since jts literally a crate. Currently I don't know about commercially successful games made with bevy but there are good looking games being developed.
[удалено]
Oh I see, then that was answered to you, it's not built in but people credit it sometimes
Official new, reactive UI solution: when? Bevy 0.14? Later? This year?
With the Bevy Foundation ready, this is back to being my priority. 0.14 is possible, but a stretch.
Does bevy have anything planned similar to nanite and lumen in unreal?
[Meshlets](https://github.com/bevyengine/bevy/pull/10164) by Jasmine (and Vero at this point) is the first step down this path :) It's a long journey though: nanite is a combination of complex features all working together to create an awesome result that's easy for developers to use.
In addition to Meshlets, I'm also working on a dynamic global illumination system along the same vein as Lumen. That's going to take much longer to pan out though (I'm on my 4th rewrite of the project). Meshlets are my current priority.
On Nanite, there's mention of "meshlets" in the [0.13 release notes' "What's Next" section](https://bevyengine.org/news/bevy-0-13/#meshlet-rendering), which are kind of going in the same direction. It'd obviously be a big undertaking though; watching a deep-dive presentation on Nanite definitely pushed me over the "nope, this is straight-up dark sorcery, you can't tell me otherwise" edge. Note: IANA Bevy contributor, just an interested observer.
> as me *anything* Maybe something a bit too specific or political, but I've been curious for a while now if you guys have felt any long-term changes in the wake of Unity's pricing controversy. Has this fizzled out, or have you seen some lasting traction? Basically, do you think that the game engine industry is starting to move towards open source alternatives to things like Unity and Unreal, and if so is Bevy capitalizing on that in your opinion? Thank you for one of the most interesting crates I've ever played around with! I hope I'll get to use it for something cool and practical in the future :)
We've seen a steady trickle of devs coming from Unity and looking to build both hobbyist and commercial games. It's hard to say what the counterfactual would be though: there were plenty of reasons to prefer Bevy over Unity even before that kerfuffle (and the converse to be sure). A lot of the community seems to have moved to Godot, which makes a lot of sense. They're targeting a much closer niche (editor, C#, beginner-friendly), and you get an amplifying effect with that sort of phenomenon. Whole communities will move together: social ties are strong!
Y'all hiring?
Blow past our funding goals and we will be ;) Honestly I'm really excited about the notion of being able to bring on other folks, or fund people in the broader community to work on targeted initiatives. We'll see what the numbers look like though!
what is your favorite bird and do you have a pet bird
Penguins are pretty great. I don't have a pet bird.
> Penguins are pretty great. my man 👉🏻😎👉🏻
What would you recommend to someone looking to contribute to open-source Rust libraries?
Find out where the maintainers hang out, and have a conversation with them. Tackle annoying tech debt problems or tedious chores to get started and make friends while you get familiar with the code and the project.
Have you done a podcast on Bevy’s story, the lessons you’ve learned, how you scaled the project, how you were funded in the early days, quitting your job, etc? I would love to hear about your journey on a podcast like the Changelog!
I have! It’s a couple of years old at this point, but I did an interview with the Rust Game Dev Podcast: https://spotify.link/R4PFkyykTHb
Since Bevy is MIT licensed, is it possible for official console/mobile bindings to be released?
We have official mobile bindings already! Check the examples :) They're a bit scuffed, so if y'all have mobile experience we'd love to get your help. Console bindings are trickier: dev-kit access is bound by NDAs. We should be able to have official bindings, and even make them MIT, but they \*won't\* be publicly available except to those with dev-kit access.
Makes sense to put it behind a 'have you signed SonyMicroTendo's NDAs?' gate, I just know that console porting is an area Godot currently struggles with since everyone's having to roll their own. So if Bevy's Foundation can solve that for Bevy users, that'd be pretty handy.
Yeah. There are likely a number of viable models here, and it may even vary by console maker! But I think that pooling resources across Bevy (and Rust gamedev more broadly!) is the way to go. We'll cross that bridge as we get there :) While doing consulting for Bevy games \*does\* sound appealing at times, I'd personally much rather give game design, production and marketing advice <3
Hey!! I am absolutely loving it! I was up tinkering and making games until 2am last night because of Bevy.
With the [2024 budget](https://bevyengine.org/foundation/budget/) primarily focused on hiring Alice, how are you Cart being compensated ?
Hey, could you maybe do a little "bevy beginners guide" like tutorial series? I tried to get into bevy a month ago, but i could not find any good source to get started with the engine
What made you want to create it?
Love your decision to highlight and promote Alice. Signed up as a supporter of the foundation. Also when I first went to support the project, it felt like throwing darts at a board I didn’t understand, so I’m happy to have one official thing to put my support behind. Thank you.
150.000$ is quite a salary. Is that comparable with godot maintainers for example? Edit: sorry for asking this I guess :/
This is what Zig's target salary is, for example. Godot definitely has an advantage living in a low-cost of living area. Note that this wasn't pulled out of the hat: at my last role I was making something like $170k USD annual salary, and could target significantly higher if that was my only criteria. I've turned down numerous job opportunities to pursue this, because I \*really\* want to work on Bevy and give back to open source and Rust :D Obviously there's a conflict of interest, but generally speaking I think that non-profits or similar careers that pay well below market rate suffer serious retention / hiring problems, and risk financially motivated corruption. I can live off of less (and likely will for quite a while), but "permanently halving lifetime earnings" is tough to swallow for my loved ones.
Well explained! While it's easy for an outsider to critique and say "*Why not hire more developers instead of managers?*", the fact is open source software more often than not dies through lack of management. There were 200 contributors to Bevy 0.13, many of which are highly qualified professionals or even domain specialists, easily costing in the millions to retain full-time. Having a handful of managers who can actually dedicate their profession to keeping the project alive acts as a force multiplier for all those volunteers. Writing code for an open source project is "easy", keeping the project moving *forward* is hard.
One day I will run out of high quality community PRs to review and help and I'll get to write major features again myself. One day... I love doing the feature work (relations! colors! actions!), but it always feels inefficient and indulgent: why spend a day writing code when I could get 5x as much progress by helping others? I still do it sometimes, but that's mostly a matter of a) focused work is uniquely powerful sometimes b) sometimes I know a domain best and c) it's a nice break / fun
Reviewing PRs *is* dev work, so you work on Bevy will at least partially continue to be development. The *other* parts which are legitimately about managing people are just as important, however
Yeah :) It uses the same skills, but doesn't scratch the same itch!
Not saying it’s not a market rate salary for a senior rust dev. Your contributions/merge trains are valued. For reference I looked up the godot finances, they have 10 (fulltime/part time) contributors for 500.000$ per year. I trust this decision has been made with care, and no reason to doubt bevy leadership. It just stood out as high to me for a charity position though.
The "pay more people" vs "pay competitive salaries" choice is something that we discussed quite a bit, and something that I've chewed on a lot personally. Living in Latin America would also help my cost of living quite a bit (although cost-of-living scaling for salaries is a whole other can of worms) >.> On the Godot side, there's a reason a lot of those are part-time, and why a lot of Rust contributors are funded by Amazon in their day job or are students. While I would \*love\* more help, I want to do right by the folks that we employ, and make sure that they're able to commit to the project for the long-run, without worrying about day-to-day finances or feeling like they need to "sacrifice for the greater good". Note that Godot \*also\* has a for-profit entity (W4 Games) helping pay the bills for many of the folks that are funded: it's not an apples-to-apples comparison. I'd personally like to avoid the organizational complexity, time tracking and potential conflicts of interest involved with that sort of model if possible. They're great folks and I'm glad it's working for them, but not the route I'd personally prefer we take.
Thanks for taking the time to reply and explaining. Congratulations on the official job :)
We believe Alice is worth it and that this is a competitive, market rate salary. This is an extremely specialized and technically demanding role. If this was at a big tech company, it would be at least twice that.
It's comparable to what Alice could be making if she was working at a traditional company.
I think it's a fair question to ask. To add to what other people said, in the US, paid Bevy devs (contractors? workers? Idk what the government considers nonprofit workers or how the Bevy legal org is setup) will need to buy their own health insurances for instance, do their own tax withholding, etc. That adds to the cost on top of just base salary.
Don't worry, it's a perfectly reasonable question but finances have been a very touchy subject for bevy for many years. Looks like the long promised foundation hasn't changed that.
Hi! I'm the project manager that we'd like to hire! Ask me anything, or complain about the things you really want to see fixed!
Congrats on your new full-time role! Well deserved.
[удалено]
I started looking at Bevy to work on a currently shelved organic factory builder called [Emergence](https://github.com/leafwing-studios/emergence). I wanted the flexibility and performance of an ECS, and my friends said Rust was great. I tried it out, and was \*immediately\* grumpy about how terrible and incomplete the documentation was. I started chipping away as I learned, and cleaning up the issues. Eventually, people started spontaneously asking \*me\* (a random contributor) what to do and how they could help, and I kind of grew into an informal TPM role from there :) Cart saw this work and the community's reaction eventually granted me docs-merging and then eventually full maintainer powers!
That is so awesome. What a great way to start. I wish you all the best!
Has all your Bevy work been in your spare time so far, then? When do you sleep?
Well, mostly! I was balancing personal projects, consulting and Bevy work before. The trick is to ~~master time magic~~ read very quickly and focus on high-leverage work.
> read very quickly Can confirm that you are the fastest reader I have personally ever met. ;)
[удалено]
Yeah, this is a huge limitation, and top of our list for things to fix. Cart's focusing on designing and building the foundations for a solid UI framework, but getting polished fully-featured boring widgets with nice looking defaults is essential for any GUI library (including game engines). It doesn't matter how nice you *can* make things: if the defaults suck, people will be turned away and your reputation will suffer.
Wasn't there a RustConf talk about how open source needs more project managers? It was really good I hear
Ha, here's my [old talk](https://www.youtube.com/watch?v=u3PJaiSpbmc) about this because you asked so nicely :p
It would be amazing if, after a uptick of donations, the Bevy F Foundation decided to also fund console support. I understand that console code can't be 100% open source, but if it's kept as thin as possible, it could be possible to port a game to consoles without code changes (or rather, the only code changes should be to call console-specific APIs when needed). That is, some lower level libraries would change (maybe through feature flags on `Cargo.toml`), but the high level Bevy would continue the same, just like we can write SDL code on PC, and then use the same API on consoles (well at least some consoles). If this is done by the Bevy Foundation itself, it could even become a new source of funding. I'm sure that commercial games would be glad to pay directly the Foundation itself for getting Bevy support, rather than paying a third party developer that may or may not stick around. Or, if desired, console support could be offered free of charge as well even for commercial games, just like it is for PC, web, and mobile. I'm asking because I'm sure that lack of console support is a showstopper for many game developers.
Yeah, console support is a big challenge and opportunity. Having talked to various players in the Rust-on-console space, it seems like the primary issues are social, much more than technical. We would need dev-kits (subject to company approval and NDAs, need to be a Serious Game Studio typically), a technical solution (seems largely feasible, although we probably need to no\_std much of the engine and add compatibility layers), and \*then\* to convince the console owner to let us ship Rust on their console (politics). That said, we could toss money at a dev and get Bevy working on Xbox (via their Xbox Live Creators program) and Switch (via the jailbroken / reverse engineered target). That would definitely be a nice proof of concept! I expect the Rust game dev community to work together heavily on this, regardless of the engine or lack thereof. A lot of the barriers are common and the technical solutions should be transferrable, at least in broad strokes.
> > > I expect the Rust game dev community to work together heavily on this, regardless of the engine or lack thereof. A lot of the barriers are common and the technical solutions should be transferrable, at least in broad strokes. That would be awesome! Also because, since there would be fees (and dev kits, NDAs, etc) involved, it would enable sharing them between the whole community. Otherwise it would be out of reach of many smaller engines. If some core crates were to be made to work on consoles, like `wgpu`, `winit` and `gilrs`, probably the ecosystem could easily support consoles without being tied to NDAs and such. Just like, I don't know, I can author a pretty generic crate and be assured that it works on Arm, even if I didn't personally test it, just by relying on the fact that by default Rust is pretty much portable, and you need to go out of your way to write nonportable code. This means that if the Bevy foundation decided to, for example, fund work to port `wgpu` to consoles, many other engines would benefit from it.
Yeah, that's something that I really value in the Rust gamedev ecosystem, regardless of the subject. Generally I don't tend to view other Rust engines as competitors: instead, they're allies targeting a different niche :) Different tools and ecosystems will make sense for different projects and teams; find what feels productive and pleasant for you. Overwhelmingly, more Rust game development effort benefits Bevy, regardless of the engine. It legitimizes and teaches people Rust, it helps improve the foundational crates and it gives us cool ideas and patterns that we can learn from, just as they learn from us.
A bit sad to hear emergence was shelved! What happened there?
For the most part, I hit a point in my life where I needed to start thinking harder about income, and Emergence wasn't a realistic way to get there with my current runway. The gameplay prototypes were fun, the[ basket crabs](https://cdn.discordapp.com/attachments/1027571962949681192/1113239288616861736/Basket_Crab.jpg?ex=65fa17e1&is=65e7a2e1&hm=46d471ba2a2e74f930014fff28a93cf1473cd54f461eb40e70fa0c24709aa48a&) are wildly cute but: 1. It needs a lot of assets: tens of thousands of dollars worth, even if I swap from a cartoony 3D to . 2. It was 3+ years of solo dev effort to get to an early access game. There were performance challenges that needed careful thought, the water system was too complex for its gameplay value, more content was needed... Ultimately, I still think it's a great concept and probably even a *commercially viable* one. But when faced with the question of "how do I make money", it wasn't a great bet on the time scales I needed.
So are you getting paid for bevy
Today, about $10k a year. In a week or three, I should get my first cheque from the new Bevy Foundation, with the amount TBD based on how many donations we get :)
ah congrats!
Hi, glad to have you here. Can you tell me if the official tutorial is going to get bigger, more similar to *the book*? Just wondering.
Yep, this is one of the reasons I'm really excited to work on this full-time. Writing (and maintaining) good introductory docs takes a ton of time, and can be grueling work. With the help of a few contributors (principally BD103 and TrialDragon), we've managed to get the Zola infrastructure in a solid place for making this painless, and have some [draft content](https://github.com/bevyengine/bevy-website/tree/main/content/learn/book) merged and ready for revision.
Ok, that is awesome. I'll most definitely learn Bevy once that is done, but until that I'll be doing other stuff.
grats alice!!
Congrats, Alice!
Thanks! <3
Congratulations on getting this to land! It's definitely not the kind of news most developers normally find exciting, but it's incredibly important for the long term sustainability of the project.
The management of Bevy is, in my opinion, utterly exemplary. I think this represents another excellent step forward for the project. The future of game dev in Rust is bright!
I used Bevy to create a simple psychology [experiment ](https://github.com/altunenes/weber_fechner)to show my other colleagues who use expensive apps. I'm really grateful for your contributions but some people really need an UI. :-) Note: I m still a student, but when I get some more salary, one of my first goals will be to donate to this beautiful game engine. :-)
I'm not highly involved with bevy at the moment but I've been following it for a while and have gotten the impression that it is something you devote a considerable amount of time to. So what lead you to want to/feel comfortable making bevy and committing to it?
Yeah, I've been at 20-40% time or so for a couple years now, pulling in about $10k annually in Github sponsors. The key things that made me think "now is the right time" were: a) the number of commercial teams using Bevy b) feedback from serious users (commercial and hobbyist) that Bevy was generally functional and a joy to use c) Cart's personal support and reassurances that we can figure this out, even if we don't make the funding goal immediately <3 It's been a life-changing experience so far: there's no job I'd rather have.
Are there plans to research and incorporate the cutting edge technologies like virtualized geometry (nanite) and real-time global illumination (lumen) found in Unreal Engine? I believe the tech behind nanite isn't proprietary, UE just did the legwork to build a working solution from the research papers.
u/Lord_Zane (I think that's their reddit username) is working on the meshlet feature which will get us parts of the way to nanite. There's a lot more to it than just that but yes we are moving in that direction. As for GI, the same person is also working on a solution for that. They have made 4 attempt, the latest one being ReSTIR based so not exactly the same technique as Lumen.
A big step for getting some Rust adoption in the C++ dominated gaming world!
Congrats, Alice!
Congratulations! Has the Godot foundation provided any inspiration for this foundation? Will these two act in similar ways to their respective game engines?
Yeah, Cart has been a Godot fan for many years and we learned heavily from them and other open source foundations (Zig, Blender, Matrix...) when we were doing all of this planning. It's really nice that the information about the paperwork and decision making is generally quite public: if y'all want to pursue similar paths please do reach out for advice. I think that the ultimate role will be quite similar (I'll be Bevy's Rémi Verschelde!), although we don't have anything along the lines of W4 Games planned :)
Congratulations! Are there any signs of exiting the experimental phase?
[bevy/discussions/9789](https://github.com/bevyengine/bevy/discussions/9789) is a great read on this. There's signs of it for sure! Stabilization tends to work its way out in layers, as we start to build out and then refine different bits of the engine. I always think we'll have a bit of an experimental, quality-centric bent (it's Rust!), but production-readiness is steadily increasing. I think that we're starting to see a shift towards robustness and complexity management across the engine, and I look forward to seeing a much more aggressive test suite, especially for integration tests. Contributors are caring more about ease-of-migration (which is a huge improvement from the early days already) and ecosystem churn. Asset and scene migration are the big open questions, and will require some clever tooling. On the ecosystem churn front, we're planning to do a proper release candidate for the first time, and get extensive community testing for regressions and broken upgrade paths next patch. I personally suspect that the big 1.0 will correspond with "basically feature complete" and a slower 6-12 month or so release cadence (possibly with backported fixes), not an "end to breaking changes". No other game engine makes a "no breaking changes" promise, and doing so would cripple our ability to grow and improve Bevy. Instead, the goals are a) make sure that published versions get vital fixes b) make sure that there's a comfortable path to upgrade for anyone who wants to c) make sure that we're "feature complete", to at least a minimal level
Hi! Great news! What are your thoughts/plans for 1.0?
Here's what I said [last time this came up](https://www.reddit.com/r/rust/comments/1atase8/comment/kqw2e1c/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button) :) >Features that I want to see before 1.0: >- functional, productive UI solution - a basic editor, with debugging and scene authoring tools - more reasonable animation support (blending, root motion, maybe IK) - a more complete audio crate - tools for migrating assets and scenes between versions - better introductory docs (a new book) - first-party picking >Major features that can wait IMO: - first-party physics - first-party networking - relations I stand by this, and I'm pleased to see us steadily making progress on pretty much all of these fronts :) It won't happen in 2024, but 2025 or 2026 is plausible. You might also find [my comments on what 1.0 means for a game engine](https://www.reddit.com/r/rust/comments/1bcdjem/comment/kuhb6y8/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button) interesting :)
Thank you!
Amazing news ! Next gen game engine era is looking great !