Mob status

[xoft]

Cuberite can generate dungeons, but all the mobspawners in them are pig-spawners. Similarly as with NetherForts and Fortresses, we're missing a few key "technologies" to make spawners generate and work properly.

[LogicParrot]

I am considering refactoring the current mob architecture to avoid reaching a big ball of mud. I believe an inheritence tree is not the best tool for modeling the mobs. Some problems:
- The current code is hard to follow.
- The state system does not cover all use cases and has to be supplanted by flags (isInLove and the like).
- Wolves can't breed, because they do not inherit cPassiveMonster.
- Many mobs have methods/fields they'll never use because cMonster is fat. I believe cMonster is fat because people in the past solved inheritence related problems by moving code upstream. For instance, I can solve the wolf breeding problem by putting the breeding code in cMonster, but then zombies would have more stuff they don't use. For the sake of long term maintainability, I believe the issue should be solved at its core, and the inheritence model should be ditched.

I'm still cooking a solution in my head but here are the initial thoughts: I'm considering a state-machine like architecture, where there's a common state map, but each mobtype has only some of the states enabled (and some states have parameters, e.g. bait type). See attached photo (mutable, likely to change).

With this architecture, each mobtype is defined solely by its enabled state combination and their parameters. (And possibly few exceptions like overriding some transitions between states (e.g. wolf idle > attacking requires sending the angrywolf packet).

[xoft]

We were already discussing this some time ago and we agreed the best architecture for the mobs to be Components:
http://gameprogrammingpatterns.com/component.html
http://ai.eecs.umich.edu/soar/Classes/49...umaker.pdf (unfortunately no longer available, use google cache to read: https://www.google.com/search?q=http://a...umaker.pdf )

Here's a link to the relevant forum thread: https://forum.cuberite.org/showthread.ph...2#pid10912

[LogicParrot]

We were already discussing this some time ago and we agreed the best architecture for the mobs to be Components:
http://gameprogrammingpatterns.com/component.html
http://ai.eecs.umich.edu/soar/Classes/49...umaker.pdf (unfortunately no longer available, use google cache to read: https://www.google.com/search?q=http://a...umaker.pdf )

Here's a link to the relevant forum thread: https://forum.cuberite.org/showthread.ph...2#pid10912

I've always had a terminology confusion here which I hope someone can clear up.

1. The gameprogrammingpatterns.com guide describes "Entity-Component-systems". It talks about splitting entities into components based on *systems* - graphics, physics, logic, etc.

2. The PDF at 49 is similar to what I had in mind. It is titled "Component-based architecture". It deals with a single system (the logic/behavior) and splits *that system* into components. This seems to match what we need.

Are these two patterns the same? They do not look the same to me, but I've never seen an article explicitly distinguishing between them.

In other words, I see a big difference between "component per each system the entity is using(logic, graphics, etc.)" and "component for each behavior/trait the entity has (health, agression, etc.)"

Also, which form are you suggesting we need to use, 1 or 2?

[xoft]

I think the point is in the "splitting", not where exactly that split is - be it in systems or somewhere else. It's just that we want to have as many logically separate parts separated into those components. It's up to us how we define our "components".

I had a slightly different plan for the AI. I was thinking that the AI "component" should give general behavior patterns - such as "zombies pathfind to villagers" and "creepers are afraid of cats"; different AI instances would give different orders. Then those individual orders (we may think of them as components in this sense) do the actual low-level work - pathfind, follow path, attack, etc.

[LogicParrot]

I think the point is in the "splitting", not where exactly that split is - be it in systems or somewhere else. It's just that we want to have as many logically separate parts separated into those components. It's up to us how we define our "components".

If you split it into modules on a behavior level, then "systems" are irrelevant, which means you took the S out of ECS.

[LogicParrot]

Spiders are now friendly in daylight and agressive in darkness.
Wolf AI was improved significantly.

Next up: Refactor and clean mob tree hierarchy.

[Jammet]

I've noticed that spiders sometimes attack even when you have surrounded yourself with cobblestone, even above you. Say you put some in front, behind, to your left and right, leaving open the diagonal spots, they seem to attack diagonally even though you can't see them. One of my buddies also has build a structure they seem to get stuck in, at the moment. I hope I can show you that sometime.

[warmist]

Noticed that your list at the beggining is missing some features. Namely the mob-mob interactions. Like the creepers running away from cats, zombies tracking villagers (other that i forget? maybe there was something with wolfs attacking skeletons/other passive mobs?)

[LogicParrot]

@warmist: Good point. Well, all mob-mob interactions are missing. I should mention that somewhere.