@cart, what’s your primary motivation for developing a game engine? Do you eventually want to transition into building games and spend less time on the engine? Or is the engine itself the end goal?
Always enjoy the Bevy progress writeups. Thanks for all the effort!
I certainly _love_ building game engine technology, but my ultimate goal is definitely to build games. I've actually already started working on a more serious game in Bevy during my free time. It isn't yet a high priority for me, but I plan to ramp up my investment in it as the engine matures (especially after editor tooling starts to materialize). I believe it is important to "dogfood" the engine / be my own user. I already participate in the official Bevy game jams, but that isn't the same as a long term project.
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.
Hey Cart! Congrats on this! I’ve been using Bevy over the last few months and it’s been a lot of fun and having been getting results I’m super proud of. Thank you!
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?
I am _very_ happy with using ECS for the core of the engine. But this is a _very_ nuanced topic. We do not meaningfully "use ECS everywhere", which is a common characterization ("square peg round hole"). I have long been an advocate of "not ECS-ing everything" (even though we do ECS a lot of things in Bevy). I'm often providing backpressure to "lets ECS this thing" in Bevy.
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).
Appreciate the thoughtful response and thanks for breaking down some of the nuances. It’s nice to have a little context on the different tools in bevy like Resources, as you mentioned. As a non expert on what happens under the hood in game engines, I get easily knocked off my horse by these Twitter debates!
6 comments
[ 3.3 ms ] story [ 25.3 ms ] threadAlways 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).