Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


Basic Component Based Entity


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
68 replies to this topic

#41 VReality   Members   -  Reputation: 436

Like
0Likes
Like

Posted 03 November 2011 - 07:25 PM

Does any one know why the inheritance obsession became so widespread that the new term "component based entity" had to be invented?


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.


I'm just wondering why there seem to be so many paradigm shifts in game development.


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.

Sponsor:

#42 crancran   Members   -  Reputation: 416

Like
0Likes
Like

Posted 03 November 2011 - 09:01 PM

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?

#43 moogleii   Members   -  Reputation: 133

Like
0Likes
Like

Posted 06 November 2011 - 03:00 AM

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

#44 VReality   Members   -  Reputation: 436

Like
0Likes
Like

Posted 06 November 2011 - 03:30 AM

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.


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.

#45 VReality   Members   -  Reputation: 436

Like
1Likes
Like

Posted 06 November 2011 - 04:10 AM

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


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

the logic seems to be in the components. Is that still true of the subsystem variant? Or do the components purely contain data.


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.

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.

#46 crancran   Members   -  Reputation: 416

Like
0Likes
Like

Posted 07 November 2011 - 04:05 PM

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.

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.



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.

#47 crancran   Members   -  Reputation: 416

Like
0Likes
Like

Posted 10 November 2011 - 06:48 AM

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?

#48 VReality   Members   -  Reputation: 436

Like
0Likes
Like

Posted 10 November 2011 - 02:10 PM

cc,

When I said,

If it doesn't make sense to create two subsystems, it probably doesn't make sense to create two component types.


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 control states and events to game specific input "signals" (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.

#49 T e c h l o r d   Members   -  Reputation: 186

Like
1Likes
Like

Posted 11 November 2011 - 03:59 AM

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.


I'm not sure anyone can write a simple 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:

  • 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.
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 game engine. Would you be interested in comparing notes?

#50 crancran   Members   -  Reputation: 416

Like
0Likes
Like

Posted 11 November 2011 - 10:43 AM

I'm not sure anyone can write a simple 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.


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.


@crancran, I noticed that you're using Ogre and many of the addons that I'm using for my game engine. Would you be interested in comparing notes?


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

#51 jaeg   Members   -  Reputation: 165

Like
0Likes
Like

Posted 11 November 2011 - 11:36 AM

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.


This tends to be my problem too. I'm not yet comfortable with my own design skills which is why I created this topic in the first place. I am feeling more comfortable with my current system now than I was before with the help of the people here. Now if my design is actually practical is totally another story. I'll find out soon after I get my entityFactory finished and parsing the levels I've already made.

#52 crancran   Members   -  Reputation: 416

Like
0Likes
Like

Posted 11 November 2011 - 12:58 PM

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.


This tends to be my problem too. I'm not yet comfortable with my own design skills which is why I created this topic in the first place. I am feeling more comfortable with my current system now than I was before with the help of the people here. Now if my design is actually practical is totally another story. I'll find out soon after I get my entityFactory finished and parsing the levels I've already made.


My first pass at my CBES project was using singletons. I knew that wasn't the route I wanted to go long-term, but it made coding much easier and I didn't have to worry about dealing with inter-communication as much. Basically the update() loops on my subsystems would use the singletons to get the components for my entity if they existed, worked a certain way if those components existed, and other ways if they didn't. Was that practical; nope :).

Several iterations ago I decided to rewrite my code and I decided to take a radically different approach to communication. Instead of using singletons and exposing portions of each system to another, I introduced an event mediator class. This class handles all inter-communication between subsystems in the entire framework. Any subsystem can register callback handlers based on specific events they are interested in. Events that are dispatched to the mediator can either be:

1. Queued for delayed delivery either at the next frame or some future time
2. Immediately

The first scenario is more aligned with a typical message loop described in windows or any double dispatch type event handler. I use this mechanic when a situation is reached in code during the current frame where I should impact another subsystem on the next frame. This is for non-critical events along with where I am not interested in getting any form of a response. It's your send it and forget type of trigger.

The second scenario is more like your typical boost signals or libsig++ mechanic where an event/signal is raised and those interested are immediately notified. The benefit of this approach would be where a subsystem reaches a state where it needs to know something immediately. The nature of my event class allows me to dispatch the event and the callback(s) all can modify the event object. When the callback finishes, the subsystem that made the call gets control again and can examine the event object and based on the data collected, proceed accordingly. This has been useful where say my physics engine needs a piece of data from my render engine and some information from my transform component. Rather than dispatching two events, I can create a single event, both subsystems are dispatched in sequence, they add their data to the event object and voila. :)

Again, is my approach ideal, probably not. But it's an interesting concept and likely not something used mainstream, unless someone here comments and tells me otherwise :P.

EDIT: I should also add that my mediator does not use an interface callback handler but instead allows the registering class to provide a class member function as the callback. The mediator essentially invokes those methods with the event object under both scenarios. This avoids the need for virtual methods and allows me to specify specific methods for specific conditions without needing to use switch statements or other conditionals.

Examples:

void OnEntityAddedToScene(CEvent* pEvent); // Render system dispatches this when node is added to scene
void OnMeshLoaded(CEvent* pEvent); // Dispatched by the mesh system when a mesh is loaded and added to a scene node
void OnTransformUpdate(CEvent* pEvent); // Dispatched by my transform system when an entity's position is changed

#53 crancran   Members   -  Reputation: 416

Like
0Likes
Like

Posted 14 November 2011 - 10:51 AM

As I continue to add subsystems and components to my design, I feel there are problems with my approach that is leading to portions of code that should be simple and short appearing to be more bloated/boilerplate coding than I would have expected or even where I suspect separation of concerns is breached. I've decided to hold off on adding any more subsystems and components until I can address the design issues and I hope others can help.

Entities are first created by the entity manager being given a template definition. The template defines the necessary components to create that entity along with the properties to initialize each component of that entity. The entity system looks up the components from the definition in the component factory, gets the pointer to the create method that the component subsystem registered with the factory and invokes that method. The entity id along with the XML definition for that specific component are passed to the create method function pointer so that the subsystem can instantiate the component, initialize it, and add that component to its internal entity<->component map. Once an entity has been created, none of the components know anything about one another. The only thing that is known are the dependencies that a specific component type has for another component and the functionality/attributes that component provides for that entity's instance. For example, our render and physics components wants to know initial position/orientation along with the physics having interest in the rendered mesh's bounding box size and any scale modifiers while my animation system is interested in mesh information so that animation states can be extracted and used.

Each of my subsystems manage two or more lists of components which are based upon the component's state. When components are created by a subsystem, they are added to the active and update lists. My thought was that rather than having the update() method loop over all components in a particular subsystem, I could reduce that cost by only iterating over components which were modified. First, is this good or bad? Secondly, about the initial "wiring up" among components, I don't like the idea of having checks in my update() method to handle lazy-initialization, but maybe this is the norm ??

My current scenario is:
  • Iterate over the updated transforms and create a transform update event. This event when dispatched invokes methods on the render/physics systems to update their components.
  • Iterate over the updated meshes and create a mesh update event. This event when dispatched invokes methods on the physics/animation systems to update their components.
  • Iterate over the updated physics and create the physics component's rigid bodies and add them to the simulation. Then step the simulation.
  • If a collision was detected, a physics update event is fired and the transform system updates components accordingly, marking components as 'updated'
  • Iterate ALL animations and transition states and/or step animation phases.
  • Iterate over the updated renders and create the scene nodes if one does not exist else update scene node's position.
The very first thing that bothers me is how I handle this transform component. I opted to have the transform do a broadcast to the entity with the position/orientation to aid in the setup of any component that may require that information. This allowed for when the position/orientation changed from another component, every component of that entity gets updated on the next game loop. When the player has force applied and physics changes the position, the physics subsystem sends an event that the transform subsystem intercepts, modifies the position and then re-broadcasts the updates to everyone. But this seems a bit redundant on the event system to a degree, but it does allow updates to the position to happen in 1 place and then replicated by the component subsystem to those interested in the changes. Is this the typical approach?

Do others have any suggestions of variant ways to approach this? If code snippets would help, I can certainly provide.

#54 jaeg   Members   -  Reputation: 165

Like
0Likes
Like

Posted 15 November 2011 - 09:00 AM

Is it ok not to have my components inheriting from a component base class? All of my systems deal with their own component type so the never use the base class and it's causing me issues like overloading the init function. Not all of the components need a CSpatial but it seems I have to overload it in the base class first then give each component derived off of it the function just to please my compiler.

#55 crancran   Members   -  Reputation: 416

Like
0Likes
Like

Posted 15 November 2011 - 01:24 PM

Is it ok not to have my components inheriting from a component base class? All of my systems deal with their own component type so the never use the base class and it's causing me issues like overloading the init function. Not all of the components need a CSpatial but it seems I have to overload it in the base class first then give each component derived off of it the function just to please my compiler.


I would suggest they all derive from some base class yes. There are a number of approaches you can take to solve this problem. My suggestion would be to consider having two derived classes from your base component class where one takes the spatial and the other does not. This will give you two types of classes to then base all your components from or you could always base some from the original parent base class if you saw the need. Remember, inheritance isn't bad if used properly :P.

But my approach to initialization was slightly different. My approach is to keep all my behavioral logic in my subsystems and treat my components mainly as data handlers. In my approach, I don't create the components directly but my subsystem does by being provided an entity reference and a list of initialization parameters. The subsystem in turn pulls creates a new component, passing the entity id and component id into the constructor. This will probably turn into a common "init" method soon when I add object pooling to my subsystems. Then the subsystem inspects the initialization parameters and calls the appropriate set methods accordingly. If parameters aren't provided and set during this call, they accept the default values dictated by the subsystem or the component's constructor.

All components typically hold a reference to their entity (whether it be a pointer or the id) and some form of a type identifier (in my case a component id). Rather than duplicate this functionality in all components, place it in a super base class and then reuse it in your hierarchy :P.

EDIT: My rule of thumb is if I have to write something more than once, it gets factored out. If I have conflicts between two objects, common stuff factors out to a base class and I derived two children from that parent :).

#56 jaeg   Members   -  Reputation: 165

Like
0Likes
Like

Posted 16 November 2011 - 08:13 PM

I ended up having to cheat a little when it came to my animation. I ended up tucking my start and end frames into my spatial object and having the render object read it. That way the AI/Behavior components can change them when needed. I'll keep this way until I get my message system capable of sending the data itself. Or is it ok to keep it like it is?

#57 crancran   Members   -  Reputation: 416

Like
0Likes
Like

Posted 16 November 2011 - 08:34 PM

I would definitely remove it because a lot of things have a position/orientation/scale in 3D space but have nothing to do with animation (based on separation of concerns).

Additionally, I do more than just set an animation into motion based on game actions. For example, when my avatar strafes left or right, I actually work with the mesh's bone structure to rotate the head of the character in the direction i am strafing. If the character is strafing while moving forward, I rotate the bottom of the body to face the angled direction while keeping the head facing forward. When the avatar is idle, it periodically switches between 3 variants of idle animation to give the illusion that the character is "real". Also, the "jump" animation is split out into various animations depending upon whether the character jumps from the ground up and back down or jumps off a ledge and free falls to the ground a far distance. So as you see, animation for me is complex and that doesn't even scratch the surface of animations when it comes to in-combat actions, various other game actions like working with trade skills, etc. I simply have the animation system tied into listening for "movement" events and other game action "events" and it fires the appropriate animations based on those. Once you have your event framework up and running, you'll see how easy it is to move that out into it's own little world and that it just sits there and compliments the other systems without them even knowing what it is doing :P.

#58 jaeg   Members   -  Reputation: 165

Like
0Likes
Like

Posted 16 November 2011 - 09:37 PM

Right now I think I have insufficient communication abilities between my components/systems. I need to rethink my messaging system. Especially when it comes to data sending in events. Void pointers to specific data objects does not cut it. Do you do your animation in an animation component or the render component? Also since as you said animations are more complex for you especially your player entity do you have multiple rendering/animation component types?

#59 crancran   Members   -  Reputation: 416

Like
0Likes
Like

Posted 17 November 2011 - 08:14 AM

Right now I think I have insufficient communication abilities between my components/systems. I need to rethink my messaging system. Especially when it comes to data sending in events. Void pointers to specific data objects does not cut it. Do you do your animation in an animation component or the render component? Also since as you said animations are more complex for you especially your player entity do you have multiple rendering/animation component types?


I chose to use a very crude approach in the beginning for messaging because I wanted to not worry too much about how they would communicate but be able to bring together a number of core components and work on the inner workings of their component functionality without being bothered. Void pointers to a defined structure would be fine assuming that you are using some form of a callback functor so that when the function call is invoked by the event framework, you know exactly what to recast that void pointer to with a static cast.


When it comes to the animation system, it exposes a great deal of features via events. So when writing the logic for moving forward in the movement component, it applies a force based on the game's movement speed and time and signals physics. Additionally, the component notifies the animation state to begin playing the walk forward animation. In the case of strafing, I have a special event that allows me to rotate the skeletal structures so I can keep my head forward but adjust the body on direction of movement. What I aim for is that the core component/systems such as animation should not be tied at all to my game but provide functionality that I can leverage while making a game. That allows it to be highly reused.

Another way to handle it would be to create a game specific animation system that listens for game-specific events and then internally works with the core engine's animation system. This way the game itself mirrors that of your engine and allows your engine to be reused in multiple games but allowing you to model your game code similarly and abstract the entire engine's systems into your own :). I have found this helpful in a few places where the engine was so modular that rather than remembering when case A needs to trigger 3 events in the engine, I simply send 1 event in my game code and a game code system receives that and dispatches those 3 events. This probably isn't the "fastest" way but keeps me from duplicating lots of code in various places :).

#60 jaeg   Members   -  Reputation: 165

Like
0Likes
Like

Posted 17 November 2011 - 09:05 AM

So you seem to have kind of a game view system going on then don't you?

So if I'm understanding right your animation system isn't in a component then? For my purposes I'm thinking of making it a component that just listens to events from it's ID.

I'm thinking of changing my event system to use more type specific events inheriting from a base event.
Currently my events look like this:
struct Event
 {
   EventType type;
   EventCategory category;
   void* data;
 };


type and category are large enum lists. When an event is called the dispatcher sends it to the handlers registered to receive specific categories. I'm thinking of changing it so I can get rid of *data and just make more detailed events. Since the handler will know what it is based on the category and type it'll know what to cast it as to get the data from it.

Also I'm thinking I'm not using it as much as I should. Right now it's just used to give the stateManager feedback on the states it controls like if in the menu a button that should make it switch states is pressed. Or in my CGame class (the engine class that controls if the game is running, sets up application stuff, ect) it uses Irrlicht's eventReciever to get keyboard inputs and broadcasts that. I hadn't thought about have entities use it to send that it moved or not.

Also what is a good way to manage the event objects produced? They aren't pointers I make them like this:
     Event event;
        event.type=E_CREDITSSTATE;
        event.category=E_GAME;
        CEventDispatcher::inst()->sendEvent(event);


That sends to the stateManager (who is registered to listen to game events) an event from the menu state to switch to the credit state. Do I need to delete the event after it gets used or will it go out of scope and disappear itself?

The CEventDispatcher calls all of the IEventHandlers->handleEvent(e) functions in the registration list for that particular category. It's up to the handlers to decide if they ignore the event or not.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS