terasology / behaviors Goto Github PK

Investigating the move_to behavior node

When trying to use the move_to behavior node in TutorialPathfinding , there were a couple of issues I came across that led to unexpected behavior.

Related to Terasology/MetalRenegades#70

Scenario 1:

Once the entity was spawned, it would just stay still at the spawn location even when MoveToAction was being called and a CharacterMoveInputEvent was being sent. In this scenario, both the location component of the entity and the target field of the MinionMoveComponent would point to the right places, but the entity would just not move. The CharacterMoveInputEvent would have the right fields but the character would not move.

Scenario 2:

The spawned entity starts moving in the direction of the target block but fails to stop at the target position. It would continue moving in a straight line indefinitely. Sometimes, the location component would point to the initial spawn point and would not get updated but the target field of the MinionMoveComponent would point to the right place.

Scenario 3:

Some times, the target would point to the spawn position itself and the entity would remain stuck at that position thinking it had reached its final position even though it hadn't.

Failing test TestActions in Behaviors

When trying to run TestActions in the test directory of the Behaviors module, I ran into some Null Pointer Exceptions that caused the tests to fail. The error is in this line

List<BehaviorNodeComponent> list = categoryComponents.get(component.category);

Why it happens (maybe)

This happens because component here is null. Thus the underlying cause of the error seems to be the AssetManager not being able to load the prefab assets. (The other assets, however, seem to be loaded).

Failure to load prefabs

This is probably an issue with the HeadlessEnvironment itself. This is the line that references the constructor to the PojoPrefab class

assetTypeManager.registerCoreAssetType(Prefab.class, PojoPrefab::new, false, "prefabs");

However, the constructor of the PojoPrefab class (which is responsible for registering the assets ) is not being called for some reason. It should also be noted that the constructors of other assets such as BlockShapeImpl are called.

In order to improve in Intelligent AI behaviour this issue is meant to give examples of intelligent behaviour.
I already made an example tree for an not so intelligent behaviour like a sheep.

This is based on the high level overview Tree from https://github.com/Terasology/Behaviors/wiki/High-Level-Overview
For me the line to make a entity feeling intelligent isnt the behaviour to the player certanly. So as you can see a stupid sheep will follow the player no matter what. That in my mind is non intelligent behaviour. What if a wolf shows up and kills the sheep. Would it still follow the player? I dont think so.
Although the logic of non intelligent behaviour towards the player is restricted to peacefull entitys.
If we think about modern shooters, hostile entitys will behave intelligent, like seeking cover when shot at or firing grenades when youre in cover.
Still i wouldnt restrict such behaviours towards the player and try to make a interacting approach like the sheep-wolf example.

Therefore environmental behaviour is what i want to mostly concentrate in intelligent behaviour.
What can be environmental conditions is the first to think about:

1. Day & Night Cycle
2. Weather Conditions (Rain, Mist, Sunshine, Snow)
3. Events (Forestfire, Thunderstrike, Avalanches, Wolf Hunt, Explosions)
4. Sounds ( Walking, Dying Sounds, Block Break Sounds, Firework)
5. Entity Visability (Seeing an Entity (not Player) )

All of the above are the first one coming to mind and which i think are able to implement in someway in the current behaviour system.
For sake of workflow i will ad some written concepts since making the visual trees right now is laborious.
IWolf , Sheep, Rabbit, Bear) Intelligent

Under certain conditions, DecoratorNodes can have their construct(Actor) called with the wrong Actor argument, causing issues if the Node is reading and/or writing to the Actor's dataMap, messing up both Actor's behaviors and throwing exceptions left and right.

So far I haven't been able to track down the cause and I don't know how widespread the issue is, but it's worth noting down.

Steps to reproduce:

• Create two entities with this as their behavior tree
• Watch the mayhem that ensues with the Timer

What fixes the above error is removing the outer loop, making the Sequence the top-level object (which also makes sense overall, as the loop is redundant). Hopefully if this decides to come up again, we'll have more info, and we'll be able to narrow down the cause.

While loading a game, I see an error:

ERROR o.t.e.u.gson.UriTypeAdapterFactory - URI type interface org.terasology.engine.core.Uri lacks String constructor

From peeking at variables in the stack trace, it seems this is coming from trying to figure out SetTargetToNearbyBlock during Terasology's LoadPrefabs step, and I think it's because gson is trying to figure out what to do with STTNB.movementPluginSystem. (because PluginSystem has a field with Map<Uri, Function<>>)

Should that field be marked transient? Or should something in BehaviorTreeFormat or BehaviorTreeBuilder know that fields marked @In should be skipped, since they expect to be handled by runtime dependency injection and not serialized data?

While testing MetalRenegades which uses FindNearbyPlayers for multiple Gooeys its performance monitor category (F3 then F4) would often be at the top of the time eaters list, at times substantially so to cause quite a bit of lag.

The Gooeys themselves were in at times odd states. I got close to a red one (runs after you and tries to damage you) and while nearby it tracked me fine. At a longer distance where it might lose me it started sort of vibrating in place akin to how the deer can get really vibraty. Found a green one in a market place that worked similarly.

Oddly on top of that in two places I found them flying. Which I'm pretty sure isn't a skill we've taught them! I'm not sure if it is a quirk, it seemed like they were just floating up, possible then correcting and warping back to the ground.

To replicate groovyw recurse MetalRenegades and start a new game with the Metal Renegades template. Find a city and some Gooeys, keep an eye on the performance monitor and their behavior in-game.

Natures

The Natures would be Coded with:

Monster M - Actually unnecessary unless this kind of diversion gets added to another kind of Entity
Peaceful (P) / Hostile (H) * Kind of unnecessary if you know which Dangerous meter which Kind extends.
Trusting (Tr) / Timid (Ti) II Guarding (Gu) / Chasing (Ch)
Solo (s) / Group (g)

Examples for Certain Natures would be

PTrs -> Sheep
PTrg -> Dog
PTis -> Rabbit
PTig -> Deer
HGus -> Bear
HGug -> Wolf
HChs -> Fox
HChg -> Raptors

Differentiating Parameters could be identified with + identifier.

Example

A Monster Peaceful Trusting Solo which can fly would be Coded with:

MPTrs + f or PTrs + f or PTrs + flying

For further explanation:

The Dangerous meter

is distinct by the Damage they do to Entitys.
So Peacfull Entitys shouldnt damage other Entiys while Hostile do.

The Kind Distinction

is based on their behaviour towards Entitys.

Timid: Runs Away from Entitys based on Action or Distance
Trusting: Follows Entitys based on Action or Distance
Guarding: Attacks Entitys based on Action or Distance maybe follows them for a certain length
Chasing: Attacks Entitys based on Distance, no necessary Action needed.

The Parameters

adjust on every monster so theyre open for each to adjust. Therefore crossings from peacfull and hostile mobs is possible by switiching their hostility on event.
The Current Parameters extend the .behaviour and its pre-made behaviours and nodes.

The Occurring differentiation

adjusts around spawning parameters. For right now we spawn mobs for testing by hand but they could be spawned in packs or solo entitys based on their kind.

The Wolf Problem

Wolves are kind of a weird pick to put.
They usually hunt in Packs and they can guard around objectives.
So its kinda hard to put them.
I Usually would put them on Guard since they have that ability. Raptors from jurassic park for e.g. don't show this behaviour. So i think putting them into different groups is reasonable based on the abilities they show with priority on guarding.

So every Guard can be a Chaser but not every Chaser can Guard.
At least that is my mentality towards these decisions.

Further Steps

It would be awesome to define behaviour trees as base for the 4 Kinds. Chaser , Guard, Timid and Truster.
So every coming Mob can be assigned one of these base Natures and then get adjusted on the parameters by fly.
Therefore not every Mob has to get its own Behaviour explored and programmed.... but!... Every Mob can be tweaked towards the experience the developer has in mind.

Exploring the Depth of Switiching Dangerous meters would also be welcomed... The Wolf in Minecraft it self is such a switching Entity and it would be a cool dynamic for players to find out if Hostile Mobs can become Trusting and Switch to the players side.

Cleaning up the engine wiki. It had a page on behavior trees, which are somewhat in flux - unsure if doc should go in Pathfinding or Behaviors, so making issues for both and linking them. Duped by: Terasology-Archived/Pathfinding#21 - pinging @synopia :-)

Original doc (make into Javadoc, readme file, or wiki elsewhere?):

TODO, copied from pathfinding module.

Nodes

Nodes are the core elements of a behavior tree. A node is a piece of code, that is run while an Actor is interpreting the behavior tree.

When run, every node must return one of this states: SUCCESS, FAILURE, RUNNING.

SUCCESS and FAILURE are returned, depending on the behavior node's task. If the task takes some time, a node may return RUNNING.

Decorators & Composites

Nodes may have child nodes assigned.
If a node accepts exactly one child, this node is called a Decorator. Such nodes add some functionality to another node, or subtree.
If a node accepts many children, this node is called a Composite. The order of the children is important, since a composite delegates execution to one of its children.
The three basic composite nodes are:

• Sequence - All children run after each other. Failing child will fail the sequence.
• Selector - All children run after each other. Succeeding child will succeed the selector.
• Parallel - All children run in parallel. When the parallel finishes, depends on its policies.
• Monitor - All children are executed in parallel. As soon as any child succeeds or fails, the monitor succeed or fail.

Some basic decorators are:

• Invert - Inverts the child's state.
• Timer - Stops time and finishes with given state after defined duration.
• Repeat - Repeats its decorated behavior forever.
• Delay - Delays the execution of its decorated node some time.

Actor and interpreter

A behavior tree can be assigned to be interpreted by several different minions. So, for each actor the tree has a unique state (state of timers, sequences, etc). This state is realized using a Task class. Instead of handling the actual work itself, a Node delegates its work to a Task class. So a node just create a Task for every actor, where the custom state data can be stored safely.

The models of the entities moving based on some behavior are rotated according to where they move.

When doing a cleanup after the switch to gLTF I had to rotate many source models because they walked backwards.
Also I recently observed that while with the rotated model, gooeys in gameplays using Behaviors now move forward, they don't in GooeyDefence where there's no rotation applied on movement.

This makes me believe it's a matter of the rotation application in Behaviors rather than an issue with the gLTF code in the engine.

With multiple characters using the same stray behavior, a target update on one character updates the targets of all stray characters. This can be seen in the gif below, with insensitiveDeer characters from Terasology/WildAnimals:

The stray behavior works perfectly with only one character, but with more and more characters the movement becomes more and more erratic.

When using the MinionMoveComponent to move characters, erratic movement/movement bugs appear when the game delays or has a low frame per second count (caused in-game, by having the window unfocused, etc). Here are some issues that have been observed in the current master branch of Terasology/MetalRenegades:

Major Bugs

Jump Looping

When a character is moving to a target that is blocked by an obstacle, a character will simply jump until they reach their target. If they cannot jump over what they are facing, they will endlessly jump as intended. But, when the game lags the character can get itself stuck inside the wall/corner. Now when the character jumps, they instead teleport high in the air and then fall down to the ground in a repeating loop:

Here, the character is attempting to travel outside the building, but has gotten stuck inside the wall and has gotten into a 'jump loop'.

In addition, when the character is manually taken out of this loop, any normal jump they make will instead be an instant upwards teleport and fall.

Character Levitation

A variation of the bug above, sometimes characters will start floating upwards into the sky; either when stuck. or sometimes when standing still:

In characters with behaviors that change when players are around (friendly, angry, etc.), the levitation stops as soon as the player steps in the immediate area of the ground where the character floated from.

Model Offset

Normally, a character's 'center' is at the exact centre of the character's model. But when the game lags a bit, this model becomes offset from the character's center position. Now when the character moves, the model rotates around this centre position, with a very unnatural motion.

Minor Bugs

Slight Stopping Movement

Normally when a character has their speed set to zero, they stop in place. However, with lag these characters will sometimes have a slight forward movement while stopped.

Sudden Erratic Motion

Normally a character will face the direction that they are travelling. However in some cases with lag, characters will sporadically rotate quickly either in place or during motion.

Stuck in one blocks spaces & fences

Observed specifically in Terasology/MetalRenegades#11

Sometimes, when a character with the gooey model (less then one block high) walks though a fence or one block high space, they suddenly stop and don't move until the fence or block high space is broken.