4 ms·

Creator and lead developer of Bevy here. Feel free to ask me anything!

• jamespoole 3y ago
  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?
  • _cart 3y ago
    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).
    • jamespoole 3y ago
      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!