# Entity Component Architecture - initialization between multiple components

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.

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.

• OK, I understand not wanting to couple two components too tightly, but this is actually going to be a simulation/building game where the player will be putting down types of flooring, walls, objects, etc, so I need some way to handle when the FloorType changes. You're right that I don't want to couple a FloorType value to a particular image, but I probably will want to couple a Floortype to how that FloorType is eventually rendered, even if it's choosing a random grass tile or layering multiple images or whatever. This logic needs to go somewhere, right? – Ben Slinger Jun 27 '14 at 12:41
• Then perhaps you don't want an ECS for this case at all. The tile map is just a list of integers that are indices into an array (or several arrays) of data that indicate everything about a particular tile, like image, type, etc. Data still defines the contents of those arrays. You don't want each tile to be its own complete object. – Sean Middleditch Jun 27 '14 at 16:30
• I have to agree with this here. ECS is a solution to some kinds of OOP problems that game programmers were experiencing; this is more of a world definition problem, still data driven but your ECS just collapses into the one system handled by Sean's explanation above and so it's not needed. – Patrick Hughes Jul 27 '14 at 5:22