# Adjust Keyboard input to match look direction?

A concept I am working on uses W,A,S,D for movement and sometimes the camera will be oriented so that the game is side scrolling, where D is forward (moving right), but other times the camera might be behind the player looking forward (Kinda like 3rd person) and In this case, W would need to be forward.

Currently I only have it set up where D is always forward but it gets highly confusing when the camera angle changes at a certain parts.

Is there a simple enough way to figure out how to determine which key would be appropriate for forward? I kinda think of it like making the keys act analogue or something like that, but can't think of a good way. Maybe something like the closer the cameras forward direction is to the players forward direction, interpolate key inputs to match axis?

Also, my camera is following on a spline path so when the direction its looking at the player changes, its not immediately 3rd person. It eases into that, so to make this more complicated, I would think that sometimes a combination of two keys would be forward (D to D&W to W)

Sorry if this is common but I couldn't figure out what to search for.

Edit: I didnt include the detail that its not purely left/right for the side scrolling part, the character can go in all 4 directions (+X,-X,+Y,-Y) but is limited by a small path. Space would be my jump. See pic below:

-
What does the W key do in side-scrolling mode? Make the character jump, or is it a special 'up' movement for things like climbing ladders? – ChrisC Jan 18 '13 at 20:08
No its not purely one direction for the side-scrolling bit. There is a little bit of space on the path(left/right) so W and S would be left and right for the side-scrolling aspect. Space is my jump. Updated the post to give a pic – Mungoid Jan 18 '13 at 20:25

I would make the transition snappy and clear cut. The user needs to know when to use which keys. While I agree it's more natural for `D` to be forward on a side scroller and `W` to be forward in 3rd person follow, transitioning between is not so common, and less intuitive.

If when in side scrolling mode there is no use for `W` then I would allow the user to continue to use it for forward, in addition to `D`. Otherwise, you'll need to make it clear that `W` is not moving them forward when in side scrolling mode.

The transition between doesn't need to detect camera angle or anything so complex. Surely you have a trigger that makes the camera switch modes from 3rd person to side scroll. Apply the keyboard input changes at the same time the transition is initiated. And always make sure the transition happens at a time when the user doesn't need to be moving forward.

If you want to make the change automatically, you can set the change to happen when the camera forward direction and the player forward direction are perpendicular or close to. You can test that by finding the angle between the two.

I would not switch the controls at all in this case. If the camera is free flowing between states, it will be difficult and frustrating for the user to keep straight which button to use for going forward.

If the transition is not clearly defined by a state machine and you have to derive it based on the camera angle, then the player will also have to derive it. If the transition is not immediately clear and only happens when the user is at a door or some other stopping point, it will be confusing to the player. When it's close to the transition point, the user will have to guess which button to use. Guessing wrong means frustration. Additionally, since they could be holding `W` to move forward, and the camera freely switches to side scroll follow, then they're suddenly moving up and not forward.

-
Sorry, i added some pictures to clear up what i meant by side-scrolling and the possible views the camera might have. I think i could use some sort of trigger when the camera hits a certain point in the spline to switch to different keys, although in this case, the camera follows a track and the immediate moment the keys would change might confuse the player. See this sample for what I am doing with the camera. And the pictures show the tracks i am talking about. midaera.com/testbuild/MidaeraTrack.html – Mungoid Jan 18 '13 at 20:34
I think if you do some testing with the controls changing, you'll find that it's not as intuitive as you might think. I implemented something similar in my game. I had a camera orbiting a world map, the WASD keys could be used for moving a selector on the world map, it was kind of confusing having it change directions near the transitions. Perhaps you'll find different results, but play testing will be the only real way to discover this. – Byte56 Jan 18 '13 at 21:22
Good point. In my mind it seemed like a decent solution but once I finished getting controls to work the way I thought it should, it felt a bit awkward and I foresee a lot of faking results. So based on your suggestion, what if I split my player look spline up to multiple based on the current 'obstacle/required camera view'? For the side scrolling, A/D is fine for left/right respectively and once you get to those platforms in image 2, i immediately change to the top-ish down view and adjust keys and once I get past that, it goes to a separate 3rd-ish person spline and w being forward? – Mungoid Jan 18 '13 at 22:53
I think that'll work. If you make the transition clear, it'll be clear to the user when to use which controls. Again, you'll want to have the transitions at place where the user is unlikely to need to be continually moving forward. It's something you'll have to play test to be sure about, but it's far better than leaving the transition ambiguous. Alternatively, you can provide both splines, and allow the user to choose between which one they want to utilize. – Byte56 Jan 18 '13 at 23:01

In both views, map the keys according to the view vector and movement of the camera. In 2D view the world may be "flat", but still thinking in terms of looking at it from a Z depth in 3D space. For me it's easier to compare it to a traditional 2D fighter where you can only walk left or right, but 3D fighters allow sidestepping and circle-strafing. Think of how the joysticks are mapped according to these views.

It is indeed harder to map WASD keys when the "clear" path to walk along is at an angle offset from what the camera sees, it's why analog joysticks are much preferred for the granularity.

Initially, WASD keys should be moving the player along the camera's local coordinates at the moment when the key(s) were pressed. This is the most intuitive way to map the keys when you cannot know for certain where the camera is in relation to the player. That blue vector that points up can just as well be the "away" vector (imagine it going down the camera's local Z axis). Contrast this to "tank" controls where W and S move the player along the vector to what the character sees.

Since your camera moves along a spline, its local coordinates change, because the tangent might change. If the player is currently moving and the camera changes direction, do not update the controls to its new local coordinates until the keys are released. This way, the player can keep running along a straight path without frantically switching controls as the camera moves.

I pretty much learned this making a Marble Blast-type game, such a game would have more slippery movement and require twitch reactions. If I wanted to U-turn on a dime, I would initially press Down to move towards the camera, but as it quickly swivels around, I would be again going away from the camera, but still holding Down and moving in the other direction. Upon releasing Down, the controls "shift" to match the camera's new orientation.

-
Thats pretty much what I was initially thinking, but with this game I wanted to make it feel a bit 'cinematic' so I wanted the camera to do its own thing while (intuitively) knowing what to do with the keys. I ultimately think Bytes suggestion may work best for my case as I don't know if I have the technical/mathematical know-how to figure out how to keep this 'smart' and still feel right for the player – Mungoid Jan 18 '13 at 23:02