[MOD] entity_ai - monster AI Framework [entity_ai] [WIP]

[sofar]

Sofar's Monster/Entity AI

See: https://github.com/sofar/entity_ai

Important Notice: This project is a work in progress and has an unusual license. Before contributing please read https://github.com/sofar/entity_ai/blob/master/readme.md.

This code may not work at all. The API is not stable.

TL:DR: the mod is AGPL-3.0/CC-BY-ND-4.0, but the CLA permits me(sofar) to submit all contributions to minetest_game and relicense it more permissively and compatible with mtg. If you contribute to this project you agree to these terms.

Youtube video about this code: https://www.youtube.com/watch?v=7_nUQRWeD7Y&list=PL0q7atYslWifTuX60rtCaocQiYUSdtZJP&index=4

[sofar]

So what is in this code?

- A pluggable API with support for all base stuff that monsters need to do (like walk, find specific nodes, run away from aggressor or attack).
- Monsters are entirely created by tables, not code. Monsters are defined as tables that specify the behavior and how to react to changes.
- Path code can be improved on benefiting all monsters
- State transitions are inherent part of each monster, monsters can behave entirely different based on a state transition. For instance, you could change textures of the monster, or become aggressive
- Two modeled monsters, with two full state tables.
- Sheep is mostly complete
- Stone Giant needs more states finished and a few bits of AI code written to be complete

Yes, it's Lua code. I've determined that for single player content Lua is perfectly fine and minetest can handle the load well. I don't intend to make this monster API useful or even performant for multiplayer (although I think it'll do just fine). If this doesn't work well in multiplayer, I don't care.

[Ferk]

Awesome! I like how the AI tables look like declarative programming. Which is quite appropriate for AI.

Though it might make sense to separate the animation/sound definitions from the AI table so it could be possible to reuse the same AI for more than one mob (eg. chickens and sheeps may have similar behavior but different sounds/animations, for people who might find complex to change the AI but still want to make a mob).

[cHyper]

+1 nice...

[sofar]

Though it might make sense to separate the animation/sound definitions from the AI table so it could be possible to reuse the same AI for more than one mob

The AI is entirely outside of the monster definition table, so it's all reusable.

The setup is done in such a way that AI code parts are not part of the monster table, the monster table just specifies the API methods available (think of it as a library of AI code bits).

I've called these code bits "drivers", and they currently live in init.lua. Both monsters in the code currently use many of the same drivers.

[Ferk]

The setup is done in such a way that AI code parts are not part of the monster table, the monster table just specifies the API methods available (think of it as a library of AI code bits).

That's nice. But as the driver ecosystem grows maybe the state definition with the parameters for the drivers could become more complex. Maybe the states could be defined in a sub-table?

So we can do something like:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

local rabbit_script = {
    driver = "roam",
    properties = {  ..... rabbit specific properties ... },
    animations = { .... rabbit specific animations ... },
    sounds = {  .... rabbit specific sounds ... },
    states = sheep_script.states
}


Then the parameters for each of the "driver-driven" states can be shared, and perhaps use the properties for slight variations.

This is just brainstorming, though. I find the overall design very interesting.

It could be fun to play with it and see how the entities interact... like having wolfs that hunt sheeps and see how the sheeps flee and react.

[sofar]

This is just brainstorming, though.

The layout of the tables itself is up for discussion - I think the layout shows you want my intentions are - providing state drivers with the specific state information needed for that driver.

My approach was to come from the `state` angle and then table off of that. Other approaches may be better, but it's entirely arbitrary for the code - it just serves readability.

[Ferk]

@sofar, could you clarify this part of the license?:

1) you can re-distribute the artwork, but only if you: a) properly attribute b) do not modify the code

"do not modify the code" as in the code of the mod?

Does that mean it's not possible to make pull requests in github? as this would involve editing the code and having the assets in the forked repo. Also this would mean the artwork is actually under a different license than CC-BY-ND-4.0, since I believe this one would not have that limitation (even though it's also sadly restricted in that it doesn't allow modifications of the artwork...).

[sofar]

1) you can re-distribute the artwork, but only if you: a) properly attribute b) do not modify the code

Does that mean it's not possible to make pull requests in github?

You can modify the code, permitted you use it for your own purposes, or make it available to users who play on your server, and make it available to anyone. If you only modify the code, and you have not modified the artwork, the -ND clause does in the artwork does not activate.

If you modify the artwork, you can not redistribute it. Of course, you can submit a PR change at all times back to my github repo, that may be technically "distributing" but in the spirit of the project is exactly what we want - you're not going to get into trouble for that.

So basically, forking for the purpose of contributing the project is expressly permitted. The "personal use" clauses of the licenses allow that.

[sofar]

The readme originally stated:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

1) you can re-distribute the artwork, but only if you: a) properly attribute b) do not modify the code

But that's supposed to read:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

1) you can re-distribute the artwork, but only if you: a) properly attribute b) do not modify the artwork

Hopefully that clarifies everyone's understanding now. I've fixed it up in the repo.

[zorman2000]

Is development on this stalled? It would be a pity, since it looks promising!

[azekill_DIABLO]

it looks terribly awesome!

[sofar]

Is development on this stalled? It would be a pity, since it looks promising!

I've been spending time on the upcoming minetest release, and getting a bunch of other features in minetest_game that needed help, so yes, this has taken a bit of a pause on my schedule. No worries though, I'll get back to it soon.

[Wuzzy]

CC-BY-ND-4.0

:-(

[sofar]

CC-BY-ND-4.0

:-(

Please read the full explanation why. Once this mod takes off, the -ND stuff goes away.

[twoelk]

(1) you expressly guarantee that you are the sole author of all
parts of the contribution.

so I can not adjust a random mob from another mod to work with this?

[sofar]

so I can not adjust a random mob from another mod to work with this?

Only if you are the sole author of that mob, or the assets. If someone would accidentally put in a model or code that has an incompatible license, it would make the project unmergable into minetest_game, which is the end goal.