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:
- 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.
- Implement both possible models, and let players choose which one they want to use.
- 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.