The Dink Network

I was just wondering if there was a way of making sprites avoid each other...

You know how sp_follow(A, B); would make sprite A follow sprite B? Well, is there anything like this such as sp_evade(); or anything?

I expect there isn't as I've browsed the DinkC reference and couldn't find anything, so I was wondering if any of you people had any ideas? Otherwise... Meh.

You would have to check the locations of sprites and move them depending on where they are.

Good idea, I suppose I could give that a shot!

Oh wow that would be a hard script to make... I haven't given it much thought, but it's not a good idea to work with move() or move_stop() in this case. Instead, create an invisible sprite for each monster you want to have this behaviour and periodically change the location of this invisible sprite after checking the locations of the monsters themselves and comparing their values to determine direction and distance from each other. Then make them follow the invisible sprite to guide their movement. This will make it very smooth, but it would still be a "mathematically" hard script to write. If you can figure out a good algorithm to check the distance and direction (like a vector) and then adjust this vector to create the invisible sprite along, it might work and even look cool.

Yeah, I was just typing up a quick test script, it's harder than I was expecting acutally

I think this is something up Someone's sleeve to help solve He's good with this kind of complicated scripting You might even try PMing him about it.

Maybe, but I wanna give it a few tries myself first, self-satisfaction, you know...

EDIT: Right, I think I've come up with a rough method of getting it to work (I'll improve it later, I just wanna get the core-concept first) but I need to make one variable equal to the sum of one variable and one constant number. However, I cannot change the first variable or it will screw up another bit of the code. This is an example:

int &var1;
int &var2;

&var2 = &var1 += 200;

But the problem is that DinkC doesn't let you do that, so any ideas?

EDIT AGAIN: Nevermind, I found a way around it.

int &var1;
int &var2;

&var2 = &var1;
&var2 += 200;

I guess I just wasn't thinking straight, I was too busy working out what the math itself should even be

EDIT THE THIRD:
If anyone ever updates DinkC, let it be known that we need more than two conditions for an if statement. I want to use (&var1 < &sprite < &var2) but NOOOOOO becuase DinkC is too thick to even being to comprehend what that means so I have to use two seperate if conditions and end up with thousands of brackets all over the place when it could be so much neater! Raargh!

Despite the rantingness, it WOULD be nice to have multiple conditions in an if statement though, stop me getting so scrambled making this

FINAL EDIT:
Now, I know it's strange, but I'm one of those people who moderately enjoy coding, so no-one post a script for it 'till I've made time to make my own I've so far got enough code to check if the guard is within a specified range, and I've started on the next phase of the code, so... Yeah.

Really don't know if this is any help or not, since I'm half asleep and making this up from the top of my head. But maybe you wanna check out CA: Initiation. Dan used some sort of a X_Y check for the guards, so they are only able to see you at certain ranges. Maybe you could somehow use this and make the sprites walk to different directions when they get to this range. Also, you might want to try and ask Robj. He has a very interesting visibility thing in his upcoming D-Mod, so that could be of some help.

I like how you're determined to figure this one out

If you don't want to keep the outcome a secret, then I'd be interested in seeing the working code when you figure it out

Yeah, I tend to approach things with the view that if someone else does it for me, I haven't really learned anything. I only ask for help if I'm not sure where to start, or am just unsure of something in general...

And yeah, once I get it working (probably sometime tomorrow, I'm kinda tired right now) I'll post it here if anyone's still interested. I was gonna use it for my Carnage Contest entry, but thinking about it it could be used for all sorts of things, like a duck-herding mini game or something of the sort...

@Skull: I think the only bit of code from there that would be similair to this would be the comparing guard's location to Dink. I've already scripted a working bit of code that can tell if sprite A is within a 200 pixel range of sprite B though, so...

Anyway, I'm now working (going off of Kyle's suggestion earlier) a way to get an invisible sprite to appear at a location away from Sprite A, for Sprite B to follow . This is of course harder than it first seems, because I need to make sure:
A.) The sprite always appears somewhere on-screen, never off-screen (otherwise it could get buggy)
B.) It needs to be slightly random, otherwise it'll be far too easy to guess how it tries to evade
and C.) It needs to be at a location so that the evading sprite doesn't walk straight through the sprite it's trying to get away from.

I've already made an extremely messy, extremely rough, but just about working bit of code. So I'm just working my way through it at fixing the above issues and stuff. So yeah, hopefully I'll be done some-point tomorrow.

Does it really get buggy if it follows an offscreen sprite? If the sprite isn't set to be able to walk off screen I don't think it will bug out.

What I would do is use Pythagora's theorem to determine an accurate distance, then have it set to move a random direction in a random direction within a 180 degree arc away from it(So if the sprite to avoid was at 0 degrees, the other sprite would then pick a random path between +90 degrees and -90/270 degrees) If there is no random function, you could always use time commands, as they are rarely entirely accurate and you can use these innacuracies to get psuedorandom values.

Also, kinda relevant, but can a sprite actually move in all directions or only eight?

I think a sprite can move up, down, left, right, and diagonally unless you tell it not to...
As for your Pythagoras's theorem, you have just blown my mind
*Goes off to check Wikipedia*
Yeah, I think that could work...
Would be far better than the messy way I'd thought of doing it.

A sprite can move to 9 directions.

Also, if you've already done with the range stuff, you just need to check the direction of the sprite and make it walk to different direction after that. I think Stone of Balance used this direction check for NPCs so you might wanna check it out.

EDIT: I'm kinda out of this. It would be easier to help if you explained what are you going to use the script for.

You can use most any direction actually, by using sp_mx() and sp_my(). I think Someone used this extensively in his d-mod that uses mouse control. I myself have only used it for missiles.

Anyway, you would indeed need something like what Fireball said, but that still wouldn't be enough. Just a random point within a 180 field would eventually lead to the sprite getting caught due to bad luck. To be superprecise you need to project a point along an axis between the two sprites involved to maximize the distance they keep between each other, if you know what I mean.

Sure, I suppose I didn't really explain why I need it, did I?

I'm using it becuase there's a bit in my game where the Player becomes mega-powerful, and all the guards try and run away from the player. But I figured I'd code it all before I actually needed it, so that it was looming over the rest of the project

So essentially, when the players moving around, the guards try and move away from him.
I now have enough code to check if the guard is within a 200 pixel range of the player. Then, if he's in range, that code works out if he's north-west, north-east, south-west, or south-east. I was just about to start coding the bit to work out where he should move to.

I think you're saying check which way Dink's facing, and move the guard accordingly? But that wouldn't work, because even if the player and guard are within range of each other, there's nothing to stop the player just turning around and facing away from him. Which, going by your method, would then make the guard turn around and walk straight towards the player.

Feel free to correct me if I've misunderstood what you meant.

EDIT: @Kyle, Fireball.
This is getting more and more complicated, and more and more confusing as the code progresses

Aha, so it's not actually important that the guards are "forever" out of reach of Dink. You just want to simulate a "feared" behaviour. That's not too hard if your field layout is not obstructed by too much hardness. You want the guards to be able to be cornered by Dink right? Then you can work with a simple system where you compare X and Y values between Dink and the guard in question and create the invisible follow sprite in the 90 degree quadrant that remains, preferably as far away from Dink as possible, but that's not even necessary if you have the script looping say, every 500 frames.

Um... I would say this is quite impossible to make work. Even if you do anything, there is always a chance that the player will become in touch with the guards. Maybe if you make them super-fast, and when Dink comes within the range, the guards will automatically run away to the other side of the screen or something. But it would still probably not work.

The only way to make it possible is if you don't want them to keep running away forever. If you actually want the player to catch them at some point. EDIT: Which Kyle just pointed out, beating me by a few seconds.

Oh Skull, you're too negative Anyway, it doesn't matter if the player catches them, it's not even necessary he avoids them in the first place, I just though it would make Dink's mega-powerfulness seem a bit more... What's the word... Interactive? EDIT: Sorry, posted this before you posted your edit

@Kyle Yeah... That's sorta what I was planning before my brain was killed by Fireball. I was gonna have it move the invisible sprite to the north-east, north-west, south-east, south-west corner, then by checking if he's in the corner of the screen, he would move vertically or horizontally, depending on which is a bigger gap between him and the player and hopefully push the guard back near the middle of the screen. Then it can start again. Thinking about it, if I do it this way, it won't be particularly complicated, just really long

Geez, just make the guards run around crazy. That will create the feel of panic.

Nope, that's not unnecessarily complicated enough for me

EDIT: I have to go to a sport club type thing now, I'll be back in an hour and a half

'NOTHER EDIT (so I don't have to keep making new posts): Right, I've worked out how I'm gonna do it now, so all that's left is to actually type it. It's getting perhaps a little longer than would have been nice, but if anyone is interested in seeing it I'll probably be done in around an hour (unless un-foreseen problems arise, which isn't all that unlikely)

EDIT AGAIN: The math is really annoying, so I expect it'll take longer than I hoped...

FINAL EDIT FOR A WHILE: Right, I've got it. He can tell where Dink is, and moves away from him if he's within 200 pixels. Then, when he gets cornered, the script checks if he'll become closer to Dink if he moves vertically or horizontally (so if he was in the top-left corner, he would check if he'd get closer to Dink by moving downwards, or by moving right). The script then makes him move in whichever direction keeps him furthest away from Dink. Then it starts all over again. I've only got it working for the top-right and top-left corners at the moment. This isn't because I'm stuck, I'm just starting to get sick of the coding. I'm gonna go play crash bandicoot or something mind-numbing, then come back to the scipting. I never knew DinkC could become this mathsy

EDIT THE FOURTH... I MEAN FIFTH: Ok, I've got it working for all the corner's now, but I'm encountering a few glitches involving the guard going off screen. Unlike Kyle said, I'm not sure if it's becuase of how I'm doing it or what, but... When the target value goes off screen it kinda spazzes the guard around the edge of the screen. So I'm fixing these bugs (which I thought I'd already fixed but apparently haven't) and then I'll upload this either today or tomorrow if anyone wants to see

I have done it! It works! The guard moves away from Dink in all directions, when he gets cornered in ANY corner he intelligently works out which way to move, he never goes off-screen, and (as far as I can tell) has absolutely zero errors! The only thing I well say, however, is that it's pretty dang messy. There's something like 500 lines of code in there I don't even need, but I'm terrified to take them out in case it inadvertently breaks something. Maybe I'll tidy it up if there's time before the contest ends. I would post it here, but it is stupidly massive (I don't have a line counter, but when you look at it you kinda just go "Woah") so I figure there's no point making the worlds biggest post if there wont even be anyone to appreciate it. Anyway, everyone congratulate me please

Congratulations man! Looking forward to seeing it in action.

And I wouldn't bother TOO much with cleaning up the code, unless it means you'll save on variables, in which case you definitely should

Thanks! Nah, tidying it up wouldn't save any variables (it uses 12, and off the top of my head I can't think of anything to use less other than using variables to mean two different things at once, which is always risky), but it would make it neater, more organised, and just generally easier to read. And funnily enough, like I said earlier, you actually could quite easily make a duck-herding mini-game with it So you never know, you might get to herd ducks in my next dmod

Hehe, if you want to see messy code, check out the bosses in three amulets

The fact that they actually works will always remain a mystery to me...

You should be able to use way less glibals...

By glibal I'm assuming you mean global variables? All the variables it uses are local ones, so I was assuming it wouldn't matter too much...

Trouble is there's a limit of the amount of variables you can have at once (248 I think) including globals and locals. If you go over that funny things start to happen.

One guard with that script on the screen means 12 variables, two means 24, etc.... shouldn't matter if you're nowhere near 248 but in a longer D-Mod using more globals that starts to get tricky.

Ok, I'll bear that in mind if I use it in any bigger DMOD's. But at the moment this is just going into a romp so it should be fine

Sounds really good, Juggly! It's going to be fun to actually see the script in action.

Thanks! I'm just sat here trying to come up with different ways to use it now, other than for creating a "Fearful" guard

Well the same principal could be used to make a really cool forcefield effect, where a sprite or Dink would cast a forcefield on themselves which bends the trajectory of a missile as it approaches so it misses the sprite

Ooo, exciting possibilities... my mind is buzzing now, want to get home from college to play around with this instead