MarekkPie wrote:Your example seems to conflate Entity-Component with Strategy. Components handle more information than merely an algorithm. I completely understand why Strategy is unimportant in Lua, but Entity-Component is a bit different.
For example, Entity-Component wouldn't allow self:shoot(), like you have in your methods, since you would have to assume the entity implements the shoot mechanic.
The code example would have been a bit more complicated to demonstrate duck typing, but the point I was trying to make is that your objects, or their metatables, can be compilations of functionality that's duck-typed, i.e., functionality is assumed to be there in some form. For instance, the self:shoot() call doesn't imply that the entity implements shoot, only that the entity has shoot, meaning that shoot can be one of those things that you mixed in before hand.
A better implementation of my idea would be a "Mixin" function, which I think middleclass has that. The idea being is that Components would be a plain lua table, and the mixin function just copies everything from the component into the entity. There would be a few details that I'm hand waving right now, that would need to be dealt with, like if two mixins both defined an update function, one would overwrite the other.
Yeah, you can use that too. When I wrote it, I was a working as a Qt software engineer and I basically mimicked the Signals and Slots system. If I tried to write the same code today, I probably would allow for generic parameter binding, rather than forcing the self.
If you continue to use that code, here's the correct way without using the table colon operator. The first parameter needed to be changed.
Code: Select all
c.publish.register(c.publish --[[ the object publish ]], self --[[the object entity ]], self.receive --[[ the receive method for entity ]])