>>839618>I'll implement a basic object ... then inherit that in more specialized objects that include anything additional.Sure, I get that, but let's suppose you have a game with three different types of enemies: those that always stay on the ground, those that always swim in water, and those that always fly in the air. What would your class hierarchy look like? Probably something like this:
GameObject
. . . Enemy
. . . . . GroundEnemy
. . . . . . . GroundEnemy1
. . . . . . . GroundEnemy2
. . . . . . . GroundEnemy3
. . . . . WaterEnemy
. . . . . . . WaterEnemy1
. . . . . . . WaterEnemy2
. . . . . . . WaterEnemy3
. . . . . FlyingEnemy
. . . . . . . FlyingEnemy1
. . . . . . . FlyingEnemy2
. . . . . . . FlyingEnemy3
So the GroundEnemy base class would contain the properties and functions necessary to make an enemy run on the ground etc.
Now what happens if you want an enemy that can both swim in water and run on the ground? It doesn't fit neatly anywhere. You can try to use multiple inheritance and derive from both GroundEnemy and WaterEnemy, but then you're inheriting the the stuff from Enemy and GameObject twice. You run into different variations of this problem a lot when projects get more complex. The reason I say inheritance is crude is that you can't pick and choose what aspects you want to inherit from which class.
>My current project is a very simple Breakout style game where I've been getting my feet wet with exposing object functionality to Lua.Sharing entire objects between Lua and C/C++ isn't particularly convenient. You can use C++ template hacks to generate bindings automatically, but this often slows down compilation time significantly and complicates memory management. My advice to you is to bind mainly functions and pass around opaque handles when you really need to, and try to keep as much as you can on the Lua side.
