Performance of metatable-based inheritance for entity classes?

[allfalldown]

To keep things nice and tidy, I was thinking of creating a bit of a hierarchy of "classes" for all my entities in my game. Basically, using setmetatable, .__index, and related functions/setups with tables, I'd make a base "entity" class that would handle collision and what not; from this, I'd make an "animatable entity" class derived from it, which would introduce necessary parameters for handling of animation and what not. Following this I'd finally, for example, make a "player" class from the animatable one; I could also inherit from it to make different enemies, animated blocks, all that.

However, while this approach could work, I'm curious about the alternative - creating single tables for each entity that just have all the variables I need for animation and collision/movement where necessary defined differently in each. The latter sounds like it'd be faster, but the former of course would look a bit "cleaner". I'm curious if the metatable-based option will not perform well and should be avoided.

[josh_uu]

Performance impact will be negligible. Your code will also likely be much more readable and easier to maintain. I can provide some links to different class implementations if you'd like. I use my own that is intentionally simplistic and only implements inheritance, if that would also be helpful to have.

[raidho36]

To keep things nice and tidy, I was thinking of creating a bit of a hierarchy of "classes" for all my entities in my game. Basically, using setmetatable, .__index, and related functions/setups with tables, I'd make a base "entity" class that would handle collision and what not; from this, I'd make an "animatable entity" class derived from it, which would introduce necessary parameters for handling of animation and what not. Following this I'd finally, for example, make a "player" class from the animatable one; I could also inherit from it to make different enemies, animated blocks, all that.

However, while this approach could work, I'm curious about the alternative - creating single tables for each entity that just have all the variables I need for animation and collision/movement where necessary defined differently in each. The latter sounds like it'd be faster, but the former of course would look a bit "cleaner". I'm curious if the metatable-based option will not perform well and should be avoided.

You can simply make a benchmark and test it. I never tested this but I'm pretty sure that the JIT compiler will convert all of that into static function calls.

[Fuzzlix]

To keep things nice and tidy, I was thinking of creating a bit of a hierarchy of "classes" for all my entities in my game. Basically, using setmetatable, .__index, and related functions/setups with tables, I'd make a base "entity" class that would handle collision and what not; from this, I'd make an "animatable entity" class derived from it, which would introduce necessary parameters for handling of animation and what not. Following this I'd finally, for example, make a "player" class from the animatable one; I could also inherit from it to make different enemies, animated blocks, all that.

However, while this approach could work, I'm curious about the alternative - creating single tables for each entity that just have all the variables I need for animation and collision/movement where necessary defined differently in each. The latter sounds like it'd be faster, but the former of course would look a bit "cleaner". I'm curious if the metatable-based option will not perform well and should be avoided.

I followed the same idea as you in my 1st bigger project omm. I created classes of classes of classes.
then i benchmarked my program and found out: the most executed code lines are those of the base_class:__newindex() method, which heavily outnumbered all other line counts. Writing this method as simple as possible gave the most speed improvement. I can see this change in the time my progam needs to run, measured with lua5.3. When i used luajit, the time difference was almost not detectable by human senses. And love uses luajit - lucky me and lucky you
The much bigger problem for you will be ineffective and overcomplicated coding style. This can waste more development and run time as this oop overhead.

[pgimeno]

I'd just like to note that separating the entities and the methods does not necessarily need to be messier or less organized. The entity-component-system approach, as commonly defined, does exactly that. The code lies in the systems, which don't really care about which entity they belong to, just about which entities contain the components that the systems apply to.