I am working on a 2D game where you land on planets with a ship and can exit the ship and walk around.

These planets are very small (think ~350 pixel radius sometimes), and are seen from the side. So you can easily see the whole planet on the screen generally.

This may be sort of confusing so here's a picture: space game

I am using the A and D keys to move counter-clockwise and clockwise, respectively. The problem is that if you are on the "top" of the planet (upper half), this makes sense: A moves to the left, D moves to the right. However, if you are on the "bottom" of the planet (bottom half), A moves to the right, and D moves to the left.

Any ideas on how can I make this more user-friendly?

  • 21
    \$\begingroup\$ Have you asked users if they find this confusing? I for one certainly don't - you press right to move your character right and left to move your character left from your character's perspective. This is much better than to, say, change the buttons in the middle of a turn (if you were planning to do that). \$\endgroup\$ – Charanor Jan 24 '18 at 19:44

11 Answers 11


My first suggestion would be to just stick with A = Counter-clockwise and D = Clockwise movement. It is not very confusing and is pretty much the "standard" (i.e. most common) choice when it comes to orbital movement like this.

Another way would be to change the way your game moves. Instead of moving the player when they are on a planet you could rotate the planet instead. This is also a very common choice but it can be disorienting if you have multiple planets on screen since everything except the player will have to rotate. If you decide to use this method it could help to only display a part of the planet to reduce the amount of moving objects your eye has to keep track of:

top half of planet only

If you are free to use the mouse you could always use mouse clicks to move around. Clicking on a location will cause the player to move towards that point and it will automatically choose the shortest direction. Circles are "clicks" and arrows are shortest direction.

shortest direction for click

As an added bonus it's also very easy to translate to Mobile controls if you wish to publish your game as an app as well.

  • 3
    \$\begingroup\$ If going with the camera movement, I suggest making it lag a bit behind, if you want emphasize the direction you are going and speed. your character would appear tilted by 5 or 10 degrees in the direction you are moving. \$\endgroup\$ – satibel Jan 27 '18 at 18:45

When the character gets out of the ship, reorient the view so the character is on top of the planet, and then move the view with the character as they walk around. This way the character is always on top with respect to the view when on a planet, so the left/right controls can stay consistent no matter where you land.

  • 3
    \$\begingroup\$ This could become very disorienting if you are not careful. \$\endgroup\$ – Beefster Jan 26 '18 at 0:04

One approach (often used in third-person games with stick-based movement that also have non-static cameras) is to establish the frame of reference for movement every time the input begins (in your case, when the key is pressed) and keep that frame of movement until the input terminates (the key is released). This means the "A" key would always move the character "to the left," whatever that was -- clockwise if it's on the bottom of the circle, counter-clockwise otherwise -- until the key was released.

Unfortunately, since you're constrained to a circle, this technique will still fall apart when the character is at or near the extreme left or right extents of the circle. You can make it work simply by choosing arbitrarily which direction to go in, but the user may find it confusing. Possibly more confusing that simply sticking with the existing "A is always counterclockwise" approach you have now.

  • 6
    \$\begingroup\$ When on the right of the circle, S should move clockwise. \$\endgroup\$ – user253751 Jan 24 '18 at 23:22
  • 1
    \$\begingroup\$ I didn't think of that because the OP only mentioned two keys, but that's a good idea. \$\endgroup\$ – Josh Jan 24 '18 at 23:24
  • 1
    \$\begingroup\$ It's also important to consider analog stick controls, where this control model feels the best. \$\endgroup\$ – Beefster Jan 26 '18 at 0:09

I suggest you take a look at a similar concept but then in 3d: Super mario galaxy.

super mario galaxy screenshot https://youtu.be/_8eJC4gIAm4?t=19m

At short movements the reference frame stays the same, the universe doesn't move, get beyond a certain threshold the universe moves along/shifts along so the reference frame is back in the middle.

You might wish to "movement blur" the universe when moving so it looks more natural and the eyes won't focus on the moving parts shifting positions.

I assume that Nintendo invested quite some research in getting the game play as smooth as possible and this is what they settled upon. I always like to look to what the bigger companies figured out, hoping they invested something in R&D for maximum comfort and playability.


Use A/D to move the character in the direction towards the leftmost / rightmost point of the planet, respectively, and W/S to move the character towards the topmost / bottommost points.

In this way, the player is always moving the character in the same direction as the input movement -- e.g. D always moves right, S always moves down, regardless of the character's position.

The game could either keep going in the same clock direction while the key is held down, or stop the character at the limiting point. If it stops, it doesn't seem like a big problem -- the player has a full quadrant in which to change their input if they want to keep going in the same clock direction.

Additionally, a circular W-A-S-D or W-D-S-A pattern of input results in circumnavigation of the planet, which seems fairly intuitive.

Holding down more than one key could just cause the most-recently-pressed key to take precedence, or you could use more complex behavior such as having eight limiting points.

  • 1
    \$\begingroup\$ This is what I was going to suggest after playing Super Mario Odyssey. However, due to the change in control schemes it was quite unintuitive at first. If it is your main control scheme, perhaps that won't be a problem \$\endgroup\$ – Kaiged Jan 25 '18 at 23:14

This is one of two classic "mental model" problems suffered by a lot of games.

Every player develops a "mental model" for how game controls map onto game actions. As games have become more and more similar in their controls over time, people have begun to expect their established mental model to apply to new games, rather than developing separate models for separate games. Which would be fine, except that not every player has the same mental model of how controls should work.

For example, the other classic "mental model" problem is whether pressing up on a joystick (typically the right analog stick of a gamepad) should mean looking up, or whether it should mean tilting forward (i.e.: looking down). Neither model is objectively right, but most players only keep one of these two possible mappings in their head, and will be thrown off if a game does something different than they personally have come to expect.

Your question is exactly the same dilemma; the "mental model" issue here is whether pushing right on a control stick means "move to the character's right" (as in Resident Evil), or "move toward the right side of the screen" (as in Mario). Or in this case, "move clockwise" (as in Tempest, when using a traditional conversion from paddle to joystick controls).

Every player will have a built-in model that they're used to which they will be reluctant to change (or have difficulty changing). In any such "mental model" issue, you have three options for how to handle the issue:

  1. As the developer, you pick which model is the best one for your game, and use it. Ignore the complaints of people who have trouble with your chosen model; they'll just have to adapt. And if your game is compelling enough, they will.
  2. Implement both possible models, and let players choose which one they want to use.
  3. Re-design the game to make sure that the mapping of controls->game actions remains the same, no matter which mental model someone is using.

Option 3 ("re-design the game so the mental models don't conflict with each other") in this case would mean rotating the camera with the player, so the player always appears upright on screen. That way, "right means go clockwise" and "right means go toward the right side of the screen" are always in alignment; there's no conflict any more and players won't become confused depending upon their mental model of how controls are supposed to work.

Option 2 would mean implementing both styles of control; one where pushing right takes you toward the right side of the screen, one where pushing right takes you clockwise, and having an options screen where the player can pick which control style they want to use.

Any choice here is valid; the different options just require different amounts of work and impose different constraints on your game. If it's really important to you for the player to be visible moving around on the "bottom" side of the planet, either for thematic or artistic reasons, then you won't want to use option 3, and should use 1 or 2. If not, then option 3 is probably the ideal choice.

A minor implementation note for the "pushing the joystick to the right means moving toward the right side of the screen" control style: When implementing this control style, you should do it by mapping the joystick direction into a clockwise/anticlockwise choice, and then keep that same clockwise/anticlockwise decision until the joystick moves again, even as the player moves around to the bottom side of the planet. That is, pressing right while on top of a planet, or down while on the right side of a planet, would each start the character moving clockwise, and the character will then keep moving clockwise even around the bottom of the planet until the player moves the joystick again, even if they move to a part of the planet where that joystick direction would now be interpreted as being a different direction.

This technique is often called "locking" the joystick control, and is generally used in 3D games when the camera makes a sudden rotation (which you don't want to cause the player to suddenly change direction), but can also be useful here in a 2D game, if a camera movement would otherwise make the player's unmodified inputs suddenly mean something different than they did before.

  • 1
    \$\begingroup\$ Is swiping down on my laptop's touch pad with two fingers a scroll up, or scroll down? If I was on a mobile device, it would be up (because my fingers and the page are 'connected') but the same direction on a mouse would be down... I feel this disconnect every time I use a Mac... \$\endgroup\$ – Draco18s Jan 27 '18 at 22:57
  • \$\begingroup\$ @Draco18s That's another great example! Windows considers that a downward scroll input means look further down in the document, while Apple considers that a downward scroll input means move the document itself downward (which means that we see more toward the top of the document). But on desktop OSes, Apple knew that lots of folks had the other mental model for how scroll inputs work, and so they implemented both and let each user choose which they prefer.. \$\endgroup\$ – Trevor Powell Jan 29 '18 at 6:38
  • \$\begingroup\$ Yeah, you can change it, I just know so many people that have it set up by default ("move the document downwards"). Heck, the windows laptop I got for work a month ago had that as a default. I turned it off right quick (I turned the "edge scrolling" feature on instead, but I think I'll turn it off again because it's too slow: seriously, the full height of the scroll area scrolls....five lines....) \$\endgroup\$ – Draco18s Jan 29 '18 at 6:58

Use W/S/A/D for input (or up/down/left/right). Treat the input as an 8-way direction (including diagonals).

Then move the player in whichever valid direction (clockwise or anticlockwise) is closest to the direction that is pressed.

  • \$\begingroup\$ I think this solution would fit better with a joystick than a keyboard, but it's still a possible solution, I would however have it as a choice, because having to move your fingers in a circle on wasd can be quite hard on the hand if playing more than an hour. \$\endgroup\$ – satibel Jan 27 '18 at 18:38

One option is instead of defining the association between key and direction of movement, to have:

  • one key to move "forward" (in the currently selection direction)
  • one key to "turn around" (switch direction)

This requires the character to have a clearly visible "direction".

Not sure that really makes much more sense than other options here, but just in case....


Down is where the gravity is. So when the player-character is on a planet, rotate the camera together with the movement of the player-character so that the character is always on top of the planet.

But while this makes navigation on the planet easier, it might disorient the player relative to other celestial objects. This is a tradeoff you need to decide on for yourself.


If you choose to use clockwise/counterclockwise movement, there are a number of things you can do to make the system easier to intuit for your players.

Give the character prominent distinguishable directions

If the character is half blue and half red, then orientation becomes easy for players to remember. Instead of having to identify "clockwise" or "counterclockwise", the players either move in the blue direction or the red direction. If the character is always facing in one direction (preferably clockwise, so that movement is most intuitive while upright) it's even better, because English speakers (and anyone else with a left-to-right language) naturally tend to associate 'right' with 'forward', reinforcing the connection between the controls and the direction of movement.

Never let the characters stop moving

As long as you are moving your character, it's easy to maintain what orientation your controls are in. After all, continuing to move in the direction you are moving in doesn't take any action at all, and when you want to reverse your movement, there's only one other key to choose. It's only when you start moving again after having stopped that you are faced with a choice. The longer you pause, the harder it will be to pick up again based on what you were doing before. By reducing pause frequency and pause lengths you can keep players from forgetting how to move.


There are multiple approaches to this.

1) How I would approach this would take sections of the planet: the top, left, right, and bottom sides (more if desirable). And have it so after the user presses a direction, the character will keep going that direction till they release that button. So if the character was on the left side and the user pressed up, then the character would go clock-wise till release. This way you don't have to worry about changes in the frame of reference while the character is moving, only after.

2) Another way would like how "Lovers in dangerous space-time" approach it. With a joystick, rather than have the frame of reference depending on the surface, they have it so the angle the joy-stick was the desired spot for "character" to stop at. So their frame of reference was at the center of their "planet". I say character and planet but they had modular ship parts on the outside where you determine where they go, ie which direction the thrusters are pointed to move the ship.

3) How you have it designed now. It can get a little getting use too but nothing players haven't seen before. You could edit it though so it appears the planet is rotating instead so the play is always "on top".


protected by DMGregory Jan 29 '18 at 14:19

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.