I am attempting to design a component-based architecture that allows Components to be dynamically enabled and disabled, much like the system employed by Unity3D. For example, all Components are implicitly enabled by default; however, if one desires to halt execution of code for a particular Component, one can disable it.

Naively, I want to have a boolean flag in Component (which is an abstract class), and somehow serialize all method calls into strings, so that some sort of ComponentManager can check if a given Component is enabled/disabled before processing a method call on it. However, this is a pretty bad solution. I feel like I should employ some variation of the state paradigm, but I have yet to make progress.

Any help would be greatly appreciated,

  • 1
    \$\begingroup\$ What about a public property "enabled" with a setter removing/adding event listeners, or just methods with first line like this if (!enabled) return; ? \$\endgroup\$ Oct 8, 2012 at 18:55

1 Answer 1


If you mean to disable an entire system simply remove the system from your active loop.

If you mean to stop a particular component from being active remove if from the pool (array/list?) of active components in your system.

If you want to stop an entity from being active (before destruction for example) simply stop all of its components.

Edit: The entire behavior of your components depends on the way they are implemented. I assume components can receive messages through a system which they can chose to disconnect from.

If you wish your components to stop being active actors the system will stop processing them:

  • an AI component will not run
  • a physics component will stop reacting to physics and be ignored by the rest of the world
  • a render component will not be drawn.

But there is also the handling of messages. There you probably want your components to stop receiving them, this way they will not process requests and apply changes they are not supposed to. But this part entirely depends on your approach to the whole inter-components communication.

If the system is in charge of managing the communication to the component it can disable the entering communication as well. i.e. close all channels the component opened.

  • \$\begingroup\$ Thank you for taking time to respond. Unfortunately, I don't believe your solutions solve my problem. For example, if object A is referencing Component B directly, removing B from an update loop will not affect B's inherent ability to make changes to A. When B is disabled, it is desired that nothing can be changed. After some Googling, it seems this problem is quite complicated and involves method-invocation interception and is language-specific. sharpcrafters.com/blog/post/deeper-into-aspect-inheritance.aspx details what would be needed for use in a C# system. \$\endgroup\$
    – Alex
    Oct 9, 2012 at 3:42
  • \$\begingroup\$ I think the answer is quite good, only I don't think it applies directly to the architecture you're describing. May I suggest you explain a bit more about your architecture in your question? \$\endgroup\$ Oct 9, 2012 at 8:56
  • \$\begingroup\$ Within due time, I will certainly share the architecture with the folks at gamedev.stackexchange. The architecture will be described in an academic paper I'm in the process of writing. Coyote's solution certainly works, depending on the architecture employed; however, I don't like the existing paradigm, which is why I'm writing a paper with new ideas :). To clarify: a method in a class derived from Component will be executed iff it's enabled. Aspect-oriented frameworks help me do exactly this by generically intercepting methods. Thanks again, and I'll keep you guys posted with updates. \$\endgroup\$
    – Alex
    Oct 9, 2012 at 15:06
  • \$\begingroup\$ Keep in mind that message passing and other component related mechanisms should be as unobtrusive as possible. i.e. Do not over-design this aspect so you can keep the memory and performance impact of your architecture low. \$\endgroup\$
    – Coyote
    Oct 9, 2012 at 15:52
  • \$\begingroup\$ Thank you for replying, Coyote. In the scope of this project, memory and performance aren't very important since the paper describes mostly theoretical work; however, those words of advice are nevertheless true, and I will certainly keep them in the back of my mind. \$\endgroup\$
    – Alex
    Oct 10, 2012 at 0:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .