1
\$\begingroup\$

Currently I'm writing an iOS game where the basic movement is rolling. Technically you make the player turn clockwise or counterclockwise. When you tilt the device to the right, you will rotate clockwise. This makes sense, because you are standing on a floor, so this will make you roll right. Same idea goes for left, of course.

But sometimes, the player can roll in some sort of looping. The problem with that is, is that the player is in contact with something above (in other words, with a ceiling). This makes the logic turn: tilting the device to the right, makes your rotate clockwise, which will cause you rolling to the left instead.

Physically this is okay for me. But I've seen lots of people trying my game getting confused about it. As they go into the loop, they turn the device the other was as well, in order to follow the direction of the loop. But that makes them roll the other way and slow down, and eventually drop.

I don't want to do a stupid check like: if touching at the top side, then reverse the control, because to me that feels not natural. So, I guess there are lots of other people with the same feeling to this as I'm experiencing.

So, my question is: Are there any good techniques of handeling this issue? Make it feel natural most of the time for everyone?

\$\endgroup\$
1
  • \$\begingroup\$ Add some practice levels? \$\endgroup\$ Dec 26, 2013 at 21:57

2 Answers 2

2
\$\begingroup\$

Your players can be categorised in one of two mental models.

Some of your players are like you -- they've associated tilting right/left with the ball spinning clockwise/anticlockwise.

Others have a different mental model: They associate tilting right/left with the ball moving right/left on the screen. It's these players who, when their ball is tracking the ceiling, expect that tilting left will send the ball toward the left on the screen.

As long as the ball is only following the ground, this mistaken mental model is okay -- the two mental models both produce the same, predictable results for any particular set of control inputs. But as soon as you throw a new context into the mix -- the ball following the ceiling -- half the players will become confused, as the game's behaviour suddenly doesn't match their mental model of what the game should be doing any more.

There are a couple things you can do to handle this situation.

The first thing to try when you find yourself in this sort of situation (half your users are confused because they have an incorrect mental model of how the game works) is always teaching. You want to have a tutorial very early in the game where you explain to the user that tilting left/right causes the ball to spin in that direction, and let them practice with it in a hazard-free scenario until they feel comfortable with it.

The second thing to try is to see if you can't make both mental models work, by avoiding the situation which causes them to come into conflict. In this case, don't have the ball be able to follow the ceiling, or perhaps spin the view around so that whatever surface the ball is following is at the bottom of the screen, so that tilting left does always move the ball to the left on the screen, even if that's technically the 'ceiling'. This has the benefit of not needing a 'tutorial' scenario; it just allows people's assumed controls to work for them in every situation, no matter which mental model they've picked, because we're presenting scenarios in such a way that both mental models produce the same expected behaviour for the same set of control inputs.

If you can't solve this sort of conflict in either of the two previous ways, then in some cases, you can offer a game configuration setting to swap control styles between the two mental models, so that each player can make the game controls work according to their own intuition of how the controls ought to work.

But you probably can't do that last option in this case -- the problematic "tilt left to go left" mental model doesn't work at all if the ball is traveling along a wall (which I assume is possible in your game, since you've mentioned floors and ceilings and loops). In your case, you're probably going to need to do one of the first two options; either teach people the correct mental model, or change your presentation style so that the incongruity between the two possible mental models doesn't present itself.

\$\endgroup\$
1
\$\begingroup\$

In addition to the solutions provided by Trevor, there is also the possibility to automatically reverse the controls on-the-fly. This is what Super Mario Galaxy does. When the player moves around small "planets", the gravity in screen space changes if the camera is fixed to show the whole planet. Effectively Mario will be upside down, but he keeps walking to the same direction he is facing while the buttons are pressed down. If the button is released and pressed again, the movement direction is recalculated. See the picture below for illustration. Flipped controls

When pressing and holding down right, character starts to move right and keeps moving around the planet until button is released. If the character is "below" the planet and right button is pressed, he starts to move right in screen space, which is the opposite direction compared to his previous movement.

The same mechanism is applied not just for spherical planets, but also in cases where there is only vertical gravity, but the direction suddenly changes between downwards and upwards. In this case when the gravity suddenly flips, the movement direction is readjusted on the fly even while the button is held down.

This approach works reasonably well for this game. Both new and experienced players can quite easily move the player around intuitively most of the time. However sometimes the player must readjust the direction when the character starts moving to unexpected direction.

\$\endgroup\$
1
  • \$\begingroup\$ Worth noting that what you're talking about here is switching the control implementation entirely to the "tilting right moves the character right on the screen" mental model, with a control lock put in place when the control scheme switches. I've never tried using a control lock for tilt controls; not sure whether it's as intuitive as it is for joysticks/joypads/buttons (it fails pretty spectacularly for spinners, for example), but it'd be interesting to try it and find out. \$\endgroup\$ Dec 27, 2013 at 18:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .