RE: [Algorithms] Game Entities - avoiding inheritance / fixedpool allocation [bcc][fake adr]

[Matt M. <ma...@cy...>]

Hmm...if I replace "data-driven" with "dataflow," the emergent gameplay
thing starts to make sense.

In a typical dataflow architecture, operations on data are built by
assembling "nodes," each of which is composed of one or more inputs, a
(reasonably) atomic operation, and one or more outputs. They're pretty
awesome for motion blending, and, when taken to extremes like in the =
Houdini
architecture, can be amazingly general while maintaining great =
simplicity at
the code (but not necessarily the system) level.

This creates a situation analogous to the Lisp "code-as-data" paradigm,
where it's easy to write code that writes code, or that modifies code, =
etc.

If you use polymorphism and interface discovery as have been discussed
elsewhere in this endless meandering thread, it's even more malleable,
because you can reason about the way the current "program" is put =
together
and change it using (sometimes even simple) rules.=20

Now, I believe a lot of the "data-driven" systems I've heard discussed =
here
involve just such pin-compatibile-reconfigurable-architectures. (I =
believe
the Halo example was "varying position according to color." ...And that =
that
is in fact the generality and "emergence-friendliness" that has been =
implied
but not very well articulated in this thread.

Of course, how this somehow is an argument against interface =
inheritance,
polymorphism, multiple inheritance, or C++ is lost on me. All those =
things
are extremely helpful in building such architecture. Unless you're still
really good at typing "void *".

> Yes, they concepts of "emergence" and "data-drivenness" are completely
> orthogonal, you can have one without the other (but Turing machines =
have
> nothing to do with it).