Obtaining a certain type of object with component based design

  • Obtaining a certain type of object with component based design jmasterx

    I'm trying to design my game to be component based rather than overly hierarchical. Essentially, every high level object in the game (like gun, or whatever) inherits and implements the interfaces that it needs. For example, IPhysics, IRenderable, IWeapon, etc.

    There are a few cases where I'm uncertain how to obtain a specific interface from another.

    For example. A Gun might inherit from IWeapon, IPhysics, and IRenderable. I then also have a player which inherits from IPlayer, IPhysics, and IRenderable. I need a way so that, when Player and Gun collide, if Player is not currently wielding a weapon, he should be able to wield the gun and hold a pointer to the IWeapon of the Gun.

    Right now, when Box2D detects a collision between 2 fixtures, I use the UserData field to store the IPhysics pointer associated with the fixture, and therefore, the IPhysics.beginContact method is invoked.

    From here, the Player needs to somehow be able to know that this is a weapon, and obtain an IWeapon* . This is the part I really have no idea on.

    Any advice on solving something like this is appreciated, even if it means some kind of design change on my part. I'm just looking for a clear way on how to solve this sort of problem.


  • Updated to the new specifics of the question

    For example. A Gun might inherit from IWeapon, IPhysics, and IRenderable.

    This is not a component system. This is not to say its not a bad system, but in this case you should be able to cast the pointer to any of the interfaces (or just cast it to a Gun object and it should Contain the interfaces) and then use it as appropriate.

    As for determining what kind of object it is that the player has collided with, you can attempt to use the internal RTTI abilities like dynamic_cast<>() or potentially implement your own RTTI (Run Time Type Information) system and add in an IType object to query if an object is of a specific type or to return the type that it is, etc. Once you validate the type you can safely cast it as desired.

    If you do have a component system and we are just not meshing on nomenclature, then just leave me a comment and explain how the components are related to each other. Often this is done by an ID of the object they are a part of.

    Hope this Helps

  • If all your objects implement interfaces (Rather than being a set of components), all you have to do to get the IWeapon from the IPhysics is cast it. In C++, a dynamic cast will return null if the object doesn't inherit from IWeapon. In C#, 'as' will return null if the object doesn't implement IWeapon. Your mileage will vary in other languages.

    But I wouldn't call this method of creating game objects a component-based system.

c++ game-design architecture
Related questions and answers
  • 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. Questions: Which approach is better and mostly used in component-based design? What Practice says? Any suggestions about implementation of Approach 4? Thank you.

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

  • different objects in my game: plane, obstacle, player, bullet and I designed them like this: class Player : public GlObject{ private: std::string name; public: Player(); Bullet fire() const; //this method is unique to the class player void generate_mesh(); } Now in the game engine I want to have a general object list where I can check for example for collision, move objects, and so... stuff } the GameEngine constructor will be like this: GameEngine::GameEngine(){ hPlayer = new Player; objects.push_back(hPlayer); } The fact that I'm using a pointer is because I need

  • Possible Duplicate: Are there existing FOSS component-based frameworks? What open source game engines with component-based design of game objects do you know? And which best of them? I mean best not in Graphics or Physics, but best in context of Behaviour, Messaging, etc. This question is the result of inspiration by another question Thank you!!!

  • The idea I have an idea for a game. A few games, actually, that can built on top of the same general design. There is a game world that the player and the other actors exist in. The player can get information from the world about his surroundings. The player can also interact with the world, picking up an object for example. Now, I would like the same thing to be possible for other, scripted... (showed to the player, and given to the scripted actors) in this case would be something like a collection of "what", "where", and "in what orientation". The question My question is: how I can

  • 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 to worry about this since it isn't an issue there. Moving to C++, this has become a fairly major problem and made me think I may have designed things incorrectly. I can't really imagine how to decouple... 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

  • 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... 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... C++ application. Entities can be defined in an XML file (the IA part in a lua or python file). The main loop doesn't care a lot about entities: it only manages components. The software design should

  • I want to make a simple game where I have some characters fighting on a plane (level). I find the trickiest part as figuring out who should do what here. I want my terrain to have friction (so you could play on ice). I also want fairly customizable characters. At first I was thinking of a mediator pattern where the game gathers information about the current player state and modifies them based on that, but I do not think this offers enough flexibility. I was thinking more along the lines of each player / character does have some logic. The Input from the game gives it the command

  • 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 constructing a node object it's done referencing a pool of structure instances to prevent allocation for 2 equal frames. Also the lights are something that I'm not sure on how to handle as I need...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

Data information