Inactive Three Tier AI

[Cervator]

Sounds great to me, would love to see it

Reads a little confusing though, you might want to use "mob" in place of "AI" sometimes, the first is more of an object while the latter is more of a concept

I figure you mean Machine Learning for some of those spots, where the AI functionally is literally "breeding" new AI Component settings (by spawning a new mob with the altered AI Component). Which is indeed very cool and would be awesome to have.

Looking forward to seeing some stuff hit GitHub! Although I'll be mostly afk today - taking off Monday and Tuesday though, so I'll be able to review more then

 

[Esereja]

Git hub pull is ready(my opinion). https://github.com/MovingBlocks/Terasology/pull/385

 

[Esereja]

I am going to make new simple evolutionary AI, which simulates ant hives live. It is school work for evolutionary computing. You will hear more about it soon.

Then questions:
can enity have more than one component than implements EventHandlerSystem or UpdateSubscriberSystem as adding portal combonent to player doesn't make it portal.

second question why adding healtmanager to enity and adding ondeath doesn't kill enity. I managed make mobs to die from faling by adding healthmanager. it was only typo which caused them not die.

 

[Cervator]

We talked some on IRC - wanted to drop this link to a metabolism thread by B!0HAX where we had some related discussion on effects that could get involved with potions, food, or other stuff that gets consumed to go with your hive AI and hunger system

As for multiple components that implement the same systems - I believe that should be possible. Making the player a portal may not work right now as I think I might have hard-coded in that a portal must also be a block to spawn stuff.

 

[Immortius]

To go pedantic for a moment, components never implement EventHandlerSystem or UpdateSubscriberSystem. ComponentSystems do. There is also no strict relationship between components and component systems.

Anyway there should be no issue with an entity have multiple components with systems implementing those, or even multiple systems related to the same component - if events aren't arriving or update isn't being called for a correctly set up component system, then that is a bug.

 

[Esereja]

Immortius Well it seems to be bug, as hunger system worked well in main. But after I changed it to mod nothing happens. No errors just nothing. stuff from mod can be accessed. It just doesn't run componentSystem part or atleast updateSubrider part.

no more starvations not even for mobs in portal mod.

I will go bug hunting as I realy need it working.
and my code is at my github

SOLVED

 

[overdhose]

hey esreja, did you create a subfolder called "\src\main\java" in your mods folder and a mod.txt file? Just guessing here at what the cause might be.

nm looks ok

I think the problem is in here for one :

@ReceiveEvent(components = {ConsumableComponent.class})
public void onActivate(ActivateEvent event, EntityRef entity) {
logger.info("Eating food: "+entity.getId());
//TODO make to recognize if object is item
if (!entity.hasComponent(ItemComponent.class)) {
BlockComponent block = entity.getComponent(BlockComponent.class);
}
ConsumableComponent consum = entity.getComponent(ConsumableComponent.class);
EntityRef player =event.getInstigator();

//reduce blocks uses
consum.uses-=1;
logger.info("Food uses:"+consum.uses+"\n");

//eat it
player.send(new EatEvent(player,consum.filling));

//destroy it no more uses
if(consum.uses<=0){

if (!entity.hasComponent(ItemComponent.class)) {
Block currentBlock = worldProvider.getBlock(block.getPosition());
worldProvider.setBlock(block.getPosition(), BlockManager.getInstance().getAir(), currentBlock);
}
entity.destroy();
}

}

block.getposition() : block was defined within another if, which shouldn't be the case I think

and import org.terasology.events.ActivateEvent; was missing from imports

and a missing import in Hungersystem :
import org.terasology.events.HealthChangedEvent;

here's what I think it should look like, more or less

@ReceiveEvent(components = {ConsumableComponent.class})
    public void onActivate(ActivateEvent event, EntityRef entity) {
        logger.info("Eating food: "+entity.getId());
        //TODO make to recognize if object is item
        ConsumableComponent consum = entity.getComponent(ConsumableComponent.class);
        if (!entity.hasComponent(ItemComponent.class)) {
            BlockComponent blockcomp = entity.getComponent(BlockComponent.class);
           
            EntityRef player =event.getInstigator();
           
            //reduce blocks uses
            consum.uses-=1;
            logger.info("Food uses:"+consum.uses+"\n");
           
            //eat it
            player.send(new EatEvent(player,consum.filling));
           
            //destroy it no more uses
            if(consum.uses<=0){                       
                Block currentBlock = worldProvider.getBlock(blockcomp.getPosition());
                worldProvider.setBlock(blockcomp.getPosition(), BlockManager.getInstance().getAir(), currentBlock);
                entity.destroy();
            }
        }
        else
        {
            EntityRef player =event.getInstigator();
           
            //reduce blocks uses
            consum.uses-=1;
            logger.info("Food uses:"+consum.uses+"\n");
           
            //eat it
            player.send(new EatEvent(player,consum.filling));
            //destroy it no more uses
            if(consum.uses<=0){
                entity.destroy();
            }
        }       
    }

 

[Esereja]

Yeah I got it solved proplem was including those, AND biggest was my mod wasn't in settings.gradle

ty

 

[overdhose]

ach settings.gradle was the last missing piece indeed... thanks I was pondering what I was still missing

 

[Esereja]

Hunger System ready and in pullreguests.
I think we need to make Checklist for mod builders.


I code AI system now

 

[Cervator]

Bump! Time to talk some AI again. I am not an architect, however, so I leave the fancier implementation details to others. I just want to get something kicked off again

While tinkering with advanced gelcubes / holdings / civilization / portals with Stuthulhu we hit a constraint of our current AI setup - different kinds of behavior is embedded in different systems that compete for the same resource (the attention of the creature entity the AI is attached to).

• SimpleAI makes a creature run around like a maniac but not much else
• HierarchicalAIComponent is a much fancier version with lots of stuff (movement and behavior variants), but isn't very extensible or modular
• SimpleMinionAI allows creatures to do work as per the player's commands (miniions)

We used SimpleMinionAI to try to get Oreons spawned from portals to do work on their own. However, without SimpleAI they all would just bundle up below a portal and stand there. With SimpleAI added in they'd run around but would conflict between work and play.

So what we really need is a generic "decider" System with the ability to take in stimuli, prioritize, then take an action and commit to it for a time period (unless interrupted by something dramatic). Additionally it would need to support doing that with all stimuli, priority weights, and actions available defined in other modules.

Upon reviewing the 3-tier design ReleeSquirrel describes above along with other snippets here and there I came up with an example I think is probably not the right design by writing it up helped with my train of thought so I'll present it here with the caveat that it is probably wrong

Spoiler: Food for thought - but don't eat it!

A new EntitySystem type ("ThinkerSystem" ?) that keeps state data in a brain. Accepts "stimuli" from the world (events subscribed to - but won't know them so they'll have to register themselves to the brain) and triggers actions (could later inject desires/beliefs in the middle). Example System implementations somewhat akin to the 3-tier design:

* InstinctSystem - very basic one-tier implementation for "dumb" creatures - directly reacting via instinct to stimuli but not thinking ahead or coordinating (when hungry go eat, if attacked either flee or bite back)
* PlannerSystem - two-tier implementation meant for AI creatures that do some limited planning and collaboration (gather food if the group is low, create shelter if any member of the group is without, organize settler/combat parties to travel places to do things)
* ReasonSystem - full 3-tier implementation including more advanced reasoning (civilization level, economy, technology, ethics ...)
* MusicDirectorSystem - example of a wildly different purpose for a "brain", this one meant to attach to a player entity to direct music choices by taking in events (combat, death, crafting, farming ..) and conditions (elevation, biome ...) near the player to decide what piece of music to play (each piece of music would come with a set of weights, a combat-intended piece would have a high combat score)

So what is probably wrong with that is that with a generic enough "ThinkerSystem" and good enough integration options with stimuli / action Systems & Components you don't need the hierarchy in the first place - there's just "ThinkerSystem" and all it does is contain a brain (data stored in the associated Component) and logic to take in generic stimuli (events) that get processed by other modules to come up with a priority per action it is aware of (again though other modules) and make a decision once in a while.

I figure ES events are what we'd need for the communication - Immortius you'll have to advise me here. Haven't quite gotten to where I can exactly picture what goes where, can just come up with examples, such as:

• Basic GelCube is a Thinker, but it doesn't have any thoughts on its own so it doesn't do anything. It might be initialized with an "IQ" (in ThinkerComponent) to suggest what sort of stimuli/actions it can understand
• Add "RunAroundAndJump" which is a Component akin to the current SimpleAI which introduces the thought of wanting to run around and jump all the time (said running around action is controlled by a RunAroundAndJumpSystem). It is a low priority / weight thought, but as the only one present the creature always runs around and jumps, like current gelcubes
• Add "HungerComponent" - hey, we have this one! But in addition to introducing hunger as a concept it now gives the gelcube awareness of hunger with a hunger counter in HungerComponent. A hunger thought is present/registered with a priority based on the counter - the hungrier the creature is the higher priority the thought is, so eventually it'll override the "RunAroundAndJump" thought. When it does the creature takes the action of fetching food and eating it, thus lowering the hunger counter (exactly how that works is up to HungerSystem)
• Add "ProcreationComponent" - comes with a thought of wanting to find a mate and create offspring. This thought starts with low priority and increases slowly with age, and/or maybe from other interactions such as having been able to eat immediately when wanting to 10 times in a row (indicates plentiful food availability / happiness). When it is high enough priority to be considered the gelcube finds a mate and they pop out a tiny new gelcube

Lots more easy scenarios to think up. If a creature is starving due to being unable to find its favored food and somebody introduces a CannibalComponent then eventually maybe creatures will start eating each other out of desperation (if the creature is coded to resist cannibalism / priority gets a severe penalty) or frivolously (creature is coded to find cannibalism natural / priority gets a bonus)

Point being - we add thoughts through modules that contain stimuli (I feel hunger) and actions (I fetch food and eat) and the ThinkerSystem picks a thought to execute based on priorities calculated by the data in the Components of the modules and maybe the IQ and preferences defined per creature prefab in the ThinkerComponent (an orc warrior might have mediocre IQ and hostile tendencies while an elven wizard has high EQ and pacifistic tendencies). ThinkerSystem also would only update the active thought once in a while and let the blessed System of choice do work through its update method. However, ThinkerComponent & ThinkerSystem never once explicitly refer to any module for actual thoughts.

Might be sort of similar to how Portals currently spawn creatures without ever referring to exact creatures, only types (like "gelcube") defined on portal prefabs. Then exact creature prefabs like "gelcubeBlue.prefab" registers itself as type "gelcube". But the exact implementation probably is much fancier involving events and fun stuff like that.

Okay ... if anybody is still reading at this point, please comment. This has probably gotten to be too much of a wall of text already ...

(Also also ... : Later on fancier AI decision models could probably be injected between the Thinker and the Thoughts, like adjusting priorities based on emotions, beliefs, prior experiences etc, akin to some of the advanced stuff ReleeSquirrel went over. But in the meantime we can start just by having a gelcube/oreon that can both run around like an idiot and go fetch food and eat when it gets hungry)

 

[Immortius]

I'll reply in more detail on the weekend, I need to think it through. However, some immediate thoughts:

• Events are great for situations where the sender doesn't care about what happens and the effects are dependent on the receiver - DamageEvent for instance can be send to blocks, creatures, structures, and each determines how to react. Telling a group/civilisation level entity about the death of one of its members would also work well as an event.
• Events aren't so great where the sender cares about the effect, although they can check afterwards. And they absolutely can't be used to request information.
• Events are a big part of the multiplayer support though, since they are one of two mechanisms information can be transferred between server and clients. Probably irrelevant for AI as it is server-side.
• The alternative mechanism which is currently in the multiplayer branch is to have an EntitySystem register itself into the CoreRegistry against an interface, which can then be retrieved by other systems (or injected with @In). This allows systems to communicate directly with each other, while still allowing the potential for modules to override them (by supplying their own system that implements the interface).
• If there is any state that should be persisted, use entities. Any state that is transient can live in the systems however. It will be wiped, but can be rebuilt during the load process as necessary.

So those are the ingredients. So the question is how best to make use of them and what degree of extensibility is required. For instance, if you want a module to be able to add a new behavior like cannibalism, you probably need to the individual-level system to allow behavior systems to plugin in, so when it comes time to decide "what now" it will consider it.

Thinking in terms of desires and behaviors that fulfill desires seems like an interesting approach - when a creature is hungry, it can check each behavior it has that provides sustenance and choose based on priority and situation, and use that to fulfill the desire.

 

[Cervator]

More musings / examples based around food

Hunger module - focuses on giving things hunger and thus a desire to acquire sustenance

• Dependency: None
• Stimuli: Hunger
• Thought: Want to acquire sustenance and consume it
• Action: Eat item with sustenance value

Ritualism module - focuses on providing expressive activities seeking to impress some divine entity or improve social standing

• Dependency: None
• Stimuli: Fervor. Also potentially a secondary "bless" stimuli if having worshiped some deity enough to warrant a reward of some sort
• Thought: Want to impress / improve
• Actions: Sacrifice object of value, dance ritually, build altar, etc. Also: Attain Blessing which could divinely provide some resource, like sustenance (if hunger enabled), if the entity believes it has done enough to deserve a prize (and a source agrees)

Cannibalism module

• Dependencies: One or more of: Hunger, Ritualism (Soft dependency? Must have at least 1 available from list)
• Stimuli: Hunger, Fervor (if available)
• Thought: Eat, impress (if available)
• Actions: Consume member of own race for ritual purpose (sustenance optional/incidental), unlock sustenance value in members of own race from hunger (may have penalty to thought priority if race is counter-cannibalism)

Predation module

• Dependency: Hunger (Hard dependency)
• Stimuli: Hunger (from hunger module)
• Thought: Hunt creature, Eat (from hunger module)
• Action: Unlock sustenance value from creatures

Farming module

• Dependency: None. Soft dependency on hunger, alchemy?
• Stimuli: ? Desire to create resource? Hunger if enabled
• Thought: ?
• Action: Unlock additional resources (crops with sustenance, herbs with alchemical uses, etc)

Writing up stuff like this seems good for uncovering the tricky spots. Like:

• Farming - if set to a hard dependency on hunger it is easy to make the farming stimuli hunger - if hungry (or smart enough to plan to not end up hungry) then farm something to increase availability of food. However, what if a crop has non-food value, or hunger is disabled?
• Predation - example of a simple module that requires another system (hunger) and unlocks additional options for it - namely hunting things that can then become food (the non-basic food sources would have to be flagged as such in a natural fashion)
• Cannibalism - example of a module that could offer different options depending on what other modules are available, namely gaining sustenance or fervor from your race-mates. Could be frowned upon or encouraged depending on racial preferences (a modifier to thought priority)

Playing with what could depend on or offer extensions to other modules gets hairy fast

For example: Hunger introduces a "sustenance" value to things. Exclusive to itself it might only allow consumption of simple / already processed items that just offer straight up sustenance. Can hook in extensions that might offer other sources and multiple thoughts to choose from. Say somebody adds a new "fruit" module just to add the blocks/items without thought of sustenance, it could be used completely without hunger enabled: Do we ourselves just toss in sustenance values as an optional value if hunger is enabled?

I guess so, wonder if that'll cause bloat over time (add all the things to all the things, just in case). Doesn't seem like there'd be a good alternative so maybe it isn't a big deal. Which side has primary maintenance responsibility over time? Does hunger say "if apple available from fruit module then make it sustenance 10" or apple say "if hunger module enabled then i'm sustenance 10" ?

Main recollection from MC is a case where a tunnel borer can drill through vanilla blocks but you have to configure the server with additional block IDs or the borer gets stopped by blocks from other mods. With a flexible enough module system maybe we can fix that within the modules as optional facets rather than make server admins deal with it?

Edit: Added in a divine source for sustenance in the rituals system I forgot about. Also note that this is more of a thought experiment for helping design the AI system than me saying we should implement all the things

 

[Cervator]

And a bit more:

It becomes obvious it'll be tricky to map creatures to roles (particular good at hunting, averse to cannibalism, when you paradoxically know neither what creatures you'll be dealing with, nor their roles, and not even whether possible roles (modules) will be active or not.

I wonder if it might be helpful to consider some sort of simple text-based trait system where as an example "hunter" is defined somewhere (and hey, maybe give it an icon if that would be neat) as nothing but a named trait that modules can then say "if something has this trait then this module's specialty will count double toward related thought priorities"

If we use a simple centralized list with nothing but the name in text (and optional icon) maybe we can pull in new traits added in new modules fast enough to have an authoritative collection of traits (if not yet corified the trait would only work in the module introducing it or maybe explicit dependencies). Kinda like the creature type list in portals, meant to help coordinate different thoughts across modules without knowing pretty much anything in advance.

Sort of like if MC had a master list of block traits in strings, so any block that registers as a "common mineral" in any mod anywhere could be bored through with said tunnel borer from an earlier example ("marble" in that case would adopt the block trait "common mineral" which always would allow a tunnel borer to dig through it)

This may not sound like it makes sense. Inside my head I think it does, but no guarantees

(I have a sneaking suspicion I'm trying to reinvent some facet of our ES without realizing we already have an option to do what I'm pondering)

 

[Immortius]

Ok, my thoughts:

• Don't overengineer towards extensibility, especially when you are unsure how things should work. You will likely get it wrong, or end up with a system too unwieldy for anyone to use.
• Components and Entities are your data model for describing the world. You should design these keeping in mind how they will work when defining prefabs. It is also an option for things to be composed of multiple entities, although this isn't supported as much by prefabs. Players are composed of multiple entities in the multiplayer branch for instance. You can divide a creatures mind from its body and have them as separate entities, which allows mixing and matching them.
• To actually provide behavior to components or combinations of components is up to the systems - there is no restriction to what you can do with systems. You can have one big system that handles all of the behavior related components, or multiple systems per component, or systems that hook up with each other or whatever.
• I would recommend against spreading across a lot of modules. It makes management difficult, and you'll run into trickiness with dependencies. I would suggest putting all the AI stuff into a single module, and having a second module for actual creature prefabs.

As for the behaviors...

Farming does not directly address hunger in my mind. This is where the AI tiers come in. A civilisation has a desired to have food available for its members. An individual has a desire to eat food, but when the individual isn't hungry or otherwise suffering from an immediate desire like fatigue, they switch over to working on a higher level goal like farming. What they do is influenced by the need of the civilisation, their personal preferences and skills, and what can actually be done. Farming is one of these higher level goals.

To expand on this, the tiers from lowest to highest area might be:

• Ambulatory and motor control - translates from a desire to go to X or interact with Y into the low level movement and manipulation necessary to do so. Essentially pathing.
• Individual level - determines individual goals and enacts them.
• Group level - determines group level goals and enacts them.
• Can keep going up. Can have a village composed of multiple groups, and a country composed of villages. Each village has its own needs and desires, but is influenced by the goals of the country. Almost certainly overkill at this point.

 

[Cervator]

Points taken and appreciated. I do tend to over-think when unsure

Will play with some ideas in code sometime. Am suddenly puzzling about the idea of also attaching Thinker to Holdings and such now too for the tier fun ..

(Edit: or rather, do a component/system per tier and attach as appropriate)

 

[Cervator]

Bump! Still moving threads out of the Incubator and ran across this one. Pretty sure I've got it open in about a dozen separate tabs, even if most of those are now actually a URL dump in my Evernote after a browser crash ...

Bumping it to the top as it has a lot of old AI musings that we've got a whole new generation of contributors that may never have seen this. And also for myself since I totally hope to still one day make it back to coding content, haha

@synopia - ping! For special interest regarding the behavior trees that are sort of more the current generation AI.