Is an entity/component system appropriate for this geometry handling system?

  • Is an entity/component system appropriate for this geometry handling system? Coyote

    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 and the display. But I started thinking about the future of this engine as I already invested some spare time over a year and a half in it. Now I would like to duplicate a few routines into OpenCL kernels and use the power of GPUs for the server side of my engine (and be ready for OpenCL enabled mobile hardware/software).

    The structures are of variable size and moving or stationary structures can be deformed or broken... ATM the storage is very inefficient.

    I thought of using a few mega arrays of GLfloat (Compatible with OpenCL) which would contain my structures depending on their size and pass 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 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.

  • I don't think you need an entity system for this at all; entity systems work well for gameplay-related code, where they are influencing behavior or properties in some fashion and can allow for rapid iteration in a very large way.

    It sounds like your geometry packaging system (for lack of a better term) doesn't need that kind of wide flexibility, and in fact you wouldn't want to allow it since that could destabilize performance.

    I would instead implement the system on its own, distinct from any kind of entity system, taking your requirements into account (which appear to be efficient storage of the shape data for both transport and utilizing in OpenCL for deformation computations, et cetera).

    Once the system is in place, you can expose it to your gameplay objects via a component that acts as a proxy for the geometry package. Such a component would essentially be a dumb wrapper around a reference to one of these geometry packages that is itself managed by the geometry packaging system. This will let your entity system refer to and take advantage of that system without complicating that system's own design with the flexibility of the entity system.

    (Incidentally, I think this is how one should generally approach interfacing physics and rendering systems with entity systems as well.)

c++ opengl component-based entity-system
Related questions and answers
  • 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... for my needs. Ah and I forgot to mention that nodes can have hierarchy, but this is not a problem if the frame data is reduced. The structure instances don't get duplicated unless any value changes. When... shader in every node. Other option I was thinking was making some helper functions to deal with the simpler cases, which would set some default parameters and would ask only the most basic ones

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

  • 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 pointers to some of Components. GameSubsystem is a very powerful and flexible abstraction: it represents any slice (or aspect) of the game world. There is a need in a mechanism of registering... 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've decided I want to write a central ResourceManager/ResourceCache class for my hobby game engine, but am having trouble designing a caching scheme. The idea is that the ResourceManager has a soft target for the total memory used by all the game's resources combined. Other classes will create resource objects, which will be in an unloaded state, and pass them to the ResourceManager...). If the resource isn't loaded, then the manager will mark the object to be loaded at the next opportunity, (usually at the end of drawing the frame). Note that, although my system does do some reference

  • to this is, I guess it can be applied to game states as well.) 2. The state of the entity sprite. Most of the time, whenever the state of the entity changes, the sprite that is used to represent it must... changed, then it (the representation) starts having an internal state. I would much rather have it stateless so that I require only one instance of every representation (just as before). Edit...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

  • 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... *) (node)); // Add it to the physics world World->addRigidBody(RigidBody); Objects.push_back(RigidBody); m_pNumEntities++; // End Physics } I then have a method to create a cube and give it rigid body 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

  • that. All this seems well and good, except I have one question, why not linked lists rather than arrays? Sure, if you had to make your own linked list class, I would be on board, but in c++ anyway, assuming.... And I could see a case there for using arrays rather than linked lists, because you would have to make your own (which while simple enough to do, could potentially lead to many more errors). I also...I was recently listen to a talk that Jonathan Blow gave, you can find it here. In the talk, he was talking about what data structures he (and he seemed to imply many others) use, and why. Which

  • ; }; 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) {<C>() = 0; } void serialize(filestream, op) { /* Serialize all componets*/ } ... }; std::list<Entity*> entity_list; With this design I can get #1

  • by an external source. My idea here was that I define the core components used by my game engine up front, and my item factory would assign the components that the item actually has, otherwise... 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...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

Data information