Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualHodgman

Posted 26 August 2012 - 06:35 AM

public void addComponent(Component Receiving, Component Attaching)
{
......
	if(Receiving.has(RidingComponent)
	   if(Attaching.is(CharacterComponent)
		   RidingComponent.addComponent(Attaching, type CharacterComponenet);
.........
}

I personally group "component/entity" designs into two categories -- those that try and perform "magic" linking of components to each other, and those that require the entity creator to manually connect components to each other.
class MyEntity
{
  ComponentA a = new ComponentA();
  ComponentB b = new ComponentB();
  ComponentC c = new ComponentC();
  void Init_1()
  {
	a.InspectParentToPerformMagicLinking( this );//uses reflection to look at my members
	b.InspectParentToPerformMagicLinking( this );//  to automatically make any required connections
	c.InspectParentToPerformMagicLinking( this );//  without my explicit knowledge of how this works
  }
  void Init_2()
  {
	a.ExplictlyLinkYouToC( c );//I, the entity author, know that A needs a C.
	b.ExplicitlyLinkYouToA( a );//  and that B needs an A.
  }
};
IMHO, the first option violates too much of my deeply ingrained engineering intuition to be considered. Explicitly plugging things in seems superior in almost every way to me... Ideally these explicit links, and the entity data-structures themselves should be loaded from data/scripts, but can be hard-coded as above.

Also I'm having trouble with how I will differentiate between entities, such as player and AI or vehicle and person.

If you need to differentiate between them, don't put them all in some generic collection (also don't inherit them from a common base if they don't need it). Am I right in paraphrasing that this is the same as: "I've inherited vastly different classes from a common base, but now I can't use them for different purposes"? If so, it's the same flaw that entity inheritance-trees had.
Put vehicles in a vehicle-list, and players in a player-list, if needed.

we should make the entities only have a reference to the generic Component class

I've seen designs such as this, but IMHO it's a harmful idea. Imagine replacing all of your floats, ints, Arrays, etc, with object... and then having to use casts absolutely everywhere. It defeats the purpose of having a type system.

If it is hardcoded, then the vehicle will be able to directly manage the characters' updates. What I have in mind is, that when a character is added to a vehicle, the player's control, or that of the AI is stripped, and given to the vehicle, which in turn has a controller, player or AI. I would have addCharacter() method in the vehicle entity or in the Riding component which will do what I just described

N.B. as well as "hard-coding" these kinds of specific relationships in your C++/C#/Java etc codebase, it can also be "soft-coded" in your scripting language or data files. IMHO, this is much better than creating an over-engineered framework.

#2Hodgman

Posted 26 August 2012 - 06:31 AM

public void addComponent(Component Receiving, Component Attaching)
{
......
	if(Receiving.has(RidingComponent)
	   if(Attaching.is(CharacterComponent)
		   RidingComponent.addComponent(Attaching, type CharacterComponenet);
.........
}

I personally group "component/entity" designs into two categories -- those that try and perform "magic" linking of components to each other, and those that require the entity creator to manually connect components to each other.
class MyEntity
{
  ComponentA a = new ComponentA();
  ComponentB b = new ComponentB();
  ComponentC c = new ComponentC();
  void Init_1()
  {
	a.InspectParentToPerformMagicLinking( this );//uses reflection to look at my members
	b.InspectParentToPerformMagicLinking( this );//  to automatically make any required connections
	c.InspectParentToPerformMagicLinking( this );//  without my explicit knowledge of how this works
  }
  void Init_2()
  {
	a.ExplictlyLinkYouToC( c );//I, the entity author, know that A needs a C.
	b.ExplicitlyLinkYouToA( a );//  and that B needs an A.
  }
};

Also I'm having trouble with how I will differentiate between entities, such as player and AI or vehicle and person.

If you need to differentiate between them, don't put them all in some generic collection (also don't inherit them from a common base if they don't need it). Am I right in paraphrasing that this is the same as: "I've inherited vastly different classes from a common base, but now I can't use them for different purposes"? If so, it's the same flaw that entity inheritance-trees had.
Put vehicles in a vehicle-list, and players in a player-list, if needed.

we should make the entities only have a reference to the generic Component class

I've seen designs such as this, but IMHO it's a harmful idea. Imagine replacing all of your floats, ints, Arrays, etc, with object... and then having to use casts absolutely everywhere. It defeats the purpose of having a type system.

If it is hardcoded, then the vehicle will be able to directly manage the characters' updates. What I have in mind is, that when a character is added to a vehicle, the player's control, or that of the AI is stripped, and given to the vehicle, which in turn has a controller, player or AI. I would have addCharacter() method in the vehicle entity or in the Riding component which will do what I just described

N.B. as well as "hard-coding" these kinds of specific relationships in your C++/C#/Java etc codebase, it can also be "soft-coded" in your scripting language or data files. IMHO, this is much better than creating an over-engineered framework.

#1Hodgman

Posted 26 August 2012 - 06:28 AM

public void addComponent(Component Receiving, Component Attaching)
{
......
	if(Receiving.has(RidingComponent)
	   if(Attaching.is(CharacterComponent)
		   RidingComponent.addComponent(Attaching, type CharacterComponenet);
.........
}

I personally group "component/entity" designs into two categories -- those that try and perform "magic" linking of components to each other, and those that require the entity creator to manually connect components to each other.
class MyEntity
{
  ComponentA a = new ComponentA();
  ComponentB b = new ComponentB();
  ComponentC c = new ComponentC();
  void Init_1()
  {
    a.InspectParentToPerformMagicLinking( this );//uses reflection to look at my members
    b.InspectParentToPerformMagicLinking( this );//  to automatically make any required connections
    c.InspectParentToPerformMagicLinking( this );//  without my explicit knowledge of how this works
  }
  void Init_2()
  {
    a.ExplictlyLinkYouToC( c );//I, the entity author, know that A needs a C.
    b.ExplicitlyLinkYouToA( a );//  and that B needs an A.
  }
};

Also I'm having trouble with how I will differentiate between entities, such as player and AI or vehicle and person.

If you need to differentiate between them, don't put them all in some generic collection (also don't inherit them from a common base if they don't need it). Am I right in paraphrasing that this is the same as: "I've inherited vastly different classes from a common base, but now I can't use them for different purposes"?
Put vehicles in a vehicle-list, and players in a player-list.

we should make the entities only have a reference to the generic Component class

I've seen designs such as this, but IMHO it's a harmful idea. Imagine replacing all of your floats, ints, Arrays, etc, with object... and then having to use casts absolutely everywhere. It defeats the purpose of having a type system.

If it is hardcoded, then the vehicle will be able to directly manage the characters' updates. What I have in mind is, that when a character is added to a vehicle, the player's control, or that of the AI is stripped, and given to the vehicle, which in turn has a controller, player or AI. I would have addCharacter() method in the vehicle entity or in the Riding component which will do what I just described

N.B. as well as "hard-coding" these kinds of specific relationships in your C++/C#/Java etc codebase, it can also be "soft-coded" in your scripting language or data files. IMHO, this is much better than creating an over-engineered framework.

PARTNERS