Engine API for Mobs

[C1ffisme]

You've seen the mods. Just download one and see the bugs or lag. If we could have the engine running the behavior of mobs, I think that they would go faster. We could make a function like minetest.register_mob(), then all you would have to do for an animals mod is use the (hopefully many) features in the function, and make models and textures (and maybe some sounds). I know many laggiful server owners will run in terror at the word "mobs", but I think that minetest can't say it's for old computers anymore. It's just too filled with features. If we wanna leave a version for older computers, someone better fork minetest before this gets added (if it does).

[Wuzzy2]

As for the fork: It already happend, it is called “Voxelands” now (formerly “Minetest-Classic”). It is based on the 0.3 codebase of Minetest-c55.

[falsechicken]

👍 I too would like to see faster mob processing at some point in the future.

[Wuzzy2]

Well, there are a lot of open questions: What should the “mob API” from Minetest do? Which capabilities do you wish (both of the API and the mobs themselves)? What features? How should/would mobs differ from entities? What Lua functions should be available? Which would be the limits? Do you want a more generic approach to mobs or a more specific one? What kinds of mobs should exist (mob “classes”)? How should mobs relate to the groups system? What kind of attacks would be possible? What could modders do if they find shortcomings in the mob API?

And, and, and …
Questions over questions.

[falsechicken]

Indeed. Tons of feedback required.

[nerzhul]

i also agree that the engine must have a little mob/pnj processor with high lua extensibility. But it needs to be discussed with other devs

[rubenwardy]

The problem is making it extendable.

Let's design it from the top down. It needs to support these types of mobs:
(please feel free to expand on this)

Must do

• Wild Prey / Herbivores (sheep, pigs, cows, horses, deer, tuna)
  • Run away from predators and when hit
  • Can run away from players if timid
• Farm Animals (sheep, pigs, cows, horses)
  • Derived from wild prey, but like security and require players to feed them. Maybe. (Minecraft doesn't distinguish between wild prey and farm animals)
• Domesticated (cats and dogs from tigers and wolves)
  • one of my favourite things in MC are the dogs
• Predators (wolves, bears, sharks)
  • Different levels of aggressiveness. (will it attack players? will it attack prey? will it attack predators?)
• Monsters (zombies, 'creeper'-style, kraken
  • Only attack players. All animals are scared of it.
• Animal Location
  • All of the above categories can be land, sea or air.

Could do

• Breeding / selection - you can create more efficient animals by breeding them together.

Why C++?

Client side prediction would be required to make it seamless on servers. C++ runs faster than Lua, less switching between C++ and Lua.

[nerzhul]

It's not the priority, because there are many things to do in the engine before adding new huge features for game, but we need to discuss on it together to find a good implementation

[rubenwardy]

The priorities should be:

• Faster protocols and more client side prediction
• Increasing user friendliness and experience, which includes removing blocking bugs.

I agree that we should talk about possible architecture.

[nerzhul]

agree

[falsechicken]

Man rubenwardy you go all in with everything you do don't you? I love it. No slackin' round here.

[rubenwardy]

It's only because I am on the computer and can type quickly. The thing is that it is all well and good suggesting a feature, but it would need to be implemented and methods of writing it needs to be discussed as well.

EDIT: It also interests me. XD

I'd suggest a modular design that Lua mods can extend. That way mods can add new behaviour to the basic framework without needing to edit C++. By this, I mean that:

• Animals use a finite state machine. C++ provides several useful states which are fast, but Lua can define them as well. Lua can also override for certain mobs (eg: dragon overriding attack method)
• Modular extensions which are independent of state or cling on to states. Like making dogs sit or taming them - you could specify on_tick, on_punch, on_state_change, on_right_click. For the shearing of sheep, you'd probably use a tool for this, so an extension isn't the best idea - but it's just an example.

I imagine you'd need to derive a MobEntity from Entity like LuaEntity is derived from it. (OOP-wise)

[nerzhul]

@rubenwardy agree

[C1ffisme]

Wow, so many comments in one day!

I like @rubenwardy 's ideas, and I think they would do nicely for an engine. See, what I'm thinking is we could have MobEntity already have some things made in C++ that LuaEntities must have in lua.

[SmallJoker]

I think Minetest shouldn't contain any mobs by default.
A mob API for mods would be a better idea. That way, it would be easy to create new mobs without editing Minetest's engine.

[rubenwardy]

That is what we are saying.

[rubenwardy]

Providing that mobs don't lag much on miltiplayer, I think they should be part of minetest_game, although they should be able to be disabled from a setting.

Explicitly disable subgame mods could be good for this.

[PilzAdam]

I think they should be part of minetest_game, although they should be able to be disabled from a setting.

"Mod" is the word you are looking for here.

[rubenwardy]

No, because mods aren't counted as part of Minetest. They're mods.

[rubenwardy]

The whole "you can just install a mod" argument is damaging the gameplay experience. Minetest should be customisable, but it should already be shipped with a fully working and fun game. While I don't particularly care for monsters, animals add to the 'immersion' of the game.

[C1ffisme]

I agree with rubenwardy. We can't just make this game for developers. It turns out we've all been under the proggramming sun too long. There are those who hide in the gamer caves and...

Did I ever mention I write books for NaNoWriMo? (National Novel Writing Month).

Anyway, we can't assume everybody wants to get tons of mods. I know people who download and sometimes make mods for minecraft, but I'm sure there is a distinct amount of people who use vannila entirely. Meanwhile, you can't play minetest without mods. (Or using V7 and attempting a very explorative survival, but that uses lots of CPU.)

[Wuzzy2]

Please stay on topic, I thought we are just talking about the mobs API. DIscussion about minetest_game should go here:

• https://github.com/minetest/minetest_game
• https://forum.minetest.net/viewtopic.php?f=15&t=9724

Other Minetest-related stuff goes here:

• https://forum.minetest.net/viewforum.php?f=3

Not that I am a moderator, I'm just saying …

Anyways, back to topic:
I want to emphasize the following points on a mob API:

• There should be some kind of basic movement patterns
• Each mob has one movement-pattern and is fixed for the mob type
• The movement patterns should be treated independently from behaviour patterns (aggressive, passive, fleeing, etc.)
• I think behaviour patterns should be dynamic and can change over time for one mob. This allows for more varied gameplay
• It would be generally good if mobs would be technically not too terribly different from players, so features which mobs have (custom collision boxes, custom max. HP, etc.) should also be changable for players and vice-verser. This allows for more flexibility.

Examples for basic movement patterns:

• Static: The mob does not move at all and is not subject to gravity
• Static Faller: Same as static, but is also subject to gravity (probably useful for human-eating plants)
• Swimmer: The mob swims at the surface of some liquid
• Diver: The mob moves inside a liquid, may also be
• Flyer: The mob moves in the air or any other air-like non-liquid non-walkable node. But it cannot stand still.
• Walker: The mob walks on the ground like the player does
• Floater: The mob can move freely through air (or similar) and does not have to keep on moving
• Hybrid: Can combine two or more movement patterns (if feasible). It is unclear how, and which ones.
• Custom: Maybe, maybe, mods could add their own movement patterns. The question is: How?

I also would like to invite BlockMen into the discussion, because BlockMen authored the Creatures mod. I think we could get some good input from there.

@BlockMen

[nerzhul]

@C1ffisme agree, it's not only a developper playground it's a serious game used by players.
I have a good experience with NPCs on mangos emulator for WoW, i think we can tanke some parts of their approach

[rubenwardy]

Yes, it is offtopic. Minetest_game stuff should be worried about later. The movement patterns would need to support any monster/animal you could think of. I'm not sure about plants. They could be cool, but they would be better as interactive nodes in my opinion, but that's a different feature. Unless they are in plant pots and can jump. Birds can walk and can fly. It would be useful to find some PDFs of papers that describe existing algorithms, and look at how other projects do it. I can't search very well on my phone.

[4aiman]

Movement patterns may be added through Lua with C++ speed if there would be some algorithm we can pass as a table and there will be a "decipher" which will interpret the passed table as a patterns for every case: idle, running away, following smth/someone, getting punched, attacking, jumping, swimming, flying, etc

Those tables may even contain several concurrent patterns chosen pseudo-randomly (for client prediction to work seamless).

It would be also wise to add the ability to override C++ methods through Lua, but that is smth we already have. Can it be optimized by itself? (E.g. not because network proto became faster).

[ghost]

Mobs are needed in the game, without them even in multiplayer is boring.

[C1ffisme]

Is anyone willing to work on a usable mob engine?

If we start a simple one, we could work up to something decent.

[sofar]

I'm not making any promises, but I have started work on a mob engine/framework/whatever.

I will share design goals and implementation later, when there is something to share. I'm using the time to teach myself the various skill that I need to make this successful, as well as do the design work without being encumbered by people telling me to make a pixel darker.

If you follow my youtube channel you can monitor progress. I'm regularly posting videos of what the current state is of the engine, although I'm explicitly not giving any details yet at this point in time.

I will not go into discussion about technical details in this thread. I have collected my requirements by looking at feedback from players on the forums and github, and am considering all the opinions already, so there's very little to be added. Needless to say that I have my standards set very high and I'm not making something simple (even though it may appear simple at first sight).

[C1ffisme]

@sofar Well, I hope something good comes out.

I think this issue should be closed, and a discussion on the forum opened.

[rubenwardy]

This is an often requested and important (imo) feature. This is a good place to discuss it

[nerzhul]

The first thing to do is to have a base class between all lifen SAO (PlayerSAO and LuaEntitySAO) which have common features, i propose UnitSAO as an intermediate which have some common features. I could provide a PR backported from my fork for this.

[neoascetic]

I guess the most problems with the performance of different mobs mods is not C++ vs. Lua speed, but lacking architecture. The same optimizations/algorithms may be done in Lua as a mod as a proof-of-concept and only later, when there is a lot of good feedback from users and server owners, moved into the core and implemented in C++.

This guarantees faster reaction on users request due to dynamic nature of Lua and independence of engine's development process, which leads to better understanding of what kind of API would be useful. Then, periodically, parts of that API may be moved into the core.

[4aiman]

and only later, when there is a lot of good feedback from users and server owners, moved into the core and implemented in C++.

Then there should be an official public poll or else any new mobs API would end like "yet another mobs API".
What I mean is, do we really have no good APIs for mobs at all?

I'd suggest making a new poll for every major release and add to C++ whichever API would be the most popular.

[sofar]

I'd suggest making a new poll for every major release and add to C++ whichever API would be the most popular.

Minetest development (just like any OSS project) isn't a democracy.

I don't think the mob API should be in C++ ever. @neoascetic 's comment that likely this is best coded in Lua, and then optimized where needed in C++, is far more realistic and the right approach. Make it in Lua, optimize in C++ where needed.

If you look at my nodeupdate optimization, you can see that with well-written solutions, you really don't have to grab for C++ that quickly.

[C1ffisme]

I'm going to have to agree with @sofar.

Doing mobs in the engine would mean that a large chunk of the mob API would be hard-coded, and that wouldn't be very good for an engine like Minetest, where you can create anything you want.

[Ferk]

I agree that the problem is not about C++ vs Lua. However, I believe it's more of a client vs server issue. Mobs (and other entities like mounts, cars, boats and other transports) work flawlessly in singleplayer, where server-client latency is barely present.

The problem is that Lua is only server-side, so it's not possible to code movement patterns in Lua to be performed directly in the client. Also, even if the patterns were coded in the engine, having client-side logic might bring other problems like players getting out of sync between each other (so they see the entities in different states) and cheaters using modded clients if this logic is not monitored server-side as well periodically (which might end up resulting in latency issues anyway unless a certain margin of error was allowed).

It would be awesome to find a simple solution that didn't require any messing around with prediction or syncing states... but I'm not sure if it exists. Not if you have entities that need low latency. Maybe the situation could be improved by at least calculating some of the movement patterns in the engine.

[neoascetic]

#3440 is related. As I've said, having client-side Lua scripting would be a great improvement.

[MarkuBu]

Is anyone willing to work on a usable mob engine?

I will start my own engine, but with a different approach than the others. I will write it in lua, but with C++ in mind. Each function, that should be written in C++ will be separated from the other parts

I don't think, there is really a need for a huge mob api, because the common functions for all mobs can be reduced to a hand full of functions. Register, create, delete and move. And they already exist

But there are functions like a collision callback, which are totally missing yet and which should be implemented in C++. Also different kind of "sensors" with callbacks would be helpful to make mobs more complex and give them more abilities. But these sensors must be written in C++ because the necessary informations are not available for mods or only at a high cost and because of possible lacks of more than a second in functions like on_step or register_globalstep.

The behaviour should be done server side, but in a script, because each mob can have different behaviours. Instead of putting different fixed behaviours into the api it would make more sense to provide some basic behaviours as templates which can be modified (or not)

I don't think, client side scripting solves the problem. It will open new issues with collision detection, out of sync problems between players and more. There should be other improvements in the client/server communication to solve this.

[C1ffisme]

I think there's a MTG issue about this, and I feel like this issue is kind of pointless now, since the issue discusses the implementation of mobs at all, which most definitely includes engine support.

Does anyone care if I close this?

[nerzhul]

don't close it as it's an issue we will solve, maybe in next release (0.5)

[C1ffisme]

Ok.

[paramat]

See MTGame issue luanti-org/minetest_game#1667 especially sofar's comment luanti-org/minetest_game#1667 (comment)

[bell07]

Agree with @MarkuBu. At the time the whole mob logic is allways in on_step, called unreasonable multiple times each second. In each call the method gets environment data and entity data, check if anything is happens and react on them. That is the main impact at the time from my point of view. The entity should pass more events from c++ world to the lua callbacks:

1. The most important is "on_collision". Should be called if entity collides an other entity or an solid node. Using this callback an arrow mod can be implemented without any "steps". Just set velocity, acceleration and on_collision callback in the mod for example.

2. Other callbacks: on_before_chasm_reached to avoid falling in chasm?

3. entity:navigate_to(destination pos or entity). An path calculator already exists in engine. A method is required to let an entity to go trough the path, with "on_direction_change" and "on_stuck" callback. Often implemented method is to follow an player or an other entity. So the path calculator should be able to adjust the path if "destination entity" moves.

4. The entity's are blind at the time. The most mobs-mods uses "core.get_node" or VoxelManip methods to get world data. Disadvantage at this point: the data is copied. The engine should be able to provide an VoxelManip-like area around the entity without copying data from map to lua table or in any other perfomant way to do it.

[Wuzzy2]

The entity's are blind at the time. The most mobs-mods uses "core.get_node" or VoxelManip methods to get world data. Disadvantage at this point: the data is copied. The engine should be able to provide an VoxelManip-like area around the entity without copying data from map to lua table or in any other perfomant way to do it.

👍 so much. This will also be incredibly useful for non-mob entities. Using minetest.get_node or even a LuaVoxelManip feels incredibly clunky and wrong on so many levels, especially if you need this info basically at every step.
The point here is not that this isn't already possible, but that it just seems the wrong way.
If there would be a standard and efficient (!) way to get the immediate surroundings of an entity, this would be a great improvement for all entities, really. Not just mobs. It will help for boats, minecarts, flying carpets ( :D ), and much more.

Fun fact: Currently, falling node entities query minetest.get_node each step.

[bell07]

Fun fact: Currently, falling node entities query minetest.get_node each step.

can be improved in "blind way" by on_collision callback, if implemented :D

[Mizux]

Why closing this while other duplicate have been also closed ? i.e. where the entity/mob feature is tracked ?

• Animals #7608
• Mobs minetest_game#1667
• MTG was officially moved to a 'bugfixes, maintenance only' mode! minetest_game#2710

If minetest doesn't want to provide any entity support, would be happy to have it written...

[rubenwardy]

Games and mods can already implement mobs, I don't see any specific need for an engine API here. This issue has also been open for a long time with no real conclusion

What would be good is more engine support for features that makes mobs mods easier/better, that's something that should be created as new issues. Examples include pathfinding improvement, animations, and sensing utilities

[bell07]

I think this issue should be reopened and renamed into "Enhance entity API to support mobs mods development".

In my last steps in mobs development attempts I missed the next entity methods:

• on_collision()
  Currently the on_step is used to poll the position each step that is not always performant or accurately.

• navigate_to(pos)
  This method should cover the path calculations and be able to navigate the mob to position according his "physical" attributes (to be defined). Navigation should run without on_step() utilization but can be stopped from mod in on_step() or on_collision() .

But now I scrolled up and see I wrote the same in 2017

[appgurueu]

on_collision seems like a sane feature. I agree that moveresult in on_step is suboptimal. That should get a separate issue rather than "repurposing" this ancient issue. Feel free to open a new one.

navigate_to is much, much trickier. The pathfinding part should already be covered by #5479. It also requires many specific choices be made that I think shouldn't be hardcoded, so I'm wary of trying to design such an API that fits everyone's use cases.

[rubenwardy]

Please open new tickets for those features