Basecamp for discussions related to how NPCs (both critters and humanoid) move around, and about the AI governing their aggressive behaviour. Also discussing Navmesh and related navigation tools.
Two navigation-related tasks landed in the Code deck. The Pathway one is especially simple, so great for newcomers! (also doesnât require any project knowledge)
https://open.codecks.io/unity-open-project-1/decks/15-code
I was looking into it until I saw that the critter already have a Roaming State.
pkso9q
Maybe I donât understand the card, so could you clarify what features are missing?
1 Like
Hey @Dnalsi !
Indeed, there is already one of the roaming strategy implemented (roaming randomly around a center point / spawning point), but currently the movement is fully set in FSM all the same for all the non static critters. Here the idea is to be able to support at least one additional strategy which is the roaming following a path defined by a list of ordered positions/waypoints (Vector3/2) and be able to inject this strategy at prefab level to be able to change from one type to another or to change the list of waypoints depending of the NPC.
Based on my own experience on this topic, the idea might be to inject the desired strategy and the associated config (roaming radius/waypoint stop duration/list of waypoints) from a new MB controller (NPCMovement) (see how Damageable is doing for dropping determination) and next in the FSM when defining the roaming action use the provided strategy and the config to drive the NavMeshAgent next destination.
I hope it clarifies the topic in the right direction 
2 Likes
Hi,
I saw that the âPathway componentâ is still unassigned
Iâd like to give it a try as my first contribution to the project. The example on the card is specified quite well. Iâm planning to implement something like that.
@Dnalsi Are you still planning to work on this? In case you are, I can choose a different task.
@cirocontinisio Please let me know if I can start to work on it.
@murkesz No, something has come up so you are free to work on it
Hi @murkesz , welcome on board! The cards are never assigned until the core team has confirmed / merged a proposal from the community. The aim is to not discourage anyone to work on any task even if someone else has already started to work on it.
Here is the case, there is someone âAlexandreGheraibiaâ who has already opened a PR for this feature: Pathway component by AlexandreGheraibia ¡ Pull Request #359 ¡ UnityTechnologies/open-project-1 ¡ GitHub. Looking at the number of commits pushed in the last couple of days, I would say it is not finished yet. (Actually, I would suggest you to amend your first commit when changing it or wait to have something working before creating your first commit. Here for instance, not sure that 35 commits for 4 new files, is really a good practice)
I do not know who he is on the forum and the quality of his implementation. There are not a lots of details in the PRâŚ
So, you have two options:
- Option 1: Pull the PR from AlexandreGheraibia and have a look at what he is doing and provide comment in his PR where you see area of improvements or propose to work with him on it to build something together.
- Option 2: Propose an alternative solution to address this feature and open your own PR for the same card.
In general, I would suggest to post here what is your approach, how it works internally and how other will be able to use it. Add some screenshots / video are often really appreciated by the core team and the community. Personally I am doing both implementation and providing my approach at the same time, even if it means changing the implementation later based on the feedback, I feel less frustrated like that: crafting something and not just designing a proposal, it is up to you 
Good luck and have fun in contributing to this project!
1 Like
Hey yâall! Jumping in the discussion from the Quests and Scenario thread one, a part of which regards this thread too.
Long story short, we were discussing about a quest in the Rocky Path area where youâd probably need to find a special Rock Critter Egg from one of the Rock Critters nests. We were wondering if this could be achieved after some kind of puzzle thinking, regarding how Rock Critters behave. We imagined them being very protective of their eggs and very aggressive. So they wouldnât move much and they would definitely attack you if you approach them. They would also be really strong, in order to force the player to think of a strategy to distract them (instead of attack them) by throwing an item that would make them abandon their nests (something that would look like one of their eggs). You think its doable/interesting to work on? Donât know if itâs something to be officially implemented in the end, but why not try and see (stating that because this is a community suggestion). I would also like to share with you an interesting gameplay example @calculus7 has posted, which is pretty much on point on what we were thinking about:
You can go to 10:05 to get a glimpse of what the game is about (really fun game, and surprisingly relatable at some aspects). Also given the fact that Rock Critters can headbutt into things, we might want to make them headbutt one another and have them either stunned or fallen from some height (this probably regards the Animation?). You can go to 28:55 to see a similar example on the above video.
Any comment on that would be really appreciated! This is just an idea, to see if this could be done/is interesting. It could also affect the Whiteboxing of the Rocky Path level as well. Cheers.
3 Likes
Hey @treivize ,
thank you for the clarification and the suggestions.
Iâve checked the PR you mentioned and it looks promising even if the solution it provides is not well documented yet. Since I would not be able to create a better tool at the moment, Iâm going to turn my attention toward other tasks in the project. (Fortunately there is plenty. :)) Cheers.
2 Likes
@itsLevi0sa , happy to see you here in a coding thread :). I really like the idea of having some puzzles mechanics in the game and not only killing critters, talk to NPC and cook some recipes.
@cirocontinisio , Actually regarding the pathway position list storage, it is requested to store it into a new component (MB script) but it would be great to store it into a SO instead and then in the NPC movement component defines a default pathway SO and be able to change the pathway SO based on a PathWayChannelEventSO that could be triggered to switch from one path to another based on a trigger in the game (accomplish a quest, trigger something in the scene, kill a critter, etcâŚ), do you think it could make sense here?
@treivize Hello there! I do occasionally pass by, as a silent observer ^^ Appreciate all the great work! (so many people I never really cross paths in the threads but would like to give a big thumbs up!) Anyway, hope my post was not out of context of what should be discussed here, and if it was, well, consider this a happy break. Good luck, keep it up
Hello,
Here is a proposition to implement the NPC moving on NavMesh. Ready? Steady? Go!
As said above currently the moving critter is fully driven by the FSM with absolute conditions and actions, so there is no capability to assign different movement from one critter (or NPC) to another without duplicating the whole FSM table.
Here again, the approach could be to move the FSM configuration of the actions and conditions related to the movement into another SO attached to the game object like done with Damageable and Attack scripts. And next fetch this configuration in FSM to drive the conditions/actions.
So a new script NPCMovement would be added and it would hold one NPCMovementConfigSO and one NPCMovementEventChannelSO.
There would be two implementations of NPCMovementConfigSO:
-
RoamingAroundCenterConfigSO
This config would describe the movement of the NPC with a random roaming strategy around a center (spawning point or a custom point) a maximum distance around this center (radius), the speed of the NPC and how long the NPC would stop between each random destination. This would map the current hard coded strategy into FSM (just adding the capability to define a custom center instead of always being the spawning point). -
NPCPAthwayConfigSO
This config would describe the movement of the NPC following a path based on waypoints. Like the previous strategy, the speed and how long the NPC would wait at each waypoint before resuming his movement could be configured independently and out of the FSM.
On the FSM side, the configuration would almost not change: only the actions/conditions implementations of the currently wired roaming conditions/actions. Here both movement strategies are mapped to 2 action strategies injected through a controller action would replace the current RoamingAroundSpawningPointActionSO: NPCMovementActionSO
[CreateAssetMenu(fileName = "NPCMoveToNextDestination", menuName = "State Machines/Actions/NPC Move To Next Destination")]
public class NPCMoveToNextDestinationSO : StateActionSO
{
protected override StateAction CreateAction() => new NPCMoveToNextDestination();
}
public class NPCMoveToNextDestination : StateAction
{
private NPCMovement _npcMovement;
private NPCMovementConfigSO _config;
private NPCMovementAction _action;
private NavMeshAgent _agent;
public override void Awake(StateMachine stateMachine)
{
_agent = stateMachine.GetComponent<NavMeshAgent>();
_npcMovement = stateMachine.GetComponent<NPCMovement>();
InitMovementStrategy(_npcMovement.NPCMovementConfig);
}
public override void OnStateEnter()
{
if (_config != _npcMovement.NPCMovementConfig)
{
InitMovementStrategy(_npcMovement.NPCMovementConfig);
}
_action.OnStateEnter();
}
public override void OnUpdate()
{
_action.OnUpdate();
}
public override void OnStateExit()
{
_action.OnStateExit();
}
private void InitMovementStrategy(NPCMovementConfigSO config)
{
_config = config;
if (_npcMovement.NPCMovementConfig is RoamingAroundCenterConfigSO)
{
_action = new RoamingMovementAction(
(RoamingAroundCenterConfigSO)_npcMovement.NPCMovementConfig,
_agent,
_npcMovement.transform.position);
}
else if (_npcMovement.NPCMovementConfig is PathwayConfigSO)
{
_action = new PathwayMovementAction(
(PathwayConfigSO)_npcMovement.NPCMovementConfig,
_agent);
}
}
}
Note: OnStateEnter, the previously stored config would be checked to verify if it would have changed during runtime and so it would inject the new strategy and config.
Finally regarding the channel attribute, it could be added to implement the functionality raised by @itsLevi0sa , thanks to it any other element in the game could trigger an event through this channel to switch the movement config of an NPC.
Here is a simple script that would achieve this trigger:
public class NPCMovementSwitcher : MonoBehaviour
{
[SerializeField] private NPCMovementEventChannelSO _movementChannel;
[SerializeField] private NPCMovementConfigSO _movementConfig;
[ContextMenu("Trigger NPC Movement switch")]
public void SwitchMovement()
{
if (_movementChannel != null && _movementConfig != null)
{
_movementChannel.RaiseEvent(_movementConfig);
}
}
}
This trigger is replacing the ongoing slime random roaming strategy by a pathway strategy at runtime.
Here is a short demo:
So that is why I have the feeling that storing the pathway config (waypoints) into a SO instead of an MB would be more powerful. @cirocontinisio , does it make sense? I know it is not aligned with the card and the on-going implementation from AlexandreGheraibia. I do not know either if it could be adapted / transposed easily to SO storage.
2 Likes
PR opened for the above proposal to be able to play with it.