#Orientation on Learning Bevy

64 messages · Page 1 of 1 (latest)

remote oyster
#

Hello everyone, I'm getting into bevy recently, planning on seriously adopting it as my main engine of choice, and also plan on maybe contributing for it in the future. But in the process of learning it's I'm getting kinda lost, I'm one of those people who needs to understand deeply how something works in order to properly use it, so I spent this week searching for ECS/Data-Oriented resources, and also some Bevy ones, but I came to the conclusion that I'll grasp it better if I just read the code and API docs. Right now I fell like I'm running in circles, currently reading the bevy_ecs code, so I would appreciate if someone pointed me to a direction, where could I find good resources on ECS design, and also what's a beginning path for grasping the bevy implementation of it. Sorry for my poor English, and thanks to everyone replying this or not, you're awesome!!

ashen bay
old zinc
#

Reading the bevy_ecs code is likely a misplay 🙂

#

It's very complex, and not very relevant to actually using the engine

#

The core idioms are very simple: components, resources, commands, events

#

Something like bevy_input or bevy_input_focus is better for figuring out what the "normal" parts are 🙂

remote oyster
#

I appreciate both your responses, but I think I did not express myself well. I'm thinking about contributing to the engine and using it, I think, from my experience, that I would be useful on the ECS and maybe networking code, therefore I'm taking a look at the engine's code. I've been searching for resources on the topic of ECS patterns, DSs and algorithms, and read all I could find (mainly THE book of DOD, the ECS Back and Forth series, bevy unofficial book, and the Sander Mertens series on medium, bit I think it's yet not enough, I'm at this moment trying to follow the PRs and Discussions of bevy while reading the code, trying to find other ECS approaches that where discarded and how the engine develops. I think that's the best path for me. But once again, thanks a lot for the replies

old zinc
#

Aha, that's a very different goal than I had in mind 😅

#

Speaking for myself (SME-ECS and maintainer), I'm very user-oriented in my approach to developing the ECS

#

Users have problems, we try and solve them, adding the least complexity possible 🙂

#

A lot of my work comes down to explaining and unifying and simplifying concepts

#

@warped adder and @crystal flume are more theoretically oriented, and love stealing things from e.g. Prolog and relational DBs though

#

So they may have suggestions for reading

#

I'm always happy to talk theory / discussion history though: just ping me!

warped adder
old zinc
warped adder
#

I think you'd feel differently after seeing some of the questions on the flecs discord 😉 the advanced query features are used by lots of users

#

Also, hytale has released a blog post where they talk about how those features made it easier for them to build combat systems, amongst others

old zinc
#

Really nice 😄

#

I do think the advanced query features are useful

#

It's just a matter of learning curves

#

And trying to discourage the enthusiastic juniors from galaxy braining themselves

warped adder
#

Hm, that's overplaying how complex they really are

#

Like, all of the prolog-like features are summarized in this query:

// find all spaceships that are docked to a planet
SpaceShip, (DockedTo, $object), Planet($object)
warped adder
old zinc
#

The point was more that my approach to designing and iterating on the ECS is to focus on user pain, not the sort of written resources that OP is looking for

#

This is still very new and exploratory: there's no "just do X"

#

flecs (and to a lesser extent Bevy) is really on the bleeding edge of this paradigm

warped adder
#

If anything that's the #1 thing I'm focused on

old zinc
#

nod

warped adder
#

Just a bit weary of people putting a spin on things where IMO it's really not warranted

old zinc
#

Yeah, valid

#

I've... been frustrated of late at folks coming into the ECS space with beautiful theoretical designs or "just copy flecs"

#

With no consideration of how it fits together or how users will benefit or if it's actually the best design

#

You have very much not been part of that problem

warped adder
# old zinc I've... been frustrated of late at folks coming into the ECS space with beautifu...

That's fair. From my POV it sometimes feels like things are being copied/adapted without attribution, like, the things bevy has copied:

  • archetype graph
  • observers
  • hooks
  • component index
  • deferred world

the things that bevy is looking to copy/adapt:

  • ecs reactivity
  • command batching
  • relationships
  • components as entities
  • systems as entities
  • archetype level change detection

Not saying that each time these things are being discussed flecs has to be mentioned (that'd be silly), but recently I've seen people pushing back on mentioning flecs, even though the thing that is being discussed is very clearly based on a flecs design

#

I don't think there's a need for that. Flecs is really not a competitor for bevy 😅 and vice versa. The rust barrier is a large one to cross

old zinc
old zinc
#

I think that for future work command batching, reactivity, and archetype level change detection are some combination of obvious and independently re-invented 🤔 I actually had no idea you had the last one

#

And the reactivity and relations stuff seems liable to diverge a fair bit

warped adder
#

I think it's more obvious in hindsight. Nobody was talking about command batching until I implemented it. People were initially very skeptical about how much of a benefit it would actually provide

#

The same is true to a much larger degree for relationships. It took years for the bevy community to come around to the idea that relationships could be a feature that's natively supported by the ECS

old zinc
#

Interesting 🤔 The .insert(Foo).insert(Bar) batching at least seems really valuable

old zinc
#

A lot of the early wisdom kind of centered around the "ECS is for tabular data" perspective

warped adder
#

Wasn't until after I showed that you can actually build large scenes with fragmenting relationships that people started coming around

old zinc
#

relations are a massive game changer

old zinc
warped adder
#

For reactivity, that's obviously not something that I invented. But you're looking to build it on top of observers/hooks (just like flecs), and those do come from flecs

#

dreamertalin's initial approach was much more inspired by JS frameworks

#

wasn't until a bunch discussions that things switched to a more native ECS approach

#

Neither here nor there I guess, just venting. Wish things were a bit more like they used to be

old zinc
remote oyster
#

Wow guys this was wild haha. I find this so strange, ECS and DOD aren't the most obscure things that only 2 human beings know about, therefore why so scarse resources on these topics haha. But your discussion and my readings gave me some directions, Relational Databases and reading docs / code from a lot of ECSs (mainly bevy, flecs, entt). Maybe some other day I would make my obsidian notes public on GitHub pages, idk.

remote oyster
warped adder
old zinc
remote oyster
remote oyster
warped adder