EcsRx
  • readme
  • Getting Started
    • Stuff To Know
    • Setup
  • The Framework
    • Entities
    • Components
    • Systems
    • Blueprints
    • Groups
    • Observable Groups
  • Framework Infrastructure
    • Application Infrastructure
    • Application Lifecycle
    • Dependency Management
  • Framework Architecture
    • High Level Architecture
    • Entity Collections
  • Plugins
    • Overview
    • Reactive Systems Plugin
    • Computeds Plugin
    • View Plugin
    • Batching Systems Plugin
    • Group Binding Plugin
  • Performance
    • Overview
    • Component Type Lookups
    • System Affinities
    • Struct Components
  • Other
    • MicroRx
    • Third Party Content
    • FAQs
    • Breaking Changes
Powered by GitBook
On this page
  • Systems Executor
  • Observable Groups
  • Observable Group Trackers
  • Entity Database
  • Entity Collection
  • Entities
  • Component Database
  • Component Pools

Was this helpful?

  1. Framework Architecture

High Level Architecture

PreviousFramework ArchitectureNextEntity Collections

Last updated 3 years ago

Was this helpful?

From a high level perspective EcsRx is built on top of SystemsRx, we make use of SystemRx's ISystemsExecutor and ISystem notions while adding our own custom handlers and ECS paradigms on top.

If we were to look at the highest level of what the MAIN architectural components were it would look something like this:

Systems Executor

As you can see we have the Systems Executor section which is where all systems end up within the framework, they are all setup internally by registered System Handlers which understand how to process certain kinds of system and wire up dependencies.

In the real world most of the handlers are IConventionalSystemHandler implementations and you can make your own versions of these if you want

Observable Groups

As systems use groups as their contracts we have Observable Group objects which deal with maintaining a list of applicable entities and notify any subscribers when they change in any way.

There is a plugin which extends this further with the notion of IComputedGroup which wraps an observable group and filters/constrains it further.

Observable Group Trackers

The last part of the System Executor section is the Observable Group Trackers which watch entity collections and notify when entities add/leave a group, this makes the Observable Group the storage of what entities are actually in the group, and the trackers just notify it when to change.

There are various flavours of ObservableGroupTracker implementations, we use the Collection based one here but there are ones for individual entity tracking against groups or batched ones too.

Entity Database

So the entity database contains all entity collections and acts as a sort of proxy to let you query into all collections if you need to, however in most cases you would deal with individual collections directly.

Entity Collection

Entities

Component Database

The component database stores all the actual component data in large arrays, this allows us to more quickly access component data.

Historically components were stored on entities but it causes the memory to become extremely fragmented so this gives a large performance benefit without anyone really needing to know whats going on.

Component Pools

These are the large arrays (simply speaking) that contain all the actual component data.

These objects just store entities and notify any listeners when entities are added/removed or components change, you can find out more .

Entities are the main thing developers interact with as they are the data containers that get bounced around the system, to find out more look in the .

Here
Entity Docs