Component programming. I think?

Started by
31 comments, last by EWClay 11 years, 1 month ago

Also, just to be clear, I'm not advocating the complete removal of events or messages from the design. All I'm saying is that the components themselves should neither send nor receive these messages. The systems, however, are free to communicate among themselves. As a matter of a fact, signaling would probably be the most efficient way to handle the achievement system, since it only needs to run occasionally. Whenever another system modifies component state that could affect achievement status, it sends a signal to the achievement system to wake it up. The achievement system runs once, awarding any achievements it detects, then goes back to sleep until it receives another "reevaluate" signal.

Advertisement

All I'm saying is that the components themselves should neither send nor receive these messages. The systems, however, are free to communicate among themselves.

Ah, then I agree completely. It may be we argued around a misunderstanding.

[size=2]Current project: Ephenation.
[size=2]Sharing OpenGL experiences: http://ephenationopengl.blogspot.com/

As a matter of a fact, signaling would probably be the most efficient way to handle the achievement system, since it only needs to run occasionally.


Well, that was my point. Agreed then.

Where the logic lives isn't a great concern to me; as long as the most suitable algorithms can be allowed to work.

This topic is closed to new replies.

Advertisement