I am running into some road blocks attempting to effectively implement ECS methodology. I have a heavy background in OOP, and I think that is really tainting my perspective.

According to a lot of the information I have gathered regarding ECS, one of the primary benefits is that each system is supposed to work independently, and also, using components should help avoid memory cache issues since components should be stored in contiguous Memory.

The problem that I am experiencing is the following.

Given a particular element for which Rendering, Animation and Physics need all be applied there is a particular sub set of information which must be available and synchronized to all systems, while an overlapping subset of information may not require availability and synchronization.

For the rendering system to work it requires a component containing a Sprite, a position and a rotation.

For the physics system to work it requires a component containing a position, a force and a rotation.

The animation system is slightly more complex, as there are three types of animation

1) Tile: No animation, requires only a sprite

2) Simple Animation: Loops through a single animation, requires a set of sprites

3) State Animation: Infers sprite from a state and a TimeInState, requires a State and a set of sets of sprites.

So it seems that there is the following portions of data required for the ECS as a whole (not partitioned into components):

Sprite - Current sprite representative of entities animation

Rendering system Read

Animation system Write

Sprites - Complete set of sprites available to entity

Animation system Read

State - Current state of entity

<Some System> Write

Animation System Read

TimeInState - How long entity has been in a particular state, to enable mapping to a specific frame of a specific animation

<SomeSystem> Write

AnimationSystem Read

Position - Both physics position and drawing position (while in an idealized situation they would be equal in actuality they are only tightly coupled through some mapping function i.e drawing Y often equals -physics Y, and physics often work of Center of gravity while rendering works on either top left corner, or center of sprite)

Physics system Read/Write

Rendering System Read

Rotation - Both physics position and drawing position (similar issues to position, but possible to avoid)

Physics system Read/Write

Rendering System Read

Force - Physics

<some system> Write

Physics system Read

-----------------------------------------------

As you can see, it becomes a rats nest of inter connectivity destroying the System Independence principle. Also, since each system uses multiple components it also destroys the Contiguous memory access principal as well. Some sources concede that complete system independence is not always possible but the breakage is acceptable as long as the more performance enhancing principal of contiguous memory access is preserved, this is seems would require Data duplication, something that I find great difficulty in accepting as good practice (this may be due to OOP and Database bias).

The animation Components present a new challenge entirely... namely, how to efficiently store jagged arrays in contiguous memory.

In my particular case it turns out to be a jagged array of jagged arrays. I plan to use a image packing software to create image atlases, the image packing software produces a string->box mapping file so a particular sprite can be located by providing the sprites String formatted Name/Id. Also, since various states may have more or less frames than other states, and since some entities may have more or less states than others you can see that the first jagged array is entity to states, followed by states to frames and finally frames to strings.

I suppose the gist of this post is.... ARRRRGGGG, WTF?!?! HELP PLZ!!

You could try packaging the data in some other way to minimize this cross-accessing. It seems you want your AnimationSystem to do a bit much, you could split it up such that one part is doing the logic and then have another System for choosing a texture from some cache based on that data and save a pointer to the current texture and data about how its used inside a texture component.

You could then package the position and rotation into one component and then have the rest of the physics data inside another. Then the rendering system could read the position/rotation component and texture component.

I think parallel reading from one array of components that some other system already wrote to and reading/writing out to the own component array shouldn't be that bad, but its something to be minimized.

Some people says to use the Observer Pattern to do the interaction between those systems. Never tried out but looks like a alternative.

Well, the purpose of an ECS is to get away from OOP and its intertwined calltrees to have a nice clean structure, where you get a fixed list of systems that do straight iterations through full arrays of components in a fixed order. For example, you first call the physics system which updates all positions and then call the render system which reads all positions.

I dont see how the observer pattern, which is basically spaghetti-code repackaged into OOP, can help you on that, when it generates back-and-forth jumping between single components of different types. For example that would mean every single time the physics system updates one of the position components there would be a render component observing it and the code would just jump there, then back, then on the next component again and so on with the contraption.

I would suggest you read the article series at http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/.

Well, the purpose of an ECS is to get away from OOP and its intertwined calltrees to have a nice clean structure, where you get a fixed list of systems that do straight iterations through full arrays of components in a fixed order. For example, you first call the physics system which updates all positions and then call the render system which reads all positions.

I dont see how the observer pattern, which is basically spaghetti-code repackaged into OOP, can help you on that, when it generates back-and-forth jumping between single components of different types. For example that would mean every single time the physics system updates one of the position components there would be a render component observing it and the code would just jump there, then back, then on the next component again and so on with the contraption.

I would suggest you read the article series at http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/.

http://en.wikipedia.org/wiki/Entity_component_system