Game Mechanics 4-way movement on touch-screens

[Smarty]

Hi,

I'm trying out a game concept currently for touch-screen devices (phone / tablet). The game has a top-down view and the player character moves in a grid of squares. It can move one or more squares horizontally or vertically. The game's puzzles rely heavily on making 4-way movement possible, diagonal moves are only possible in two steps (one horizontal, one vertical). A typical example game would be Sokoban, but the difference is that there will also be some kind of button to trigger an event on the square the character is currently on.

There are several ways to go about designing the touch interface that I can think of, and I'm not sure which will feel the more natural to use. Here's each:

• 5 on-screen buttons (4 arrows, 1 trigger). Downsides: apart from this not being a standard in mobile games, on-screen 5 buttons also take up a lot of screen estate.
• Left, right, forward buttons. One button less than above, but more difficult for the player to navigate the character.
• Virtual joystick plus button. My personal issue with virtual joysticks, either in a fixed position or planted where-ever you put your finger, is that because there is no real thumb stick, your thumb feels cramped trying to stay within the confines of the stick movement. You can't feel when you've pushed too far.
• Tap edges (plus button). Tapping (and holding) the edges of the screen to move in a certain direction seems logical, but your hands need to move a lot more across the screen and this also blocks your view, especially on a tablet.
• Tap on the square to walk to (and tap current square to trigger). This seems like an obvious choice, but the character normally moves squares either horizontally or vertically. If I would tap a square diagonally from the character I would have to apply some path-finding to find the most ideal route (not all squares can be walked on), and this may not be the route intended by the player (in Sokoban, this could mess up the puzzle).
• Drag and hold in a direction to walk (and use other half of screen as button). This requires no visual controls, but to be able to switch from e.g. horizontal to vertical movement, the player would have to lift their finger and drag again.

I haven't played a great deal of touch-screen games that involve 4-way movement along a grid of squares, but the ones I did used on-screen buttons and that did feel very clunky to me. I think touch screen control should be so transparent and natural that there is almost no question on how they should be used, and hardly any explanation required.

I'm very interested to hear of people who have played mobile games a lot whether they see benefits of any design over another, or if anyone knows of a good design not listed here (it's fine to mention Android games that have solved this elegantly, I would love try them out).

 

[Storyteller]

tap squares in sequence and follow that path to avoid coding pathfinding or unwanted paths in movement
alt:
tap space next to you to move,only move one space

 

[Smarty]

tap squares in sequence and follow that path to avoid coding pathfinding or unwanted paths in movement
alt:
tap space next to you to move,only move one space

Thanks. My problem with the tap-to-move is that you need to tap positions in the x and y axis from the character whereas tap-to-move suggests any square is game. This is a confinement that may not be clear to the player, and may feel cramped.

Tapping only the space next to the character is not preferred, as the character must sometimes move several squares in a certain direction, and at times quickly. Repeatedly tapping could be a strain, as well as hamper continuous movement.

I'll still chalk it up as a vote for tap-to-move, though.

 

[HayManMarc]

What about tap and drag, drawing the intended path as you drag? When you lift your finger, that would be the end point of the path. (may need a confirmation of some kind, if you want to allow for player mistakes/sloppy dragging.)

 

[Smarty]

What about tap and drag, drawing the intended path as you drag? When you lift your finger, that would be the end point of the path. (may need a confirmation of some kind, if you want to allow for player mistakes/sloppy dragging.)

Yes, that sounds like the drag-and-hold solution in my list. And since there are only 4 directions, players get a ninety degree range of sloppiness (anything between a 45 and 135 degrees angle between start point and current position is up, for example). It's the option I currently favor most, but there are things to think about - I need to consider what to do when players do not 'draw' a clear line (actually a direction vector) and I need to decide the minimum distance between start and end point before it is registered as a move. But above all, dragging can go into the area reserved for the 'trigger' button, so I need to make sure these inputs do not collide.

Anyway, one point for drag. Do you know of any 4-directional touch screen games that use this input? It'd be nice to see a good implementation of it.

 

[Yal]

Tap on the square to walk to (and tap current square to trigger). This seems like an obvious choice, but the character normally moves squares either horizontally or vertically. If I would tap a square diagonally from the character I would have to apply some path-finding to find the most ideal route (not all squares can be walked on), and this may not be the route intended by the player (in Sokoban, this could mess up the puzzle).

One idea could be to highlight the four neighboring squares, and only allow tapping those. (If a square additionally is not a valid move, highlight it in red). It could get cumbersome to tap to move one square at a time if the player needs to cover a lot of ground regularly... but I'd say having lots of empty space in your levels is a design flaw in a game like this (since it easily feels like padding, and if the levels are too big to fit on one screen they instantly get much harder to take in).

(I actually recently helped test playing a puzzle game with this control scheme, and at one point its creator reworked some levels to make them smaller. It was a noticeably change for the better. Tapping the cell to move to also was the only natural choice in that game since manipulating the player's movement options was the main mechanic, so what movement inputs were available wasn't always obvious)

 

[Smarty]

Thanks Yal (and hi, good to see you still around).

I should have explained maybe, but the squares look like terrain. I do not expect confusion from that. I can relate to the idea to keep puzzles confined to smaller maps, but a bigger playfield allows for increased puzzle difficulty (I will zoom out, but obviously smaller squares will make them more fiddly to touch). Partly however it is also an action game, so moving more than one square with a single action is a requirement.

But, in a comparable manner as mentioned above, I think I might try highlighting all squares in the 4 cardinal directions where the player can tap on. This may even only be required for the first few levels until the player gets a feel of the control requirements. Another point for tap-to-move, I guess.

 

[Thunder Lion]

Thanks. My problem with the tap-to-move is that you need to tap positions in the x and y axis from the character whereas tap-to-move suggests any square is game. This is a confinement that may not be clear to the player, and may feel cramped.

Tapping only the space next to the character is not preferred, as the character must sometimes move several squares in a certain direction, and at times quickly. Repeatedly tapping could be a strain, as well as hamper continuous movement.

I'll still chalk it up as a vote for tap-to-move, though.

they could implement this but have a on action basis, say if you activate the space the character moves to that space smoothly then goes to the grid. Next the player can keep holding down and the character will go to that square they are touching

 

[HayManMarc]

Do you know of any 4-directional touch screen games that use this input? It'd be nice to see a good implementation of it.

I'm sorry, Smarty, I don't know of any off-hand.

 

[Electros]

Yes, that sounds like the drag-and-hold solution in my list. And since there are only 4 directions, players get a ninety degree range of sloppiness (anything between a 45 and 135 degrees angle between start point and current position is up, for example). It's the option I currently favor most, but there are things to think about - I need to consider what to do when players do not 'draw' a clear line (actually a direction vector) and I need to decide the minimum distance between start and end point before it is registered as a move. But above all, dragging can go into the area reserved for the 'trigger' button, so I need to make sure these inputs do not collide.

Anyway, one point for drag. Do you know of any 4-directional touch screen games that use this input? It'd be nice to see a good implementation of it.

I'm creating a mobile puzzle game, and using the same method with the angle calc and 90 degree leeway for up / down / left / right. It feels intuitive, and it is pretty straightforward to lock out invalid moves (edge of grid etc).



With regarding to the trigger button area, with my block selection I am using the global controls, and only validating if a block is selected on the initial click - if not, the dragging and released code is ignored. You might be able to implement the same, so any dragging or release into the trigger area will not trigger it, only if the initial click was done there.

 

[Smarty]

they could implement this but have a on action basis, say if you activate the space the character moves to that space smoothly then goes to the grid. Next the player can keep holding down and the character will go to that square they are touching

I'm not entirely sure what you're suggesting here, I'm afraid. Could you elaborate?

I'm creating a mobile puzzle game, and using the same method with the angle calc and 90 degree leeway for up / down / left / right. It feels intuitive, and it is pretty straightforward to lock out invalid moves (edge of grid etc).

Yes, I can see that works nicely for a sliding puzzle game too. I think I'm going that route. Nice looking little game, by the way.

With regarding to the trigger button area, with my block selection I am using the global controls, and only validating if a block is selected on the initial click - if not, the dragging and released code is ignored. You might be able to implement the same, so any dragging or release into the trigger area will not trigger it, only if the initial click was done there.

I see. I do intend the ability to cancel moving to a square, in the sense that they can move back the direction they came from if the character is between squares.

As for activation, I need a trigger button because the grid square the character is on may contain i.e. like a device that needs activation. I don't want to activate it automatically upon entering, because the player must be able to cross the square without triggering what is there. I know I'm talking in vague terms, but essentially part of the puzzle mechanics is to move around and decide to trigger an action on a grid square or not. His actions have consequences to the grid map, on which he must eventually navigate to the exit.

 

[Strawbry_jam]

Personally I like drag and hold. Buttons and joysticks feel like they cover up important screen space (if not by the buttons themselves, your hand). Set locations to tap (like edges or buttons) are difficult in action games where you get no physical feedback and timing matters. Missing the button is frustrating. It wouldn't be so bad in a game where timing isn't so important.

You could even include multiple options and let the player choose which one they prefer in options or something.

 

[Smarty]

Personally I like drag and hold. Buttons and joysticks feel like they cover up important screen space (if not by the buttons themselves, your hand). Set locations to tap (like edges or buttons) are difficult in action games where you get no physical feedback and timing matters. Missing the button is frustrating. It wouldn't be so bad in a game where timing isn't so important.

I have seen some games that draw the joystick where ever you place your finger, but still your finger can push further than the constraints of the virtual joystick. Best to have little to no visual indication at all, I think.

You could even include multiple options and let the player choose which one they prefer in options or something.

Yes, thank you, that is under consideration, although I'm verging more and more to the drag and hold solution.

So, chalking up another point for drag and hold, one important thing to consider is the hugely differing screen sizes. And I don't just mean resolution, but also mean physical size. What is the length of the vector a player should drag before it registers as movement? Since DPI differs greatly between e.g. tablets and smart phones, I'm thinking of using the DPI to calculate the physical distance a finger traces across the screen. Does anyone have suggestions for the lower threshold?

 

[Yal]

So, chalking up another point for drag and hold, one important thing to consider is the hugely differing screen sizes. And I don't just mean resolution, but also mean physical size. What is the length of the vector a player should drag before it registers as movement? Since DPI differs greatly between e.g. tablets and smart phones, I'm thinking of using the DPI to calculate the physical distance a finger traces across the screen. Does anyone have suggestions for the lower threshold?

One idea could be to let the player adjust this in the options, by "physically" dragging two circles (deadzone and max length / "average") to fit their screen. Might be a bit iffy to get the precision right for small changes, though, so it could be good to include +/- buttons to make small adjustments, perhaps?

Thanks Yal (and hi, good to see you still around).

No problem, still feels like I wasn't giving an all that good suggestion but I hope it was to some use Having a real job (I finally grew up!) cuts down on my time/energy both to make games and talk about making games, but I lurk the forums a few times per week and I couldn't resist a topic posted by a fellow GM veteran~

 

[Smarty]

One idea could be to let the player adjust this in the options, by "physically" dragging two circles (deadzone and max length / "average") to fit their screen. Might be a bit iffy to get the precision right for small changes, though, so it could be good to include +/- buttons to make small adjustments, perhaps?

I considered it, but I'd like the players to get going with the least amount of fuzz regarding the interface. Precision configuration may be too fiddly.

No problem, still feels like I wasn't giving an all that good suggestion but I hope it was to some use Having a real job (I finally grew up!) cuts down on my time/energy both to make games and talk about making games, but I lurk the forums a few times per week and I couldn't resist a topic posted by a fellow GM veteran~

Good for you. I think. Totally agree on the time/energy reserves. Whenever you feel like it drop me a PM and tell me about your new job, I'd be interested to know.

 

[ParodyKnaveBob]

Howdy, Smarty, nice to see you still around. $¦^ J

Tap-drag-hold...
A "virtual joystick" wouldn't actually need a limit, would it?
Taming Dreams is a (sadly defunct) Android game with a mechanic like this. (You can play the first couple chapters free. The third chapter is actually really, really great, although it costs some.) Caveats: I found it super confusing at first, but it might be that it wasn't well explained, and it's an RPG that isn't timing-heavy on the map thus might not be as relevant for you. Also, for actions (talking, reading, peering into pots, etc.), a simple tap nearly anywhere on the screen did it. (For menu, tap with two fingers on the screen. "Nearly" anywhere because Agitations (not "Battles," perish the thought,) can be avoided by tapping rising Miasmon bubbles, but this sounds irrelevant in your case.)
The nice thing with this method is being able to keep one's taps nowhere near "the action" and thus keeping everything better visible.

Before I remembered that game, though, the first model that went through my head I made up while reading your post.
Tap-(-and-hold-)in-general-relative-direction-to-go...
It's super easy for me to visualize this, but not quite as easy to explain, hm. Let's-a go:
1. Tap kinda generally left of char, char moves left a square.
2. Tap and hold kinda generally left of char, char starts moving left until you let go.
3. Just made this up since you said you'd like reversible moves: Tap kinda generally left of char, char starts moving left -- but give a quick swipe right (whether having ended first tap or not), and char about-faces to return to previous square. Furthermore, tap kinda generally right of char while moving left between squares, char likewise about-faces to return to previous square.
4. To prevent accidental wrong directions, introduce deadzones (perhaps a mere 30–15 degrees) between directional zones (60–67.5 degrees each). At first, some players might fight against this as feeling arbitrary, but it should hopefully train the player's muscle memory for later to keep away from the diagonals.
5. Tap on character to get action button. Likewise, introduce a deadzone immediately around the character to prevent accidental action/direction mishaps.
This might be nicer if the char stays (more or less?) centered with the camera moving around the room.

Alternatively, you might tap-(and-hold-)in-general-relative-direction-to-go like above, but relative to the center of the screen instead of relative to the character: an invisible D-Pad with an invisible button in the center, always centered on the playing field.

I hope this helps,
Bob

 

[Smarty]

Howdy, Smarty, nice to see you still around. $¦^ J

Likewise, Bob! And thank you for your feedback.

Tap-drag-hold...
A "virtual joystick" wouldn't actually need a limit, would it?

No, it doesn't. I was referring to games where a thumb controller is being drawn on the screen where ever you put your finger. I dislike that, because you can drag your finger far out of touch of the visual control, but still hold it pushed in a certain direction. And, I don't think we want to clutter the already limited screen estate.

Taming Dreams is a (sadly defunct) Android game with a mechanic like this. (You can play the first couple chapters free. The third chapter is actually really, really great, although it costs some.) Caveats: I found it super confusing at first, but it might be that it wasn't well explained, and it's an RPG that isn't timing-heavy on the map thus might not be as relevant for you. Also, for actions (talking, reading, peering into pots, etc.), a simple tap nearly anywhere on the screen did it. (For menu, tap with two fingers on the screen. "Nearly" anywhere because Agitations (not "Battles," perish the thought,) can be avoided by tapping rising Miasmon bubbles, but this sounds irrelevant in your case.)
The nice thing with this method is being able to keep one's taps nowhere near "the action" and thus keeping everything better visible.

This is what I would aim for, although I'll struggle to have an action tap not interpreted as a move or vice versa. I tried and I must say this game seems to do it really well, given that you don't actually have to lift your finger to change direction and without this swiping becoming an unexpected mess. If I can figure out how they decide what the player wants, I might try it this way.

Before I remembered that game, though, the first model that went through my head I made up while reading your post.
Tap-(-and-hold-)in-general-relative-direction-to-go... (snip)

Yes, that's more or less the Tap Edges solution, except that you rightly point out that you can divvy up the entire screen for that. My objection stays the same, though - it feels like a hand that needs to move around the player obscure the view too much. Although it might be a better solution than Tap On Square To Move To because it forces the player to select the route.

This might be nicer if the char stays (more or less?) centered with the camera moving around the room.

Not an issue. Given that the player gets a fairer chance to solve the game's puzzle if he sees the entire map, I am thinking of zooming out only, when required.

 

[HayManMarc]

What if the "virtual joystick" followed your finger, but only changed directions with a new direction of swipe? Then you could touch and hold to start movement and move finger a little to the right, then the player object would move right until you either lift your finger (stopping movement) or, keeping finger touched, swipe a little bit in a different direction. The object would then go in that direction.
Problem with this is not being able to stop and think about where you want to go, unless if swiping opposite of current direction makes the object stop.

Hope I explained well enough. On my phone and work is about to start.

 

[Smarty]

What if the "virtual joystick" followed your finger, but only changed directions with a new direction of swipe? Then you could touch and hold to start movement and move finger a little to the right, then the player object would move right until you either lift your finger (stopping movement) or, keeping finger touched, swipe a little bit in a different direction. The object would then go in that direction.

I have considered that before - generally calculating the angle between two 'rest' points of the finger. This would also correct for people tracing curves or other quirky shapes. Maybe I'm thinking too hard about this, though, but I can't help but think how you decide what is the next resting point - both in terms of the pause duration, as well as in terms of how still you expect a finger to sit on the screen - it probably needs up until a threshold to register as (not) moving. These feel like magic numbers to me that you somehow just have to 'get right' for all players and screen DPIs, preferably without configuration by the player. We need get these kind of things right in one go - one of the most off-putting things in a mobile game is to have frustrating controls, which can make or break it.

 

[HayManMarc]

I guess, at the beginning of the game, after it starts, you'd get the dpi/resolution saved in a variable, then refer to it for your finger-move threshold, using a percentage or something. But I'm just guessing since I've never done anything like this before. Interested to know the outcome, tho.

 

[Smarty]

I guess, at the beginning of the game, after it starts, you'd get the dpi/resolution saved in a variable, then refer to it for your finger-move threshold, using a percentage or something. But I'm just guessing since I've never done anything like this before. Interested to know the outcome, tho.

Yes, you can. It's actually possible to calculate the physical distance traveled by a finger. But choosing the right distance is probably left to experimentation.

 

[ParodyKnaveBob]

I practically assume you have GMS2 since you *chortle* wrote the book on GM standards. $;^ b
(Unless that wasn't you but rather Yourself. Hm.)

Re: How to detect certain things the player wants (finger sitting still, how much distance, etc.), have you experimented much or any with GMS2's new touch-optimized events? Swipe, Double Tap, etc. look great, but I have zero experience with them so far since I have close to zero experience with Studio 2 so far.

 

[Smarty]

I practically assume you have GMS2 since you *chortle* wrote the book on GM standards. $;^ b

No I don't. And I don't think I did?

Re: How to detect certain things the player wants (finger sitting still, how much distance, etc.), have you experimented much or any with GMS2's new touch-optimized events? Swipe, Double Tap, etc. look great, but I have zero experience with them so far since I have close to zero experience with Studio 2 so far.

Same I'm afraid. I may consider upgrading, but there's a price tag to it obviously.

 

[ParodyKnaveBob]

No I don't. And I don't think I did?

Ah, sorry. I can never remember which GMC Elder was Mr. Habgood. ~shrug~

Same I'm afraid. I may consider upgrading, but there's a price tag to it obviously.

Interesting @ no GMS2. I suppose if nothing else, you could prototype the controls in the free GMS2 trial and see if 1. the new events make it worth the upgrade for you or 2. you can get a good feel using them and then just reverse engineer the logic behind some of it using GMS1 (or 3. the new events do nothing for you and you promptly return back to the ol' GMS1 drawing board). I've only used the free trial some, and I must say, I like, but also, yeah, new price tag.

 

[Smarty]

Ah, sorry. I can never remember which GMC Elder was Mr. Habgood. ~shrug~

Ah, I see what you're referring to now. No, that's not me. He is one of the main authors behind the two Game Maker's Companion books. And yes, I contributed to the second book, but the books centered around game design with GameMaker as the tool of choice. The books didn't intend to be an authoritative guide on using GameMaker. And anyway, that was 8 years ago.

Interesting @ no GMS2. I suppose if nothing else, you could prototype the controls in the free GMS2 trial and see if 1. the new events make it worth the upgrade for you or 2. you can get a good feel using them and then just reverse engineer the logic behind some of it using GMS1 (or 3. the new events do nothing for you and you promptly return back to the ol' GMS1 drawing board). I've only used the free trial some, and I must say, I like, but also, yeah, new price tag.

Wasn't aware they added these new events, the sales pitch seemed to go on mostly about the IDE. Thanks, I'll consider trying this, or eventually shelling out.