Hot answers tagged multitouch
5
Most any top down perspective will work. 2D games have done this in the past with games like PacMan:
Additionally, any top down perspective where the camera is at the center of the screen. This gives the kind of view you showed in your comment:
Both of these assume the players are sharing a play field. If the players are not sharing a play field, you ...
5
You are almost getting it right, but you should use your pointer id to request the X/Y instead of i
int id = event.getPointerId(i);
int x = (int) event.getX(id);
int y = (int) event.getY(id);
From the MotionEvent documentation:
The order in which individual pointers appear within a motion event is undefined. Thus the pointer index of a ...
3
In a word: Swiping.
I played Pac-Man championship edition on my Android phone and what I thought really worked for it is that while there was an on screen joystick, you didn't actually have to touch it to move Pac-Man in the proper direction. If your finger fell off the joystick it didn't matter. All that mattered is in what direction you moved your finger.
...
3
Personally, I've found most "on screen joysticks" pretty lame, no matter how slickly they're implemented. Its a pretty clear case of taking a solution from a different technology (consoles/arcades) and trying to apply it to a new and rather different technology (multi-touch screens), and resulting in a mess. So, I'd add some more "cons" to your list that ...
2
Turns out this was a device independent problem (See comments above) and the issue posted to Google Code can be found here. There was actually no problem with the code in libGDX. I'm Posting this as an answer rather than deleting so that people like me can find the answer before ripping their hair out.
2
Given what you've told me in your comment, you can do something like this:
float touchX, touchY;
public boolean onTouchEvent(MotionEvent event)
{
if (event.getAction() == MotionEvent.ACTION_DOWN ||
event.getAction() == MotionEvent.ACTION_MOVE)
{
// store values
touchX = event.getX();
touchY = ...
2
Well, the answer would probably be: because Windows, Mac and Linux are not primarily touch screen platforms, and multi-touch inputs is a concept that only makes any sense on touch screen platforms.
Why would engines support an input mechanism if the platform doesn't? In some cases (e.g. iOS from Mac OS) there's a common framework because the platforms have ...
2
To reduce the amount of if statements you have you need to make your solution data-driven instead of manually adding logic for each UI component that needs to interact.
You could do this by storing your buttons data (such as each buttons bounding box and state) in an array of structs or a NSArray (or NSMutableArray) of classes. Then when you receive a touch ...
2
I found side-of-screen touch and hold controls to be the most responsive.
If the person touches the left side, run left (until he lets go). If the person touches the right side, run right.
RunRunRiot! is an example of this.
As for jumping, you could go for a mid-screen tap (using either hand).
Examples (landscaped iPad)
Running right
______________
| ...
2
I think this will work for you.
One mistake you made was iterating over all pointers for every event. It's only necessary for move events.
Secondly, you actually do need to put the index value into the getX and getY functions, but you get the id associated with that index to use as a reference to your game objects.
You assign an id to your joystick during ...
1
What if you treated a half of the screen like a virtual track ball where the position/speed of your character is directly tied to that of the ball? Swiping and releasing would set your character into constant motion (and cause the trackball to spin). Holding your finger on the screen would be like holding the trackball so that you could make small ...
1
You could consider having more precise controls for only when the player character is airborne.
For instance, if the right side of the screen controlled lateral direction, you could have the entirety of the left side be for the jump. Once airborne, the bottom left half of the screen could be 'descend' and the top half could be double jump.
Another option ...
1
The best input for a touch screen game I have found is on those really simple platform games when all you have to do is touch the screen to jump! Any game that uses the accelerometer for movement input to me is very disorienting!
This is a common dilemma when developing on a touch screen, if only there was a D-pad attachment that was popular. I think you ...
Only top voted, non community-wiki answers of a minimum length are eligible
