Entity system in Lua, communication with C++ and level editor. Need advice

Question

I have a 2D basic editor written in Qt, and I'm in the process of adding entities. I want the editor to be able to receive RTTI information from entities to change properties, create some logic being able to link published events to published actions (for example, A level activate event throws a door open action), etc... Because of this I guess my entity system should be written in a scripting language, in my case Lua.

On the other hand I want to use a component based design for my entities, and here starts my questions:

1) Should I define my componentes in C++? If I do this in C++ won't I lose all the RTTI information I want for my editor? On the other hand, I use box2d for physics, if I define all my components in script won't it be a lot of work to expose third party libs to lua?

2) Where should I place the messaging system for my game engine? Lua? C++?

I'm tempted to just have C++ object to behave as servers, offering services to lua business logic. Things like physics system, rendering system, input system, World class, etc... And for all the other things, lua. Creation/Composition of entities based on components, game logic, etc...

Could anyone give any insight on how to accomplish this? And which approach is better?

---

Sorry for the late response James, I did go to sleep. I have prefered to create a new response becaue I'm going to write a somehow long text.

I think you were not wrong and you did get the idea exactly as I wanted. Let me explain my ideas right now and key points after some sleep to clarify everything:

1) Components: At first I wanted to write them in lua. Now I have clear I'm going to write them in C++ and expose everything needed. Ussually only interfaces are exposed to lua, so I have come across that to export properties to be published in the editor we could get all "getXXXXX" methods (that have been exported to lua) and show them in the editor as XXXXX. Other things like data type, etc... should be thought.

2) Entities: They will be defined in lua through composition of C++ components (entity templates). They could be hardcoded too in the C++ side and have a factory for components and another for entities and let the lua side instantiate them.

All this, is what I can think of now. I know my editor can still be using game objects even if it is external, but the game am I into is for iphone using cocos2d and the editor is writtien in QT, so, I can't have the game running in a qt canvas and make qt<->game talk.

Answer 1

1) Yes. While you want to expose the functionality via Lua for scripting you will in general want all the objects defined in C++. This will likely require either using the built in (and usually crappy) RTTI or writing your own system (If you look into it, for the basics, its really not that hard to do so dont let this deter you).

By keeping all of the objects within C++ then your game knows how to deal with them, and you can use the scripting to define them or give them small little action sets via the script and the like. And as you said, this keeps them available for other third party libs if need be.

2) C++ again. This will just be another thing that you want to expose through Lua so that other things can trigger or script logic to react to the messages and the like. This will also let the objects defined in C++ use the system as well with out having to go through Lua to do it.

In general I would say Always design your engine in the language its going to be running in. Hardware these days is very powerful compared to even a few years ago, but that doesnt mean you will not reach the ends of that power with your projects. A Scripting language will never run as fast as a compiled language.

Secondly this allows you to develop the entities/objects as completely as you want with out having to expose everything to the scripting interface. This is potentially another handy layer of abstraction that you can utilize to rework and upgrade or the like, parts of the system as you work on it with out necessarily having to redo every part at the same time.

Plus, Kudos on the Component system... Most people go straight tree hierarchy from the get go and then get overwhelmed with its upkeep and lack of extensibility.