New AI for Mobs

[SamJBarney]

So I've got a basic cComponent class written out on the main repo, in a branch called 'ComponentRewrite'. If anyone wants to contribute anything, please feel free to do so. I have to work today, and probably tomorrow, so I most likely will not get much done on it. If anyone can think of any generic virtual functions that need to be a part of it, please feel free to add them.

[xoft]

I think the cComponent class is wrong. There should be a separate class for each category of behavior. Did you read the link that FakeTruth posted? ( http://ai.eecs.umich.edu/soar/Classes/49...umaker.pdf ) Especially pages 37 to 67.

We should have a cMovementComponent, cAttackComponent, cEnvironmentComponent, cInteractionComponent, cAIComponent etc., each having only those callbacks and data relevant to the category; then we'll subclass each component for the specific behavior: cMovementComponent -> cMovementWalking, cMovementWalkingClimbing, cMovementFlying; cAIPassive, cAIAggressive, cAINone (for pickups etc), cAIPlayer(for cPlayer). Then, a cEntity would comprise of these components:

class cEntity
{
  cMovementComponent * m_Movement;
  cAttackComponent * m_Attack;
  cEnvironmentComponent * m_Environment;
  cInteractionComponent * m_Interaction;
  cAIComponent * m_AI;
}

I'm not exactly sure if cAttackComponent should be part of the entity, or rather of the cAIAggressive subclass, because that's the only one doing any real attacks. Also not sure about splitting environment and interaction, perhaps they should be together.

[SamJBarney]

So you're thinking that these components should not have a base class? I did read the link that he posted.

I think that environmental and interactions should be split for this reason: While environmental and interaction are both reactions, they are reactions to different sources. Interactions happen between entities, and as such are handled by the cInteractionComponent. Whether or not they take damage when exposed to air, water, lava, or any other type of block is determined by the cEnvironmentComponent. By splitting these up, this allows plugin developers another degree of freedom when designing custom mobs for their plugin.

As for cAttackComponent, I think its perfectly valid to have it as part of cEntity. For instance, wolves would have some sort of passive cAIComponent, but when they are struck by a player/mob (Interaction), they then start attacking the player until they are dead or the player is. Because it is a reactionary action, we can't rely on the AI to handle it.

[xoft]

I think the components are there so that they can be swapped at runtime. So a wolf getting attacked would actually swap its AI from cAIPassive to cAIAgressive. Still, it's true that in any case the attack is more useful in the base cEntity, so that we could make wolves that attack by biting and wolfves that shoot arrows, for example.

The components should have a base class, of course, I'm just saying that there should be multiple base classes, each for a specific behavior. A separate base class for the AI component and a separate base class for the interactions.

[SamJBarney]

So you think the inheritance tree should look something like this, right?

• cComponent
  • cAIComponent
    • cAIPassive
      
    • cAIAgressive
      
    • cAIVillager
      
    • cAITame
      
    • etc.
      
  • cMovementComponent
    • cMoveSlime
      
    • cMoveWalk
      
    • cMovePlayer
      
    • cMoveClimber
      
    • cMoveHorse
      
    • cMoveMinecart
      
    • cMoveBoat
      
    • cMoveXp
      
    • etc.
      
  • cEnvironmentComponent
    • cEnvironmentNether
      
    • cEnvironmentOverworld
      
    • cEnvironmentEnd
      
    • etc.
      
  • cInteractionComponent
    • cInteractionVillager
      
    • cInteractionXp
      
    • cInteractionMinecart
      
    • cInteractionBoat
      
    • etc.
      
  • cAttackComponent
    • cArrowAttack
      
    • cThrownAttack
      
    • cPunchAttack
      
    • cBiteAttack
      
    • cJumpAttack
      
    • etc.
      
  • cVisualComponent
    • cVisualMob
      
    • cVisualXp
      
    • cVisualBlock
      
    • cVisualPlayer
      
    • etc.
      
  • cLuaComponent
    

And just so you know, I figure we need the visual component now because we won't be doing just mobs anymore. Each visual component would know how to display itself on the client-side, and contain anything related to collisions.

[xoft]

Almost. There shouldn't be any cComponent base class - each category has its own abstract base class. And the cLuaComponent won't work either, there'll need to be a cAIPlugin, cMovePlugin, cEnvironmentPlugin etc.

[SamJBarney]

Why won't the cLuaComponent work?

[xoft]

Because we don't want a common ancestor for *all* the components. We want specialized components, so that they can be mix-n-matched together. Therefore, there can't be *one* cLuaComponent, but rather a Lua component for each category, implementing only that category's callbacks.

[SamJBarney]

Okay, if you insist.

[xoft]

Well I insist because I haven't received any counter-arguments. If you have any reasons to support your decisions, I want to hear them. By no means I am all-knowing, I do make mistakes, and it's highly likely that I missed some point that could prove substantial.

My basic argument against all-containing cComponent is simple - in order for two entities to share the same movement, but a different AI, the AI and the movement need to be separate classes.