I'm wondering what's the best way to implement a (1) flick gesture and in particular (2) slide a game object a given distance based on the last direction and speed my finger was moving towards before I lift my finger off the game object & screen (see picture attached for a graphical view of what I'm trying to achieve).
Now I can successfully TAP and MOVE the game object however I cannot get a FLICK gesture to work and I'm having all sorts of issues trying to get the game object to move any further once I lift my finger off the object. Now when I lift my finger off the game object I'm unsure how best to move it (I.E. rigidbody.velocity, add force, or transform.lerp etc) and I'm unsure how I move it in the correct direction based on my last touch movements.
I'm having some success with the flick gesture (measuring and comparing time between first latched and release and Vector2 distance) however I'm unsure about ascertaining the direction of the flick and still having issues with getting the game object to move, ... any advice?
check out this thread, it may be helpful.
- Always try -
Mimic3D now available!
Make any progress eventually on this? Mind sharing? I'm trying to code something similar and it's kicking my butt so far.
I found it really easy to make a flick gesture on my iPhone game. I'm going to share my workaround.
First of all, you should create an invisible plane mesh wich automatically aligns horizontal to the world space, and at the center of the object you want to flick. Scale it quite big so it will be always in the viewport. The standard Unity plane mesh will be perfect. Let's call it SwipePlane.
What's this plane for? It is necessary so you can get the real direction of the swipe, as with it you can calculate swipe direction in 3D space, and not in screen 2D space. You'll understand better its utility while reading.
Now, that's my procedure:
1 - Detect the initial touch and create a point using Camera.ScreenToWorldPoint. XY coordinates must be touch coordinates, and Z value must be zero. Save this Vector3 in a variable, i.e. P1.
2 - Use again Camera.ScreenToWorldPoint in the same way, but with Z value of 10000 instead of zero, or something that high. Save this other Vector3 in another variable, i.e. P2.
3 - Cast a line from P1 and P2, using a layer mask to detect any collision only with the SwipePlane. Store in a variable the hit.point value, i.e. SwipePos1. This is the initial 3D position of the swipe.
4 - Now, as soon as you detect the same finger is moving, start a timer (i.e. SwipeTimer) wich counts in seconds. In this phase we suppose the user is swiping the finger on the touch screen.
5 - When you release the same finger, detect its position. Repeat the same thing you did in step 1, 2 and 3, so you can cast another line on the SwipePlane and get another hit.point, wich will be saved in SwipePos2. This time we know the final 3D position of the swipe. Also, in this step you have to halt the SwipeTimer, but don't reset it.
6 - Now, do Physics.CheckCapsule from SwipePos1 to SwipePos2, and, with another layer mask, check if you hit the object you want to flick. We use a capsule collider so if the user misses the object just slightly, the swipe will be accepted just the same.
7 - If the object is missed, simply end this script and restart from the begin. If the object has been hit, now you have: the swipe time (SwipeTime), the swipe length (Vector3.Distance(SwipePos1,SwipePos2)) and the swipe direction (SwipePos2-SwipePos1). And if you do length/time, you will also get the speed of the Swipe. There's everything you need now!
8 - Finally, apply direction and speed to the object at your own pleasure, maybe with Rigidbody.AddForce, wich is perfect for this kind of things.
I'm not posting my script because it's so filled with many other things, that it will be more an obstacle to read rather than something explanatory. Anyways, I hope my solution will be helpful for you and many others.
EDIT: Oh! I just noticed that the first post was talking about 2D positions! Well, in this case, just don't use the SwipePlane, but we should know in wich way he's using 2D sprites.
Last edited by MrDrayton; 07-04-2011 at 03:29 AM. Reason: fixed errors