ajmmertens

Judging by the system & component names this looks to be pretty well designed tbh. There are a lot of systems for sure, but considering this is a city simulator that's kind of expected.

> I bet the current design passes and queries data all over the place, very redundantly

That's not how ECS works. A system has one or more queries that provide it direct access to the data. There's no passing around of queries or data.

The query engine works on top of an Entity Component System (ECS) storage that stores entities and their data in cache coherent (SoA - https://en.wikipedia.org/wiki/AoS_and_SoA) data structures.

With any kind of database - even in-memory SQLite - there is a query interface between you and the data. In ECS you access data directly, which is at least an order of magnitude faster.

Or if you want code that's easier to extend, read and don't want to do your own memory management.

Here's a bit of code from that project that generates a monster: https://github.com/tmewett/BrogueCE/blob/master/src/brogue/M...

It just allocates an object per monster, followed by initializing a long list of members that presumably just gets longer as more game systems get added.

The same code in ECS would look a lot simpler, and probably perform better/have better cache locality.

The same goes for Flecs:

- it has tools like https://github.com/flecs-hub/explorer that work with any Flecs project

- it has builtin support for hierarchies/prefabs and more (https://ajmmertens.medium.com/building-games-in-ecs-with-ent...)

- it has optional support for systems/scheduling

- it has an optional reflection framework

- it has an optional DSL for describing assets/scenes, with an online playground to try it out: https://www.flecs.dev/explorer/?local=true&wasm=https://www....

- and a lot more: https://www.flecs.dev/flecs/md_docs_Quickstart.html#autotoc_...

The way you frame the question already suggests a solution, and one that indeed doesn't fit ECS that well. That doesn't mean you couldn't design a DAW using ECS, but you'd have to redesign how it works.

For example:

- create custom components for different instruments

- create systems for specific instruments that match the necessary components

- write the result to a common component (e.g. "ChannelOutput")

You could then add components for EQ, effects, routing, ... and introduce systems that match those. The advantage of this approach would be that you end up with a bunch of loosely coupled systems (for instruments, effects, mixing, ...) and an in-memory representation that's cache & parallelization friendly.

One other datapoint would be that Unreal's animation sequencer uses an ECS design, which has a lot of things in common with a DAW.

Glossing over lots of details here, you can't of course design a DAW in one paragraph.

> but still ECS incurs massive overhead compared to basic arrays of structs

I actually know of quite a few projects that use ECS as the foundation for a low level rendering library precisely because it lets you iterate over a bunch of plain arrays, but with more flexibility.

The overhead of an ECS depends on many things, but if you have lots of entities with similar components, the overhead per entity can be quite small.

The opposite also applies: don't reinvent the wheel if you want to get something done.

Existing game engines like Unity/Unreal already have builtin solutions for entity management, but if you're (for whatever reason) using something that's more custom you can avoid having to reinvent entity management by using an ECS library. Similar to how you'd use libraries like SDL/bgfx/sokol for graphics.

I'm definitely not going to argue that you need ECS to do much of anything, but ECS has come long way in the past 4 years from a tool that lets you have lots of entities in a game, to a more generic system for entity management.

Things like entity relationships (https://ajmmertens.medium.com/building-games-in-ecs-with-ent...) introduced features that were already common in existing entity management systems, such as entity hierarchies.

An ECS can also come with a bunch of tools for inspecting entities, monitoring performance or changing components in realtime (https://www.flecs.dev/explorer/). Definitely not something you need to complete a game, but very handy.

It could be yep. One of the things that makes it a good fit for this use case is that Flecs has a query language that supports things like graph traversal and joins. Combined with either the builtin REST API or some custom protocol you could use it as a realtime in-memory database (which is what I use it for).

Definitely possible. I know of a project that used an event-based architecture to decide when to run ECS systems.

The biggest reason for me was to reduce compile times, which got cut into approximately half when I replaced STL containers with simpler custom ones. This starts adding up in large projects, where lots of files end up including the ECS.

Pretty close, but there's a bit more to it. This post goes over one way an ECS can store data: https://ajmmertens.medium.com/building-an-ecs-2-archetypes-a...

Whether ECS is complex or not depends a lot on which one you use. I've heard the same thing from a lot of gamedevs that use DOTS, but people in general seem to be pretty happy using Entitas (also a C# ECS that can be used with Unity), Bevy (which is based entirely on ECS) or for that matter Flecs.

Is it faster than Y? https://github.com/SanderMertens/y

> It does not change anything to all the other problems of bundling dependencies. Including the problems related to diamond dependencies.

As you put so eloquently before, that should not be the prerogative of build systems like bake, but of package managers like apt-get, brew and vcpkg. Bake is blissfully agnostic to those problems (thank god).

One thing that hasn't been discussed so far and I would like to highlight is code that is not distributed through package managers, as so often is the case for commercial closed source code. Bake is a great fit for these use cases, as these projects can simply zip up the bake environment (together with miscellaneous files like HTML, JS and what have you), unzip it on a different machine, and everything just "magically" works.

> Then just use a developper package manager like Nix, Guix, Spack or EasyBuild that do the staff. Instead of converting every other project to Bake for the sake of it.

If you got the impression that I am on a quest to convert every non-bake project to bake, then let me put that concern to rest. I love using bake, it is saving me lots of time and, TBH, I think there are some neat ideas in bake that other people might like, but that's it. After the code is built, it's like every other C/C++ library, and people are free to use whatever build system they feel comfortable with to link with those libraries.

Thanks for highlighting this- yes, there are quite a few other projects named bake. The internet is a big place, and while that means that it's almost impossible to come up with a name that's not already in use, the likelihood of running into each other is also small. In other words: I don't see this as a big problem unless one of the "bakes" becomes really big (like CMake big).

So what is the chance of this happening? Lets look at the list you provided:

- some aren't (C/C++) buildsystems (hackage::bake, bitbake, cake bake).

- some projects are dead (linuxrocks123/bake, openhub.net/bake-build, nsnam.org/bake)

- some projects are almost dead (esrlabs/bake)

That leaves one active project, which is Bakefile, which is not a build system but a makefile generator akin to premake. Bakefile (not bake) has a very different front-end (a bkl file) and different intent, so the potential for confusion is not big. IMO the internet is big enough for two different projects with a similar name :-)

Worst case the similarity in names makes it harder for me to get traction, but that's ok really. For me bake is a means to an end, and by no means the most important thing I'm working on. Would I enjoy it if people adopt it? Sure. But it's not the end of the world if that doesn't happen.

I am currently working to reintegrate a feature in bake (from before the fork) that will allow you to run unit tests on discovered projects. Stay tuned ...

Is this because you feel there is already a lot (perhaps too many) other build tools around?