Component based entity system API naming problems

One cat
  • Component based entity system API naming problems One cat

    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 of an entity, you'd do the following:

    pEntity->GetComponent< CPoint >()->SetPos( Vector( X, Y ) );

    That means, if I'd bind it to Lua 1:1 you'd also have to:

    ent:GetComponent( CP_POINT ):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, this doesn't seem perfect either:

    • The Entity metatable gets cluttered because it has to take all functions of all components

    • Naming problems: ent:SetJointMotorEnabled() again seems kind of bad

    Do you have any ideas how I could find a better naming scheme for component functions, without risking the scripting comfortability?

  • I haven't worked with Lua in a while, but couldn't you let your components themselves change the entity interface through the Lua wrapper (last time I used Lua in a game was in 2005, the wrappers must have evolved since then)?

    By having it at the components level, you could have your position component register a "SetPos" function on the entity that calls the component directly and have a JointMotor component register an object in entity with a function "SetEnabled", this way it's "data driven" and support both ent:SetPos(123, 456) and ent:JointMotor:SetEnabled()?

    As long as the registering of subobjects and functions validates that there is no name clash, you should be alright.

  • The fundamental problem here is that you've exposed the component system to the API. You need to encapsulate that stuff behind your interface.

  • We have a similar situtation in our project, and we solved the problem by saving components (not functions) to LUA metatables. Basically, when we are creating an entity (or game object as we call them) on LUA side, code looks something like:

    function createShip()
        self.transform = registerToComponent("transform")
        self.sprite = registerToComponent("sprite")

    Now, we can use simply

    entity.transform:setPosition(5.2, 4.8)

    to set position (and texture). And we are totally happy with this!

    (And actually I think this is better than having just entity:setPosition and entity:setTexture since when you have lots of components, resulting entity API would be just a big mess.)

c++ entity-system component-based lua
Related questions and answers
  • remove_component(C* c) {<C>() = 0; } void serialize(filestream, op) { /* Serialize all componets*/ } ... }; std::list<Entity*&gt; entity_list; With this design I can get #1...; }; class Entity { int id; // entity id std::vector<Component*&gt; components; bool has_component() { return components[i] != 0; } template <class C> C* get_component() { return dynamic_cast<C> components[C::id](); } // It's actually quite safe ... }; Another approch is to get rid of the Entity class: each Component type lives in its own list. So there is a Sprite list

  • 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... Components. 3: Component registers itself in GameSubsystem(s). We know at compile-time that there is a GameSubsystemRenderer, so let's ComponentImageRender will call something like... Components in GameSubsystems (when GameObject is created and composed). There are 4 approaches: 1: Chain of responsibility pattern. Every Component is offered to every GameSubsystem. GameSubsystem makes

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

  • ::createScene() { m_pSceneMgr-&gt;createLight("Light")-&gt;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... code shows the changes I made to get accurate physics. void GameState::createScene() { m_pSceneMgr-&gt;createLight("Light")-&gt;setPosition(75,75,75); // Physics // As a test we want a floor plane...::toString(m_pNumEntities), "cube.mesh"); entity-&gt;setCastShadows(true); Ogre::AxisAlignedBox boundingB = entity-&gt;getBoundingBox(); // The ogre bounding box is slightly bigger so I am reducing

  • I am studying entity indexed components and came up with a naive C++ implementation which just iterates over all entity "hash tables" and applies update/delete/insert functions in place. I'm having... there are libraries suitable to store components that are commonly found in games (position, movement, hp etc.) and allows ~500 queries per second on a netbook class computer over a database of ~10000 components total. Or is this even feasible? How much I can accomplish with this approach? In essence I want to be able to do something like this with reasonable efficiency: moving_update(DB

  • ) is therefore highly wasteful. Then again, making each entity state a singleton hardly seems appropriate. What do you suggest I do? (The same can be said about game states, so whatever the solution...This is the first time I'm trying to make a 2D game, so I'm having quite a few difficulties in getting things right. Right now I'm trying to figure out exactly how the entity state machine should work. 1. I noticed entity states are... well, stateless. Basically, they just act on the data in the entity accordingly, they hold no data of their own. When an entity forwards events to its states

  • until you pop out into an open space, known as a ' ' (space) character. You lose one life for each INITIAL collision with the X wall, and do not lose another until you have popped out and been freed from it. As an added touch i have made it so after you collide while traveling down the randomly generated map (or rather as the walls move uppward while your character stays put) the X chars you've... all the code: Thanks again! #include <iostream> #include <time.h&gt; // or "ctime" #include <stdio.h&gt; // for #include <cstdlib> // Windows stuff #include <Windows.h&gt

  • how to give the entity manager a list of types that are updatable. Then ALL of the components of that type can update rather than managing it per entity (which are just indexes in my system anyway...In order to get components to be able to update every frame (and leave this functionality out of components that don't need to) I got the idea to make an UpdateComponent component. Other components...() that gives UpdateComponent a pointer to the MovableComponent. Many components could do this and then UpdateComponent could call all of their Update(gametime dt) methods without having to care about

  • question about it is, is this a worthwhile approach at all? If it's a bad design I want to know now before I invest too much more time making all the screens I'm going to need. How do you build up...I've been working on a 2d RPG for awhile now, and I've come to realize I've made some bad design decisions. Theres a few things in particular that are causing me problems, so I was wondering what... 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

Data information