5 ms·

Disclaimer: never actually shipped a game. I've worked with Bevy, and there's it's incredibly easy to write "quick and dirty" to test stuff. I guess the major

Disclaimer: never actually shipped a game. I've worked with Bevy, and there's it's incredibly easy to write "quick and dirty" to test stuff. I guess the major "downside" you need to account for is that the type system will try to prote you from crashes. Which can be a bit of a chore since youknow it won't crash with the values you've given it. But if you're comfortable with .unwrap and the occasional unsafe while prototyping, it's honestly fine (at least within Bevy). Alternatively, they could try "scripting" behaviour first before implementing it in Rust, although from what I understand bevy's scripting support (I don't think it's explicitly supported, but bevy is very extensible) is still very early in development

pornel 2y ago
ECS is like a whole another language on top of Rust, and it is dynamically typed. If you add a scripting language and blueprints, you're shortening the feedback cycles by using Rust less. I like Bevy, but it seems like Rust currently is much better suited for making game engines than the games themselves. Some "RustScript" is needed.
- kaoD 2y ago
  > ECS is like a whole another language on top of Rust, and it is dynamically typed. Can you elaborate? Or did you mean dynamically dispatched?
  - pornel 2y ago
    1. You dynamically add components to any entity, so entities don't have a static type. Semantically they're comparable to a JavaScript Object where you can add and remove properties at will, rather than being structs or class instances with a closed set of fields. 2. Bevy's entity references are generational IDs, without static lifetime guarantees (and restrictions) of Rust's references.
    - CaptainOfCoit 2y ago
      > so entities don't have a static type. They do, they're `Entity`, always. > where you can add and remove properties at will I don't think this is true for either `Component` or `Entity` in Bevy. You set what fields a `Component` has when writing the code, then it remains so during the runtime. There is no dynamically adding/removing fields at runtime, at least yet. What you do tend to do in Bevy is adding/removing `Component`s to `Entity`s at runtime, is that maybe where the confusion comes in?
      - spoiler 2y ago
        I think they used it more as an analogy: components fill a similar role as properties do in JavaScript.
        CaptainOfCoit 2y ago
        But that's not really true either, is it? You don't query properties in JavaScript, at best you query for Objects of a certain shape/name. You don't encapsulate data in properties so one object has many different behavior based on those, you either split the Object into many different ones and have one parent, or you mix the behavior into the same Object.
        spoiler 2y ago
        Yeah I it's not right. Although, it's a decent early mental model for a JS dev learning ECS to adopt until better intuition develops!
      - consteval 2y ago
        > They do, they're `Entity`, always Yes, technically, but in how they're used - no. They're a dynamic type. > What you do tend to do in Bevy is adding/removing `Component`s to `Entity`s at runtime Yes, this is dynamic typing. Or, at least, one way to look at it - and what allows games to be iterated on quick.
- binary132 2y ago
  Something wrong with Lua? ;)

pornel 2y ago

ECS is like a whole another language on top of Rust, and it is dynamically typed. If you add a scripting language and blueprints, you're shortening the feedback cycles by using Rust less. I like Bevy, but it seems like Rust currently is much better suited for making game engines than the games themselves. Some "RustScript" is needed.

kaoD 2y ago
> ECS is like a whole another language on top of Rust, and it is dynamically typed. Can you elaborate? Or did you mean dynamically dispatched?
- pornel 2y ago
  1. You dynamically add components to any entity, so entities don't have a static type. Semantically they're comparable to a JavaScript Object where you can add and remove properties at will, rather than being structs or class instances with a closed set of fields. 2. Bevy's entity references are generational IDs, without static lifetime guarantees (and restrictions) of Rust's references.
  - CaptainOfCoit 2y ago
    > so entities don't have a static type. They do, they're `Entity`, always. > where you can add and remove properties at will I don't think this is true for either `Component` or `Entity` in Bevy. You set what fields a `Component` has when writing the code, then it remains so during the runtime. There is no dynamically adding/removing fields at runtime, at least yet. What you do tend to do in Bevy is adding/removing `Component`s to `Entity`s at runtime, is that maybe where the confusion comes in?
    - spoiler 2y ago
      I think they used it more as an analogy: components fill a similar role as properties do in JavaScript.
      - CaptainOfCoit 2y ago
        But that's not really true either, is it? You don't query properties in JavaScript, at best you query for Objects of a certain shape/name. You don't encapsulate data in properties so one object has many different behavior based on those, you either split the Object into many different ones and have one parent, or you mix the behavior into the same Object.
        spoiler 2y ago
        Yeah I it's not right. Although, it's a decent early mental model for a JS dev learning ECS to adopt until better intuition develops!
    - consteval 2y ago
      > They do, they're `Entity`, always Yes, technically, but in how they're used - no. They're a dynamic type. > What you do tend to do in Bevy is adding/removing `Component`s to `Entity`s at runtime Yes, this is dynamic typing. Or, at least, one way to look at it - and what allows games to be iterated on quick.
binary132 2y ago
Something wrong with Lua? ;)