New AI for Mobs

[xoft]

Hmm, how difficult would it be for *all* entities to be "componentized", by putting the components into the cEntity object, and cPlayer still inheriting from cEntity? That just might work. The movement and AI and all other components will then need a special "client-controlled" component.

[SamJBarney]

Off hand, I don't think it would be any more difficult. We would just be going one step backwards on the inheritance tree.

[xoft]

We'll need more components, though - cPickup, cProjectileEntity etc.
Just for making a clearer picture, here's the inheritance diagram I created a few months ago:

[SamJBarney]

I think that the hardest thing will be the generalization of the code. If you think about it, all of these have a specific movement type, and logic to handle how they react to the environment, etc., etc..

I'm not too familiar with anything not under cMonster. Xoft, what more component types are you thinking of?

[xoft]

I meant specific component classes, not actual component classes.
For example, the cFallingBlock needs a unique interaction with the world - when it hits a solid block, it either reintegrates as a block or drops as a cPickup. The cPickup needs a unique interaction with pawns - it can be picked up by them (this might be useful, though, as cExpOrb uses the same code for collection)

I think it might be best to componentize cPawn for now (and keep the cPlayer descendant), and if we ever want to componentize anything more, we'll move it "under" the cPawn.

[SamJBarney]

I dunno; to me it seems that it would be just as easy to componentize cEntity as cPawn. We might as well do the entire system instead of part of it with a chance of doing the rest in the future. I've been looking at the code, and cPawn doesn't really do much. We might as well get rid of it along with cAgressiveMonster and the rest.

If anything, we could just check to see if the entity can take the pickup or the exp orb. It wouldn't be that hard. We would just add a virtual function in the cComponent class that can be overwritten to determine whether or not it can accept the pickup/exp, and if it can to do so. Something like 'OnPickup'.

---

Well, if we want to move to cPawn, we can just change which one we are using. I've opened a branch and started just some very basic coding. If anyone can think of any virtual hooks that need to be implemented, please feel free to add to it.

[Taugeshtu]

Projecting components system over all entities have one nice bonus I can see this far already: we can easily make hopers or what-are-they-called thingies that suck items. Also, hoper minecarts, and item droppers, and all sort of crazy stuff.

Though I'm a bit concerned about xoft's notion of building stuff out of components during compile time... Are you sure guys this can't be done let's say during server init in a reasonable (perfomance-wise and complexity-wise) manner?

[SamJBarney]

I thought that was one of the reasons we were considering moving to a component system, so that we could define which components to use at run-time. At least that was what I thought we were going to implement.

[Taugeshtu]

Maybe I just misunderstoor xoft?

[xoft]

Yes, the components can (and will) be swapped at runtime. Don't worry, Taugeshtu, it has minimal performance or complexity issues. I had some thoughts about mixing multiple "behaviours" (the instance that we'll put into the component "slots") together to make a composite behavior, this could be done in runtime as well, quite simply.