All entities should be constructed of components

[SamJBarney]

I know this is an idea that I have talked about on the forum, but I think I should move it here just temporarily so that it can be looked at without getting cluttered down.

Another reason is that before I would get started on this, I would ask that ALL changes being made to any type of entity be put on hold until the rewrite is completed to avoid merge conflicts. That is what happened last time that I started on it, and I do not want it to happen again.

Proposal

ALL entities should be constructed from discrete components which define the entity as a whole. These components should be separated into the following categories:

• Movement - Defines how the entity moves, if at all
• Attack - Defines how the entity attacks targets
• Physical - Handles collision detection
• AI - Handles how the entity reacts to being interacted with, along with how the AI acts in general.
• Environmental - Handles how the entity reacts to the environment, such as items being destroyed when they hit a cactus.
• System - Handles packet creation for letting the client know that the entity was spawned. Ex: Mob spawning is different than exp spawning

Along with that, each type of component provides a Lua interface to allow for custom components to be defined within Lua plugins.

Each vanilla mob will have default components defined in the settings file for MCServer that can be adjusted.

This change should allow for a greater flexibility for MCServer without compromising speed, and allow us to get a good, solid AI in place that is extensible.

I really would like to get this done soon. Please let me know if my conditions at the top of this are acceptable.

[tigerw]

Eh, I think this is too complicated.

Say you wanted to have interchangeable attack methods for mobs.

1. Have a config option in monsters.ini for AttackMethod=
2. Have the string parsed into a AttackMethod enum and have the m_AttackMethod variable set
3. In cMonster::Tick() where Attack(a_Dt); is called, add:

switch (m_AttackMethod)
{
    case amCreeper: cCreeper::Attack(a_Dt, ...);
    case amZombie: cZombie::Attack(a_Dt, ...);
}

Etcetera for anything else.

---

For the merge conflicts, why not do work on a branch, and bring it up to date when finished? Work on this may take some time, and wouldn't it be somewhat inefficient if all work on entities were stopped in the meantime?

[jfhumann]

You could use the Strategy Design Pattern to implement attack behavior,
etc. You wouldn't need any switch/case blocks when calling the
functionality that way. Of course you still have to parse the config file,
but actually I think it's doable.

[madmaxoft]

@tigerw actually the component design is less complicated and more flexible. I like it more than using hierarchy for the entire mobs. The point is that we drop the individual mob classes altogether and the cMonster (cMob) class will be the top-level; advantage to this is that Lua doesn't need that many exported classes, it will do perfectly with a cMob export.

However, I'm not sure about all of those components. I think the Physical and Movement are too tied together - for any movement you need the dimensions, collision checking and pathfinding. And the System is useless in our multi-protocol-version scheme, it is already handled in the protocol classes. It would make sense, however, to unify the protocols so that there aren't separate SendSpawnMob, SendSpawnObject and SendSpawnVehicle functions, but rather a single function SendSpawnEntity that decides on its own what packet to send, based on the entity type (some entities may move between categories in various protocol versions).

[madmaxoft]

Also, the AI and the attack are quite tied together, the AI needs to know what the attack is, whether ranged or melee, so that it moves the mob accordingly

[SamJBarney]

So lets say someone wanted to create a mob from a forge mod? How would we want to handle the spawning of it?

[madmaxoft]

True, there's no way to spawn the custom mob on clients; but then, how do we provide a protocol-specific spawning method? The plugins don't go as deep as the protocol level, and I'm not sure we want them to, with all the protocol changes.

I suppose it would be possible to make a "custom mob" category that would let the plugins include some additional data with the mob, such as the protocol entity type; and make all this possible.

[SamJBarney]

Or we could just make two components. One that handles normal spawning, one that handles custom spawning.

[madmaxoft]

And how would the custom one spawn, when the spawning packets are very different for each protocol? I want to keep the protocol-related differences inside the cProtocol descendants, not pull them out into other classes.

[SamJBarney]

So do I have a "go" to do this? Is everyone alright with it?

[SamJBarney]

Oh, Xoft! I just realized that you were talking about just mobs. This rewrite is for ALL entities (minecarts, mobs, etc.), not just mobs.

[SamJBarney]

Or do you believe that would be too much of a hassle to competely rework? If so, I can just limit myself to cPawns and below, and do the entire entity part later

[SamJBarney]

You know, I'm just going to work on cPawn and below. That ok?

[madmaxoft]

I think that doing all this in one go is suicidal. Therefore I intended to do this incrementally - first componentize the mobs' physics, then their AI, then perhaps extend the physics down from cMonster to cPawn, etc. Doing this incrementally will make it easier to merge the changes more often, with less conflicts and more testing in between.

[SamJBarney]

Alrighty. Will do.

[sphinxc0re]

Any updates on this one?

[SafwatHalaby]

Is this still relevant with the new AI?

[sphinxc0re]

It might be

[worktycho]

I think its something we should do, but not as a complete rewrite. Just refactors here and there, when working on the methods for other reasons.

[SafwatHalaby]

Yes, a complete rewrite feels like overkill to me.