Suitable in memory storage library to store components for entity systems

artificialidiot
  • Suitable in memory storage library to store components for entity systems artificialidiot

    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 trouble maintaining a logical view of the game world (i.e. updates shouldn't be visible while iterating) and there is no attempt at maintaining spatial or temporal coherence of data.

    I wonder whether 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) :- alive(DB,A),alive(DB,B),wontcollide(DB,A,B),
                         move(DB,A),move(DB,B).
    
    wontcollide(DB,A,B) :- get_component(DB,position,A,PA),
                           get_component(DB,position,B,PB),...
    
    move(DB,A) :- get_component...,update(DB,position,A,NewP).
    
    DB=loadgame();
    loop{ moving_update(DB); blow_stuff(DB); collect_loot(DB);...}
    

Tags
c++ component-based entity-system
Related questions and answers
  • ; }; class Entity { int id; // entity id std::vector<Component*> 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... 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

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

  • only the transformations needed each frame. My Components would then point to these arrays. Is it the right approach? If not, how to store the structure data to get it loaded only when needed to GPU memory and maintain the Component structure. Do I even need a system and components to display and manipulate the structures? Note: This is not a homework. It is more a question of interest to get...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

  • 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... physics then position change? Is this even necessary? What are other ways of insuring that components that should be process every frame are in fact processed? EDIT I think I will be concidering 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

  • 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

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

  • I want to be able to move a sprite from a current location to another based upon where the user clicks in the window. This is the code that I have: #include <SFML/Graphics.hpp> int main...::GetPosition(App).y); } // Clear screen App.Clear(); // Draw the sprite App.Draw(Sprite); // Update the window App.Display(); } return EXIT_SUCCESS; } But instead of just setting the position I want to use Sprite.Move() and gradually move the sprite from one position to another. The question is how? Later I plan on adding a node

  • 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.... state_->handleEvent(event, this); } That means that I don't really ever need more than one instance of a particular entity state; doing something like entity.setState(new StandState) 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

  • I've recently decided to revamp my game architecture to get rid of deep class hierarchies and replace them with configurable components. The first hierarchy I'm replacing is the Item hierarchy and I... functionality into the base item class. But then I was noting that the Item had alot of unused/superfluous data. Now I'm trying to do a component like architecture, at least for my items before attempting to do so to my other game classes. Here's what I'm currently thinking for the component setup: I have a base item class that has slots for various components (i.e. an equipment component slot

Data information