How to know which finger is released
OniCraft
Member, BASIC Posts: 43
I'm working on mutli touch
I used mouse count to know which fingers the actors are assigned to
Ex:
A actor is finger 1
B actor is finger 2
but if B actor is touched first
then B actor is finger 1
but I have a question for releasing the touch
How can gamesalad tell which finger is released so that the assigned actor will know what to do next?
I used mouse count to know which fingers the actors are assigned to
Ex:
A actor is finger 1
B actor is finger 2
but if B actor is touched first
then B actor is finger 1
but I have a question for releasing the touch
How can gamesalad tell which finger is released so that the assigned actor will know what to do next?
Comments
And I don't claim to be a master. In fact, I don't know why I'm even writing this, it's a bit of a nightmare to explain, and depends on exactly what you're trying to do with your game.
But I decided to go ahead and write this up, in case it provided at least a decent example of how it might fit your situation. And you could extrapolate from there.
But, basically, if you're going to do anything tricky with multi-touch, you're going to have to write up your own multitouch system that keeps track of the touches in detail.
It doesn't work as intuitively as you might think, as a user just tapping the screen and stuff.
The best way to get your head around it is to muck around in a test project, with a few actors that follow your fingers.
Make, say, a green square that constrains it's PositionX,Y to Touch1X,Y, then a yellow actor that tracks Touch2, and an orange one that tracks Touch3. Maybe have each actor display a number for it's Touch Count.
Then load it up on the viewer and drag your fingers around, and lift your fingers in different orders, and replace them back on the screen, and just get in your mind how the device actually tracks them.
Basically, you want to make your own attributes that also keep track of which touches are used.
The tricky thing is that, if you touch and drag with "your finger 1", that'll be Touch 1.
Then you also touch and drag with "your finger 2", that'll be touch 2.
Then if you release finger 1, you release Touch 1. But seeing as you're still holding down finger 2, Touch 2 is still being used. So when you touch the screen again, that finger will be assigned as Touch 1. Because Touch 1 is the first touch available.
So it can get confusing if you're using 3 fingers. Because the device keeps track of any fingers that are not lifted up, and keeps their Touch remembered.
So you might have two fingers on the screen, but they might be Touch 2 and Touch 3, because you took off the finger that was Touch 1.
Now if you touch the screen with a third finger, that'll be Touch 1!
But when you're "programming behaviours" in Game Salad, you only really have access to "Touch Count", which does NOT really give you back the information you might be looking for.
You really need to create attributes that you can map across to the device's own touch logic... That way, you can have a proper "conversation" with the game about what finger is doing what...
I find you can't always rely on the built in Game Salad behaviours to trigger logic exactly as you'd expect (in some circumstances, such as "If Touch is Released"), so you really need to create your own attributes to trigger off events, and track whether an actor is touched, and whether it's released. Using attributes for this ensures that the logic is triggered properly, and is controlled in a reliable way.
For the touch count aspect, I make these attributes:
The actor itself can have an attribute called self.TouchCount (Integer) =0 (by default).
This simply keeps tracks of if it's been touched, or released.
I have a set of global (game) attributes that keep track of which touches are being used, and which are available. These can be booleans, or integers. Booleans use less memory. But in my game I use Integers, because each of my 9 "touch sensors" have an ID, and I set the Touch1Used or Touch2Used (etc) to be the number of the thing it's touching. It would depend on your situation.
eg:
Touch1Used = true/false (or 0, 1, 2, 3, 4, 5, 6, 7, 8, 9)
Touch2Used = true/false (or 0, 1, 2, 3, 4, 5, 6, 7, 8, 9)
Touch3Used = true/false (or 0, 1, 2, 3, 4, 5, 6, 7, 8, 9)
etc
You might want to support up to 5 or 6 touches, potentially. I support 6 in my behaviours.
Then, every time the player touches the screen, you should create you own behaviours that will find the lowest available touch, and assign it to that touch (make it TRUE if it's a boolean, or give it an ID for what it's touching if that helps with your other game logic).
The example I will give here is for touching say an accelerator button. Usually you wouldn't need to keep track of this touch count, if your game is just controlled by 4 static buttons. But in my game, I need to know the touch counts for some fingers (used for aiming guns), and because of that, I need to know about ALL touches, otherwise I can't track the touches I'm interested in.
So my accelerator button has an ID of 8 (it's my 8th touch sensor). I just have that written on a piece of paper. But it could be done with an attribute if that works for you.
I use this ID again later when releasing the appropriate touch count.
ASSIGNING TOUCH COUNTS
Rule: If touch is pressed...
-Change attribute: "ButtonPressed" =1
(I use this for actually triggering the game logic part of my button or actor - in this case, making my car accelerate.)
(And then I do the bit to record what touch is assigned to this finger - it's set up in a way that means I know the same touch counts that the device itself is counting - I just mimic the system that the devices use behind the scenes, of assigning the lowest available number to any new touch detected...)
If attribute "self.TouchCount" =0, then assign lowest available touch count:
-Timer: After 0.01 seconds...
--If Touch1Used =0...
---Change attribute: Touch1Used =8
---Change attribute: self.TouchCount =1
----Otherwise, if Touch2Used =0...
-----Change attribute: Touch2Used =8
-----Change attribute: self.TouchCount =1
------Otherwise, if Touch3Used =0...
-------Change attribute: Touch1Used =8
-------Change attribute: self.TouchCount =1
----------etc (keep checking for the lowest unused touch count, and assign that)...
(Note that these are nested OTHERWISE rules, so it assigns the Touch Used to the lowest available touch, then quits out of the loop (as you don't want it to assign to multiple touches!)
(Note also that I set selfTouchCount =1, so that it doesn't retrigger this rule again once it's been set, until the player lets go and releases the touch count - using the rules described further down below).
(And at the very bottom of this rule, in the otherwise section)...
Otherwise (if touch is no longer pressed)...
-Change attribute: "ButtonPressed" =0
(This is used to trigger my rules for releasing the touch - explained below).
=============
Note that you must have this same sort of system in EVERY actor, or area of the screen, to know if the user is touching there. You need to track ALL touch counts, not just the ones that happen to touch the actors you're interested in.
Remember that the device is detecting ALL touch counts, and counts them in order of the lowest available touches. So you must do the same.
Remember that the player might touch say, the main hero character (touch 1), and an enemy character (touch 2), but might also accidentally drag one finger onto the corner of the screen (touch 3), and you need to know that they have that third finger in play as well! Because if they then touch a third actor to shoot at it, you can't send it the XY of touch 3. You need to send the XY or touch 4!
So you kind of need to have these touch count sensors all over the screen, even if that sensor is just there to be aware of how many touch counts are in play and which have been released.
I personally have 9 touch sensors at play in my game, to know where the player's fingers are at all times, as my game is quite complex in terms of the controls)... My touch sensors cover the entire screen, butting up neatly against one another, so all touches are accounted for.
=============
So, here are my behaviours for detecting when a touch is released, and I free up that touch count. I have this rule in every "touch sensor" to know when a user releases a touch...
I tried doing this in the Otherwise section of my "If touch is pressed" rule above, but I didn't find that reliable. So I used the self.TouchCount attribute as my own trigger attribute to detect whether the button is released, to ensure my logic works reliably.
(I found that relying on the "OTHERWISE" section of an "If touch is pressed" behaviour caused problems where buttons wouldn't get released properly, especially if you dragged a finger across one button onto another, or put two different fingers on one button, then released one... stuff like that).
So!...
RELEASING TOUCH COUNTS
If attribute "ButtonPressed" =0
-If Touch1Used =8...
--Change attribute: Touch1Used =0
--Change attribute: self.TouchCount = 0
-If Touch2Used =8...
--Change attribute: Touch2Used =0
--Change attribute: self.TouchCount = 0
-If Touch3Used =8...
--Change attribute: Touch3Used =0
--Change attribute: self.TouchCount = 0
-If Touch4Used =8...
--Change attribute: Touch4Used =0
--Change attribute: self.TouchCount = 0
-If Touch5Used =8...
--Change attribute: Touch5Used =0
--Change attribute: self.TouchCount = 0
-If Touch6Used =8...
--Change attribute: Touch6Used =0
--Change attribute: self.TouchCount = 0
These make sure that any touches that were made on that button or actor (in this case, with ID =8), are released when this button is no longer pressed.
I also occasionally get my system stuffing up (if the player does lots of fingers on one button, or slides their finger around from one button to another in some cases, from memory), but I have a sort of "sanity backup check" behaviour that says...
If TouchCount =0, ... (then set all touches used to 0 -> to clear out any problems or errors)...
-Touch1Used =0
-Touch2Used =0
-Touch3Used =0
-Touch4Used =0
-Touch5Used =0
-Touch6Used =0
It means that even if my game stuffs up, and the player goes, "Whaaahahh!???", they can release their fingers and everything goes back to normal. It really saves your ass. As invariably, if it gets complex, one of your actors will think it's still being touched, or that it's being touched by a finger that it isn't.
Obviously, I want to tweak my system so it never stuffs up! But this sanity check really does help during development, and to catch little issues that are hard to track down.
Hope that helps.
Would be keen to know if anyone else out there has a better solution!
I think you could come up with something along these lines, but neater and simpler, for a game which just needs to track 2 or 3 fingers, and may have more margin for error.
You can see my touchcount system in action in this video of my game... (a work in progress)...
Basically, you don't need to worry about any of this stuff if you don't care where their finger is. But if you want to detect that they've touched the screen with a touch, and you want to move an object to follow their finger, or aim bullets at their finger, then you need to know which touch count it is!
So in my game, I let the user touch the entire middle section of the screen to aim guns.
If it's touch 3, then I need to KNOW it's touch 3, and pass the co-ordinates of Touch 3 to my targeting system to fire bullets at that location.
At first, I tried to just detect the TouchCount (straight from Game Salad), but that just lets you know how many touches are occurring in total.
So if the player uses one finger (touch 1), then another finger as well (touch 2), then releases their first finger, the TouchCount =1, but the current touch that is still being used is Touch2. So if the user places their first finger on the screen again to shoot, TouchCount =2, but the finger they just put down is Touch1.
So you need to know it's Touch1 (using your own attributes system), and then make behaviours to send the coordinate positions of Touch1 to your gun aiming system, and that's where the bullets will be fired.
You can't just send the coordinates of "Touch2" just because the TouchCount =2.
So, in my "Shootbox" (which is a big transparent actor that stretches over the entire central gameplay area), I use a modified version of the rule above about assigning the touch count. I detect which touch it is (by finding the first available unused touch) and also set Shootbox_TouchCount = that touch count).
I then have another set of rules saying to send that touch's XY coordinates to ShootBoxTouchX,Y (which I then use for aiming the bullets towards that touch position)...
If Shootbox_TouchCount =1
-Constrain attribute: ShootboxTouchX = Game.Touches.Touch 1.X
-Constrain attribute: ShootboxTouchY = Game.Touches.Touch 1.Y
OTHERWISE...
-If Shootbox_TouchCount =2
--Constrain attribute: ShootboxTouchX = Game.Touches.Touch 2.X
--Constrain attribute: ShootboxTouchY = Game.Touches.Touch 2.Y
OTHERWISE
-If Shootbox_TouchCount =3
--Constrain attribute: ShootboxTouchX = Game.Touches.Touch 3.X
--Constrain attribute: ShootboxTouchY = Game.Touches.Touch 3.Y
etc... (for each touch)
That way, I know which touch count is touching the Shootbox, and I send the values of the appropriate Touch X,Y to my aiming system.
[Phew. Remind me why I'm making such a complex game, please.]
The level of detail to which you need to track touch counts yourself will depend on what sort of information you need to know about each touch.
If you just want to know if a button has been pressed on a menu, it's irrelevant!
Good luck.
PS: To some degree, I think a user can almost always stuff up any complex touch system, if they want to. I think part of the art is to make it obvious how they're meant to play the game, and any cases where they stuff it up (like having three fingers all in the firing area, means the game will shoot at one of those fingers, and when they release the touches, make sure you handle the situation). You've gotta just do the best you can to make it intuitive, reliable and accurate.
PS: It'd be good if indentations written in posts would make it through to the forum posts, if possible, as code examples are easier to write up with indentation, but they get lost, but I guess that's HTML for ya!
Touch1Used, Touch2Used, Touch3Used, Touch4Used, Touch5Used.
So you can see which touches are being detected as what.
It's a great way to spot where things are going wrong. Where things aren't getting "released" or "assigned" properly.
Wow! That is incredibly helpful. Thanks for the thorough explanation of a very tricky system.
P.S.
Instead of using tabs for indentation, I just use dashes to indicate the level of indentation. It think its helpful. (No one has complained yet.)
Main Rule
-- maybe a constrain
-- secondary rule
---- some more change attributes
---- some more change attributes
----tertiary rule
------ more stuff
------ kind of ridiculous, but usable
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
FryingBacon's Multitouch video series...
I wonder if Game Salad could give us some more built in attributes that expose more touch information to us automatically?
I'm not really sure if it's possible. Could Game Salad return us a value of which count a touch is, and the XYs for each touch?
Maybe it's best for us just to write our own systems, in the end. Just wondering.
Or does the iOS SDK actually reveal more information to the user, and give them more tools to work with, if they're programming natively?
Videos 1 and 2 give you a good insight into the relevant topics to get you started with multitouch.
In video 2, that system works as a starting point.
But it doesn't really cater for other touches on the screen. It relies on the players to use only one finger each, and not to touch each other's screens, and as soon as a third finger is added to the screen, the game wouldn't work properly anymore.
Players can break stuff unless you really implement a robust multitouch system.
But it's a great example of how it works, and you can build extra checks and rules on top of that, as FryingBacon says in the video.
Great videos to get you started!
I'd really advise that you implement a system that tracks ALL touches on the screen (at least up to 5 or 6 touches), and then deal with the specific touches that affect gameplay.
It means your game won't break so easily.
It seems like a complex way of doing something that doesn't actually work properly.
But I guess it could help people get a start with their own systems.