What do you call straight forward motion?
Author
So, in a WASD game, the W-S keys control back-and-forth movement, and A-D side-to-side. In my code, I call the latter strafe movement, so lots of variables gets prefixed with "strafe". For straight-forward movement, though, what do you call it? It's "longitudinal" right now, but for obvious reasons I don't want to keep typing that...
In chess, movement parallel with the edges of the board is called 'cardinal'. The four points of a compass are the 'cardinal directions' or 'cardinal headings'. So try that.
On a partially unrelated note; why do you have variables prefixed with 'strafe'? What do they store?
On a partially unrelated note; why do you have variables prefixed with 'strafe'? What do they store?
Author
Quote:Original post by Wyrframe
In chess, movement parallel with the edges of the board is called 'cardinal'. The four points of a compass are the 'cardinal directions' or 'cardinal headings'. So try that.
On a partially unrelated note; why do you have variables prefixed with 'strafe'? What do they store?
Mm, I like the sound of "cardinal," but wouldn't that refer to east and west as well as north and south? I'm thinking of just the movement analogous with north-south, relative to the mover.
As to why I have strafe variables: depending on WASD input, I calculate the speed the player wants to go in the longitudinal and strafe directions, and then set velocity accordingly.
The word you're looking for is "Move"
W and S "Move" the player. Easy as that. It's a pretty common label for that functionality. A and D is pretty much exclusively refered to as "strafing" as you already call it.
Calling it anything else will confuse players. They'll get it if you call it "Moving" or "Move". Another popular term is "Forward/Backward" (or split it up individually).
Don't overcomplicate things.
W and S "Move" the player. Easy as that. It's a pretty common label for that functionality. A and D is pretty much exclusively refered to as "strafing" as you already call it.
Calling it anything else will confuse players. They'll get it if you call it "Moving" or "Move". Another popular term is "Forward/Backward" (or split it up individually).
Don't overcomplicate things.
Why not just "forward" and "sideways"?
But really, chances are that the fact that you have two whole "sets" of variables - one set for motion in each access - points out a design problem. You should be defining some kind of 2-dimensional vector type instead, and using one set of variables with vector arithmetic.
He's looking for a convention for variable names. I doubt the players will see those, much less care about them.
But really, chances are that the fact that you have two whole "sets" of variables - one set for motion in each access - points out a design problem. You should be defining some kind of 2-dimensional vector type instead, and using one set of variables with vector arithmetic.
Quote:Original post by dashurc
Calling it anything else will confuse players.
He's looking for a convention for variable names. I doubt the players will see those, much less care about them.
Author
Quote:Original post by Zahlman
Why not just "forward" and "sideways"?
But really, chances are that the fact that you have two whole "sets" of variables - one set for motion in each access - points out a design problem. You should be defining some kind of 2-dimensional vector type instead, and using one set of variables with vector arithmetic.
I've been shying away from "forwards," since the same axis is just as frequently negative. But, as you say, maybe I should reconsider the whole system, as people seemed surprised I'm making the distinction at all. Thanks for the advice.
Quote:Original post by Sol BlueQuote:Original post by Zahlman
Why not just "forward" and "sideways"?
But really, chances are that the fact that you have two whole "sets" of variables - one set for motion in each access - points out a design problem. You should be defining some kind of 2-dimensional vector type instead, and using one set of variables with vector arithmetic.
I've been shying away from "forwards," since the same axis is just as frequently negative. But, as you say, maybe I should reconsider the whole system, as people seemed surprised I'm making the distinction at all. Thanks for the advice.
Yeah, just let it all be considered a local movement vector. It's in player-space, meaning forward to the player is forward in the player's Z axis (or X or Y, depending on your coordinate system). So:
vector3 move(0, 0, 0);// every frame or soif (moveLeft) move.x += -1; // to the leftif (moveRight) move.x += 1; // to the rightif (moveForward) move.z += -1; // to the forwardif (moveBackward) move.z += 1; // to the backward// global movementvector3 movement = playerOrientation * move;// now you'll want to clear the per-frame move variablemove = vector3(0, 0, 0);
Author
Thanks for the advice, agi_shi. I do something similar, actually. When it comes down to moving the object around, it has a velocity vector, which it scales by elapsed time and applies to its position vector. Before that, the longitudinal/strafe variables are used to track player input:
W: longitudinalSpeed += 300;
S: longitudinalSpeed -= 300;
A: strafeSpeed -= 300;
D: strafeSpeed += 300;
That sort of thing. These desired speeds are then used to build the velocity/position vectors when it's time to actually move.
There are probably ways I could track this without separate variables for the two axes, but what prompted the post was finding an alternative to the clunky "longitudinalSpeed."
W: longitudinalSpeed += 300;
S: longitudinalSpeed -= 300;
A: strafeSpeed -= 300;
D: strafeSpeed += 300;
That sort of thing. These desired speeds are then used to build the velocity/position vectors when it's time to actually move.
There are probably ways I could track this without separate variables for the two axes, but what prompted the post was finding an alternative to the clunky "longitudinalSpeed."
I just call my 4 potentially-analog axes Move, Strafe, Turn, and Look, because they're all short and reasonably descriptive. But actually maybe it would be better to combine move and strafe into a vector at the input system level. Especially since that would give a nice place to normalize the vector, to prevent the classic bug with independent x/z movement, where you go about 1.41 times as fast if you walk diagonally all the time :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
