In this post, an update on how patrolling has been implemented.
For patrolling behaviour, I opted to use blueprints which would provide more of an advantage for time-saving and being more easy to design. This is also at little to no detriment to performance, due to the low intensity nature of what I'm implementing.
Structure
An enemy blueprint (or any, enemy as an example) can have a 'WaypointsComponent' attached
With the WaypointsComponent, the editor can utilise functionality to create a group of waypoints. This container is attached to the enemy
The WaypointsComponent houses all this information and references to the group, which can be accessed by Tasks.
There are Tasks implemented which work to allow AI to navigate a patrol path with these waypoints.
Making Waypoints
I've developed a system for handling this through creating a component which can be attached. This houses the logic for creation of waypoints as well as providing functionality which can be used when implementing the patrolling AI. Here are its defaults and settings that I've exposed to the editor. I've developed a means for creating waypoints and associating them with the component's owner through editor-exposed functions, which makes creating and keeping track of waypoints for each enemy easy. I've chosen to develop this component so as to make this functionality applicable to any other project.
Patrolling Behaviour
The tasks involved rely on the use of this component, as the component stores all the required information on it's owners waypoints. The use of component for accessing this information is useful in that these tasks only need this component (and an enum set) to work. This means that as long as these requirements are made, this can be applied to any type of AI character (as there are no casts to specific blueprints, only the component).
Comments