There’s a huge series on you tube on the Unreal Engine page and there are working samples here: [UPDATED 5/16] A.I. Templates - Bot, Car, & +Flying AI - Community Content, Tools and Tutorials - Unreal Engine Forums
Posted the fourth video in the series, which makes the guard actually do some damage:
Hey ,
How about this for resetting values based off pawn sensing?
(ignore the mess. There’s a lot of bad prototyping going on just out of view)
The timer gets reset every time it’s triggered. So in this case, while the player pawn can be seen, the ResetSeen event is never triggered. But a second after the last time he saw the player, it resets. Just tried it, and it seems to work as intended.
Next up is trying to get the enemy to face the player when not moving towards them (if they can see the player of course).
It isn’t a bad idea to use a timed reset value. One of the issues currently is that we only handle seeing ONE object. Where we really want to handle seeing multiple objects and adding them to a list of recently seen objects. Or we might want to “see” objects of multiple types, but decide that one of those things is actually worth bothering with.
I’m going to post another video tomorrow that explores things like choosing what to define as an “enemy” and this kind of thing. Bearing in mind that the sensory system we are using is likely to change pretty soon. So its not worth spending too much time worrying about it if it works for your needs right now. I dislike the idea of having a timer in the blueprint though, I’d rather expose an event from the sensory system and do it that way.
Exposing it to an event is a much better idea. The entire sensing tick could be exposed to evens, giving easier access in in tasks, services and decorators . Though note that mine is if the enemy is seen, not the name of the enemy actor. The name is handled in a different blackboard key.
I can’t find a way to access the pawn sensing tick. I know I can change it’s interval, and start and stop it, but I can only get hold of it when it actually sees or hears something. Looking through all the nodes available, I don’t think it’s possible in blueprints at the moment.
Yeah, I haven’t seen the tick available for sensing, which is a bit of a pain.
Ideally the sensory system would have a bunch of event callbacks for different stages of the sensing. So for instance it would have an “event seen” which would be triggered the first time an entity is seen, an “event lost sight” when the entity then becomes unseen, maybe an “entity in sight” which would periodically call back with a list of currently visible entities. It would need some filtering mechanisms (maybe bit masks like the physics system?) so you could cull out objects quickly etc.
Sensing is quite a complex subject though, so maybe in reality its best to handle all of that in code (for performance reasons). Its the typical programmer/designer crossover area where it might actually be better for the designer to see it as a black box. But I’m both a programmer and designer so it annoys me when I come across that kind of thing 
I’ll likely spend some time on some internal AI work once I’ve done the first few series of AI tutorials done. I really want to do some work on procedural character animation before then though.
Its good fun!
Here’s part five of the AI Guard tutorial: Unreal Engine AI Tut
Thats the last one for now on the AI Guard, now on to “Mob” AI for a while. Will revisit the AI Guard once we have some enemies to guard against!! I’ll post here when they are available.
Just posted another video, this time a quick random wandering zombie: Unreal Engine AI Tutorial #2 - AI Game Jam Part Three - YouTube
Next up is definitely mobs.
I’m sat at work excited as hell to get home and look through your tutorials, many thanks for putting them online for us.
Glad you like them. I’m going to try and get a more complex one out this week sometime (a mob that can do ranged and melee attacks, has random patrolling etc). But I’ve got to make some procedural generation code too so I’ll have to see.
I do take requests though, so anything you want to see just post here and I’ll do what I can.
Problem with Arrive Steering behaviors
Learn a lot from your tutorials, Many thanks for putting them online.
May be you can help me with the problem I am stuck in right now. I am trying to implement the arrive steering behavior based on Craig Reynolds steering behaviors theory. The problem I am having is that my objects oscillate around the target position; after oscillating less and less for awhile they finally come to a stop at the target position. Does you have any idea why this oscillating behavior occur?
Here are the blueprint images of the arrive and move function of the vehicle.
Thanks,
Hmm, can’t quite make out the details of the top image. But I’ve come across this kind of thing before. My advice would be to print out distance and force for each time step and look at what happens as they reach zero. Clearly there’s too much force being applied causing an overshoot.
Usually its going to be caused either by incorrect maths (lets say something like floating point rounding error, or a slight miscalculation), or temporal aliasing (you’re computing a force vector at a point in time, but in reality to actually steer to a stop you would have to compute that force at EVERY timestep (i.e. continuously, rather than in discreet steps like you get in games). Ideally you’d see both values for force and distance converge to zero with both hitting zero at exactly the same time. I’ve not looked at Reynolds original paper for quite some time (steering really doesn’t tend to work for most things in games) but you could have a look at the code for OpenSteer and see his implementation of arrival, see if he has any fixes in place for this issue.
The easy fix would be to have an area around the arrival position that is considered arrived. It looks as far as I can make out like you already have that in place. Having the ability to be “near enough” is actually a good thing in general, because game environments tend to be pretty noisy. You might also just clamp to the target position if you get below a small threshold away from it, resetting the velocity to zero.
Let me know how you get on. Maybe post the final distance/force values (and speed as well) as they might hold a clue where things are going wrong.
Phil.
That would be amazing, subscribed!
Start of the next tutorial series: Unreal Engine AI Tutorial #3 - Mob AI Part One - YouTube
There will be quite a few more to come (first one tomorrow).
Arrive Steering behavior
I was just busy with other projects so couldn’t reply quickly. I think i figure out the problem with arrive, i don’t know if its a hack or thats how its suppose to work with unreal. So when i was dubugging every frame I noticed that when bot enter the stopping radius, decelerate amount multiply by elapsedTime is really small and thats why it didn’t stop at the arrive point but when I removed elapsedTime and just apply decelerate amount to the velocity it worked properly.
Thanks for the help and your new videos are really helpful.
Thanks
Wow, thank you very much .
Thank you very much for these. I’ve been working through them and they have been really helpful.
I do have a few questions. The slides that you use for explaining the theory. Is there any chance you could share those? At the moment I’m constantly pausing and scribbling things down but I can’t read my own writing 
Also I’m working through the Mobs tutorials now and I was wondering if you (or anyone else for that matter) knew of the best way to have them just pottering around and not necessarily following a set patrol?
Again many thanks for the hard work you’ve no doubt put in.
Looking forward to any and all future tutorials from you
Hey Zaos,
We’ll be adding some more behavior for the Mobs, on my todo list is some “just general doing stuff” content. So its on the list
Slides? yeah sure. I’ll post them on slideshare over the weekend and add another post here.
Phil.
Cheers, you’ve been a great help.