Mobs

[MarkuBu]

What are the requirements for mobs that they can be added to MTG?

I will list a few attributes I have in mind:

• Hostile and friendly mobs
• Hostile mobs should attack in different ways (melee, range, jump...). Most mobs (dirt, sand, oerkki) are just variations of a zombie
• Friendly mobs should spawn only on map generation and maybe very rarely later. I played a game with mobs redo and I just killed cows around my spawn point for 3 ingame days and I had enough leather for 3 full armors and enough food for weeks
• Mobs should be able to look at the player like in Minecraft. This makes hostile mobs more aggressive and friendly mobs look cute. And it gives the mobs more character
• Mobs should move and rotate smooth. All current mob API rotate the mobs immediately. That looks odd
• Animals spawn by noise. So animals spawn at the same position if the same seed is used for a new map
• Spawning of animals depends on biomes (biome list)
• mob settings should be stored for each world
• Mobs should be optional in MTGame and contained within a single mod to help subgame creators.

Mob types

• passive (insects, fish, birds)
• farm animals (can be tamed, breed)
• counter attack (passive until attacked)
• hostile (attack immediately)

Movement types:

• walking/running
• swimming
• climbing ladders
• climbing walls (e.g. spiders)
• flying
• follow target

Attack types

• melee (armed/unarmed)
• range (bow/throwing/spell casting)
• jump
• explode

More suggestions?

[tobyplowy]

@MarkuBu something I really want is good player tracking now mobs seem to move cube by cube but why do they actually not go straight to you?

Better ai for not dying (now they just walk of clifs and in lava and fire and that is stupid)

[C1ffisme]

Mobs such as cows or sheep should spawn in herds, not alone and purely randomly.

Hitboxes for the animals shouldn't be solid walls, instead you should be able to push animals around.

Mobs need to detect any, and I mean any, damage that the player would recieve from a certain action, whether it be drowning, falling off cliffs, lava, fire, or anything added by mods, such as effects.

Mobs should have knockback, and other feedback from being hit.

Friendly Mobs (and maybe hostile ones) should support baby versions, as well as breeding. This doesn't really have to be part of the API, but it would be helpful at the very least.

Also, entities should be made more cost effective, so I can cram hundreds of cows in a chunk if I wanted.

[MarkuBu]

Hitboxes for the animals shouldn't be solid walls, instead you should be able to push animals around

I made a suggestion because of this. on_collision callbacks will help a lot

5458

[paramat]

• Mobs should be optional in MTGame and contained within a single mod to help subgame creators.

[MarkuBu]

What type of mobs and how many mobs? Should hostile mobs be realistic (wolf, bear..) or fantasy?

[tobyplowy]

What type of mobs and how many mobs? Should hostile mobs be realistic (wolf, bear..) or fantasy?

For minetest game I Would say some Basic farm Animals (cow, pig, sheep, maybe horse for transportation and a goat because they are cool) and for monsters I would say (orki and dungoen master)

Hitboxes for the animals shouldn't be solid walls, instead you should be able to push animals around.

Mobs should have knockback, and other feedback from being hit.

Those are 2 good ideas!

[MarkuBu]

contained within a single mod to help subgame creators

@paramat why a single mod? How does it help subgame creators?

Oh, and btw:

• mob settings should be stored for each world

I'm adding more informations to the first post

[ghost]

We currently have nearly a dozen incompatible 3rd party mob APIs implemented via mods. This should be ended.

I'm absolutely fine with mobs being a mod. But all the AI and mob-related functionality (walking, running, climbing, friendly/hostile, spawn behavior, targeting, attacking, pathfinding etc.) should be done in C++ for best performance and consistent behavior.

[MarkuBu]

I only agree partially. There are many things that should be done in C++

But for example the "AI" should be part of the mob. It doesn't makes sense to define a common behaviour for all mobs

What we need is a better pathfinder. Someone already worked on a new version, but this was never finished

I opened an issue for a collision callback for entities, but I'm afraid it will take years until this is added

[MarkuBu]

Maybe we have a lot of mob API's, but I think they all have the same problem (at least the API's I know)

They all define one global on_step routine and each mob has to run all the checks, if it is needed or not. That makes it easy to add new mobs (just edit some values from a template), but it will cost computation time.

Lazy coding always cost computation time

mobs_redo for example checks in every loop for fall damage, breeding and many more. Flying or swimming mobs don't need to check for fall damage, hostile mobs normally don't breed and so on

[ghost]

It doesn't makes sense to define a common behaviour for all mobs

Not a behavior, but general functionality. Instead of re-implementing the same things over and over again in each of the mob mods there should be a set of standard actions (as said: walking, running, friend/foe status, pathfinding, attack status/triggers, etc.) that all mobs can use.

What is used and when - yes - this depends on the mob that the mod is going to add to the game. So instead of coding a compluicated attack function mob mod authors can simply use if mob.being_attacked_by(player) then mob.attack(player) end or somehing like that (where mob is the mob where to code is attached to).

[MarkuBu]

What we need to implement in C++ are things like callbacks that we don't need to check everything again and again.

What we need to implement in C++ are "senses". If we want to make mobs smarter they need more information about their environment.

[raymoo]

Pathfinding smoothing: mobs should try to minimize the number of turn they make, and turns should not be sudden. The ability to extend attacks with custom functionality (I.e. with callbacks). Animation blending. Avoidance of dangerous nodes.

I think the navigation ones might be doable in just Lua if the engine removed redundant path nodes (something attempted in the past but with bad results, I think).

[C1ffisme]

Add another mob type: ambient.

Things like rats, bats, birds, insects, etc. should be doable, but in such a way that they tax hardware as little as possible.

[ghost]

Add another mob type: ambient.

Maybe something like ambient-only mob-like things you can see but you can't interact with. like birds far up in the sky (just the shadow of the birds and if you climb up they fly away so you'll never reach them). Or tiny flies (only visible as single dots) in caves or forests where single rays of sunlight are shine through.

[paramat]

Sorry i don't necessarily mean 1 mod, but the mob mods should be separate mods added to MTGame, because this division into mods has been requested.

[C1ffisme]

@dsohler

Maybe something like ambient-only mob-like things you can see but you can't interact with. like birds far up in the sky (just the shadow of the birds and if you climb up they fly away so you'll never reach them). Or tiny flies (only visible as single dots) in caves or forests where single rays of sunlight are shine through.

That's possible, although I was thinking a bit more towards the bat mob from Minecraft, but more optomized. (And possibly less annoying.)

[ghost]

Sorry i don't necessarily mean 1 mod, but the mob mods should be separate mods added to MTGame, [...]

Yes, it should be as modular as possible. MT provides a solid feature-rich API for controlling the mobs, pathfinding, breeding, attack functions, etc. and the mods add the actual mobs and the "AI" (when to attack, when to breed, when to do this-or-that) to the game without having to re-implement the base features all the time.

[MisterXtreme]

OK, so on the question of mobs, it depends. Do we want MT game to be a bit realstic, then I'd say for peaceful have Cows, chickens, pigs, horses, and some other things that seem to have escaped my brain, and bears, sharks, pumas, jaguars, etc for hostile. And some sort of breeding mechanic involving wolves to get dogs, as just taming a wolf doesn't make much sense On the other hand, if we want MT game to be a bit more fantasy like (sounds cooler to me), I'd suggest the above, and the Dungeon master, as for the oerki, I never understood what it actually was/should do, and some cool "creatures" like golems.

[C1ffisme]

A lot of people are talking about what mobs to include. I think this is a bit out-of-order thinking here. Why don't we figure out an API before we attempt to add creatures in at random?

(Also, I feel as if we have too many of the same animal suggestions in the comments. E.G. "Cows, chickens, pigs, sheep" for passive mobs and "oreki, dungeon masters" for aggressive mobs. Not that I mean to offend anyone, but can we at least think of something that hasn't been done before? Maybe the aliens from which mese originated?)

[MarkuBu]

Realistic hostile animals have zwo big problems: non of them spawns in caves and they don't despawn by day

But as C1ffisme says: this is an API discussion

[ghost]

Do we want MT game to be a bit realstic, [or do] we want MT game to be a bit more fantasy[?]

Depends on your intention. You can select a futuristic texture pack and add mods adding futuristic items and BAM you now have a world set far in the future. Or on the moon, or on Mars. Or set it up to be in a postapocalyptic world using a subgame for that.

Realistic or fantasy (or futuristic, or science fiction, or real world, or post-apocalyptic, or ..., ...) completely depends on what you want.

Neither Minetest or Minetest Game should force one or another direction. Minetest should simply provide a genera API for controlling mobs in a sane way without needing to re-code basic features all the time. Minetest Game (and all other subgames and mods) should then have simple access to that API being able to add mobs as they want to have them.

[tl;dr] Don't add mobs to Minetest, add an API and have mobs be mods.

[MarkuBu]

Don't add mobs to Minetest, add an API and have mobs be mods.

That's the plan

[tobyplowy]

@MarkuBu sorry for the useless comment but are you going to make the API just a question

Know that if you don't the mob API will not be added any time soon

[MarkuBu]

I can only make a proof of concept because I'm not good enough in C++, but it is necessary to write some functions in C++

What I want to do is to define a standard for mobs and I want to write a proof of concept in Lua, but parts of it needs to be ported to C++ for better performance

[tobyplowy]

@MarkuBu ah I see I'm sure if you release the proof of concept that some other people will start helping you improve it :) Now let's get back on topic :)

[MisterXtreme]

I've used blockmen's (now abandonded, but could probably be re-continued) CME mob mod, and I've heard Open AI is also a good mobs mod.

[raymoo]

What happened to sofar's mob thing?

[paramat]

Yes sofar is the mob expert in MTG. He's working on his own subgame i think which i guess will have his mobs. One that is released we could possibly look at that code to help code mobs for MTG, if he doesn't do that himself.

[sofar]

I've not commented in this thread because it's mostly a rehash of what was said in different threads, and very little usable extra information is added.

As I've posted before, the problem is really that all existing mob mods out there are not engines or frameworks, but more "template" mods. And as soon as someone comes up with a question that is in the form of "but can we also make it do X", the answer from the mod maintainer is "I've copied the code and made this tweak to mob X".

This isn't scalable. This isn't maintainable. It's just terrible design. And it won't ever work reliably for all monsters. Each monster ends up being 100% hand crafted code. I can't see a design like that ever being part of minetest_game.

This is why I set out to prototype a completely different design, and set some rules:

1 - zero code mobs 2 - completely scriptable mobs

What I mean by this I'll try to explain:

1 - zero code mobs

The idea here is to detach code from mobs entirely. If you write some useful code for a mob, then other mobs should be able to use the exact same code to do the same actions. There should never be two pieces of code that are largely the same.

Second, as long as there is private code for a mob, we have little control over when the code executes and what influences it. So we need to detach this as well. So mobs should become event driven, and the code that handles the events should be generic and fit as many mobs as possible.

2 - completely scriptable mobs

What we do not want is to hard-code behavior changes. Hard coded behavior changes mean that events are happening and being processed without any way to influence these events. Hard coded event handling means we can't change the behavior without editing code, and this is bad because what if we need to change the behavior of 100 different monsters? We'd be changing hundreds of sections of code.

(a good example of hard coded behavior is the mobs_redo cow - it can be milked irregardless of whether you whacked it with a sword first. You'd think a cow that is fleeing away from an attacker would be really hard to milk, but no, the mobs_redo cow can be milked at all time, no matter what)

--

So instead, we should create a mob engine that can handle any event, and allow any code to handle those events for any mob, including ignoring certain events when needed.

To implement this, I wrote a mob engine called entity_ai (the name is misleading, I know) that does the following:

1) implement a mechanism to declare states, and state transitions

Each mob is defined as a state table. In the state table you define all states the monster can be in (array format).

For example, a hypothetical sheep can have the following states: "eating", "idle", "randomly wander about", "flee from attacker", "find food", and "die"

To define when the sheep goes from one state to another, we can define "events". These events cause the sheep to go from "eating" to "idle", from "find food" to "eating", from "eating" to "flee from attacker", etc.

2) implement flexible event handling

Each state allows specific events to happen, and the sheep to transition to a different state based on a factor (the term used)

Events are simple conditions: "damage from attacker", or "damage from environment" or "walked around for 15 seconds" or "health changed to 0".

Now we can connect the states using these events:

["eating state"] = {
    factors = {
        { event = "damage from attacher", new_state = "flee from attacker" },
        { event = "full from eating", new_state = "idle" },

Now, important is to note that the factors can store data into the mob's state, so that each code bit can discover and use bits of data that a factor has left behind. This allows the sheep to flee from the player who hit it, and not another player.

factors are also optional. If a state has no factors, it won't ever transition to another state. (The exception is the death event, of course.)

3) Each state can have a custom driver

The driver object determines what the mob does in each state. It selects the pathfinder algorithm (find a specific node, find a specific player, something else) and selects the movement algorithm to execute the movement (swim, fly, walk, etc.) and the engine does all the hard work, including changing the animations, making sounds, etc..

4) all of this is pluggable and extensible

no code is specific to mobs. Each of the functions can be inserted into any mobs' state and configured to run. If someone writes a driver to make a monster do air flips, every mob can make air flips as long as they insert the new driver into one of the states.

any new factor can leave information in a structured way for the driver code to pick up. If some new driver and factor can handle some new event with better data, the only thing needed would be to upgrade the state diagram to include the new driver and factor. There would be no coding involved.

And since the state model is unlimited, you could even make mobs open doors (find_door finder, walk_to_door driver using walk_on_land movement algorithm, then when_near_door use open_door driver to interact with the door, then use door_opened_ok event or door_locked event to proceed to walk_through_door state or shout_angrily_at_locked_door state). Or you could make a mob that trades with a player, or you could make mob that .... (insert behavior you want it to do)...

And, nothing prevents any driver to change fundamental properties of the monster. You could make a state "grow" the monster when an event "was_fed_cookie" happened, and the monster could grow and grow and grow. The only thing needed would be (1) a grow driver that increases the monster size, (2) a factor "was_fed_cookie" to make the monster go into "grow" state, and then hooking that event up to different states (e.g. idle state or walking_around state)

5) everyone can skin and re-model mobs and make new ones

Now that there's no coding involved unless you are adding new behavior, you can re-use and create new monsters without writing a line of code.

Please take a look at the "sheep" in entity_ai to see how this looks in reality:

https://github.com/sofar/entity_ai/blob/master/sheep.lua

---

All of this is IMHO the solution to all the different mob engines: A design like this allows us to take the best parts of all the existing mob frameworks and insert them as reusable pieces (dynamically, even) into the existing mobs.

Now it's no longer guessing what happens - the state diagram clearly defines everything that a mob can do. Now you know exactly what driver was the problem and where this driver code came from (whether it was a special bit of code from the "banana" mob or the default engine "flee_from_attacker" code).

We can also re-use existing decorations easily. The model allows all the animations and visual properties to be simply defined and reused.

Simple mobs can be single-state, even. Nothing says you need to implement any state transitions, although a "death" state is recommended to handle the default "death" that is present by default.

Mobs can bring their own custom code and register new bits of code, or use the library of default drivers, factors, pathfinding algorithms.

---

The way forward.

The entity_ai code is far from complete. While the sheep acts pretty nicely by itself, it doesn't drop any items if you kill it (no item_drop driver is implemented) and it doesn't breed yet (no breeding factor/driver code bits are present). But, you can already spawn sheep and they'll behave nicely and scripted like you see in the videos I posted.

There is also a stone monster that is 50% driver ready and has completely new animations that is ready to be "drivered" and has the standard roaming about code.

However, the engine part is mostly complete. New drivers, factors and pathfinders can be easily added by mods, and writing a state diagram and adding animations is fairly simple.

Mob spawning is not implemented in this code. I envision a completely different spawning mod taking care of spawning mobs, because we may have completely different ways of spawning mobs. For instance, farm animals need to be consistent and always re-spawn. But monsters should despawn after a while and just be forgotten - we'll spawn new ones when needed. So you already need 2 completely different spawning algorithms, and so, for that reason, I've not implemented any spawning yet. (entity_ai does implement loading/saving in mapchunks, of course).

I've also envisioned a 100% mob persistency algorithm that I've never coded up. Subgames may want to spawn named mobs on their map and always keep them around. They may also make them "virtually" move about and do stuff on unloaded map parts, as if they're actually in the library on tuesday and in the music theatre on fridays. This would allow people to make RPG subgames or adventure worlds. We HAVE to use the same basic code to drive all of these mobs/npcs/monsters though.

The re-use of code bits and breaking down functionality to the core aspects is critical. Nobody can maintain and develop a mob engine that supports 50+ different monsters that has custom code for almost any aspect of the mob. If the minetest core pathfinding API changes, we should be able to fix all the mobs by fixing the 1 code piece that provides the pathfinding code, etc.

[sofar]

One last comment: I wrote entity_ai almost a year ago, and have not worked on it for a while. The main reason is simple, I've prioritized other things. That doesn't mean that entity_ai isn't important to me (it is), it just simply means that right now I'm working on something else that I find more important, and, when the time comes that it becomes my priority again, I'll work on it again.

The thing to note is that it's easy to make me go work on entity_ai again: help me change it to the next level of functionality needed. Submit patches, try and use it, submit bugs etc.. If enough people help out, I'll be happy to jump on it again and make it a priority.

[MisterXtreme]

Just a thought: Mob spawning is kinda a mod thing, so maybe just have different spawn types, just like different states, ie. spawntype: event eent is completion of x structure, and despawntype = never/on event/after x amount of time. Sound good/makes sense? P.S. I suck at writing theoretical lua, sorry. :P

[MarkuBu]

@sofar I start this issue because you stopped development. Sadly I never found the forum post or the github repo. I only saw your videos.

Maybe I should mentioned that I don't want to write the 1000th reincarnation of simple mobs. My approach is completely different to any existing mob engine, including yours.

I started a first version last year, but sadly I lost all code by a harddrive crash. I want to implement two standard techniques for mobs in gaming: steering behavior and GOAP (your states sound a little bit like GOAP)

I watched your videos and there are a few things I don't like

• they jitter
• they run into each other and continue walking
• they run into obstacles and continue walking
• they rotate immediately
• …

This is the one of the last videos from my sheep, compared to mobs redo. See how easy they can jump up stairs. https://www.youtube.com/watch?v=0wC3JlKkvv0

And even with hundreds of sheep there was no jitter or lag (only if a new mapblock is loaded) https://www.youtube.com/watch?v=MjGkZ4tE5Ek

And maybe take a look at my last video https://www.youtube.com/watch?v=lws8pATSaQY

(sorry for my bad English)

This is not necessarily the behavior the sheep should have in the game. This is just a showcase what would be possible

[sofar]

@MarkuBu

Your path/rotation code could become the default walking code in entity_ai, But, nicely walking animals is a detail problem. You implemented a solution to a small detail problem. (there are hundreds of detail problems that need to be implemented)

entity_ai implements the structural solution to allowing details to be solved independently, and concurrently. it solves the larger problem. That's the only way forward imho. Anything else just repeats the same mistake over and over again.

So, grab entity_ai and start changing the pathing code if you want. (https://github.com/sofar/entity_ai/blob/master/path.lua#L109)

[sofar]

I also want to be clear;

entity_ai is ready to be used for mobs. There are already 2 mobs in the mod, All the basic parts are there and you can start hacking away adding new drivers/factors/finders to it.

Me not working on it does not in any way whatsoever stop anyone from using it already.

[tenplus1]

@sofar - milking mobs redo cows isn't hard-coded, it resides inside the on_rightclick function of the cow registration and can easily be amended to milk cows only when self.state ~= "runaway"... The redo api can be extended in many ways by the mob registration itself to do almost anything.

[sofar]

@tenplus1 you just confirmed my point.

[lnjX]

@sofar

As I've posted before, the problem is really that all existing mob mods out there are not engines or frameworks, but more "template" mods. And as soon as someone comes up with a question that is in the form of "but can we also make it do X", the answer from the mod maintainer is "I've copied the code and made this tweak to mob X".

This isn't scalable. This isn't maintainable. It's just terrible design. And it won't ever work reliably for all monsters. Each monster ends up being 100% hand crafted code. I can't see a design like that ever being part of minetest_game.

You can't call this 100% hand crafted code (it's definitely not or I've misunderstand you): https://github.com/minetest-mods/mob-engine/blob/develop/zombie/init.lua

FYI: CME also has implemented knockback for mobs.

[sofar]

@LNJ2 it's still handcrafted code:

• you only have one attack model. I don't see anything to suggest that this mob can't have 2, 3, or 500 different ways to attack a player.
• hostile = true supposedly means that it attacks players. How about a sheep? How about a rat? It just leaves alone those delicious edible mobs alone? How do I make it scared of (for instance) apples?
• how do I make a mob decide to give up chasing a player because it is getting too far away from the start of the chase point?
• how do I make a map with pre-spawned mobs that don't respawn?

etc etc etc

It's still "handcrafted" code in the sense that you have a few routines somewhere that handles 10% of the things that entity developers can imagine. It'll never be good enough for everyone, and I can already spot big missing gaps in it.

[lnjX]

@sofar These features just aren't implemented yet. How do you want to start differently? But you're right all current APIs are missing many features to do such things.

[ghost]

all current APIs are missing many features to do such things.

And all current mob API designers think that their approach is the one and only best approach instead of combining the efforts and create an API together.

[lnjX]

And all current mod API designers think that their approach is the one and only best approach instead of combining the efforts and create an API together.

But CME is just the best, please come all and contribute to it! https://github.com/minetest-mods/mob-engine

:rofl:

[MisterXtreme]

I'm considering trying to do something about a mob API, all this talking has been done, now lets start, sure, stuff will break at first, that's why we have forks & alpha tags. ;)

[sofar]

https://github.com/sofar/entity_ai for those that want to go forward...

[MarkuBu]

I'll try your mod with my new pathfinder. Will see how it performs.

[MarkuBu]

https://github.com/sofar/entity_ai for those that want to go forward...

I'm not 100% sure, but it looks like a Stack Based Finite State Machine.

[sofar]

I'm not 100% sure, but it looks like a Stack Based Finite State Machine.

It's been called worse :)

[rubenwardy]

Stack Based Finite State Machine

Pushdown Automata (PDA) - a state machine with a stack. Not read the code though

[MarkuBu]

Ah, ok.

But I want to implement GOAP. Might not be necessary for many mobs, but it gives more flexibility. You can "plan" your actions. For example a NPC is hungry. He has different ways to get food.

The easiest way: he can eat an apple, but no apple tree is near. But there is water and he can go fishing. But he has no fishing rod. He has a stick, but no string. He can harvest cotton to get string, build a fishing rod and can go fishing If he can't find cotton he can go back to the village and so on

You can define actions and each action has a cost. A planner searches the list of actions to get the goal with the cheapest cost, similar to A* and the planner pushes the actions to a FSM.

That's the basic idea

[Wuzzy2]

@sofar: You are spot on with your analysis on the current situation and you have correctly ranted about all the wrongs in the mob mods. Even if Mobs Redo (and other mods) have become slowly better in the past, there are fundamental design flaws indeed. Now I think I understand why there aren't any mobs in Minetest Game. You probably just want to implement mods properly instead of shoddily? Seems legit.

Sidenote: The reason why I took Mobs Redo for MCL2 was simply because it was reasily available and had many “minecrafty” features which would be required for MCL2 (like breeding, feeding, and such). It's not that I am 100% happy with it. I think the other mods (including entity_ai) simply don't have the “minecrafty” features (yet). So I was simply being pragmatic.

I like the idea of zero code mobs very much. I think less code to solve the same problem is a good thing, it makes stuff much easier (if done right). I just wonder how this can be implemented for something as such as complex as mobs, esp. when you want to make it extensible. It also gives a huge chance for standardization.

You got me interested in entity_ai and I wanted to check it out but then I suddenly saw “CC BY-ND-4.0” in the README. NOPE.