I keep reading Rust is not that well suited for building game engines specially non-ECS ones. compared to C++ what did you find extra hard to implement in a performant way?
More traditional game engines tend to be a giant tangle of pointers with much more complex lifetimes than what Rust's borrows would allow. For example, the skeleton used to animate your character is reliant on a centralized hierarchy of transforms, which is deeply interwoven with physics, rendering, gameplay scripting, etc. These relationships and lifetimes is difficult or impossible to model with Rust's borrows, forcing the use of unsafe, and makes it harder to expose safe Rust interfaces to engine users due to Rust's aliasing rules around borrows and essentially forces the use of a scripting runtime. These factors also make it very hard to make performant multithreaded code without littering locks or channels everywhere, in any language or runtime, not just with Rust.
Bevy's ECS handles this by flattening these relationships. Instead of pointer chasing through the physics system to fetch rigidbodies which then point to the transforms, you expose the backing ECS memory as a query view: `Query<(&mut Transform, &Rigidbody)>` directly fetches all entities that have the two components without relying on one to hold a reference to the other. The lifetimes of the queried components is strictly bound to the surrounding function (a system in ECS terminology) by the borrow checker, and all of the unsafe used to create those borrows is neatly packaged behind the ECS crate boundary. This is so effective that the majority of Bevy's crates can have `forbid(unsafe_code)` enabled.
The downside here is that all of the complexity is now centralized into the bevy_ecs crate: there are many parts in it that are basically C written in Rust, but that does mean that we can focus all of our memory safety efforts on that one crate instead of making that collective responsibility of everyone in the ecosystem.
Of course, we do expose unsafe APIs from the ECS, but the use of this escape hatch explicitly demarcated, and generally you'll only see incremental performance improvements (no big-O algorithmic gains) over their safe variants. With the sole exception of `Query::get_unchecked_mut` allowing parallel access to mutable components that cannot be proven to be safe from static analysis (e.g. parallel hierarchy traversals), which enables parallelism where it otherwise would not be feasible.
> We should pick a platform that is federated, where you have ownership and autonomy over your identity and your audience. Social media should not be own-able by a single group or person. Social media is serious business. It ties directly to human rights and business outcomes. It shouldn't be in anyone else's control but yours.
I agree, but why not also apply the same logic to the other two communication platforms you are using (Discord and GitHub)?
Interesting discussion, and good points highlighted about Bluesky's did model that means you essentially don't own your identity either (in typical scenarios and when it will likely matter most). That takes a big chunk out of the "host your own data" narrative.
One point I disagree on that's also mentioned in the replies: I don't think a global state should be seen as necessary or even desirable. Sure, it helps people who optimize for clicks/likes/attention as a business model But that shouldn't be the only concern. Having some degree of uncertainty around the global state can help reinforce a healthy skepticism towards what you're seeing in general. The 'correct' global number of upvotes on a post, or the majority of what has been said about a subject might still be manipulated to the point of being essentially fake. Optimizing for virality is not desirable if you think of the platform as a public good. Think about what it has done for the centralized platforms, and the consequences it's had in the real world.
This is not meant as a criticism at all, I like Bevy. Are you familiar with the Mr. Beast PowerPoint that said:
> Your goal here is to make the best YOUTUBE videos possible. That’s the number one goal of this production company. It’s not to make the best produced videos. Not to make the funniest videos. Not to make the best looking videos. Not the highest quality videos.. It’s to make the best YOUTUBE videos possible.
When I glance at the Bevy discussion link you shared, my reaction is:
> Your goal here is to make the best GITHUB OPEN SOURCE game engine possible. It's not to make the most performant game engine. Not to make the game engine that powers the best games. Not to make the best looking graphics in a game engine. Not the highest quality game engine or game editing experience. It's to make the best GITHUB OPEN SOURCE game engine.
> Your goal here is to make the best GITHUB OPEN SOURCE game engine possible.
That sounds awful if applied to Bevy, and seems you misunderstand what "Mr. Beast" is trying to say.
They're not saying make the best game engine, but make the game engine that would do best by GitHub-popular metrics, which is absolutely the wrong way to go.
I hope they continue to simply make the best game engine available, as before, and ignore useful metrics or focusing on where it's hosted.
They didn't misunderstand, they're calling out Bevy's priorities.
Bevy is still incomplete as an engine. AFAIK there's only one commercially successful game made with it, Tiny Glade, and it doesn't even use Bevy's renderer but a custom one.
Yet the Bevy developers distract the project with essays and debates about the politics of their federated social media presence. You don't need that to build a game engine, but you do to build a "GITHUB OPEN SOURCE" game engine. I don't think there's anything inherently wrong with it, but that's clearly the focus here.
> They didn't misunderstand, they're calling out Bevy's priorities.
Yes, but the misunderstanding I'm trying to point out is that Mr Beast is not trying to create something of value, they're trying to create something that works well on a specific platform.
In the Bevy analogy, that would be creating a GitHub project that gets the most stars, regardless of how useful or well the engine itself is working.
I'm instead saying the same thing as you, they should continue focusing on building the greatest engine, regardless of the platform for hosting the project.
If Bevy were to follow Mr Beasts advice, they'd focus on flashy demos, engaging READMEs and so on, to increase the success on the platform itself, instead of focusing on the engine itself, which from following their direction almost since inception, they're doing a pretty good job with already.
If your goal is to be viral and not care about the quality, then maybe following Mr. Beast's advice might make sense. If you'd rather risk popularity by trying to what you think will actually be better without knowing whether it will end up being viral, it makes sense probably to take anything he says with a grain of salt.
I guess my point is, writing 3,000 words on social media choices isn't going to make the game engine any better. But I can see how it is really important to the community and developers, which is to say, it's really important if the product is not a game engine but An Open Source (Esoteric) Game Engine Hosted On GitHub. Do you see what I am saying? That is the difference between making the best videos and making the best YOUTUBE videos. Mr. Beast isn't confusing, he's capitalizing the important part of what he is trying to say!
I fully understand what you're saying; I just don't agree with it. For starters, people can be complex and have more than one goal. The effect of making an open source project isn't necessarily just the utility of the project itself, and if some of those other potential effects are desired, the best way to do things won't necessarily be the same as if there's only one output that someone cares about.
For another thing, even if there aren't any other specific effects that are desired, there still might be some that are specifically not wanted, and avoiding those might be important. Mr. Beast is a exactly the type of example that demonstrates this point; by focusing on making the "best" YouTube content as measured purely by popularity, he's done all sort of things that someone might very understandably want to avoid. I agree that he's not confusing, but that's not the issue with him. He's extremely transparent in how little he cares about whether what he does actually helps anyone other than himself (or if he hurts other people in the process of helping himself). I suspect this is quite different from the mentality of most open source developers, who are putting in personal time and effort towards contributing to something that realistically has little likelihood of direct personal benefits for those involved. What you're perceiving as a lack of focus comes across to me as having the humility and thoughtfulness to try to look at the big picture and understand one's actions in the context of a larger environment that isn't improved in the long term by pursuing a single narrow goal to the exclusion of literally everything else.
Okay… Unity and Unreal have a lot less focus than Bevy, but are much better game engines. They will be shipping more great games every day than Bevy will in the next year, including beloved meaningful ones, like Silksong and Indiecute and Cuddlygame or whatever. And hardly anyone there, like most big corpo employees, is directly benefitted from the better games, they get paid the same amount of money, but the rub is also, everyone I know working at Unity and Epic is really sincere and loves games.
Of course I understand these are different things. Bevy is not at all competing with Unity.
Because Bevy is trying to be best GITHUB OPEN SOURCE game engine. I’m just trying to be a little jocular about how… you know, I didn’t say unfocused, but surely it seems a little silly to write 3000 words in response to a community worried about which open source social media federation protocols to adopt. That giant thread IS the product, it makes perfect sense from the POV that Bevy is trying to be the best OPEN SOURCE GITHUB GAME ENGINE, in the same way that Mr Beast is making the best YOUTUBE videos or Egyptology professors are making the best EGYPTOLOGY writing or painters are making the best PERSONALLY MEANINGFUL FINE ART or whatever. I like Bevy!
> Bevy is trying to be best GITHUB OPEN SOURCE game engine
You're the only one saying this. No one else, including the person working on the project that you originally responded to, have claimed this is their sole goal to the inclusion of everything else. It's hard to tell if you think they literally don't care about anything else but are choosing their actions poorly, or if you think that they have the wrong priorities and should change them, or if you just didn't really stop to consider that maybe your assumption about what you're saying they're trying to do is incorrect and haven't read what I'm saying closely enough to understand that no number of examples of other things that happen to fit what you're saying is relevant if you aren't able to establish why anyone else should agree that it applies here in the first place.
One could argue the opposite, let's take bevy as an example:
more popularity could bring in more contributors or more funding which would hopefully result in making a better engine.
The same could apply to Mr. Beast videos (more views translate to more money which translate to better production and staff which translate to more or better videos) but the goals are inherently different (maximizing profit which rewards quantity over quality)
Community drama has always been the achilles heel of large, open-source projects which are volunteer driven. Focus on community is critical to delivering this, especially when your product relies on mind share.
I'm not quite sure why, but this release feels special, there are a ton of new features that I'm really excited to try out. All kinds of applications for the remote protocol even beyond the editor or games.
Two questions: is there any timeframe on the new declarative scene system (BSN)? and if mod_picking was moved into bevy itself, are there any plans to do the same with xpbd or rapier in the future?
We'd like to land initial BSN features within the next two cycles (obviously sooner is better than later).
We do have plans to upstream a physics plugin, but we aren't yet in a rush to do so, given how great the 3rd party options are. Once visual Bevy Editor workflows start being viable, the pressure to bless a physics plugin will go up I think.
Practically at the moment you do need to learn Rust to use the engine. Our public APIs are all Rust APIs. I'll note that Bevy's ECS makes a lot of Rust more approachable, as it is written to "feel" high level, and it solves a lot of the ownership problems for you that normally trip up newbies. I am of the opinion that Rust is a productive gamedev language, especially in the context of Bevy.
That being said, we've built Bevy ECS and our Bevy Reflect (our Rust reflection library) in a way that enable bindings to other languages to be built. People have built partial Lua and Javascript scripting support on top already. For ecosystem health reasons, I believe that Bevy should have one official language (Rust), but we still want to give people the tools they need to build the integrations they want.
We do get a healthy amount of donations, both from corporations and individuals (see https://bevyengine.org/donate). If you navigate from there to our foundation page, you can see how we spend it. We are a 501c3 non-profit, so each year we MUST file a public annual report as well outlining our activities.
As a casual onlooker, reading blog posts here and there, it's evident the topic of Rusts' suitability for game development is a hot topic of discussion and research. Sometimes it feels there is a sort of existential dread coming with the thought that Rusts' design maybe simply makes it too much of a pain in the long run in attempt to force code to comply with it's required way of thinking.
Do you ever find yourself wondering if its the right path to commit to for future games?
The strong criticism Rust got in this area is being poorly suited for rapid throwaway prototyping. I think that's fair — slow compile times and language's focus on writing things properly on the first try are the opposite of what you want when trying out random ideas and seeing what sticks. I think that may be fixable. Partly it's a skill issue (with enough experience, you can cut corners when you known which ones to cut). Partly it could be improved by tooling for hot reloading, and perhaps a scripting language integrated with Rust.
In Bevy in particular almost everything happens through ECS, and the ECS has a Reflection API, so you can hook it up to whatever you want, and manipulate it from any language.
I also wonder what about the rest of the game development lifecycle. Games are taking many years to develop, and not all of that is quick exploration. The more of the game starts taking shape, the more you actually need stuff to work. You need ability to refactor, polish, and extend the implementation without breaking things. You need to be fixing gameplay bugs, not wasting time on hard-to-reproduce crashes.
I personally love working with Rust. I think it delivers on the various buzzwords that made it popular. In general when people critique Rust in this context, it comes down to:
1. Rust's ownership / mutability features
Bevy ECS specifically alleviates a lot of the ownership problems that newbies often encounter in Rust. It doesn't solve _all_ of those problems ... there are definitely still UX rough edges. This _will_ be a sticking point for some people. The cost / benefit here is also hard for newbies to evaluate, as it is a _very complicated problem that requires years of experience in the space_.
From my perspective, the cost is worth it. Strict mutability and ownership rules allow us to parallelize everything safely and automatically. Strict mutability allows us to (via the DerefMut trait) _perfectly and automatically_ detect all changes to components and allow developers to react to them. This is something that is unique to Rust, at least in the mainstream. You will not find this type of feature in ECS-es written in other languages, as they literally don't have the semantics to globally distinguish between a read vs write pointer deref.
Opt-in garbage collected ECS is something that people are experimenting with in Rust right now), which would allow people to define "do whatever you want" code.
And _right now_ you can always just use Bevy ECS's unsafe api variants to do whatever you want when the "safety" isn't worth it to you.
I value what I like to call "progressive disclosure of complexity". I want people to be able to quickly and easily use the tools I build without much experience. And as they gain experience, I want them to be able to seamlessly dive further down the stack. I believe Rust handles the encoding the "low level" stuff better than every other language, both by more accurately modeling system constraints and by protecting people from doing the "wrong thing". It also allows you to use those low level pieces to "climb up" the stack until you have something like the Bevy API.
Unlike most engines, in Bevy you can start "at the top" in your program, hit F12 in your IDE to "go to definition", and keep going until you hit the core language APIs. And _then_ you can hit F12 one more time and go into Rust's source code. This experience is extremely empowering, coming from engines like Godot, which have a "high level" API with a "hard cut" before you go into the engine with a completely different language and paradigm (and no good way for your IDE to bridge the gap).
Bevy (and Rust) are for the developers that care about understanding (and controlling) their tools from top to bottom, and are willing to undergo a bit of initial pain (relative to scripting languages) to make that happen. Rust is not a perfect language and it isn't the best "constraint solve" for everyone. But I am most interested in building a holistic experience that empowers people that value that kind of thing.
3. Compile times
Rust compile times can be long if you aren't intentional about it. That being said, Bevy is built in a way to make compile times reasonable. With our "fast compiles" setup (see the getting started guide on our website), I can compile a change to our examples in ~0.5 seconds. Thats close enough to "instant" for me. The trick in general is (1) make sure you aren't writing code in a such a way that requires recompiling EVERYTHING (2) use dynamic linking for large deps (we do this for you in Bevy via the dynamic_linking cargo feature) (3) use a fast linker (covered in our guide).
Ensuring you follow principle (1) in large projects is a skill that needs to be honed. But on the Bevy side, via our opinionated Plugin structure (and dynamically linking those plugins), I think we can provide bounds that discourage people from shooting themselves in the foot.
I will close by saying that it is worth thinking critically about what tools you use and not following hype trains blindly. Picking Rust _and/or_ Bevy for your project _is_ currently something that many people should not do. However I think that Rust and Bevy are both VERY good tools that will be right for some people. And due to their "carefully and seamlessly climb up the stack" approach instead of "riskily climbing down when necessary", they have extremely solid foundations, and their user experience improves constantly. They are both increasingly suitable tools for more and more categories of people, and I expect that trend to continue.
This is _not_ a repost from our perspective. This is a massive new chunk of features and content (993 pull requests from 256 contributors) including new hot-topic features like Virtual Geometry.
The GP comment is a bit overstated (I doubt anyone is going to ban Bevy posts) but Bevy has had plenty of recent exposure on HN and most release posts are moderated away on HN because the discussion is almost always about the project in general rather than the release, unless the changes are truly monumental.
That's your last three releases plus something about a foundation, in the last year alone. It's great it's getting traction but it's also quite a bit more than most other projects as it is.
The issue is that that refers to "Show HN" posts. If some engaged dev posts your updates, how is thst different from spamming every Opeani update? That's just organic interest, given that this is the one of the most well known Rust game engines, a mix of two topics that traditionally get attention here
Please reread https://news.ycombinator.com/item?id=9775868. It says one year since it received significant attention, not one year except when a massive chunk of features and content is added. Dan explicitly addresses that case (“but that only applies after the "significant attention" test has been passed”).
And as you can see, the criteria is “Whether or not it contains significant new information (SNI)” which is indeed exactly the opposite of what you are saying.
Noteworthy: this was our first release that used our new Release Candidate (RC) process and automation to facilitate collaboration on the release blog post. Both of which were a great success! The quality bar of the release has been raised significantly: expect fewer bugs and faster 3rd party plugin updates!
There is a Rust tool named `generate-release` within the website repository[0]. It handles interacting with the Github API to get a list of significant changes, breaking changes, and contributors. (The main Bevy repository has pull request labels for all of these, so this is pretty easy.)
I know the latest UI update/plan is not released yet, but do you feel like you’ve discovered the way forward in that area? Or are there still lots of unknowns?
Yup! I've had 95% of the new design written out for weeks now. The last unresolved questions revolved around some scene inheritance details, which I've largely sorted. I've been distracted by release prep, but now that its out I should have this ready in short order. I'll note that the primary focus is rolling out the new scene system / format. This enables and improves UI use cases, but the reactivity bits are still being investigated (ex: check out the bevy_quill and bevy_reactor experiments).
Outside of the core reactivity and scenes work, I'm really excited about the improvements in both text rendering and picking. I think both of those will make a huge difference in terms of usability and correctness.
Once those are a bit more stable, I'd like to target a focus system for UI, to enable good keyboard and gamepad menu navigation and to hook up to screen readers.
Probably been answered already (feel free to point me there) but how does Bevy compare with Godot (other than one might prefer Rust)? What type of game/situations would Bevy be much more performant where it matters?
Bevy makes it much easier to write reasonably fast, easily maintained, refactorable code. It's great for situations where you have a lot of complex logic, want to do something particularly weird, or require a lot of non-rendering performance (Unreal still crushes us on rendering performance due to several decades and billions of dollars of investment).
Factory builder and simulation games are the classic example of "when should you use Bevy". You should absolutely pick Godot right now for games that are more content-focused that need a lot of level design: puzzle games, platformers, walking simulators...
That makes sense. So Bevy would be a good choice is you want to example build a Hearts of Iron clone where rendering (i guess) isnt the heavy part but instead simulationg alot of events and complex AI actions. Thanks!
Nothing to ask right now, just -- thank for your (and Alice's) work!
The (non-game) things that I do would be infinitely more painful without Bevy ECS, so I sponsored personally at Diamond for now.
Very excited for relations and I'm hoping that the Bevy Foundation can attract the support it's looking for (and I'll switch over to corporate in a few months if things don't go unexpectedly sideways with my company). :)
It has certainly been a wild ride. Running an organization is certainly a different skill set. I've learned that I'm pretty good at that side too, but it drains me in a way that programming does not. Bevy's success has definitely been a mixed bag for me. It has been extremely fulfilling and a dream come true. But things were also much simpler, calmer, and pleasant when I was building Bevy alone incognito.
No question, just want to say thanks! I've had a lot of false starts trying game tutorials but the ones I found for Bevy were really easy to follow. I was working two versions behind and the changelog for Bevy was so well done that I was able to figure out most of what changed. Bevy was also just straightforward to use.
I recommend checking out Bevy Jam games (which are pretty much always open source) for more complete / real world examples: https://itch.io/jam/bevy-jam-4
Definitely a bit of a gap in our official learning material. Hopefully we can close it soon!
As far as Lumen goes, there are a few experimental early-stage projects that add real-time global illumination to Bevy, such as bevy-solari [1]. Most of them rely on hardware raytracing support, as this simplifies a lot of things, and the new baked GI stuff that just shipped in 0.13 is fine for non-RTX. Besides, there's a good chance that hardware raytracing support will be very commonplace by the time any of this reaches production quality.
For Nanite, the closest thing that's being actively worked on is meshlets [2]. These actually are pretty close to ready and likely to land in 0.14 (no guarantees of course). These provide some, but not all, of the benefits of Nanite. LOD features can potentially be layered on top of meshlets in the future to provide a solution to roughly the same set of problems that Nanite solves, with some advantages relative to Nanite and some disadvantages.
Hi, I'm the author of both the Solari (Lumen) and Meshlet (Nanite) PRs, and I'm happy to see interest in them! To expand on pcwalton's answer:
Solari is _extremely_ experimental. I'm basically entirely scrapping my previous version[1] based on Radiance Cascades[2], and starting over with ReSTIR[3] techniques. Don't expect it anytime soon, but I'm definitely having fun working on it! The real technical blockers to Solari is that wgpu, our graphics library, does not have upstreamed raytracing support. I've been using a semi-buggy fork[4], but we'll need to get it merged before Bevy can merge any Solari code.
Meshlets (no cool product name like Solari) on the other hand are much less experimental. I already have a very functional and fairly fast GPU-driven renderer based on meshlets implemented, and mostly reviewed, and it should hopefully get merged into Bevy's main branch within a few weeks. Check the meshlet section of the "What Comes Next" section at the bottom of this post to see an image. I'm planning to do a livestreamed review session to get the PR pushed through since it's such a complex PR (thousands of lines). However, what I have so far is just the basics. Memory usage is a big issue, and lack of hierarchical LODs (the main selling point of Nanite) are not yet implemented. Further more, I'd really like to have both mesh shaders (for large triangles), and software raster (for small triangles) implemented to improve the visibility buffer raster speed. Mesh shaders are sadly not supported in wgpu, nor has anyone started a fork to implement them. For software raster, we need support for 64bit integers and texture atomics in wgpu, but that's something we're working on[5].
So yeah, lots of experimental work that's going to take a while to be production-ready and available to users, part of which will need to be working with wgpu to implement more modern features, as wgpu's current priorities are understandably focused on the WebGPU spec, which lacks the newer features from 2020+ that started shipping in the last 2-3 GPU generations. I'm having a lot of fun though, and making good progress!
The blog post directly mentions efforts towards a GUI-based editor in the "What's next" section.
We can definitely deliver on global illumination in some way, as shown with the irradiance volume support added in this release, though it may not match Lumen 1:1. Nanite is definitely more involved, but worth investigating.
Just to clarify, irradiance volumes (and other forms of GI added this release like lightmaps and reflection probes) are statically baked ahead of time, meaning they'll start showing incorrect lighting as you move objects and light sources around. They take time to bake (slowing down development iteration), and limit how much you can do with them / need careful usage and placement, but are widely supported, and give great results for very cheap runtime costs.
Lumen is a fully _dynamic_ GI system. No slow offline baking, and much more flexible (and therefore realistic) lighting, especially reflections. The downside is it's much, much slower (but still barely fast enough to be realtime 60fps), and requires a semi-recent graphics card that support hardware-accelerated raytracing.
As for whether meshlets or realtime dynamic GI is harder, well, I'd probably lean towards GI right now. I haven't yet started the (very complex) LOD building system for meshlets though, so maybe I'll change my mind in the future :)
I can't help but feel that between events and commands, and especially with all the parallelism, there's no clean, powerful solution to manage all manner of inter-system interactions. Having .before(), .after(), .chain(), different schedules and whatnot is great, but I think there's something lacking in the model to round it all out. Granted, I'm a novice in these matters and I understand that concurrency brings many hard problems. Could you spare your thoughts on the matter? Thanks!
Pretty straightforward process / I just made it up. Throw some olive oil in an Instant Pot, add beef and sear (no need to fully cook, just brown it), add ~4 cups of water and ~2 cups of lentils (I eyeball these), throw in chopped onions / bell peppers / mushrooms / garlic, add spices (plenty of turmeric + generic store bought "curry powder", garlic powder, dill, cayenne pepper, salt), and the secret ingredient: ~1/2 cup of smooth peanut butter (trust me this is very important ... when in doubt add more).
(edit: I keep the Saute setting on while im adding ingredients and occasionally stir. Then I seal it up, turn on the "bean chill" mode on high. And wait 40 minutes for tasty goodness)
Core pillars (including WIP things like Scene, UI, Editor, Audio) are in place. Partial or full engine stability (see my "partial stabilization discussion: https://github.com/bevyengine/bevy/discussions/9789). More than a few fully released quality games. More than a few fully released quality non-games / tools (we're already seeing Bevy being used as a foundation for things like CAD software and modeling tools).
Any idea why the example image in the OP link appears to be running at sub-optimal framerate?
What is the expected ECS overhead per frame (not including graphics interaction, i.e. code specifically in the ECS model)?
Since an ECS is typically a flattened scene graph, is there still a game loop? Wouldn't be necessary, correct? You only need to respond to the inputs...
I would say that the systems in the ECS _are_ the game loop. The ECS overhead per frame is kind of hard to measure / it depends on the scale of usage. To establish the scale of operations: Random single-entity ECS data accesses are a sparse array lookup to find the table the entity is in, and then an array lookup to find the component in the table. Iterating components in a query is roughly the same as iterating an array / is very cache friendly. Running individual systems is _slightly_ more expensive than a function call. Scheduling systems in parallel does introduce some overhead (which is currently higher than we'd like / we're working on optimizing it), but when you pay that cost you get the benefits of everything running in parallel.
There is still a game loop that runs every tick. The engine wouldn't work so well if we only responded to inputs as they come in, event pub-sub style.
As for ECS overhead, I've made it one of my top priorities to eliminate it wherever possible since it underpins the entire engine. We're at the point where most optimizations are saving a few tens or low-hundreds of microseconds per frame in your average game/app (i.e. lowering context switch costs from parallel system execution). If you're pushing below 60 FPS in your app, chances are the performance issues are not coming from the ECS, but some other part of the engine, or the app's own code.
> Since an ECS is typically a flattened scene graph, is there still a game loop? Wouldn't be necessary, correct? You only need to respond to the inputs...
How do you plan to have stuff moving then? You need to update their position every frame, so...
