4 ms·
Man, this Specs [0] library is so strange to me, coming from a Unity background. Is there some sort of comparison as to why one way is better than the other? [
by CGamesPlay 4y ago
Man, this Specs [0] library is so strange to me, coming from a Unity background. Is there some sort of comparison as to why one way is better than the other?
[0] https://docs.rs/specs https://docs.rs/specs
- nextaccountic 4y agoMaybe you would like Bevy's ECS more? https://bevyengine.org/learn/book/getting-started/ecs/ https://bevyengine.org/learn/book/getting-started/ecs/ (it's a later design that incorporated some improvements, like, you don't need to define a struct and impl a trait to define a system)
- dymk 4y agoBevy's ECS is incredibly ergonomic and makes writing ECS code fun. You give Bevy a function and it automagically turns it into a system by doing dependency injection. No need to write an impl for it, the system takes care of that for you. It makes prototyping very fun, as it's cheap to experiment with different system configurations.
- jakkos 4y agoIf you mean a comparison between SPECS' paradigm, ECS, and Unity's mix of OOP/composition, the main benefit of ECS is performance. The way ECS loops over arrays of data means that the memory accesses it makes are nearly always already in cache. Games spend a surprisingly large amount of time just waiting to receive values from memory. In the right circumstances, normally when dealing with huge numbers of objects (think simulation games), ECS can be entire orders of magnitude faster. Other than that some people just prefer coding in ECS. Unity has been developing its own separate ECS framework for a while now.
- pornel 4y agoIt is a very different and seemingly weird approach. It's almost like writing SQL queries for your game world (e.g. "find all entities with a Flying component and attach them a WooshSound component). A clever memory layout makes these queries super fast. It makes separation of concerns very natural. Different parts/layers of the game, like inputs, AI, sounds, graphics, effects and animations can be coded separately. You don't end up with "god class" for player's object that does a bit of everything. You have player entity that has components attached, and each system operates on its own set of components. I can't really do it justice in a comment. It's a quite different approach, so it's not directly comparable. It's like OOP vs Rust's traits. ECS happens to match Rust's memory model and traits incredibly well. Here's a more in-depth talk about this: https://www.youtube.com/watch?v=aKLntZcp27M https://www.youtube.com/watch?v=aKLntZcp27M
- wdroz 4y agoEven the Data-oriented design[0] is eyes opening (which is part of the ECS). The classic example is[1]: Instead of having a list of structs, where each struct get some types (int, float, ...), you use one struct, where the fields are list of types (array of int, array of floats, ...) [0] -- https://en.wikipedia.org/wiki/Data-oriented_design https://en.wikipedia.org/wiki/Data-oriented_design [1] -- https://en.wikipedia.org/wiki/AoS_and_SoA https://en.wikipedia.org/wiki/AoS_and_SoA
- kramerger 4y agoUnity uses ECS, just in a more visual way.
- wdroz 4y agoI did some Unity3d back in 2013, I don't remember using ECS (intentionally?). After a quick search, it's seem that the MonoBehaviour are the old way and ECS the new ways? That's nice.
- kramerger 4y agoWhen you drag and drop something into an object, you are actually adding a component to an entity. It's kinda behind the scene ECS.
- bodge5000 4y agoECS is an absolute pain to work with and makes everything so much slower...until it clicks. In the past I've compared it to learning programming all over again. The SQL reply summed it up quite nicely, basically you perform queries for anything with a class attached and then perform your operations on all of those. It sounds really inefficient, but in terms of raw performance the results usually speak for themselves. A good example I encountered with Bevy, another Rust ECS framework, is imagine you want your camera to follow your player. Rather than having a script on your camera and a different one on your player, you could just attach a generic class to both, query through anything with that class and update the position of it based on the input.