Minetest_game: 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.

[sofar]

On 07/23/2017 02:30 PM, Wuzzy wrote:

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

my intent has been and will always be to make a solution that can be
merged into minetest_game. For this reason I want to prevent fragmenting
the mod, and it clearly states in the readme that the mod will be
relicensed upon merging to the minetest licenses.

[C1ffisme]

You mentioned that hostile mobs should look agressive, whilst passive mobs should look cute. This is a tiny nitpick, but honestly the hostile mobs should look cute too.

Unless you specifically want to go for a horror genre, cute and colorful art is _really appealing_ these days (even to adults), considering how most Nintendo characters (and Sonic the Hedgehog) go for colorful and bright themes and characters.

Plus, it's a lot easier to make a brand like that. Regular zombies that look like they came from any zombie movie won't be very recognizable by an outsider, but an original artistic take on a zombie (like Minecraft's iconic green zombies wearing steve clothes), or much better, an original creature altogether (MESE aliens, anyone?), is going to be very recognizable to someone who hasn't played the game if it's popular enough.

[nerzhul]

the npc engine must be in core, not in mtg, mtg should only be a consumer of the framework, providing mobs.

[Wuzzy2]

@sofar: I don't care about promised licenses, because those are not real (at least not yet). I care about the actual status i the present, and in the present it's non-free. No free software = no support by me. 'nuff said.

[rubenwardy]

It's free software but non free assets. Fsf is fine with this

[sofar]

On 07/24/2017 03:52 AM, Wuzzy wrote:

@sofar https://github.com/sofar: I don't care about promised licenses,
because those are not real. I care about the actual status i the
present, and in the present it's non-free. No free software = no support
by me. 'nuff said.

sorry, at this stage in the project I can't afford to have people fork
it and make half-ass copies that are incompatible and disruptive. Once
the API is complete and the engine fully implemented, then I'll
relicense, but not before. If you can't understand that, and don't trust
my motives, then that says more about you than me.

I don't want your "support" either. You have a tendency to provide good
criticism (and lots of it) and then fork the code without largely (or
not at all) contributing back, which is all fine and dandy, but more
than often not a mutually beneficial type of relationship.

Nothing personal of course, you're doing what is largely best for your
projects, where as I have the long-term benefits of minetest and
minetest_game in mind with my choices.

[sofar]

On 07/23/2017 10:48 PM, Loïc Blot wrote:

the npc engine must be in core, not in mtg, mtg should only be a
consumer of the framework, providing mobs.

For the record, I completely disagree with this. At this point in time,
I doubt that the loss of flexibility outweighs the performance gains.

As long as entity on_step() is written in lua because it needs to be
able to execute arbitrary code, having entities entirely in core is an
illusion.

Perhaps things like motion control can move to core, sure, but that's
not the same as moving the entire engine (whatever the definition of
that is) to core, which would make modding largely impossible.

[ghost]

For the record, I completely disagree with this.

So you agree with re-inventing the wheel in slow Lua all the time for all the mob mods instead of having one single performant API in core?

[Ferk]

I think the main reason mobs are slow is the networking. The mobs themselves are not that slow even if coded in Lua, but there's a noticeable delay, specially when the connection is not optimal. They work fairly well when in singleplayer, for example.

Changes in motion control and client prediction in the engine would definitely help here, but imho it would be a mistake to hardcode the mob behavior and assume all the problems are caused by Lua.

[ghost]

They work fairly well when in singleplayer, for example.

Can't confirm when compared to Minecraft.

[Ferk]

Can't confirm when compared to Minecraft.

Can you be more specific? what exactly does not work well?

I'm not talking about missing features, walking speed or anything like that, which is a different issue not really related to using lua (current mobs are intentionally designed to be more simple and predictable, don't change behavior too much and walk slow to mitigate the network lag). I'm asking what of their currently intended behavior is not working well.

[ghost]

Can you be more specific? what exactly does not work well?

In Minecraft you can breed them you can tame them, you can give them names, they don't stutter, there is properly working pathfinding, they have fitting sounds, they have proper animations (i.e. walking speed and direction matches animation and orientation), they don't simply spawn at random locations, they sometimes work in groups (Zombies and Endermen can team up, skeletons ride on spiders). They can drop their items, you can give them items, they do not glitch through walls, etc.

And this is outdated information, because I did not play Minetest since "the Microsoft incident". But even back then the mobs were more feature-rich and polished and versatile than nowadays in Minetest

[Ferk]

You are reaffirming my point then, all those are missing features or low quality assets, not bugs caused by Lua.

Good luck trying to implement all of that completely in C++ in a way that games can have any minimal level of flexibility, without using Lua.
The points related to the assets of the game (animations, sounds) don't even have much to do with the engine.

Most of that (breeding, taming, giving names) is already technically doable in Lua.
Stuttering and pathfinding (movement) is what we are saying that needs to be implemented in the engine with better prediction, since it's affected by network latency.

[octacian]

I'm not sure, the performance gain of implementing in C++ could be quite substantial. However, it would need to be implemented a bit differently from most other APIs, in that it should be easily expandable. A core API (although it might be a lot of work) would provide a universal API accessible to all subgames and mods, rather than going even deeper into the current mod dependency hell seen both between mods and even more so in MTG itself. Not only that, but a core API could better implement pathfinding with client-side prediction, and as aforementioned, would be much faster.

Although it might be more work to do properly, I believe a core API is definitely the way to go. It would be faster (performance-wise), more universal, reduce dependency problems, and likely do other things that I haven't thought of.

[raymoo]

With mob movement control moved to C++ I think most of the other stuff would not gain a significant boost from being implemented in C++. For example, for breeding you would make the mobs move toward each other, and in Lua you would do a check once per step to see if they are close enough to breed. One check per step is very low cost and it doesn't really matter if it is done in Lua.

[paramat]

MT mobs not being feature rich is more because of lack of dev time, we're not a professional production company worth 2 billion USD that makes the world's 2nd most popular game, yet people often have the same expectations, make lots of feature requests which they expect to be considered because we are open source, and judge MT relative to MC, unfairly. Considering the lack of human resources MT is actually extremely good.

[Ferk]

The breeding check doesn't even need to be every step, it's not like animals need to be constantly in heat ^^U just once in a while, when ready to ehm... mate.
Things like "taming" are triggered by the user so it would happen so rarely that it would matter very little.

Actually, I'd bet there were already some mob mods having these features (even if not as modular as entity_ai).
I still think the main problem with MT mobs is how they are so sensitive to latency.

[raymoo]

I mean a check once every step while they are trying to mate.

[ghost]

if you don't have anything useful to say, could you stop twisting things around and attempt to derail the discussion by attempting to paint participants in the discussion as something they are not?

Aww, you pissed now because you can't silently edit and censor other peoples posts like you can do at the forums? Sorry pal, but that's just how it works. Btw. you still did not answer my question.

EDIT: reported for trolling by sofar

[sofar]

@dsohler

thanks for confirming that you really are just trolling around. I will recommend to the other members of the team that they start deleting trolling comments here as well.

[ghost]

Whatever rustles your jimmies.

Still awaiting an answer to - now - two questions.

[C1ffisme]

MT mobs not being feature rich is more because of lack of dev time, we're not a professional production company worth 2 billion USD that makes the world's 2nd most popular game, yet people often have the same expectations, make lots of feature requests which they expect to be considered because we are open source, and judge MT relative to MC, unfairly. Considering the lack of human resources MT is actually extremely good.

I do get that we actually do need to spend time on engine optimization, networking security, bug fixing, etc. But I feel like the development of Minetest Game just needs more imagination put into it. And that's not just me being cheesy-sounding, I feel like we copy too much from Minecraft just because we can't think of a more original implementation. (Besides maybe a faster one that reduces possible gameplay mechanics, like TNT not becoming an entity when lit.)

[Xaleth]

What I suggest is that the mobs API be written in C++ in the minetest engine and the mobs created in MTG and written in Lua.

[MarkuBu]

@NewbProgrammer101 which mobs API? We don't have a real working API. First we need something that is working

1 - zero code mobs

@sofar I was thinking back and forth, but I don't agree with you. It must be possible to write custom code.

The simple reason: each mob can have different properties. Each property has to be coded.

Let's assume entity_ai works as expected and I want to add a mob. I fork entity_ai as usual, make the changes and make a PR. So far, so good.

But: what if nobody is there who makes the PR? What can I do if it takes to long until my code is merged? Or if someone else adds a similar function, but not identical. Who maintains that? Who changes his mob "script" to fit the other function? Or add both functions, even if they are similar? What if the maintainer decides not to add a function?

I could continue this until death. What I want to say is that two things can happen:

1. no one uses entity_ai or
2. dozens of incompatible forks raise up

You are right, there are a lot of common functions that some mobs can share, but even basic things like idle or move can be different.

For example movement: some mobs walk, some mobs jump, some crawl, swim, dive, fly, dig through earth.... And each of this can be broken down in multiple parts. A seagull flies differently than a parrot, a duck has different behavior etc.

How to ensure that new function will be added within a reasonable time? Who decides if a new function, that already exists in a similar way, will be added as a new function or patched into the existing function?

I agree with you that as many functions as possible should be added to the engine, but custom code should still be possible. That's the only way to ensure, that devs are willing to add new mobs. If a custom code works as expected it is still possible to implement it to the core. But if devs have to wait until a new version is released to get their new functions, they won't add new mobs.

And what happens if the engine has only a few basic functions without custom code we can see at simplemobs mod. We have a lot of variations of the Zombie, just with different models and textures.

@NewbProgrammer101 and because of that it is impossible to add the complete engine to the core because it would take month until the new functions are available and it would be much more difficult for devs to write them. You can add some common helper functions to the core that need a lot of calculation time, but most of a mob engine will always be written in lua.

[sofar]

Let's assume entity_ai works as expected and I want to add a mob. I fork entity_ai as usual, make the changes and make a PR. So far, so good.

no, you don't fork entity_ai. You just write new drivers that depend on it, package them in a mod, and make a mod that defines an entity that uses those new drivers.

The core of entity_ai never has to be replaced with a new core. There is no forking problem. Just add new drivers and register them with entity_ai.

[sofar]

I agree with you that as many functions as possible should be added to the engine, but custom code should still be possible.

I ... completely do not agree with this statement. I have been saying the exact opposite, and therefore opposing a core entity implementation. I can see some use for code parts like path following, but in the current state I think it's meaningless since there is no data to support that that would be an actual improvement.

[MarkuBu]

@sofar Then I completely misunderstand you, I'm really sorry. I read again and noticed that I missed that line before

New drivers, factors and pathfinders can be easily added by mods, and writing a state diagram and adding animations is fairly simple.

Now it makes more sense to me and it sounds more like what I have in mind. Just the names like factor or driver confuses me. I know them as actions, preconditions and effects. And the major difference is that you add these things directly in a table and I commonly add them with a command.

What I mean with custom code is the same idea like adding your drivers and factors as mods. I have a common interface for actions or effects, so it is pretty similar.

I think we have both the same (or at least similar) idea, just with different implementations.

Maybe you can make an example mod how to add new factors and drivers or overwrite existing? This might help many devs to start with their own code

[sofar]

There are already a bunch of "mod" like pieces in entity_ai that register stuff. You can essentially put this code into a new init.lua and it would be a valid extension to entity_ai's library of functions. Then your entity table just plugs those functions in where needed.

https://github.com/sofar/entity_ai/blob/master/factors.lua#L15

https://github.com/sofar/entity_ai/blob/master/drivers.lua#L15

https://github.com/sofar/entity_ai/blob/master/finders.lua#L63

and then it's all used around here:

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

[MarkuBu]

In the meantime I have understood it a little better, but thanks. I'll try this mod. It seems that no one uses this until now

[Xaleth]

One more thing: the mobs shouldn't have cube or rectangular prism selection boxes.

The entire model should be one whole "selection box."

[sofar]

@NewbProgrammer101 that's an engine/core issue, and shouldn't be filed here.

[Xaleth]

Ah, understood.

On 12/03/2017 07:52 PM, sofar wrote:

@NewbProgrammer101 that's an engine/core issue, and shouldn't be filed here.

[paramat]

~I don't actually consider mobs as essential for desktop MTG, optional mods can be used to provide them,~ but there is one good use: making the Android app more enticing.
The majority of app downloaders seem to download something that looks roughly like MC and has some mobs, this is one reason why the official app gets fewer downloads.

I would be fine with a very simple mob mod, and almost started work at one point. But many core devs seem to want something complex, which sort of makes it not happen. What's better in the short term, ultra-simple or nothing? :)

Also, i consider 'mobs redo' too complex, and is likely to have many issues, seems better and less painful to code something new and simple to be sure of quality.

[rubenwardy]

I consider mobs essential for all ports of the game, desktop or not. Frankly, you don't get to decide everything about MTG

[paramat]

you don't get to decide everything about MTG

Well of course =) and that's surprisingly unpleasant and unjustified :(
I'm just stating my opinions, and in no way implied i decide everything.
You did ask me to look at the roadmap so that's what i'm doing, and providing input.

[LoneWolfHT]

:+1: for a mobs mod but not mobs_redo
Something simple with a good API and clean/efficient code is what I'd like to see

[Ferk]

Imho, it should be simple but more than anything it should be extensible.
Something in the spirit of entity_ai would be a good candidate, since you can have simple behavior shipped in MTG but allowing for mods to extend it by adding additional mob actions and logic, all through the same framework.

Users wanting more should not need to install a completely separate framework that somehow overrides the one shipped, fragments the compatibility between mob mods and makes things more messy and ultimately more complex.

[paramat]

To be clear, i do support adding mobs to MTG, and not just for the sake of Android.

[paramat]

Sorry for my earlier comment, some of it was too negative.

There was a suggestion, i think on IRC from rubenwardy, for types of mobs:
2 hostile, 1 of which supernatural, 1 realistic.
2 peaceful.
I agree with the hostile suggestion, and request we add the Oerkki as it seems the most appealing and suitable of the old MT mobs: occurs anywhere, not just in dungeons.
For peaceful i suggest at least 1 is wild. The other could be farmable or domesticated, not sure what though.

However, i'd rather not have a sheep for wool, as wool in MTG is essentially actually cotton. With sheep there's then no reason to grow cotton. Seems best to avoid stirring up the wool/cotton mess in this way. Also because i wouldn't want something as fundamental as wool depending on having sheep mobs, which may not be wanted or suitable in some situations, a crop is more accessible to all.

[TumeniNodes]

The only area I am torn on, is wool.
Cotton... is _not_ wool. Cotton is cotton & wool is wool. They are very different natural materials.
I _do_ feel eventually, this should be addressed in the game code.
We can have both wool & cotton uses.
~The only reason things are set up as they are today... is following the lead of MC.~ (striken as I realize quickly I was mistaken on this point cotton for wool is entirely an odd MTG thing)
This is another way we can set this project apart.
Just a suggestion for future consideration.

Consider this as well please.
Adding a couple mobs, as rubenwardy suggests _will_ go a long way with end users... even if they are not perfect and precise... and will be a huge boost for the project.

[runsy]

I propose to adopt the mobkit solution for mobs instead.

https://github.com/TheTermos/mobkit/blob/737b769307aaf7c545fbee2362c6474e7662170e/mobkit_api.txt#L21

It would be easy and abstract to implement it in a C way. The API would be only 3 C minetest functions (register low level function, high level function and clear functions) and the management of the priorities. The concept is cool.

With this, several mob engines could be implemented by modders; one API, infinite engines. The mob behaviours, AI, pathfinding, etc. of course are in the mod side too.

I know that is a particular solution, but revolutionary and creative. Just what Minetest needs as Veloren and Hytale are doing right now.

[paramat]

Adding a couple mobs, as rubenwardy suggests will go a long way with end users... even if they are not perfect and precise

As mentioned above, most core devs want something complex (a feature-rich engine API or an altered version of mobs_redo mod), which is fine if they worked on it, but this has been intended for years and it never gets done due to the complexity and lack of core dev time.
Meanwhile, suggesitons, like my own, for adding very simple mobs, are opposed. However, a simple implementation is likely to be coded, and could always be in place until the complex implementation is done (if it ever is).

This is an example of a bad occurrence in MT development, where a simple improvement (which could be temporary) is opposed because of a desire for a complex one, which gets discussed a lot but not worked on, so it never happens or does not happen for years. The result is no improvement at all.
Until someone works on the complex implementation, we should not oppose simple ones.
Simplicity is a core concept of the MT roadmap.

[ghost]

I wholeheartedly support the addition of mobs into MTG.

[paramat]

Closing due to #2710