Hi.

I was building a game program that uses an "Entity-Component-System" type architecture and was wondering how you would go about implementing doors. In the program as it stands, there are the following requirements:

1. Components should be generic enough that you can form new entity types without a type of component for every type of entity (as that essentially defeats the purpose of the ECS architecture, which is to allow you to make all kinds of things with composition),

2. Components should contain only data, no code.

3. Systems contain all the code for the logic.

4. There is a messaging pipeline where the systems can send messages to each other.

Given this, I am wondering how you would go about implementing doors? It seems that doors require a state and changing that state changes the graphic displayed for the door. Right now, I have a GraphicComponent which stores a key to a graphical asset, and a PositionComponent to store the entity's position. There's also a PhysicsComponent which stores the physical properties of the entity. But if I add a StateComponent to store the door's state, then, when you change states, that has to update the GraphicComponent somehow, and also the PhysicsComponent to make the door passable -- this is a tile-based game, not one taking place in a continuous space. However, because of requirement 1, genericity, we cannot have anything too specific to the door in the StateComponent, but we must specify how to update the other components. But how do we do that without violating requirement 2 -- absence of code in the components? I have a "Finite State Machine" (FSM) object in my program, which would seem to be what I'd want to use, however it's meant to be general (I use it in the user interface to handle various user interface states, such as main menu, playing the game, etc.) so when you make one you specify code, not just data. It would seem it would violate requirement 2 to stick that in the StateComponent.

What is a good way to do this? Should I just use the FSM and see if I can get away with it?

And it gets worse: what happens if you want to have the door be jammed by something else sitting on the door's tile when it's open? Then there needs to be something to sense the object is present. How can you do this without a dedicated system for doors which would violate condition 1?

One of the more friendly designs I worked with had a general concept of a "portal" as a component.

Portals had pathways that could be reserved in a single direction. Using a portal could be locked, only one user at a time. Sometimes with a direction specified two characters could use the portal in the same direction at the same time.

Many doors were a single portal, that is, they supported one person going through one location as a time. Some doors were two portals wide, generally a two-door wide doorway. Sometimes there were large archways as 3-wide or 4-wide portals.

Other objects also implemented these portals. Stairwells were portals, usually 1-wide but sometimes 2-wide, where once a character registered to use it the direction was locked and more could use it in that same direction, until everyone was off. Bridges were similarly implemented.

And of course you could even implement Portal-style portals with such a system although we never did with the game; a portal is just an object with two endpoints and a transition animation.

I don't think there is any harm in a DoorLogicComponent though if you implemented some scripting, say Lua, it would just be a LuaComponent with a script assigned to it which could be "better" but not worth implementing scripting for i'd say.