Movement conventions

[Herr Schatten]

I'm currently in the process of developing a vertical scroller for the Sega Master System. I'm still in the early parts of development, but I'm interested in hearing some opinions on how player and bullet movement should be handled.

1. Player movement: With digital 4-way controls, I have two options of handling diagonal movement of the player sprite. I could make it move at the same speed as it's moving horizontally or vertically (using fixed-point math), or I could just make it move both vertically and horizontally at the same time, making diagonal movement effectively faster. I've seen both in various games. Which option do you think feels more natural?
Regarding option 1: What happens if the player hits the edge of the screen while moving diagonally? Will it just keep going in the one direction it can proceed, but with a fraction of the speed? Or will it proceed as if the player would press directly in the straight direction? That would make sure the player didn't have the feeling of being slowed down, but it could yield unexpected results and possibly create the feeling of losing control.

2. Bullet movement: If I give the player a spread shot, how would I go about moving the diagonal bullets. Again, I could make it move the same distance vertically as a straight one (Super Star Soldier does this for example) plus the horizontal movement or I could move it at the same speed, but with another vector (e.g. Blade Buster). Again, which do you prefer?

[Squire Grooktook]

General Advice: Always normalize diagonals. That means that (on a pixel by pixel speed measurement) diagonals should be slower. Use Pythagoras Theorem to calculate the speeds.

This is what most quality shmups do. You can even test/observe it by doing exactly what you said and moving diagonally against the top/bottom/sides of the screen. You'll notice a very slight decrease in speed as long as you hold two directions instead of one, because the diagonal movement value is actually slower.

There are some who will tell you that it's okay to have wonky non-normalized diagonals. But they are fat and smelly and you shouldn't even think about it if you're not YGW.

[Shepardus]

I think games like Battle Garegga play well despite having non-normalized diagonals, rather than because of it. It'd probably feel weird now if you changed Battle Garegga to normalized diagonals since it'd mess with the movement speeds, but if you're early enough in development that this is a question, just normalize your diagonals. It's far more intuitive since that's how constant speed movement is supposed to work, and it avoids the issue of feeling simultaneously too fast and too slow.

I prefer the movement staying at the slower speed if you move into an edge diagonally - it's an additional form of control for the player (a sort of focused movement), and it'd feel bad to the player if they suddenly sped up in one direction because they hit the edge when they weren't expecting it.

[trap15]

I think games like Battle Garegga play well despite having non-normalized diagonals, rather than because of it. It'd probably feel weird now if you changed Battle Garegga to normalized diagonals since it'd mess with the movement speeds, but if you're early enough in development that this is a question, just normalize your diagonals. It's far more intuitive since that's how constant speed movement is supposed to work, and it avoids the issue of feeling simultaneously too fast and too slow.

I prefer the movement staying at the slower speed if you move into an edge diagonally - it's an additional form of control for the player (a sort of focused movement), and it'd feel bad to the player if they suddenly sped up in one direction because they hit the edge when they weren't expecting it.

Agree with both of these parts. Garegga actually does have a rather interesting reason to keep non-normalized diagonals: medal catching. With non-normalized, you can move horizontally and still catch up with the medals without any loss. I still think it's a bad design decision, but when you think about it in that context, it's more likely to have been an intentional choice than "we already did this".

[Sumez]

There are some who will tell you that it's okay to have wonky non-normalized diagonals. But they are fat and smelly and you shouldn't even think about it if you're not YGW.

This.

Since you're developing for Master System, and most people would probably play using a D-pad, I guess you could argue for non-normalized diagonals feeling intuitive, but the arcade joystick is the classic controller people relate to the genre, and with a controller like that, you're effectively hiding the fact that a diagonal is just two directions pressed simultaneously, and you wouldn't want diagonals to be faster than movements along the axes.

For question 2, if your spreadshot actually goes in different directions, I'd say normalize the speed of the angled shots, too. Especially if you're planning on going in a 45 degree diagonal angle. In general though, you want player shots to be so fast it's not much of an issue. Think of the classic Contra spreadshot:



But honestly, it's not gonna throw anyone off if you do it the other way around, as the impact on gameplay is minimal, while the cosmetic difference is pretty obvious. It'll just end up being something that identifies the individual feel of each game. Here's an example of not normalizing spreadshots:

[Herr Schatten]

Thanks for the input and the explanations. Normalized diagonals it is, then.

Since you're developing for Master System, and most people would probably play using a D-pad, (...)

In this day and age, most people will probably play using directional keys on a computer keyboard. Of course I'm developing first and foremost for the original hardware, though.

[the2bears]

Another vote for normalized diagonals. Just implemented them in my current vertical shooter project.

[Herr Schatten]

Another vote for normalized diagonals. Just implemented them in my current vertical shooter project.

I just implemented them in mine, too, and it really feels 'right' when playing. Since in my game all movement is based on 16-bit fixed-point math anyway, it would have actually taken an extra effort to make them non-normalized. It's just that I found non-normalized ones so frequently in 8-bit shmups, that I wondered whether I was missing an important reason to use those. Hence, my question in the original post.