About when will we get proper mobs in minetest?

[Sokomine]

I believe Sokomine was meaning that the job is not assigned to someone, someone volunteers to take it up.

That's right :-) Even the C++ part (if it's needed) has to be done by someone. Convincing the devs that the changes are good is another matter. But first we need some good code I'm afraid. Most of the simple mobs forks are not so good in that regard.

[golthem]

I think you're absolutely right with regards to the simple mobs forks. I also believe we need to figure out what route we plan to take, a fake A.I. (like simple mobs) or actual A.I. (something better done in C++ rather than Lua).

I also think we need less of those one man teams out there. I freely admit I can't do models and I can't do textures. If we could get together a couple coders, a modeler, someone to do the textures, and a plan, I'd join the project in a heartbeat.

Perhaps I'll work on organizing some sort of team to do this but I'd like to work on that plan part first. :-)

[johnwayne1986]

Would be nice to have a proper Mobs-API. I could help a bit at coding, but I am not yet experienced in the minetest code. I started looking at mob mods in the last days more or less because of this thread. However, I still need more time to understand the code.

Anyway, before something can be coded a proper design of a framework (C++) and API, as some people said, is important. On the one hand the API must be flexible enough to allow diversity of mobs (including special behaviour). On the other hand the framework has to do the computationally demanding tasks. Also a unification regarding the mob interface for a good compatibility to other mods would be desirable.

@golthem: Do you like to open a space to discuss the design etc.? It might be a github fork of minetest with a wiki. A fork is anyway needed, since the C++ code has to be modified. I would like to contribute at coding and API design in my spare time but not at leading or organizing the project. Actually for the API design the experience of mob mod creators (like tenplus1 and some others here) would be of great value. Maybe you can motivate some people to form a (spare-time) team to start thinking about the requirements of a mob API and maybe more? At a later (but not too late) stage the core developers should get involved for giving some comments if the direction is ok for them. They finally decide what is merged and what not. And with their experience they probably now which direction is the right to go.

[y.st.]

The point is, people will dislike the game if there are mobs.

I know I, for one, patched out generating of the C++ mobs back in the 0.3.1-0.4dev days. Mobs, by default, detract from the beauty and wonder of the game.

I completely agree. If mobs were in the game by default, I would never have become as attached to Minetest as I have. I would love it if mobs stayed out of the default subgame.

That said, I really shouldn't have any say on the default game. I'm working on setting up my own subgame, and I really only use minetest_game for testing things these days.

[benrob0329]

I think that having a mobs api in the default, or in the C++ side of things, would be nice.

A friend and I are working on a modular (API+sub mods) mobs mod based on BlockHeads's Creatures mod.

[golthem]

Would be nice to have a proper Mobs-API. I could help a bit at coding, but I am not yet experienced in the minetest code. I started looking at mob mods in the last days more or less because of this thread. However, I still need more time to understand the code.

Anyway, before something can be coded a proper design of a framework (C++) and API, as some people said, is important. On the one hand the API must be flexible enough to allow diversity of mobs (including special behaviour). On the other hand the framework has to do the computationally demanding tasks. Also a unification regarding the mob interface for a good compatibility to other mods would be desirable.

@golthem: Do you like to open a space to discuss the design etc.? It might be a github fork of minetest with a wiki. A fork is anyway needed, since the C++ code has to be modified. I would like to contribute at coding and API design in my spare time but not at leading or organizing the project. Actually for the API design the experience of mob mod creators (like tenplus1 and some others here) would be of great value. Maybe you can motivate some people to form a (spare-time) team to start thinking about the requirements of a mob API and maybe more? At a later (but not too late) stage the core developers should get involved for giving some comments if the direction is ok for them. They finally decide what is merged and what not. And with their experience they probably now which direction is the right to go.

The biggest problem with modifying the C++ side of things is simply that the project would be big. If we do this, it needs to be done with a plan otherwise it will fail.

Some people like mobs in the default game, others don't. If we end up modifying the C++ code, my suggestion would be to have an option for enabling mobs in the settings menu but have it disabled by default.

The main thing is, we need to wrap up the conversation and start doing.

[benrob0329]

My suggestion is to make the API in C++, and expose it to Lua, similar to how nodes are done.

[golthem]

My suggestion is to make the API in C++, and expose it to Lua, similar to how nodes are done.

This is most likely the method we would use (as discussed above).

[johnwayne1986]

Yes, when I wrote API, I meant Lua-API. All mobs should still be defined in a mod, but with a better interface than minetest.register_entity. Actually, right now, all mods define first a mob-API (with a custom framework for movements etc. written in Lua) and then the different mobs with it. The C++-framework would replace the one written in Lua and maybe add more flexibility or features. A good result in my opinion would be when all mob mods can use the new API (if they like) without loosing any feature. Of course the new API specifically for mobs would not replace the current more general interface minetest.register_entity. Thus the current mods would continue to work without modification.

@y.st.: This is just about a better API. There will still be e.g. the mobs-redo mod, which you can use or not. This is not about changing mintest_game or adding mods to it. However, maybe sheep or other friendly mobs would be cool for the default setting, but that should not be discussed in this thread. This must be discussed when the API is finished.

@benrob0329: Sounds interesting. Do you have a public repo or a discussion board or something? Would be nice to see it.

[benrob0329]

We are still getting the basics working, I get back to you on that.

[rubenwardy]

I don't care so much about monsters, but I'd like environmental animals and realistic animals:

grassland: sheep, pigs, birds, worms, rats, horses
forest: pigs, birds, wolves (+ dogs)
(near) desert: lions, tigers, camels, deer
sea/rivers: tuna, salmon, sharks, whales
jungles: monkeys, parrots
tundra: wolves (+ dogs)

the Github issue for this: https://github.com/minetest/minetest/issues/2291

[benrob0329]

I'd be ok even if such mobs were in default, I much prefer the animals approach.

[ArguablySane]

I'm going to reply here because I don't have a github account yet.

I like ruben's idea of movement patterns for swimmers, walkers, flyers, etc. Those should be implemented with fast c++ functions which take the mob towards its current target location. Those functions should also run on both the server and client to avoid de-sync issues.

There should be various higher level AI functions which receive information about the mob's surroundings and periodically update its target location. There could be some default ones such as wanderer (just randomly moves around), grazer (looks for grass and eats it), predator (looks for players/mobs and attacks them), territorial (tries to kill anything which comes close, but doesn't stray too far from a specified location), etc. It should also be possible to implement custom AI in Lua since it's not time-critical code. It will still work okay if the AI function is only updating every second or two.

There should also be a way to define an animated model for a mob. This is potentially quite hard. How I'd approach it is to have each movement pattern come with a set of animation states, such as standing, running, swimming, etc. Each of those can then be assigned a particular model animation. Additional animations such as sitting, sleeping, attacking, or looking around could be handled by the AI, and potentially added with Lua scripting.

[CrazyDaisy]

Well, it's 2016. Any news on mobs in the core code? My suggestion is maybe an API in the core that mods can use to create mobs. The core needs to handle all the cpu intensive stuff and mods just handle the basics. This would allow all sorts of mobs to be created, or none created. It would allow there to be mob mods to handle passive mobs such as sheep, cows, chickens, etc. Would allow there to be mob mods to handle aggressive mobs such as zombies or whatever. Or if the player doesn't want any of it, no mods could be installed.

All it takes is a group of people with the knowledge to get together and get it done. Would probably take less than a month of part timing it. Then the mod makers can get to work putting the new API to use, which would flush out bugs that can then be fixed. A survival world without something to defend against is pretty boring. A world with a ton of farming mods but no animals to farm is also boring. Using the current lua for mobs just isn't cutting it. The majority of the mob code needs to be in the core of minetest to keep performance high and keep glitches low. If I knew how to do it, I would jump on it.

[MineYoshi]

Well, it's 2016. Any news on mobs in the core code? My suggestion is maybe an API in the core that mods can use to create mobs. The core needs to handle all the cpu intensive stuff and mods just handle the basics. This would allow all sorts of mobs to be created, or none created. It would allow there to be mob mods to handle passive mobs such as sheep, cows, chickens, etc. Would allow there to be mob mods to handle aggressive mobs such as zombies or whatever. Or if the player doesn't want any of it, no mods could be installed.

All it takes is a group of people with the knowledge to get together and get it done. Would probably take less than a month of part timing it. Then the mod makers can get to work putting the new API to use, which would flush out bugs that can then be fixed. A survival world without something to defend against is pretty boring. A world with a ton of farming mods but no animals to farm is also boring. Using the current lua for mobs just isn't cutting it. The majority of the mob code needs to be in the core of minetest to keep performance high and keep glitches low. If I knew how to do it, I would jump on it.

The simple fact is that Minetest Game wouldn't have any "mobs-in"... Since Minetest Game only gives the needed to play. About adding an API to the core, being sincerely i don't know what the devs could think, of course you can do a fork and add the API to a new game based in Minetest :D. But the fact is that the developers agree with adding, coding and debugging the API, also i don't how hard can it be...
Your idea is very great (I should say it, i never thought before adding an API in the core), but that be added is something that i don't know...

[Byakuren]

Well, it's 2016. Any news on mobs in the core code? My suggestion is maybe an API in the core that mods can use to create mobs. The core needs to handle all the cpu intensive stuff and mods just handle the basics. This would allow all sorts of mobs to be created, or none created. It would allow there to be mob mods to handle passive mobs such as sheep, cows, chickens, etc. Would allow there to be mob mods to handle aggressive mobs such as zombies or whatever. Or if the player doesn't want any of it, no mods could be installed.

All it takes is a group of people with the knowledge to get together and get it done. Would probably take less than a month of part timing it. Then the mod makers can get to work putting the new API to use, which would flush out bugs that can then be fixed. A survival world without something to defend against is pretty boring. A world with a ton of farming mods but no animals to farm is also boring. Using the current lua for mobs just isn't cutting it. The majority of the mob code needs to be in the core of minetest to keep performance high and keep glitches low. If I knew how to do it, I would jump on it.

I haven't experienced significant lag from mob mods. Can you be more specific about how lua for mobs isn't cutting it? One place I can think of is pathfinding. The current pathfinding routine (minetest.find_path) gives paths with lots of right angles, which looks strange when mobs follow it directly. This might be fixed with just a better pathfinding function though, rather than a new system specifically for mobs.

What I would worry about with most code being in the engine is a lack of flexibility. Maybe a mob system in the engine could provide switchable behaviors for different things mobs do, including "custom" types that defer to a lua callback. In general, mobs should be easy to interface with and extend from mods, including mods other than the ones creating the mob.

[Mainpage]

I'm a bit late to this party but I'll offer my opinion anyway.
Someone should make a lua mob mobs that actually uses the engines pathfinding algorithm and use good 3d models that are actually consistent with the default minetest texture path (which IMHO most mob mods aren't). Or just modify Pilzadam's simple mobs to use the algorithm (which I'm pretty sure it doesn't, please correct me if I'm wrong).

[cHyper]

I'm a bit late to this party but I'll offer my opinion anyway.
Someone should make a lua mob mobs that actually uses the engines pathfinding algorithm and use good 3d models that are actually consistent with the default minetest texture path (which IMHO most mob mods aren't). Or just modify Pilzadam's simple mobs to use the algorithm (which I'm pretty sure it doesn't, please correct me if I'm wrong).

+1
thats also my opinion...

[Byakuren]

Mobs Redo uses the engine's pathfinding system for longer paths already and the paths are hideous.

[Novacain]

well, this thread is old. One thing that is neglected massively in this thread is that we simply need an API built into the engine for handling moving entities. I say this because it would solve a large portion of the mobs problems.

The other reason I think we need it is because it's a solution that extends to many parts of the game. Mobs could still be mod based (which I think is essential to the essence of minetest), but it would also enable many other aspects to the game. We can now have projectiles, vehicles, dungeon master's fireballs, and many other moving entities that previously would just be cut to speed the game.

On the topic of mobs though, I think that a limit to the number of mobs around a player should be built-in to the mod. I have many thoughts about mobs :P

[Byakuren]

well, this thread is old. One thing that is neglected massively in this thread is that we simply need an API built into the engine for handling moving entities. I say this because it would solve a large portion of the mobs problems.

You need to be more specific. The current entity system already has support for movement.

The other reason I think we need it is because it's a solution that extends to many parts of the game. Mobs could still be mod based (which I think is essential to the essence of minetest), but it would also enable many other aspects to the game. We can now have projectiles, vehicles, dungeon master's fireballs, and many other moving entities that previously would just be cut to speed the game.

I guess understanding this part depends on understanding the previous part. But it looks like you are saying what we already have is adequate, because we can already have projectiles, vehicles, fireballs, etc.?

On the topic of mobs though, I think that a limit to the number of mobs around a player should be built-in to the mod. I have many thoughts about mobs :P

Built-in and configurable, hopefully.

[SegFault22]

The reason we need mobs is to make the game more immersive. With mobs, you can hunt monsters and wild animals for special resources and food, and you can tame wild animals and breed them in a farm for food and other resources.

However, all mods which deal with mobs are severely lacking in performance and features, mainly because they use the Lua end of the system to compute everything. Lua would be fast enough for mobs, if the entire game were written in Lua, but that is not reasonable. The mobs systems are slow because Lua code is being run frequently and its outputs have to be translated into the C++ part of the game, which is considerably slow.

The best solution would be to create APIs for various features of mobs, such as the movement, AI, drops and so on, so that instead of having to program all of the mob system in Lua to be run frequently during the game, the mod developers only have to register a few things in the loading phase and then the C++ part of the game handles the rest. This will be significantly faster, because it only has to translate between Lua and C++ during the loading phase. When it is time for a mob to move, the process occurs in C++; when a mob is killed and items need to be dropped, the table of items and chances for that mob is looked up and then processed to decide what is dropped, and then the item-entities are spawned, all within the C++ part and not having to do anything in Lua; when a mob's AI calls for it to hit a player, the player is damaged and the entire process happens via C++.

Once such APIs are created (I suggest the Lua functions minetest.register_AI() for AI patterns including attacks, minetest.register_mobdrops() for mobs' drops-tables, and minetest.register_mob() which registers the mob and takes parameters for the registered AI pattern to use, the registered drops table to use, a model and a texture), it will be relatively easy to create new mobs which are computed quickly and efficiently.

I'm not sure whether it's best to include attacking mobs' attack damage level in the registered AI pattern, or in the registered mob entry - if it's in the mob's registry entry, different mobs can use the same AI pattern and deal different damage when they attack (such as spiders) avoiding several registry entries with only one or a few different values and the rest being identical; but if it's in the AI pattern, that is simpler because the attack condition(s) are put there.

I have seen that the topic of vehicles has come up - these suggested registry functions would be no good for vehicles, because they aren't designed for that. So, we could instead have another function, minetest.register_vehicle(), which takes care of registering vehicles - it would take parameters covering at least one "seat", possibly a player orientation to use for the seat(s) (for example, a hang glider or a parachute would look weird if the player is sitting while attached), controls assigned to the seat(s), characteristics of movement (cars slide around on flat terrain, planes go through the air, parachutes fall slowly, etc), if they can crash and what happens, and if they require fuel and what kind of fuel it is (and engine characteristics) and also some base numbers used to determine the rate of fuel consumption relative to the engine speed and the movement characteristics (if a car is falling through the air but the player isn't pressing the "gas pedal", only idle fuel consumption occurs just as if it were on the ground - instead of just consuming fuel based on movement speed, where it would run out of fuel quickly while it is falling although it is idling - a rocket consumes fuel based on the burn rate, which may stay constant). It may end up being substantially different from this, but it would still be much better than trying to run all of the computing processes within Lua and then translating everything to C++ function calls from the Lua API function calls.

Sure, we don't need vehicles or even mobs for more immersion-factor, but it would be a great start, especially since the immersion factor is like 0.1 or 10% (1 or 100% is "totally stuck to it"), since we don't have any really good power-system mods or machine-system mods. Technic is pretty good for the first power system mod unique to minetest, but it has some flaws, like the switch-block that you need in order to make any power network do anything, the slow speed of power transmission, and the limited variety of unique machines that do something more useful than automating or improving processes you could do without machines (centrifuge? electrolyzer?), and the limited variety of (or absence of) features not centered on the power network (IC2 for minecraft has a crop-tending-machine that consumes power, but they added several new crops and a really nice crop system that uses sticks and nutrients and an air-quality factor) - if the mod were expanded or revised, possibly warranting a "2" in the name, it would most likely then have more features like crop automation, a better power system (only using the switch for turning a junction on and off, like a cable that can be toggled - it shouldn't be needed to make a network), maybe even a reasonable automatic mining machine, which would increase the immersion factor substantially. The Carts mod is a pretty good attempt to make a working carts system, but it also has flaws, such as the carts sometimes flying off the rails, and the carts not turning naturally at curved rails, and the lack of a cart linking feature (trains of carts, very useful) or specialized carts that carry something other than a player (only makes sense with a cart linking feature) - if these were addressed and resolved, the carts system alone would make the game more immersive "than you can shake a stick at" (20% more orso), because then you would be able to make reasonable railways that serve reasonable purposes, such as moving large quantities of resources from a mine to the surface or from a factory to a warehouse - tracks would actually have a purpose, beyond decoration or being part of an unfinished feature idea first included a long time ago. Heck, we could maybe even get a cart-locomotive that is powered by technic electricity, consuming power from an internal buffer and having inventory slots for extra storage devices, and possibly being recharged when on track that is above or near enough to a special power-transfer node.

People really don't just want some specific feature in order to make the game better. What they want, yet seem to (commonly) never be able to put into the right words, is for the game to be more immersive, by having more cool and interesting features, which bring challenges for the players to achieve something worthwhile - such as mobs to hunt or farm, so that they have a reason to build and expand a farm, for collecting and using the products from animals (wool, food, leather); machines which process materials in ways (electrolyzer, centrifuge) previously not possible via the crafting grid or anything remotely (hand-powered grinder) like it, necessitating the need for a power infrastructure complete with generators, storage banks, distribution lines, transformers, maybe even some switches, to be expanded as the need grows; a reasonable carts system, complete with cart linking, realistic turns, maybe even switches and special tracks (item loader/unloader? just imagine...), making it possible for the first time to haul more than one inventory full of resources (outside of your actual inventory) out of a deep mine and into your base, to be processed and eventually used, while also making it reasonable to build a world-wide train network to facilitate rapid transportation between far-away cities and sites, in the absence of public teleportation mods (or just for the scenery and coolness-factor, even if there are public teleportation mods being used); exotic materials, making wonderful tools yet only occurring deep underground, where it takes a long time and lots of work to reach them, but the reward being tools which seem to never wear out (mese is the new wood) and/or decrease the block breaking time to nearly nothing, and expensive new ingots/shards to sell to other players interested in enjoying their excellent properties without having to go where you went (for a considerable fee, of course, so you can buy stuff you need and go get more of the wonderful stuff).

All of these things will make the game more immersive, bringing reason and purpose to a place once dominated by boredom and abundance of empty space. When the game is more immersive, players want to collect resources and build stuff, because it is more fun, as they overcome challenges and are rewarded for their work. When players are having fun, they usually won't stop playing the game unless they just have to for some important reason, rather than leaving because they started to feel like there's nothing to do or that it is a bore to do what they can do in the game without such features as previously mentioned (or any features like them at all). If we do this, not only will people enjoy playing the game much more, but the community will grow faster than it ever has, maybe even someday exceeding that of Minecraft (as it peaks and drops off, which is inevitable, and appears to have already begun, because they stopped publishing graphs a few years ago, which would obviously show the decline in sales increase velocity, maybe even negative velocity). From the first few mods adding so much more immersion, many more smaller mods will begin to be created, many of those being related to the "big ones" or being addons which expand them with more features or more stuff for existing features. In about half a year after these systems are fully implemented and those types of mods released, the game will become more customizable with new mods than ever before, maybe even passing minecraft mods as well. Nobody knows how far it can go, or how many niches can be filled by mods using these APIs and creating unique features.