roguelike movement, part two
Previously, I looked at roguelike movement in the context of movement between tiles, the screen view, and the game world. As I'm updating Kunoichi, I wanted to try out some alternative movement styles. These are all in the context of instant, absolute movement in an absolute world, with the constraint that the player (and NPCs, by extension) have facing in a turn-based world.
Rotate and move, shown below, is what Kunoichi originally used and can be found in a number of action RPGs. The player presses a direction and the avatar rotates and moves in that direction immediately—rotating is coupled to movement and can't occur independently.
Rotate to direction and move rotates the avatar to the direction pressed if the facing is different. Once the facing and the direction pressed are the same, the avatar moves in that direction. This and all subsequent types decouple rotation from movement. If both rotation and movement have the same cost, then moving forward has a cost of one and moving any other direction has a cost of two.
Rotate toward direction and move limits how far the avatar can rotate in one turn, here 90°. Moving forward or to the sides as the same cost as rotate to direction, but now turning around costs 3 time units. Additionally, rotate toward requires deciding which direction the avatar will turn for the initial rotation (counter-clockwise as seen above).
Rotate toward direction and move with backwards movement extends rotate toward direction by allowing the avatar to take a step back without changing facing. This makes turning around expensive (3 time units) but allows the avatar to backpedal out of a bad situation for much less (1 unit) at the cost of not seeing what's behind the avatar. This is the most confusing rotate-then-move option, though, and in my experiments I frequently confused this with relative movement in an absolute world.
My favorite so far as a developer is rotate toward direction and move with backwards movement—it provides more options and has an interesting cost distinction between turning around and moving backwards. But as a player, I have problems actually using the scheme. As such, I'm inclined to either stick with rotate and move or try rotate to and move.