

Anatomy of a knockout - ibdknox
http://www.chris-granger.com/2012/12/11/anatomy-of-a-knockout/

======
seanmcdirmid
I'm a bit confused by the design space here. How are components here not just
mixins that are supported in more sophisticated OO languages? There also seems
to be dynamic inheritance going on (as in Self or even CLOS). Still, it sounds
like the system is definitely OOP, just not OOP in the very limited Java/C++
sense.

I've been using a similar object system through an adaptation of Rodney
Brooks', of iRobot fame, behavior-based programming model. You can read about
it in my Coding at the Speed of Touch paper.

~~~
ibdknox
I'm not sure what your exact definition of OOP is, but one thing that is
missing that I would generally have in mine is encapsulation of logic - there
are no methods.

I guess you could argue that there's a form of multi-method going on, but that
seems like a stretch.

~~~
seanmcdirmid
OOP is defined by object identity (which you clearly have with entities) and
state encapsulation. Methods aren't really required and many early OOP (actor-
based) systems even lack them! Whether there is polymorphism, or if that
polymorphism is expressed inwardly (via virtual methods) or externally (via
match-based systems)...are all enhancements. Of course, its probably not that
useful to go down this pedantic rabbit hole.

I'm trying to understand if your CES system is equivalent to dynamic mixins,
or if there is something else at play here. I've seen this pattern many times
before, and have even used variations of it in my language designs. Checkout
papers linked in the following LtU posts:

<http://lambda-the-ultimate.org/node/4257>

<http://lambda-the-ultimate.org/node/2149>

Both systems are object oriented and neither system relies on methods.

Also, does this way of expressing a system help with your liveness goals in
Lighttable? I've found that the ability to apply mixins dynamically does, in
the sense that I can reuse objects after a code change by applying additional
mixins or cleaning up mixins that are no longer relevant.

~~~
ibdknox
It does indeed help with the liveness a great deal, though it takes a bit of a
different form than what I described here for building a game. I'll probably
write the second post in the next couple days that goes over what that looks
like.

Based on my cursory understanding of how dynamic mixins would work, it seems
like they are similar to components - both are just ways of composing state
into an object. I think the one major distinction is that components are not
meant to really bring logic with them while mixins in most mainstream
languages provide more than just state. That difference is implementation
specific though.

For what it's worth, the question I started with was how do you create a
runtime modifiable system that also allows for potentially infinite
customization? What I came up with is behavior oriented, though I think
different than what you're describing in your paper.

EDIT: Thinking more about it, another difference is that everything I've shown
is just data, there are no special language constructs at work and I would
venture a guess that gives you more freedom than a mixin system does. The
example components I give all expand out into nothing more than a map full of
vectors containing maps.

~~~
seanmcdirmid
I think its quite close to behavior oriented programming, at least as defined
by Brooks. Keep in mind his goal is robotics, which is very similar to games
(or to say, a game is just a robotics simulation!).

I'm not really interested in the distinction between language-based vs.
library-based extensibility: they are quite the same thing even if the syntax
is different (and yes, language-supported extensions are definitely less
flexible!). Also see adapter extension in Eclipse: every object supports the
"HasAdapter, GetAdapter" interface, which allows for lots of dynamic
extensibility.

Also, when you say "data," do you mean state? E.g., adding physics state to an
object undergoing physics simulation. Any chance for data in the form of a
lambda (basically, that would be virtual dispatch)?

------
groby_b
Seriously? It's hard to find an example? I'd suggest buying a copy of Thief :)

Yes, the ideas behind component systems are _that_ old. (The earliest
reference that I recall off-hand is Scott Bilas presentation from GDC 2002:
[http://scottbilas.com/files/2002/gdc_san_jose/game_objects_s...](http://scottbilas.com/files/2002/gdc_san_jose/game_objects_slides.pdf))

There's _plenty_ of explanation on the Internet.

~~~
ibdknox
example = source code

I didn't mean an example of a game built with it - there are lots of those. :)
As you say, it's an old methodology, with Scott being the first one to really
spread it around (as far as I could find), so there's a decent amount of proof
it's a viable strategy. But aside from specific questions on SO and such, I
couldn't find a lot of talk about it in a general, but practical sense. i.e.
here's what you do to implement it, here's what a game looks like in it.

~~~
groby_b
Implementation: Game Programming Gems 6. (Or possibly 5) :)

And Thief really is a prime example, because it comes with an editor that
exposes the component system. That completely covers the "here's what a game
looks like in it" angle.

There's also a whole load of info on "data oriented programming", which sort-
of follows a similar approach.

Not that it'll help your specific issues, but I figured I leave pointers for
anybody else reading about it and being interested.

Edit: Oh, and before I forget it: Search for "functional reactive programming"
- that goes down this path a bit further, and it's as the name implies a good
match for functional languages.

~~~
sirclueless
As a more modern example, you could look at Scribblenauts Unlimited, which
also has a component system and some fairly deep and general logical systems.
There's an item editor, which exposes all of the underlying interaction logic
and component interfaces, and also does some interesting things with sprite
generation.

------
ibdknox
This is the first part of what my talk at the Clojure Conj was about. Part two
is about how this relates to Light Table's design :)

------
zachrose
I am so curious about this: where is the state!?

I understand that functional programming avoids state and mutability, but
there must be bits in memory that describe what's happening in the game, no?
So entities are unique ids, which I interpret as "objects" without data or
methods. And components are described as collections of state, but really
they're just functions? I'm looking at the code, and while I don't understand
Clojure syntax yet I can see that there are "things" like :camera, :player,
and multiple :platforms, which are defined with what I assume to be
preliminary data like position and dimensions.

Can anybody give me some clues?

~~~
ibdknox
components are maps of state. so when you call (position 10 10) it's returning
a map.

