Entity Component Architecture - initialization between multiple components

Question

I'm starting work on an game set in an isometric world, and I'm having a bit of trouble understanding how to implement certain aspects of the entity component system idea.

Here are the Components and Systems I have so far:

WorldData (only one ever used, contains map and cell sizes) Camera (currently also only one ever used, though that could change I guess) WorldPosition (just contains X and Y values, in world space) Renderable (contains the image to draw, screen position values + offset, and a depth) Floor (contains the type of flooring and a walk speed)

Now If I create an entity with WorldPosition, Floor and Renderable components, where do I put the logic to enforce certain rules. For example, if Floor.FloorType is set to 'Grass', I want the image in the Renderable component to be set to 'floor-grass.png'. Should this go in something called 'FloorSystem', which checks every entity that has a Floor and Renderable component and updates them? And if so, do I need some sort of 'dirty' flag on Floor to say when it has changed, so that FloorSystem knows to update it and is not updating every floor tile in every frame? Or do I instead create a 'Dirty' component which I attach to that entity when it changes?

Any guidance would be much appreciated! I love the general elegance of this architecture and I think it will work well in my game once I get a better handle on it.

Answer 1

Now If I create an entity with WorldPosition, Floor and Renderable components, where do I put the logic to enforce certain rules. For example, if Floor.FloorType is set to 'Grass', I want the image in the Renderable component to be set to 'floor-grass.png'.

In a data file. There's no reason to say that you can't have a tile with FloorType=Grass but with Image=brick.png. Maybe you want it for some secret area the player has to use sound or some other property of the ground type mismatching the visuals to figure out. Or maybe you just want to have a wide visual palette and 20 different grass tiles that are all grass but look different.

You really don't want to couple Floor and Renderable. They are entirely separate things.

There's no good reason to encode policy into code. It's data. Leave it in data. You might make a map editor tool that does some extra checking to protect designers from common mistakes, but avoid enforcing design rules in the code itself.

And if so, do I need some sort of 'dirty' flag on Floor to say when it has changed, so that FloorSystem knows to update it and is not updating every floor tile in every frame? Or do I instead create a 'Dirty' component which I attach to that entity when it changes?

No. In the first case you still have to iterate over all tiles to check a dirty flag, and the second is an abuse of components. You can easily enough just make a dirty list that you append objects to if they need an update, but you certainly don't need it in this case.