• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
jaeg

Basic Component Based Entity

68 posts in this topic

That's a great a point.

This is driving me up a wall:
CEventDispatcher.h
[code]

#ifndef CEVENTDISPATCHER_H
#define CEVENTDISPATCHER_H
#include <vector>

#include "Event.h"
#include "IEventHandler.h"

using namespace std;

//class IEventHandler;

class CEventDispatcher
{
public:
virtual ~CEventDispatcher();

static CEventDispatcher* inst();
// Adds an event handler to the vector list
void addHandler(IEventHandler* handler);

// Sends an event to all of the event handlers
void sendEvent(Event* event);

//Clears handler list
void clearHandlers();
void removeHandler(IEventHandler* handler);

protected:
CEventDispatcher();
private:
static CEventDispatcher* pInstance;
vector<IEventHandler*> handlerList;
};

#endif // CEVENTDISPATCHER_H
[/code]


CEventDispatcher.h
[code]#include "CEventDispatcher.h"

CEventDispatcher* CEventDispatcher::pInstance=0;

CEventDispatcher::CEventDispatcher()
{
//ctor
}

CEventDispatcher::~CEventDispatcher()
{
//dtor
}

CEventDispatcher* CEventDispatcher::inst()
{
if (pInstance == 0)
{
pInstance = new CEventDispatcher();
}
return pInstance;
}

void CEventDispatcher::addHandler(IEventHandler* handler)
{
handlerList.push_back(handler);
}

void CEventDispatcher::sendEvent(Event* event)
{
for (unsigned int i=0;i<handlerList.size();i++)
{
handlerList[i]->handleEvent(event);
}
}
[/code]


EventHandler.h

[code]

#ifndef IEVENTHANDLER_H
#define IEVENTHANDLER_H

#include "CEventDispatcher.h"
#include "Event.h"



class IEventHandler {

public:
virtual void handleEvent(const Event* e) = 0;

IEventHandler() {
// Self-Register with the event dispatcher upon creation
CEventDispatcher::inst()->addHandler(this);
}
};

#endif // IEVENTHANDLER_H
[/code]

Event.h
[code]#ifndef CEVENT_H
#define CEVENT_H
enum EventType
{
// Mouse button events. Each of the next six events gets passed
// the absolute position of the mouse
E_MOUSELEFTBUTTONPRESS,
E_MOUSELEFTBUTTONRELEASE,

// Start new games
E_NEWGAMEEASY,
E_NEWGAMENORMAL,
E_NEWGAMEHARD,

// Game play related
E_INCREMENTSCORE,
E_PAUSEGAME,
E_CONTINUEGAME,
E_GAMEOVER,

// Close the App
E_APPCLOSE
};

struct Event
{
EventType Type;
void* Data;
};
#endif
[/code]


I keep getting a compiler error saying that CEventDispatcher has not been declared in IEntityHandler.h. I've tried variations on include files but can't get anything to compile. I'm trying to set CEventDispatcher as a singleton. I've probably set the singleton up wrong this is my first try at one.
0

Share this post


Link to post
Share on other sites
I believe it is your circular dependencies in your header files between IEventHandler.h and the CEventDispatcher.h. If you uncomment your [b]class IEventHandler;[/b] statement and then remove the [b]#include "IEventHandler.h"[/b] in your event dispatcher header, it should compile. Since you aren't using IEventHandler in your dispatcher header except as a holder reference, you can simply forward declare it since your handler header is actually including the dispatcher header so you can self-register :).
0

Share this post


Link to post
Share on other sites
That was one of the things I tried and it would complain about the handleEvent function not being declared.
0

Share this post


Link to post
Share on other sites
[quote name='VReality' timestamp='1320279034' post='4879953']
u want to get clever(?) you could go ahead and make the call on all sub-systems, but have them cache a list of entities to remove, and perform the removal during their normal processing of their components (you might have to do this sort of thing anyway, if you're multi-threading). That eliminates the extra searches. And that list will usually be empty, and rarely have more than one entry.
[/quote]


Nice idea; didn't consider that approach.

Therefore, given subsystem determines a specific entity should be removed; such as our CorpseSubsystem. It invokes the EntitySubsystem::queueEntityForRemoval(). This adds the entity id to a pending removal list. The last step in the main game loop immediately after render() is to invoke the entity system's update() method. Here, I could traverse this pending removal list and then issue the request to all other subsystems to remove that entity's components. The benefit here is that if dynamic components are created for that entity during it's life cycle, by issuing a delete to all subsystems, I insure that all references are adequately removed and returned to object pools. These subsystems move that entity's components to a pending list and then the first step that each subsystem does at the beginning of their update() during the next loop iteration is to remove these stale objects and return them to their object pool for reuse later.
0

Share this post


Link to post
Share on other sites
[quote name='jaeg' timestamp='1320291810' post='4880010']
That was one of the things I tried and it would complain about the handleEvent function not being declared.
[/quote]

Have you created a class that derives from IEventListener yet? If you have, did you implement that pure virtual method? That type of error to me sounds as though it's complaining about that scenario rather than the relationship between the interface class and the dispatcher. I put your code into Visual Studio 2010 here based on what you provided and it compiled perfectly once I made the tweak I indicated.
0

Share this post


Link to post
Share on other sites
Let us assume we have 3 types of components: spatial, mesh, and render. The spatial holds my position, the mesh contains a list or reference to a mesh for the entity, and the render is where the actual rendered content is maintained in the scene graph via a render scene node.

I assume that my spatial subsystem would create a scene node at the specified position in the spatial components. As the component's position changes, the spatial update() would reflect those changes to the referenced scene node. The mesh component would load whatever mesh information from the resource system and prepare it for the rendering phase. The render component would request a reference to both of these components (mesh/spatial) during initialization and then during the render system's update() loop, the we'd check if a scene node for the mesh has been added as a child to the scene node referenced by the spatial component. If so and the mesh has changed, the render component would update the mesh on the render component's child scene node. If a child scene node hasn't been created, the render system creates one off the spatial component's node, and then applies the specified mesh. Am I on track?
0

Share this post


Link to post
Share on other sites
I'm using MinGW so that might be my problem because I made the changed you've said and added a class that inherits the handleEvent function but no go..
0

Share this post


Link to post
Share on other sites
[quote name='jaeg' timestamp='1320325156' post='4880108']
I'm using MinGW so that might be my problem because I made the changed you've said and added a class that inherits the handleEvent function but no go..
[/quote]
Show me what that inherited class looks like.
0

Share this post


Link to post
Share on other sites
[code]#ifndef CSTATEMACHINE_H
#define CSTATEMACHINE_H
#include "IEventHandler.h"

#include "CState.h"
#include "CMenuState.h"
#include "CGameState.h"


class CStateMachine: public IEventHandler
{
public:
CStateMachine();
virtual ~CStateMachine();

void switchState();
void init();
void update();
void draw();

void handleEvent(const Event* e);

CState* state;
protected:
private:

};

#endif // CSTATEMACHINE_H[/code]

[code]#include "CStateMachine.h"


CStateMachine::CStateMachine()
{
}

CStateMachine::~CStateMachine()
{
//dtor
}

void CStateMachine::switchState()
{

}

void CStateMachine::init()
{
state = new CMenuState();
state->add();
}

void CStateMachine::update()
{
if (state!=NULL)
{
state->update();
}
}

void CStateMachine::draw()
{
if (state!=NULL)
{
state->draw();
}
}

void CStateMachine::handleEvent(const Event* e)
{

}
[/code]



Hot pancakes and syrup I got it. I added #include "IEventHandler.h" to CEventDispatcher.cpp and it compiled.
0

Share this post


Link to post
Share on other sites
[quote name='crancran' timestamp='1320276903' post='4879933']
[quote name='smr' timestamp='1320274090' post='4879912']
Just a word of caution: ...
[/quote]

Isn't this where being able to build templates in the game editor would play a vital role?
[/quote]

Yes, templates would make things easier for the designer, but what about the developer? Let's take your example of separating vital stats out into each their own subsystem and component type: HealthComponent, WeaponComponent, ArmorComponent, StrengthComponent, DexComponent, AttackComponent, etc. What would combat look like for an entity like this?

I attempted to provide a code sample, but it was so complicated that I didn't think I would be able to accomplish it without actually opening up my IDE and formally coding something. I can say it would involve a lot of asking systems if the two entities involved had certain stat components, passing messages around to receive damage, cooperation between stat components to try to figure out how much damage should be taken, whether a hit is even made, etc. It just seems like adding complexity just because you CAN and because somewhere down the line someone told you that you SHOULD loosely couple EVERYTHING. Loose coupling is great but loose coupling for the sake of loose coupling is just another way to shoot yourself in the foot.
0

Share this post


Link to post
Share on other sites
[quote][color="#1C2837"][size="2"]I attempted to provide a code sample, but it was so complicated that I didn't think I would be able to accomplish it without actually opening up my IDE and formally coding something. I can say it would involve a lot of asking systems if the two entities involved had certain stat components, passing messages around to receive damage, cooperation between stat components to try to figure out how much damage should be taken, whether a hit is even made, etc. It just seems like adding complexity just because you CAN and because somewhere down the line someone told you that you SHOULD loosely couple EVERYTHING. Loose coupling is great but loose coupling for the sake of loose coupling is just another way to shoot yourself in the foot. [/size][/color][/quote]

I was thinking the same thing myself. To me a single vital's component would be best. While my game isn't an RPG neither does it have a complex stats system but even if it was an RPG don't 90% of entities that might interact in away that involves vitals all have basically the same set of stats, given different values of course but that should be taken care of with the factory that put the entity together in the first place potentially with a data table or an external Init script (What I plan on using)

My whole purpose of using this system is to get away from hardcoding my entities so I don't have recompile when I want to add a new type making it easier.

Like when I parse my level and encounter an AnimatedMeshSceneNode (The mesh type I'm going to make all entities out of) I want it to extracted the name from the node (Yay Irrlicht!) and use that to build the entity by loading the external scripts with the same name. I also want to be able to just give the factory a name to manually create an entity if I need too.

[quote]
[color="#1C2837"][size="2"]I assume that my spatial subsystem would create a scene node at the specified position in the spatial components. As the component's position changes, the spatial update() would reflect those changes to the referenced scene node. The mesh component would load whatever mesh information from the resource system and prepare it for the rendering phase. The render component would request a reference to both of these components (mesh/spatial) during initialization and then during the render system's update() loop, the we'd check if a scene node for the mesh has been added as a child to the scene node referenced by the spatial component. If so and the mesh has changed, the render component would update the mesh on the render component's child scene node. If a child scene node hasn't been created, the render system creates one off the spatial component's node, and then applies the specified mesh. Am I on track? [/size][/color][/quote]
[color="#1C2837"] [/color]

To me it seems too broken up. If I may ask why not just use the entity's scene node directly as a way to store and access the positional and rotational data? Do everything directly it? Removing the need for a spatialdatabase by just having a subsystem that contains all the entity node components with the given IDs?


I also want to thank everyone who has responded. This has probably been one of the most fun topics I've been in on a forum.
0

Share this post


Link to post
Share on other sites
[quote name='smr' timestamp='1320329930' post='4880140']separating vital stats out into each their own subsystem and component type: HealthComponent, WeaponComponent, ArmorComponent, StrengthComponent, DexComponent, AttackComponent, etc. What would combat look like for an entity like this?[/quote]

[quote name='jaeg' timestamp='1320337066' post='4880172']To me a single vital's component would be best. ...don't 90% of entities that might interact in away that involves vitals all have basically the same set of stats[/quote]

If we think about componentized entities as being a data oriented approach, the guiding principal is to separate the entity into chunks of data which will be processed together.

If we envision all those stats being used for the purpose of producing a feature (like combat) through some sort of complex interaction, then we're envisioning processing all the stats together, so they should form a component. [i][b]Breaking each stat into it's own component is a violation of data oriented design[/b][/i]. Well formed components make it relatively easy to write the code, as well as letting that code run more efficiently.

Now if you find that you have various different types of entities which actually only need subsets of those stats, then you'll find it pretty difficult to code those interactions which process all the stats together, because those interactions would make no sense for entities which you've decided don't need those stats. In that case, you've identified some subsets of the stats which should form smaller components.

Rather than thinking of it as data oriented, I like to think of it as feature oriented. Entities have features, or aspects, or abilities, etc., like the ability to be placed in the 3d game world, to be rendered, to animate, to participate in a physics simulation, to collide with other entities, [i][b]to give and receive damage[/b][/i], etc. Each of these features involve it's own (mostly) unique data, [i][b]and the code which operates on it[/b][/i]. In general, a component should contain the data (specific to a given entity) which a subsystem processes. If it doesn't make sense to create two subsystems, it probably doesn't make sense to create two component types.

One area of stickiness is when multiple features are equally dependent on a common piece of data (e.g., AI, physics, and rendering all depending on entity position). The only two approaches that come to mind for dealing with this are either to factor that data out to a separate component (which breaks data orientation, forcing components to look it up while processing), or to duplicate that data (forcing components to synchronize it, and opening the door to copies being out of sync). At the moment, I tend to lean heavily towards the first approach, especially in the case of entity position, since there is a sub-system which makes sense for dealing with position data only.
0

Share this post


Link to post
Share on other sites
Should I make separate classes for the subsystems or could I just have a single subsystem class that has functions that let you decide what events they should receiver for the components they update?
0

Share this post


Link to post
Share on other sites
Short answer, they should be different.

Whenever you are coding a particular class/object, you should always refer to two principles.

The first is called [i]Separation of Concerns[/i]. This principle is often used when it becomes evident that an object needs to be re-factored into smaller distinct features that should overlap as little as possible. The term [i]concern[/i] can be defined as a focus, interest, feature, or behavior depending upon your context. The second is called [i]Single Reponsibility Principle[/i]. This principle basically outlines that every object/class should have a single responsibility, and that all its services (methods/functions) should be narrowly aligned with that responsibility.

So if we think back to what we're trying to do with a component-based design, we are trying to isolate and narrowly defined set of functionality or feature/behavior into classes that are as self-contained within reason. This way should we need to change the behavior of a component and its managing subsystem, we can with as little risk or need to decipher additional lines of code that have no relevance to the feature we're trying to enhance or bugfix :).

Those two principles should always be relied upon and you will find it is much easier to make modifications over the life cycle of any programming project. Of course it's my opinion and others mileage may vary in how strongly they feel about those two principles. :).
1

Share this post


Link to post
Share on other sites
[quote name='crancran' timestamp='1320361269' post='4880327']
Short answer, they should be different.

Whenever you are coding a particular class/object, you should always refer to two principles.

The first is called [i]Separation of Concerns[/i]. This principle is often used when it becomes evident that an object needs to be re-factored into smaller distinct features that should overlap as little as possible. The term [i]concern[/i] can be defined as a focus, interest, feature, or behavior depending upon your context. The second is called [i]Single Reponsibility Principle[/i]. This principle basically outlines that every object/class should have a single responsibility, and that all its services (methods/functions) should be narrowly aligned with that responsibility.

So if we think back to what we're trying to do with a component-based design, we are trying to isolate and narrowly defined set of functionality or feature/behavior into classes that are as self-contained within reason. This way should we need to change the behavior of a component and its managing subsystem, we can with as little risk or need to decipher additional lines of code that have no relevance to the feature we're trying to enhance or bugfix :).

Those two principles should always be relied upon and you will find it is much easier to make modifications over the life cycle of any programming project. Of course it's my opinion and others mileage may vary in how strongly they feel about those two principles. :).
[/quote]

Exactly! I think these two principles pretty much define a component.
Does any one know why the inheritance obsession became so widespread that the new term "component based entity" had to be invented?

I personally blame online tutorials. :D

EDIT: I just noticed this might be misread. No offense intended. I'm just wondering why there seem to be so many paradigm shifts in game development.
0

Share this post


Link to post
Share on other sites
[quote name='Madhed' timestamp='1320364949' post='4880339']Does any one know why the inheritance obsession became so widespread that the new term "component based entity" had to be invented?[/quote]

It comes from object oriented design, under which you focus on defining classes to represent your different types of application-domain objects. When thinking in terms of object oriented design, you typically think about how different types of objects relate to each other - what attributes they share, and how they differ. And the basic strategy for sharing features is to define object types in terms of other (more basic/general) object types.

This approach worked very well to promote encapsulation and separation of concerns, when the objects, and the relationships between them, were relatively simple. For example, suppose you made a banking system and defined class hierarchies for accounts, and transactions. Those are relatively simple, conceptual objects, with only a handful of possible operations each, and not much variation in the different types of each.

Once you get into our type of real-time simulation world, with a wide variety of objects having arbitrary collections of a lot of very different types of features, it breaks down pretty quickly.

But let's not forget that once you use a component system to build your wide variety of entity types, there's still room to then create small hierarchies of closely related entity types. For instance, you could define a class to represent the skeleton MOB, pulling together all its requisite components. And you could define a handful of different skeleton variations which represent minor alterations like differing initialization values. True, this might not make it into the run-time, and might be happening in a tool, but the point is, even when using component based entities, inheritance isn't obsolete. We just have to use it where it's the best tool.


[quote name='Madhed' timestamp='1320364949' post='4880339']I'm just wondering why there seem to be so many paradigm shifts in game development.[/quote]

Because we've been making games a long time, and their complexity has been continuously changing. The problems with object oriented design are something we had to learn the hard way.
0

Share this post


Link to post
Share on other sites
So my Transformation component (aka Spatial) right now has 4 properties. Naturally this component has two Vector3 coordinates to represent the position and scale. It also contains a quaternion representing the location's rotation in 3D space. The fourth property is my scene graph's node reference. First, is it typical that this type of component would hold a reference to a scene node? I can't rely on my or mesh render components if the entity is a sound and isn't visible, so this makes logical sense to me. Does it to others?

If that is the right approach, then I would expect my mesh component would simply create a child scene node off the node of the transformation and place my entity's mesh attached to that node. Similarly, if I attach a 3rd-person orbiting camera to my player because I he is what I what I want to focus on, then the camera component would chain child nodes off the transformation's scene node too.

The next step would be to consider input. I have a player input component that my input system works with. If I hit the "W" key, this gets mapped to a move forward situation by my player input component. I would think it would then make sense that the player input component would look up the transformation component and call a void setMoveForward(true) method. When the transformation subsystem iterates it's components, it detects the move forward flag, sets the appropriate speed calculation and adjusted the node's position accordingly. Is this a decent approach to this?
0

Share this post


Link to post
Share on other sites
Great discussion you guys have got going here. I recently started looking into component based design as well, and the original variant I've seen doesn't really have subsystems; therefore, the logic seems to be in the components (more akin to the OP's first post). Is that still true of the subsystem variant? Or do the components purely contain data.

For instance, if I wanted to model chess, should the movement logic be in the movement subsystem, or in the components? I see pros and cons for both. If it's all in the subsystem, I imagine the subsystem could conceivably become large and unwieldy, perhaps with giant if then/switch ladders. But on the flip side it's all contained in one place. If the logic is all in the components, then each component is responsible for it's own movement type, but then the code is spread out....
0

Share this post


Link to post
Share on other sites
[quote name='crancran' timestamp='1320375666' post='4880356']is it typical that this type of component would hold a reference to a scene node?
...[snip]...
I would think it would then make sense that the player input component would look up the transformation component and call a void setMoveForward(true) method. [/quote]

These are tough to answer because there is no right approach. Personally, for instance, although I know that scene graphs can be used for other things, I prefer to keep it within the rendering engine, and not let most other systems/components know anything about it. Similarly, I wouldn't want a basic position tracking component/system to deal with locomotion or physics.

But that's just me - based on the degree of specialization and encapsulation I tend to think in terms of. You'd probably get a better answer from someone whose approach is more similar to your own.
0

Share this post


Link to post
Share on other sites
[quote name='moogleii' timestamp='1320570004' post='4881008']
if I wanted to model chess, should the movement logic be in the movement subsystem, or in the components? I see pros and cons for both. If it's all in the subsystem, I imagine the subsystem could conceivably become large and unwieldy, perhaps with giant if then/switch ladders. But on the flip side it's all contained in one place. If the logic is all in the components, then each component is responsible for it's own movement type, but then the code is spread out....[/quote]

We could be talking about the logic for determining legal moves for a given piece, or the code to actually move a piece to a target square. Either way, there's so little data involved in making decisions about how a piece moves that there's hardly any need for a component at all. The only data a component would hold is the type of piece, which would undoubtedly be redundant with information held elsewhere.

If the code were in the component, it might use a virtual function, or some other stored object/function pointer, to select the move code appropriate to the piece. If instead, the decision were handled by logic in a sub-system, it would likely be a single switch statement, dispatching to that same move code. Probably the most complex part of the whole movement system would be the way in which different types of movement might try to share functionality between them.

It seems no more complex to handle this in a sub-system than in a collection of movement component sub-types.

Hypotheticals aside...
[quote name='moogleii' timestamp='1320570004' post='4881008']the logic seems to be in the components. Is that still true of the subsystem variant? Or do the components purely contain data. [/quote]

The idea is that each subsystem provides it's own functionality to entities, and the components are the way in which entities can elect to participate in that functionality. Code may still belong to components, and when it does, the idea is that the sub-system, rather than the entity, should run that code.

[i][b]But that's just a general preference which has potential to lead to more efficient processing, and simpler deterministic processing order, which is not really the point of using components. The main point of using them is to facilitate the definition of a wide variety of entity types which can each utilize an arbitrary selection from a rich set of features.[/b][/i]
1

Share this post


Link to post
Share on other sites
[quote name='VReality' timestamp='1320571852' post='4881011']
[quote name='crancran' timestamp='1320375666' post='4880356']is it typical that this type of component would hold a reference to a scene node?
...[snip]...
I would think it would then make sense that the player input component would look up the transformation component and call a void setMoveForward(true) method. [/quote]
These are tough to answer because there is no right approach. Personally, for instance, although I know that scene graphs can be used for other things, I prefer to keep it within the rendering engine, and not let most other systems/components know anything about it. Similarly, I wouldn't want a basic position tracking component/system to deal with locomotion or physics.

But that's just me - based on the degree of specialization and encapsulation I tend to think in terms of. You'd probably get a better answer from someone whose approach is more similar to your own.
[/quote]


Would you care to share how you would approach locomotion and physics? The entire input/movement/physics debate has been a focus for me these last few days as I have been trying to integrate Bullet. I have come to the conclusion that I my design for these aspects are not well thought out as I would have liked for them to work well together.

As for the scene graph, I would like to keep it self contained, but I honestly struggle with how I can do just that. A lot of it could just be that I have a very flawed way of approaching the design my components and how they integrate with the rendering engine itself. Lets take a 3rd person camera for example, one approach I read was to setup the scene graph so that both the camera and the avatar were both children of the same scene node (position). This way as you moved the avatar (position node), the camera would remain relative. This involved the camera component having 3 scene nodes chained together to deal with the camera's pitch, yaw, and roll separately. I suspect this is wrong and why I am finding a scene graph node pointer in several components.

Lets take a few non-visible elements for a moment. We have a 3d sound that is playing. Wouldn't there be a need to represent this with some form in the scene graph? What about triggers that upon being interacted with fire some logic? Maybe I have this notion of how I have seen other game editors layout all the entities and components in a view of a game map and I'm trying to tie the two together in my mind in a bad way.
0

Share this post


Link to post
Share on other sites
I have been looking over my component structure the past few days and I have began to question my approach. In a number of places, I have always seen it iterated that there is this 1:1 relationship between a component and it's subsystem, but why so?

I have two components, a light source and a mesh. Both of these components make sense to be derived from a render component so they get child scene graph properties that all render components should have; however, the process to go about creating a light versus drawing a mesh are slightly different but the end result is the same and at this point I see nothing beyond the few lines of code of creating the render engine objects to be different between these two.

It would seem in this scenario I could benefit from placing logic inside the component itself either by passing the subsystem as a pointer to the component's update method or during the creation of the component so that it can either 1. perform the creation/update process internally based on it's state or 2. make a function call to the system where the create/update methods exist for lights and meshes.

I understand the benefit of having the subsystem as it relates to the main game loop itself; however I can see why having logic for creating/updating a component's state reside in the component itself, particularly where you may have many derived classes of a particular component type and rather than having separate systems, the same system could manage those grand children components so long as they adhere to a common interface but require either system method calls or to place the logic in the grand children components for state management.

How have others accomplished this?

EDIT:
To add to this, I am also working on the concept of input. I am using OIS (for those who may be familiar) and so my input system class has the necessary callback methods for receiving the buffered keyboard and mouse actions.

The goal is that these events need to be eventually routed to either the PlayerControllerComponent which allows me to control a player by certain actions, the CameraControllerComponent that allows me to control the camera by mouse rotation and button combinations, or to be routed to the GUI system.

This seems to be somewhat game specific in a way rather than generalized correct? What I mean is that the input system is responsible for collecting an input and dispatching it. At that point how it reaches the player controller or the camera controller components are dictated by game logic right, not at the game engine level? By that statement, a simple Game Controller class could listen to the event bus for these events and then drive dispatching the input to the GUI first, waiting for a response. If the GUI doesn't process it, then translate the event into a game key binding action and then dispatch the action to the event bus. This action is what the controllers would respond to. Is that how it typically is handled or a good way?
0

Share this post


Link to post
Share on other sites
cc,

When I said,

[indent=1][quote name='VReality' timestamp='1320344859' post='4880222']If it doesn't make sense to create two subsystems, it probably doesn't make sense to create two component types.[/quote][/indent]

I was only talking about figuring out how to split a single entity's data down into components. I agree with your analysis completely. I see no reason that a single sub-system can't handle multiple component types. A physics system might handle AABB components, and spherical components, and rag-doll skeletal components, etc. And I see no reason that code specific to those component types can't reside in the component objects.


As for input, you'll generally want an abstraction to map input [i][b]control [/b][/i]states and events to game specific input "[i][b]signals[/b][/i]" (e.g., Move_Forward = W is_down or UP_Arrow is_down, Fire1 = Right_Trigger on_press, etc.). On top of that you'll generally need some sort of scheme to group bunches of signals together so you can activate/deactivate them, prioritize them, override them, etc.

I like a system in which entities/components which are interested in input can poll for a given signal, so code that cares about the input gets it when and where it needs it.
0

Share this post


Link to post
Share on other sites
[quote]So I've been working on a simple component based entity system so I can create entities on the fly without have to have extreme levels of inheritance.[/quote]

I'm not sure anyone can write a [b][i]simple[/i][/b] Component-based Entity System. Firstly, there's no standard definition for a component or entity. Secondly, there's a massive amount of grey area between Component communication which also appears to be the most complex aspect behind the approach. Thirdly, its not a programming paradigm in itself and trying to treat it as such complicates matters. Perhaps a Component-Oriented Programming Language would be cool, however, as it stands its just a architectural pattern applicable to high-level modular game entities - imo.

Components are cool for Game Entities. I found myself evolving naturally towards Component-based Entities in writing my umpteenth iteration of a 3D GUI which was the highlight for my Game Engine. In fact, I thought I came up with some revolutionary approach to designing GUIs at the time, only to discover after reading ~20 Threads on GameDev.net and some popular Articles on the net the approach has been adopted by Pros for years :angry:.

With my new found knowledge, I ditched my previous Game Engine design and started building the all new Entity Component-Objects design that adheres to two concepts:

[list=1][*]An Entity is a container defined by its Components![*]Components are Special Purpose Objects that belong to the Game Engine's Subsystems: Rendering, Physics, Audio, Scripting, Input, Networking, Solvers, etc.[/list]
Of course, I have my own definition of components/entities and my own communications system implemented with techniques derived from my previous GUI inter-communication and data modeling. But, I think if you hit the two concepts you're doing good for a basic component system and I'm no expert on the subject as I find myself constantly tweaking the system.

@crancran, I noticed that you're using Ogre and many of the addons that I'm using for my [url="http://glucose.svn.sourceforge.net/viewvc/glucose/Projects/S3GE/S3GE/ReadMe.html"]game engine[/url]. Would you be interested in comparing notes?
1

Share this post


Link to post
Share on other sites
[quote name='T e c h l o r d' timestamp='1321005584' post='4882888']
I'm not sure anyone can write a [b][i]simple[/i][/b] Component-based Entity System. Firstly, there's no standard definition for a component or entity. Secondly, there's a massive amount of grey area between Component communication which also appears to be the most complex aspect behind the approach. Thirdly, its not a programming paradigm in itself and trying to treat it as such complicates matters. Perhaps a Component-Oriented Programming Language would be cool, however, as it stands its just a architectural pattern applicable to high-level modular game entities - imo.
[/quote]

I believe CBE systems are at the core simple, but you have to simply wrap your head around how to approach the project with this design model in mind. A lot of times, some of the biggest hurdles developers face is to what degree do we split functionality into components and how do the various parts of this approach communicate, as you indicated.

I came to the conclusion after reading so many articles, forum threads, and asking others about how they approached a problem that there is absolutely no RIGHT way to use this pattern. I've seen effective uses of this pattern but trying to compare the approaches were likely comparing apples to oranges. The neat thing about so many different approaches is that it gives a fresh new outlook on the pattern every time I find a new way someone approached something, which often takes sheds light on my own hurdles.

Communication for me has probably been one of the hardest aspects of using this pattern. I am still by no means comfortable with my current approach but its a crude, elementary, but working solution that I look at being something I can tune and refine at a later point.


[quote name='T e c h l o r d' timestamp='1321005584' post='4882888']
@crancran, I noticed that you're using Ogre and many of the addons that I'm using for my [url="http://glucose.svn.sourceforge.net/viewvc/glucose/Projects/S3GE/S3GE/ReadMe.html"]game engine[/url]. Would you be interested in comparing notes?[/quote]

Sure thing, I'll send ya a note with contact details.
CC
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0