Anatomy of a knockout | Hacker News Reader

Anatomy of a knockout

chris-granger.com

73 pointsibdknox15 comments

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.

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.

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.

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.

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)?

That's effectively unfortunate to compare your design to OOP because we tend to have different opinions of what OOP is. If you see OOP simply as message passing and polymorphism then your "all-e" and "renderer" functions just reimplement these ideas (as opposed to have your function simply assign different values to your data). Why isn't your "render-player" not a method?

It would have been interesting to go into more details about the CES design. For example, how do the components interact with each other? How is "position" updated when interacting with "walker" and "jumper"?

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...)

There's plenty of explanation on the Internet.

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.

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.

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.

How about a book chapter?

http://gameprogrammingpatterns.com/component.html

Nice, these are definitely mixins.

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 :)

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?

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

Reply on news.ycombinator.com