How do I create (semi realistic) guard patrols?

Sorry title is a bit vague. I have a basic level set up in which has rooms in which guards a "patrolling" (what's actually going on is guards a moving from left to right or vice versa until they hit a wall and simply start moving in the opposite direction). What I've been trying to do is make the patrols in such a way that when a guard gets to a wall at the end of a room, rather than immediately turning around and continuing to move (in a way that makes it look like the guard has just bounced off the wall like a tennis ball), the guard actually stops at before the (like 16 pixels) away from the wall for 2 seconds before turning around and starting to again. Ala "more realistically guard patrols".

The concept sounds simple enough, and I'm sure the more realistic of you would know how to do this, but I've failed to do it well. I say failed to do it well because I have tried it but my method doesn't run so well, at any random time between 10-300 seconds, the guard will glitch and start turning left, right, then right, then left, etc, for a good 10 seconds or so.

What complicates things is the need for guards to stop at a distance from the wall. Ideally I'd have simply have put an on collision with " wall" action > set patrol to false > wait 2 seconds > change direction > set patrol to true. But that'll have the enemies waiting literally face-on-wall waiting for 2 seconds. So that won't work. So I have to use the overlapping at offset conditions. But this command triggers and continues triggering while enemy is within that offset of the wall. I tried adding a trigger once which so of solved my problem, but lead to this curious bug.

May someone show me how to do this?

NB sorry I can't upload a capx or screenshot at the moment

You can use guard.x and guard.y to specify at which coordination they need to stop moving.

And you can use "System > Wait" to make them wait a certain amount of seconds before the next action starts(walking a different direction).

Yeah I don't see what could be messing up. Maybe look at the third party moveto behaviour. Or use pathfinding to the target xy. If it's glitching it must be something to do with your events which we can't see without capx or screenshot. With your 2 second thing, why not just move the wait until after you turn it around?

If I was doing patrolling I would probably have invisible sprites for each waypoint and use pathfinding. Also pretty sure there is a tutorial or FAQ on this.

Here's a simple left/right patrol example, with the guards waiting a random time before turning around:

https://dl.dropboxusercontent.com/u/905 ... atrol.capx

It incorporates the Wait and invisible patrol markers mentioned above.

Cute

The project .capx. If you run it and keep watching the guards move left to right and back again, you'll notice after some time one or more of the guards glitches and starts facing left, right, left, right and so on. It goes on for a bit before it stops and normal operation is resumed.

OddConfection gave an elegant solution. I've learned from it and I think you should too. Yours doesn't work because of inherent timing issues. Hint: the System:Wait does not stop other events from running. Every tick.

Also you have some misconceptions. You do not need System:Pick All Enemy followed by System:For each Enemy You can remove these entirely and the logic is the same.

And I find any time I've used System:Wait I've introduced subtle timing issues, so I'd be careful of that technique.

If you're wanting to see how your type of approach might work, I've attached a capx. The basic approach is still yours, but it's greatly simplified.

[attachment=0:pbe087bp][/attachment:pbe087bp]

Cute <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

Who says you can't make a cute game without any artistic ability? <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz">

And I find any time I've used System:Wait I've introduced subtle timing issues, so I'd be careful of that technique.

Yes, System->Wait can sometimes be problematic as it's not always intuitive what it will do.

I've made an alternate example using the Timer behaviour:

https://dl.dropboxusercontent.com/u/905 ... Timer.capx

It uses an extra event, but has the same number of actions as the previous example and should perform the same.

Who says you can't make a cute game without any artistic ability?

We should totally put both of our lack of artistic ability together and make the next 'piano tiles' type hit

I've made an alternate example using the Timer behaviour:

Yea I was going to suggest for the Enemy to have its own timer. Except your guys stand facing the wall while they're waiting

Wow. Just wow. I'm amazed at how quick y'all gathered and solved what seemed (to me) to be impossible bug. And what's most amazing is how elegantly simple your solutions are. A million thanks guys. The incite has changed my life, literally(Now I gotta go question my whole game and everything I implemented, basically question my existence :-\ )

Nah, I had several goes at it and was still getting the glitchy behaviour. Then I realised it must be a timing issue and moved the code into single sequences of actions and that did it. It's not easy to get your head around events, and the timing of them, and the fact that multiple things can be happening at once (and 60 times a second!). And I'm still learning to let C2 do a lot of the hard work for me As seen by OddConfection 's first solution, there's always a simpler way.