Movement system low or high level in ecs design

Started by
15 comments, last by Dominik2000 9 years, 3 months ago

All the DrawableComponent.Draw function does is call the actual render code. I haven't written that ECS myself, it's taken from the codebase of Almirante Engine.

Also, since RenderComponent is the only DrawableComponent (at least for now) I'd only have to replace a single line of code.

RenderComponent.Draw always calls the DrawModel function, which in turn calculates the world matrix, sets the shader and it's resources and calls the Draw function on the model itself (using SharpDX.Toolkit)

Moving the dependency to a system would be pretty easy if nessecary:

Create RenderSystem class, inherited from EntityProcessor or ParallelEntityProcessor

Set it's Filter to RenderComponent

Put in code to:

1. Fetch data from entity

2. Call render code and pass the data to it

Done.

I've modified the base ECS code a bit already. I could remove the DrawableComponent base class and have Drawable stuff handled by systems.

Advertisement

I took a look at the Almirante source code on github. In my opinion the author didn't understand the benefits (or reasons to use) an ECS/data-oriented design. It looks like a confused mish-mash of traditional OOP and data-oriented design. From what I can tell from the source, Entities look like they are designed to be inherited to provide functionality. Components are stored on the entity and nowhere else (so you can't easily iterate over components of the same type). DrawableComponent (which inherits from Component) looks like it is meant to be inherited from to provide custom functionality. It is accessed in typical OOP fashion. I don't see much point for "systems" to exist in this architecture.

So, this is not a "traditional" ECS by any means. It looks like typical OOP with a lot of extra cruft.

You do have a point here phil. It appearantly takes elements from typical ECS and typical OOP. On the other hand, it works and does it's job and as long as it does that, I'm happy :)

What's with the EntityXY framework? I look at this, while implementing my framework, the system manager is greatly the same.

But my question to the post of crancran remains, could the message queue for moving the entities combined with an event manager which I need anyway?

What's with the EntityXY framework? I look at this, while implementing my framework, the system manager is greatly the same.

But my question to the post of crancran remains, could the message queue for moving the entities combined with an event manager which I need anyway?

The reason you find so many variants of an entity framework is because there is no standard practice.

As for the queue, you could implement a single or multiple queues depending on your needs. Chances are a single queue would be sufficient as a starting point and build upon that idea long-term if you find you need to separate the queues for any particular reason.


What's with the EntityXY framework? I look at this, while implementing my framework, the system manager is greatly the same.

Do you mean EntityX? It's a nice framework IMO, not sure what you're asking about it though.

My Gamedev Journal: 2D Game Making, the Easy Way

---(Old Blog, still has good info): 2dGameMaking
-----
"No one ever posts on that message board; it's too crowded." - Yoga Berra (sorta)

Yes, sorry I mean EntityX. I ask if I could take this as reference, to get an imagination of what an ecs system has to do.

This topic is closed to new replies.

Advertisement