Bevy's Third Birthday
bevyengine.org
bevyengine.org
Always enjoy the Bevy progress writeups. Thanks for all the effort!
Making money in open source isn't easy (or stable), especially when I'm not particularly interested in the "commercial open source" route. So it would be nice to have revenue streams from games as well (not that games are a particularly good way to make money!). I think there is a lot of value in building high quality Bevy games and making the source code available to people willing to support me financially.
I’ve just been seeing talk online recently about how we (gamedevs) shouldn’t be automatically going to ECS as an architecture for making our games. That there could be simpler ways or that ECS can be a inefficient approach for some problems.
Just wondered what your thoughts are on this since Bevy has ECS at its core. Are you still happy to have ECS as the core of a general purpose engine?
First some clarity: ECS isn't just one thing. It is a broad category. For example, Bevy ECS has a variety of ways to store data (tables, sparse sets, custom storage in "resources"). We try to use "the best tool for the job" based on the problem we are trying to solve. For some engine features we represent data as Components / Entities (stored in either a table or a sparse set). For other engine features we use hash maps, dense vectors, generational arenas, atomic reference counted pointers, etc. We store these types as "ECS Resources". Bevy ECS is as much about providing easy access to non-ECS things as it is about providing access to components stored in a particular storage backend. Imo the "resource model" is way better than just defining global variables like many other engines do.
_Every major engine_ has some kind of "data layer" that makes describing data and composing behaviors easy, principled, and consistent within the engine. This data layer will tie into things like visual editors, scenes, save files, debuggers, etc. For Bevy, we call this data layer Bevy ECS. Again: it is multifaceted and flexible.
I'm familiar with the recent discussions on Twitter (ex: Seb brought it up in the context of renderer dataflow and other prominent people chimed in). We've actually independently (as in over the past 6 months or so) decided that using ECS table/sparse set storage _for renderer dataflow specifically_ is suboptimal for us. The "archetypal ECS" approach to tracking the components an entity has and building unified storage for fast iteration is not worth the overhead of constructing the storage. The way renderer data is constructed and accessed does not align well with that. The 2D side of Bevy Render already doesn't use Entities/Components to draw sprites (and instead opts to store this data in dense Vecs). We've been discussing the best way to adapt the other parts of the renderer to transition to a similar model.
We will continue learn + adapt. We use ECS storage (as in Entities with Components stored in a particular storage backend) in places where we think it is the best fit and not in places where it is not. I believe the result in Bevy (user experience, performance, API) is excellent (and others seem to agree).