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?

[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.

[ghost]

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