ajmmertens
Joined 7 years ago
Karma
103
Submissions
50
Member since
Dec 29
Recent submissions
Comment · 2 years ago
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.
Comment · 2 years ago
> 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.
Comment · 3 years ago
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.
Comment · 3 years ago
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.
Comment · 3 years ago
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_...
Comment · 3 years ago
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.
Comment · 3 years ago
> 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.
Comment · 3 years ago
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.
Comment · 3 years ago
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.
Comment · 3 years ago
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).
Comment · 3 years ago
Definitely possible. I know of a project that used an event-based architecture to decide when to run ECS systems.
Comment · 3 years ago
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.