game-editor.com

... So I'm working with little flying drone robot guys, and I want them to follow the player around, but not go straight to him... So I figured if they are targeted on an invisible actor which randomly changes it's x,yt coordinates (within a reasonable distance of the player actor) then my drones would basically follow the player, while seeming like they have a mind of their own and change course a little bit every couple of seconds... does that make sense? How would I make that happen?

Have them Fly right at the target, then add a error factor.

For example, if the target is at angle 230, subtract 10 from that, and and a random number from 0-20. they will fly towards, but not always exact. If you measure the distance to the target, you can adjust the amount you subtract(error factor) to be smaller, and reduce the random aspect as well, as you get closer.

At long distances have a small random factor as well, so that they fly straight.

.... what would the script be to do that? It'd be a drawactor script?

Yes, in draw actor likely. Where ever you move the drones.

As an alternate, you could have the player actor miss report its location. Make a two global variables that act as the players X and Y decoys. When the player moves, it sets the decoy X and Y. The drones chase that.

Alternately, since you are a graphics man, consider using near invisible Field of view actors.

Make wedge shapes and assemble into an animation. Give the drones child actors that play that animation. The wedges sweep out the field of view. A highly mobile player will be harder to track, and a stationary one an easy target.

Make wedges visible so that you can test easily, then for the final production, reduce them to near zero. As long as they have some small amount of opacity, GE will generate collision masks for them. The wedges allow the drones to see by feel.

I've got a post around here somewhere that outlines that.

Here it is:
http://game-editor.com/forum/viewtopic. ... ight=sight

Interesting... a few ideas to try for sure. I think your field-of-view-cone conecpt may be used for a different enemy... I'll try to figure out the error factor (probably take me all day)... :shock:

Was just playing around with the script editor for my drone, and uh, could not find anything relating to adding an error factor. If you wanted to wtire up a script example when you have a moment, I'd appreciate it!

Sorry. Error factor is not something that is specific to GE. The term comes from "margin of error", refering to something being close, but not exact.

Its basically just a variable that you make. I'll try to explain it in generic terms.

Say you want to move an actor very slowly. Perhaps slower than one. Obviously, you cannot move less than 1 pixel, so unless that fractional extra gets stored, you never get anywhere. Luckily in GE, Makslane has done this for us. We dont have to.

Anyway, what happens is that the fractional part gets stored and added each time, and when it exceeds one, The actor moves one(or more) pixels.

In the case of angles, it refers to the fact that from a long distance, you only have to head in the general direction to be moving correctly. As you get closer, you tighten the error factor. Your field of view(or movement) gets smaller as you approach.

I appologise for the simplistic explainations. I write my posts in a way that I hope will be generic and clear(and useful) to a new user and possibly younger user 1, 3 or even 5 years from now. Often pictures and samples help, but they are not guarranteed to remain with the posts.

Now for some code samples and maybe some pictures.

I'll assume you have found the angle to the target, and stored it in a variable called Ang2Targ. We will take that and a float variable called AngErrTerm, which we have set to 10. We are not concerned with distance in this sample.

Imagine Ang2Targ as a line extending into the distance. It has no thickness. AngErrTerm will add that. First, we subtract one half of the error term from the angle.

Ang2Targ = Ang2Targ - (AngErrTerm *0.5);

It is safer to multiply by a decimal than to divide, because you dont risk a division by zero error. Next we add a random number from 0 to the value of AngErrTerm.

Ang2Targ = Ang2Targ + rand(AngErrTerm);

We can simplify both lines into one, but it can make it trickier to read.

Ang2Targ = Ang2Targ - (AngErrTerm *0.5) + rand(AngErrTerm);

And thats it. We have made the solid angle we started with into an angle thats only roughly the same direction. With a larger error term, it becomes less exact.

I'd put this in draw somehow.

put this in the draw actor script editor of the actor doing the moving:

//moves the actor towards actor2 with an error of + or - 10
int n;
int i;
int initialx;
int initialy;

if (n==0){

//saves the starting point
initialx=x;
initialy=y;


directional_velocity=3;

angle=direction(x, y, actor2.x, actor2.y)+rand(20)-10;
i=distance(x, y, actor2.x, actor2.y)+rand(20)-10;
//change actor2 in all places to your actors name that this will move towards

n=1;
}

//if the distance has been reached then stop movement
if (i<=(distance(initialx, initialy, x,y)))directional_velocity=0;

Thanks to both of you for taking the tim to write that stuff up.... I'll try to figure it out and put it to practical use, big help both of you!

here is the ged file of my example code posted above