Opinion? Iphone Game Navigation is a PITA

I am trying to find a decent method for navigating a character in an iPhone (iPad) game. I have 3 ideas, none of which I am overly excited about :frowning:

  1. Use of direction buttons (as in screen shot)… I can configure them in differnt ways
  2. using Swipe Gestures (but I think this would be rather slow, but maybe not)
  3. Touch the grid and have the character move towards the cell the user touched

Right now #3 is topping my list.

other ideas??? please???

I’ve played games that use # 2 and they’re not bad
Although in reality they seem to use a combination of #2 and #3

So if I leave my finger on the screen they move towards my finger (up or down left or right) continuously
If I tap they move “once” and dont continue to move that direction

If that explanation makes sense ?

@DaveS,

I’d suggest a 4 or 8 way joystick, placed bottom left. Your current layout would likely require 2-thumbs to navigate, the joystick only a single thumb. You can have a setting to toggle for left handers.

Kind regards, Andrew

1 Like

I vary rarely play games on my phone. However I love the “Monument Valley” games and navigation is handled by tapping where you want the character to move to.

My game for iPhone (HexFiller) is more towards the arrow keys along the bottom. Particularly on the iPhone it can be hard to hit the exact spot on the screen. And you are holding the phone at the same time to complicate the situation.

The problem is when using an iPAD … I find directional buttons and dPad even more difficult because the device is wider.

So I have opted to use the playing area as one BIG “dPad”. touch the screen and the character moves towards the touch point. The board is divided into quadrants (corner to corner) so a touch can be +/- 45 degrees (if that makes sense)

I finally think I found a viable solution.

I looked a various other games… and found PacMan had a good way.
It uses the UIPanGestureRecognizer
this allows the app to track the finger movement as is goes around the screen, in a manner similar to a track-pad. Then when ever there is a CHANGE in direction, it gets set to the function that handles the actual movement

    @objc func gesture$Pan(_ sender: UIPanGestureRecognizer) {
        var direction:  String = "#"
        let velocity = sender.velocity(in: sender.view)
        if (sender.state != .ended) {
            let isVertical = abs(velocity.y) > abs(velocity.x)
            if isVertical {
                direction = velocity.y > 0 ? "S" : "N"
            } else {
                direction = velocity.x > 0 ? "E" : "W"
            }
        }
        if direction != lastDirection {
            lastDirection=direction
            directionEVENT(direction)
        }
    }

That sounds a lot like what I mentioned way back

Dont know if it tells you how far the gesture is from the position of the sprint that is being controlled but I’ve seen some that use that distance to control velocity
The closer your finger is to the sprite the slower it goes
Further away it moves faster

Either way treating the entire screen as a “track pad” makes sense

Velocity-sensitive keyboards equate the speed with which the key is being depressed with how hard it’s being pressed and therefore how loud the resulting sound should be – at least according to product documentation I’ve read. This has always seemed counterintuitive to me (you could in theory play a bunch of 64th notes very lightly and intend for them to be soft) – yet, it seems to work well enough to satisfy musicians. Velocity is a tricky thing, conceptually … it doesn’t necessarily relate to the real world like you’d think.

This isnt a keyboard though
Its a touch sensitive screen for an iPad / iPhone :slight_smile:

We’re literally talking the velocity of a sprite in a side scrolling game :stuck_out_tongue:

I understand that but thought there might be some counterintuitive relationships in common. But I have never done game development, so there’s that :wink:

one thing is did find… while it changes directions quite fluidly… the character RUNS too fast!!! I need to slow him down, otherwise he over-shoots things :slight_smile:

it just took me a while to figure the “HOW” :slight_smile:

1 Like

I do agree that getting “velocity” right for musicians can be hard

But this is, I believe, quite different

For instance there is a version of Galaga for the iPad & iPhone
And it uses the entire screen as Dave and I describe - like a track pad
Move your finger left and the ship moves left
Up it moves up
It basically follows your finger
But if you move rapidly it moves faster
Or if you just tap far away it will quickly move the ship that direction quickly

Now what that ratio of “fast” to “slow” is I dont know
But it is apparent is moves the sprite more rapidly

This use of the entire screen like a trackpad seems very natural and required almost no instruction

Glad you did
I had no idea HOW just that it made sense :stuck_out_tongue:

Well darn… using the screen as a track pad makes is super easy to control direction… but the accuracy of STOPPING at the right place is a problem.

For animation purposes, I found 5 squares per second is in line with what other tile based games do, any slower and it looks bad, any faster and things just zoom super fast

Possible to use the distance of the touch point from the sprite as a speed control maybe ?

Well the way I have it working right now is similar to how a keyboard entry would work (one reason is so I could use the same process for Desktop where a keyboard IS used). So when the swipe detects a change from the last direction used, it caches that value (N,S, E or W) and activates a timer, and every timer period it executes a move command (think key repeat). Its just difficult to find the right repeat interval to make game play and animation “feel right”. Another issue is the above posted routine, requires an actual “veloctiy” which doesn’t really allow for small increments of movement.

That all being said… I may have to go back to a “tap and hold” method