Jump to content
  • Advertisement
Sign in to follow this  
Paragon123

Some pointers please (Entity component systems).

This topic is 2144 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

@beernuts

 Perhaps I am misunderstanding your objection to the function pointers. (I don't mean to harp, I really am only trying to understand your advice). 

Let's wipe the board clean and focus on Entity Behavior.

A particular entity is associated with at least the following components

1) PositionComponent: X,Y position

2) VelocityComponent: X,Y Velocity

3) BehaviorComponent: <Some data structure defining the specific set of logic used make decisions>

 

There exist at least the following Systems

1) MovementSystem: 

       Requires an entity to have a Position and a velocity component. Displaces the current position by a value equal to the velocity component.

2) BehaviorSystem:

      At minimum, sets the entities VelocityComponent based on current entity state.

 

The source of confusion is the statement "A component should not contain a function pointer."

However, it must contain some data which defines behavior.

 

It has occurred to me that you might be saying that a function pointer is simply too "low level" to be considered a valid piece of data for a component to care about. A function pointer in a BehaviorComponent may indicate something along the lines of

[BehaviorComponent.cs]
behaviorComponent{
  functionPointer behaviorFunc;
}

[BehaviorSystem.cs]
...
   funcPtr = Entity.GetBehaviorComponent.behaviorFunc;
  funcPtr(Entity);
...

[Anywhere.cs]
function doRandomBehavior(Entity){
   Entity.SetVelocityComponent(getRandomNumber(), getRandomNumber())
}

[Initilize.cs]
Entity e=new Entity()
e.AddComponent(behaviorComponent(doRandomBehavior))

Are you instead proposing something along the lines of

[BehaviorComponent.cs]
behaviorComponent{
  String behaviorType;
}

[BehaviorSystem.cs]
   function doRandomBehavior(Entity){
      Entity.SetVelocityComponent(getRandomNumber(), getRandomNumber())
   }

   map<String, FunctionPtr> behaviours;
   behaviours["Random"] = doRandomBehavior   
   

...
   functionptr func = behaviors[Entity.GetBehaviorComponent.behaviorType]
   func(Entity);
...

[Initilize.cs]
Entity e=new Entity()
e.AddComponent(behaviorComponent("Random"))

Thus, ensuring that the the behaviour system controls where the behaviour specific logic lives and not forcing the component to decide that? 

And are you recommending this because storing a String in external storage is less error prone and more conventional and easier to understand then attempting to somehow store a function pointer, even though the end result is similiar, you just mention this because it is cleaner? 

 

Share this post


Link to post
Share on other sites
Advertisement

@Paragon123

 

If you choose to go this route (ie, having a BehaviorComponent, and inside it, it defines different behaviors), then, OK, I suppose having a Function Pointer in a component could be considered a shortcut to using a data field to determine a specific behavior.  It just seems to bend the entity-component principles I try to adhere to, but, looking at it from a different angle, I think it would probably be a fine solution.

 

However, please also consider using different component types to define the Component, ie BehaviorZigZagComponent and BehaviorRandomComponent, and having two separate Systems, ZigZagSystem and RandomSystem.  In this case, no function pointer are required, and the Entity-Component framework will handle everything for you. 

 

I don't have enough experience with ECS's to tell you which might be better, nor do I know the scope of your project to decide which might be better, but I just wanted you to realize this other option exists.

Edited by BeerNutts

Share this post


Link to post
Share on other sites

One issue with having function pointers in Components is that it makes it much harder to serialize them (e.g. to save game state).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!