We're currently working on an Entity Component System for D (
https://github.com/Zoadian/nitro)
Here some good explanations:
http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/
http://www.richardlord.net/blog/what-is-an-entity-framework
On Tuesday, 4 February 2014 at 04:12:49 UTC, Luís Marques wrote:
I loved reading Walter's component programming article in Dr.
Dobb's [0] in late 2012. I had missed H. S. Teoh's mid 2013
article on calendar textual formatting using the component
approach [1], but fortunately Ali brought it to my attention
recently, and I also find it absolutely fascinating!
I think what's most interesting with Teoh's article (and I
think that was Ali's point when he mentioned the article to me)
is that the calendar example is not as an obvious target for
the component approach, or at least that the design and
implementation is not as obvious for someone new to that
approach.
Now, while Teoh's example is much more complex than Walter's,
both examples are for cases of pipelined problems (source ->
filter1 -> filter2 -> sink). What I have been wondering during
the last few days is how much this "component programming"
approach could be applied to scenarios where you would normally
have a jumble of objects. For instance, try to picture a game
or simulation where spaceships fire at each other, pick up
objects, communicate, and so on, or something like that. My
instinct would be to code a solution which would be classified
as typical OOP code. Would it be possible to come up with a
solution that would be more in the spirit of "component
programming"? Or are such solutions only practical/applicable
for pipeline-like scenarios?
--
[0]
http://www.drdobbs.com/architecture-and-design/component-programming-in-d/240008321
[1]
http://wiki.dlang.org/User:Quickfur/Component_programming_with_ranges
