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

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

    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.

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

c++ architecture lua component-based
Related questions and answers
  • don't want to find out in the end that I have to rewrite everything again, as a lot of other objects will be working with these data. Sorry if it's a too subjective matter, but I need some insight. I'm...well... I'm building the animation system of my game engine (the skeletal and skinned animation stuff), and I came to a point where I added so much functionality in the frame and node structures... that make really hard to work with when coding some functions that use them. I was thinking of making ie. SimpleMesh and HierarchyMesh objects, which will also require that the renderer can deal

  • I'm writing a shooter (like 1942, classic 2D graphics) and I'd like to use a component based approch. So far I thought about the following design: Each game element (airship, projectile, powerup... components. A powerup has the Sprite, Position, BoundingBox. And so on. The main loop manages the game "physics", i.e. how the components interact each other: foreach(entity (let it be entity1... remove_component(C* c) { components.at<C>() = 0; } void serialize(filestream, op) { /* Serialize all componets*/ } ... }; std::list<Entity*> entity_list; With this design I can get #1

  • areas of concern I have and wanted to get some opinions on the proper way others have solved them or would solve them. 1. Cyclical Dependencies When I was doing the game in C#, I didn't really have... sort of designs other people used to overcome them, or would use. For a little background, I started working on it in my free time last summer. I was initially making the game in C#, but about 3 months... as drawable and updatable and I get a stack of screens handling my battle graphics. While I haven't been able to get the screen manager to work perfectly yet, I think I can with some time. My

  • I'm creating a component-based game object system. Some tips: GameObject is simply a list of Components. There are GameSubsystems. For example, rendering, physics etc. Each GameSubsystem contains... GameSubsystems) can implement registerComponent(Component*). pro. Components and GameSubystems know nothing about each other. con. In C++ it would look like ugly and slow typeid-switch..., GameSubsystemParticleEmmiter can be merged into GameSubsystemSpatial (to place all audio, emmiter, render Components in the same hierarchy and use parent-relative transforms). con. Every-to-every check. Very

  • My engine uses a component-based entity system internally, and I want to bind it to Lua for scripting. Now, I want to save people who write scripts for it typing work. In C++, to set the position... ):SetPos( 123, 456 ) But let's be honest, would you want to type so much just to set an entities' position? I don't think so, that's why I "hid" the component system from Lua: Right now, what you do is ent:SetPos( 123, 456 ) The component stuff is handled internally. You can still manually add and remove components from Lua with ent:AddComponent and ent:RemoveComponent, etc. Now

  • physics properties. I know there will be errors here as I get the items colliding with the ground but not with each other properly. So I would appreciate some input on what I am doing wrong. void... this on what I had done there, but modifying it to fit with Ogre. It is working but not correctly and I would like some help to understand what it is I am doing wrong. I have a state system and when...::createScene() { m_pSceneMgr->createLight("Light")->setPosition(75,75,75); // Physics // As a test we want a floor plane for things to collide with Ogre::Entity *ent; Ogre::Plane p; p.normal = Ogre

  • Say I develop a game for mobile platform running OpenGL ES 2.0. I have done 2D part, and now I wish to import some 3D objects. The imported 3D objects must contain the following: Vertices positions Normals UVs Texturing information Animation information Collision mesh Maybe some other things... I am aware, that I could and (maybe should) create my own file format that brings these data from..., that will let me import 3d meshes into my game, ready to use? The solution/middleware should be: easy to use easy to port efficient not consuming too much memory with unnecessary things containing all

  • I am trying to make my own game for fun, it is basically a 2d side scrolling shooter, with dynamically generated enemies, levels, loot, and some other things. Currently I have dozens of XML files... be a better idea to use a SQLite database to store all this information? I have looked around, and it seems to be a mixed response. Does anyone have any sort of insight into this? I am using C++ and OpenGL... sub components, that get picked out of a pool, according to factors such as rarity, the player level, and the game level. Currently the way I have it setup, is where during initialization the game

  • I'm working on a Component/Entity-System based game engine atm. And I have this little dilemma. I have simple geometrical structures which might be downloaded or created in game at some point. These structures are used to create models that are used in OpenGL and OpenGL ES and then for some collision processing. During dev and Beta I am quite ok with maintaining data copies for the physics... a little multiplayer side project running as nicely as possible. Note: I can't create an OpenCL tag so if someone else could and add it to the question it would be appreciated.

Data information