Tag Info

Hot answers tagged

16

Can I discourage you from attempting to emulate a D-pad on a touchscreen device? The problems with emulating a D-pad on a touch screen are: the D-pad takes up screen space that you could be using for the game; unlike a real D-pad, an emulated D-pad offers almost no feedback: as a player, you can't tell which direction you're pressing in, neither by feel ...


16

There's a comprehensive question on UX about touchscreen button sizes. The recommended size depends highly on your game, but the minimum size is quoted as 9-12mm, about half an inch, and this is based on the size of fingers. Keep in mind that this is a guideline, and the cost of ignoring it is that your users will tap the wrong thing on occasion. Depending ...


10

I know this isn't the most useful answer, but unless you are porting a project over from another platform, I'd suggest reconsidering on the virtual D-Pad. Most implementations of virtual D-Pads have been poor at best, the lack of tactile feedback make them a poor choice for the platform. You are far better off looking at building an interface to your game ...


9

What you need is to know the geometric distance between the user's touch (T) and your "difference point" (D). distance = squareroot((T.x - D.x)² + (T.y - D.y)²) Then as another answer said, just check if the distance is less than the circle's radius, 5 pixels in your example.


8

There are pros and cons to both, but the decision is ultimately yours. You'll have to decide based on the style of your game and the type of game. Static position: Always in the same place, predictable. This means the user will always know where the indicator will be and allows them to avoid covering it up on their own. Kind of boring and requires some ...


5

I can't tell you about cocos2d specifically, but in general, tap vs. drag is the same input recognition problem as mouse click vs. drag. The standard way to handle this is to note when a mousedown (or touch) happens, and store where it happened, for later reference. Watch for mousemoved (or touchmoved) events to see if it moves around. If it moves to a ...


5

There is an XNA sample of touch thumbsticks here I would reiterate that a dpad is unlikely to be the right interface for a touch screen like device. Something like what epic has done with Infinity Blade for the iPhone may give you inspiration Movie Link


5

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. ...


4

Mouse and keyboard, I love you! Look at the competition, that has got to be as good as any advice you can get here. It sounds like you have put good thought into it, all the options you mention sounds reasonable. But a lot of it is down to testing. You might spend a lot of time redesigning the interface, but it's a crucial element, so it's worth it, despite ...


4

I suggest using an orientation histogram. First, collect sample points on your curve, ensuring they're far enough apart to be meaningful. Choose a minimum distance of 10 pixels, for instance. Then iterate on point triplets [A,B,C] and compute the orientation change: v1 = (B - A).normalize(); v2 = C - B; f = atan2(-v2.x * v1.x -v2.y * v1.y, v2.x * ...


4

Your code is only looking at the Single Touch portion of the event. You will only ever receive information about the first finger to hit the screen. If you lift that finger, your event will jump over to the second finger that is down, right? You need to implement MotionEvent.ACTION_MASK to get the multi-touch parts. Something like: int action = ...


4

You can use atan2 to find the angle of rotation. If (tx, ty) is your touch coordinate and (x,y) is the center of your rotation you can call double rot = Math.atan2(ty-y, tx-x); //first y then x rot is an angle in radians [-pi, pi] just rotate your triangle using it EDIT Implementation. Assuming that you have setted up opengl so that screen ...


4

You check for input in your Update method. Update is where you'll respond to input, move entities around, do collision detection, update counters, update and data that needs updating. Draw is where you draw everything... Initialize is where you set initialize whatever data structures you're using. LoadContent is where you load save states, load ...


4

Do this in character controller script's Update() First of all you have to detect the user input via touch(begin/moved/ended) methods and then you have to calculate the gesture it ended up in like swipe-left. You can assign a bool to it like SwipeL = true; Now you have to add a condition in the methods where character movement is mapped with ...


3

Like the others have said, it's best to come up with a design that fits the environment, not force the environment to fit your design, but if you do stick with the D-Pad, here's how you might do it: If you think of the "touch point" as a mouse cursor, you are basically create a "hot spot" that reacts to the cursor movement. The best/simplest way to do it I ...


3

You may split the arrow into a shaft and a head. Then you just enlarge the shaft and add the head later on. This will prevent your arrowhead from being stretched and if you pick a shaft image which will not show any signs of strechting (i.e. a rectangle) the whole process will be hidden.


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 ...


3

What exactly "doesn't work" about the multi-touch? The second touch provides no apparent effect at all, or it provides some input but the inputs don't work properly? Many Android phones, even newer ones, may not have "true" multi-touch. These phones have hardware limitations that effectively let them mimic pinching and rotating gestures, but don't ...


3

For the curve or straight line problem, I think I'd keep a list of the positions of old input. Then, I'd check the slope between every point (delta Y / delta X). If the slope does not change a lot, then it's probably a line. If it varies a lot, it's probably a curve. You could use a limit representing the slope difference that determines if the input is a ...


3

Occasionally touch events get dropped, so you may also need to implement the same logic in touchesCancelled:withEvent. See http://discussions.apple.com/thread.jspa?messageID=8397178


3

Virtual dual-sticks are just rough on a touch screen. Option #1: Movement Stick + Touch to shoot Put one virtual stick on screen to control the player. The other finger touches on the screen where you want to shoot. This still gives you one virtual stick to deal with, but moving is often less critical than aiming in this style of game so at least the aim ...


3

(I'm assuming you're talking about vertical shooters a la 1942). The gold standard seems to be what cave did in do-don-pachi resurrection: http://www.youtube.com/watch?v=lm9cOiydk3w Basically all movement is relative and basic firing is automatic. Special firing (i.e. bombs) is done by a touch button off the side of the screen somewhere (do don pachi had ...


3

I think you need to translate screen to world space. Camera.ScreenToWorldPoint


3

Seriously, Google that stuff: http://docs.unity3d.com/Documentation/Manual/Input.html There is a complete manual on unity. Took me just one google search.


3

As Byte56 said, the decision is yours. But my personal opinion is that an floating HUD game is better. I think something like this: is better if you don't need the extra space around the user's finger that's occupied by the GUI. Then you can make it adapt depending on some variables, like it becoming smaller when an enemy is hit, ...


3

If your hit test is really that simple, then instead of doing more complicated triangle intersection as Byte56 suggests you could do simple AABB-ray intersection test. The intersection test will tell you the point that was hit. This point in model space will lie on one of the faces (so one of X, Y, or Z will be +/-h, where h is the half-width of your ...


2

I see most people here thinks a D-Pad is a bad idea, and they are right - most of the time. Dungeon Hunter from Gameloft for Android is a great example of a great D-Pad for touch-screens. It is responsive, have a 360 degree direction, an is not "dumb". What I mean that it is not "dumb", is that when you press the D-Pad and slide you finger out from the ...


2

In your example, isn't the reason why the button press should take precedence simply because the button is on top? So you don't really need to assign priorities, or sort your list, as you already have such an order in place somewhere else - the draw order. Just handle mouse events in the inverse order that you're drawing your entities. For example, in my ...


2

Looks good. But you don't really need a CCScene class. Just implementing the scene-method listed below in your CCLayer works fine. And the need to let the singleton maintain a list of active squares is indeed unnecessary, unless you have a good reason to keep it. // Scene with layer method +(CCScene*) scene { CCScene* scene = [CCScene node]; ...



Only top voted, non community-wiki answers of a minimum length are eligible