Smoother VectorToAngle
app_sauce
Member, PRO Posts: 206
I am making a mechanic for a game where the player drags his finger and the "aiming line" adjusts and points in the direction the player wants to shoot. The code I used in the projectile is Change Velocity then in the direction I use, VectorToAngle (TapX-mousex, TapY-mousey). This works fine. For my"Aim Line" I use a small actor and Replicate it 14 times with 50 pixels spacing. In the Replicate direction I use the same VectorToAngle code. The problem is that it doesn't seem very precise. The furthest small actor seems to move about 5 pixels with every tiny adjustment you make with your finger. I tried multiplying The VectorToAngle codes above by 1.5 and things tend to get wonky. I won't the aim line to move in smaller increments, giving the player more control. I will continue to mess around with this and would appreciate any help.
SocializeTwitter , **My Site ** **Play Loop Zen Free **iOS HERE, Google Play HERE
Comments
This is an issue with your mechanic design rather than your code, if you are moving your finger through a tiny arc, and that arc is being represented by an extended line going in the other direction then this will always be problem.
I am starting to see that is the case. I was trying to make the mechanic in a way that no matter where the first tap is in relationship to the ball(that is about to get launched), the aim would always control in the same manner. So if the ball is at the top of the screen the player would not have to drag their finger passed the ball in order to shoot it down to the bottom of the screen. I guess I will have to re-think the mechanic for now.
SocializeTwitter , **My Site ** **Play Loop Zen Free **iOS HERE, Google Play HERE
That should work fine, all you need to player to be able to do is to drag a longer line.
If - for example - the aiming line the player drags is just 20 pixels long, then a change of 10 degrees (a pretty big chance when it comes to aiming) is just a movement of 3.47 pixels !
Whereas if the aiming line being dragged is 200 pixels long, it takes a movement of 34.7 pixels to change the angle by 10°, so obviously with smaller drag ranges it's going to be difficult to be accurate.
And if we imagine the line indicating the direction (the line being projected in the direction of fire) is 200 pixels long and the drag range is 20 pixels, then for every 3 pixels the player's finger moves, the end of that line will jump 30 pixels, so unless the player keeps his finger very still that line with be constantly jumping around.
I made a quick example, seems pretty stable: attached
(click anywhere on the screen and drag)
Yea the longer I drag my finger the smoother the movement becomes. Since I don't want the projectile to travel at variable speeds I could incorporate some type of charge up distance before I show the aiming line. That could definitely work. Thanks as always @Socks!
SocializeTwitter , **My Site ** **Play Loop Zen Free **iOS HERE, Google Play HERE
Good idea, here's a quick version which would force the player to drag their finger out to at least a couple of hundred pixels, they would only be allowed to release when the lines goes red or they hear the beep (or something similar). File attached:
@Socks I have the line actor working pretty smooth Thanks for the help. One problem I am trying to figure out is a way to limit the length of my aim line if it overlaps with another actor. It is problematic because the player will constantly being adjusting his aim and my aim line has pretty big gaps. I'm not used to working with the replicate behavior so not really sure how to go about this problem.
SocializeTwitter , **My Site ** **Play Loop Zen Free **iOS HERE, Google Play HERE
I don't understand what is being said here, you'd need to be more specific, I'm not even sure how those two sentences are related (if they are?).
But basically you have a lot of control over how Replicate works, every part can be under the control of an expression, so you can control size, distance and space between replications, so the aim line can grow and shrink as you want and the replications can stretch out or remain constant as if you want.
@Socks My aim line is 1 to 24 little dots with a spacing of 50. I'm trying to figure out how to make the dots in the line disappear from the spot at which they overlap with another actor. And I don't just want the dot that is touching the actor to disappear but every dot from that point on. But, in certain circumstances, since their is a 50 pixel spacing actors will be between two of the aim line dots without touching. I drew a quick sketch. The green checks are what I want and the red x's are what I have.
SocializeTwitter , **My Site ** **Play Loop Zen Free **iOS HERE, Google Play HERE
Why is this relevant / being mentioned ? (sorry if I'm not understanding this properly) ?
@Socks Because I am assuming that my rule should be triggered by an overlap and when The actor I am aiming at is between 2 of the replicated aim line dots it never overlaps. I want the aim line to never go past a object that is directly in front of it. Right now my aim line just continues to grow, I cant figure out a way to have it know if an object is in front of it and only go to that point.(i don't know if that make sense?)
SocializeTwitter , **My Site ** **Play Loop Zen Free **iOS HERE, Google Play HERE
Ah ! I see, thanks for the clarification, it makes sense why you were mentioning that now.
Replicate doesn't actually generate geometry, it is visual only, so ideal for things like power meters and direction arrows and other visual stuff, and in this regard it is super efficient, but as it's not actually generating geometry it cannot detect collisions, so it doesn't matter whether the target actor is touching one of the dots or one of the spaces as neither will trigger a collision detection rule.
If you wanted to detect a collision you could simply use a line (a long thin actor), you can even do the same 'replicate' look of using Replicate by tilling an image within the line actor.
That makes sense.
You can measure the distance between two objects with the magnitude function.