Bullet Trajectory and Scrolling

[wiNteR]

Which games the bullet trajectory is actually affected by scrolling and which ones the scrolling is merely a visual effect? For example, in Stage-5 of Raiden III the background is moving extremely fast, but it doesn't seem to change the bullet trajectories. But for Cave games, and horizontal games in general, it does seem like the scrolling has an effect. So it seems that different games treat it differently, perhaps even at various points within a game.

[Udderdude]

Usually bullets failing to scroll with the background is a sign of lazy coding, or lack of background layers.

[nimitz]

It's called bullet Wobbling (when the panning of the screen affects the bulet position relative to the player). Cave games do not have that, if there is anything it's visual only, does not affect the game.


If you want a great example of true bullet wobbling try R-shark by dooyong

[Battlesmurf]

It's actually one of the reasons I don't play Raiden 4 more. Beautiful game, lots of fun- but the bullets shouldn't move when I move. It makes the game feel slower too.

[Damocles]

Welcome to the wonderful world of Under Defeat. ...of sorts.

[louisg]

Lots of PCE games do this and it bugs me. Though, anything 3d with rapidly panning cameras obviously doesn't make the bullets follow the rotation of the camera or it'd be impossible to play .

I don't remember UD having bullet wobble...

[Elixir]

It's actually one of the reasons I don't play Raiden 4 more. Beautiful game, lots of fun- but the bullets shouldn't move when I move. It makes the game feel slower too.

This. Bullets don't have a mind of their own, they should be treated as such.

No idea why this still exists. Bullet wobbling is just terrible:

[wiNteR]

Usually bullets failing to scroll with the background is a sign of lazy coding, or lack of background layers.

It can be lazy coding, but doesn't necessarily have to be. For example, consider the case where the background is scrolling very fast just for cool effects.

Cave games do not have that, if there is anything it's visual only, does not affect the game.

Are you sure about this? Because most of these games where the horizontal area is greater than the screen this effect is there (horizontally at least). But horizontal direction is solely in player's control, in vertical games that is.

My original question was for the direction of automatic scrolling, which is obviously vertical in vertical shoot'em ups. In any case, see the last pattern of ESP Rade for example. The effect seems to show itself pretty clearly there, or am I missing something?

Anyway, I was just interested whether someone has tried to make any list related to this.

[Obiwanshinobi]

Verticals have backgrounds?

[spadgy]

It's called bullet Wobbling (when the panning of the screen affects the bulet position relative to the player). Cave games do not have that, if there is anything it's visual only, does not affect the game.


If you want a great example of true bullet wobbling try R-shark by dooyong

I couldn't find an R-Shark video anywhere!

To confirm, does Bullet Wobble mean that, for example, in a vert shmup that lets you pan left and right in a playing field wider than the screen area, as you do pan left and right in that way the bullets do not pan left and right in unison with the movements of your ship? In other words, the bullets' trajectory is unaffected as you pan the screen on the X-axis - right?

Or is it the other way around, in that your panning does cause the bullets to pan with you?

It should go in the glossary here. We have Scroll Wobble right, but that isn't quite the same thing is it?

[clp]

Haha i tried r shark last night in mame to check this and holy fuck is it bad .

[captpain]

It's called bullet Wobbling (when the panning of the screen affects the bulet position relative to the player). Cave games do not have that, if there is anything it's visual only, does not affect the game.


If you want a great example of true bullet wobbling try R-shark by dooyong

I couldn't find an R-Shark video anywhere!

To confirm, does Bullet Wobble mean that, for example, in a vert shmup that lets you pan left and right in a playing field wider than the screen area, as you do pan left and right in that way the bullets do not pan left and right in unison with the movements of your ship? In other words, the bullets' trajectory is unaffected as you pan the screen on the X-axis - right?

Or is it the other way around, in that your panning does cause the bullets to pan with you?

It should go in the glossary here. We have Scroll Wobble right, but that isn't quite the same thing is it?

This terminology is confusing me, too.

In R-Shark, it looks like the bullets actually move the same direction that you scroll. So, when you scroll left, the bullets sort of wiggle with you to the left, instead of staying where they were relative to your ship. I don't know exactly what's happening, and it's hard to describe, but it's one of the worst shmup things I've ever seen

[BulletMagnet]

It should go in the glossary here. We have Scroll Wobble right, but that isn't quite the same thing is it?

It's actually listed as a "term under consideration" in the discussion thread - one of these days I need to go back and update that thing.

[toaplan_shmupfan]

Or is it the other way around, in that your panning does cause the bullets to pan with you?

Yes.

If an enemy fires in the center of the screen and one moves their icon (plane, ship, whatever) that causes the screen to pan and reveal more of the left side of the screen, the bullets should continue to follow their path which means they would be dodged and further to the right of the icon.

If the bullets drift left along with the icon as the screen is panning, that plays just a bit different than deliberate homing shots, and that annoys me. It means bullets dodged may not be fully dodged because the entire shot pattern can drift. It's less of a problem with an aimed pattern since those don't usually flood the screen with bullets but in the case of a screen flooding manic pattern that's going to be a huge problem.

[Dave_K.]

It should go in the glossary here. We have Scroll Wobble right, but that isn't quite the same thing is it?

It's actually listed as a "term under consideration" in the discussion thread - one of these days I need to go back and update that thing.

I believe they both describe the same thing, but are viewed differently by different people. At least with R-Shark as the prime example, its not the bullets that are wobbling, but the panning background layers that give the illusion that bullets are speeding up or slowing down relative to the background horizontal movements. If you really focus on the bullets positions relative to the ship, and ignore the background (this is difficult), you'll see the bullets maintain their original trajectories.

What udderdude stated is correct, the bullet layer is not panning along with the background layers, and is a sign of lazy coding, or perhaps, a gimmick to increase the game's difficulty.

[wiNteR]

Bumping my own ancient topic again because I have nothing better to do.

So basically there are few of elements to it. As I understand it, these would be:
1) Vertical Scrolling
2) Horizontal Scrolling (when the horizontal game area is bigger than the playing area)
3) Garegga Effect (happens only with moving enemies)

(1) is the effect that I was originally trying to mention in my first post. For example, with different games you can 'feel' roughly whether it is or isn't in place. There are few examples that I can think of.

For example, in SnS-2 I am quite certain that this isn't implemented anywhere. The bullet trajectories are completely in dissonance with the background movements. But it 'could' be that regardless of background some 'scrolling speed' was implemented.

For Cave and Psikyo games it feels that it has been implemented in the stages -- yet on the boss battles it is hard to tell. What happens actually on the fast scrolling bosses? Is the default scrolling speed (the speed that is kept during stages) still implemented? What happens in case of stationary bosses? Most likely one would guess that here the scrolling 'actually' stops (that is, scrolling speed = 0).

So, in general, it is clear that even if scrolling is implemented it does seem that at some places the scrolling speed could be different from the background speed (usually for fast-scrolling ones).

But why is it difficult to tell? It's not hard to see why. The reason is that the trajectory of uniformly moving bullets will still remain uniform regardless of whether the game implemented scrolling or not. But it doesn't mean that there is no such effect. Effectively you can see this for (stationary) turrets where the intended direction of fire is clear. If the game actually implements vertical scrolling the 'line of the bullet' will be slightly different from the direction of the turret. If not, both the direction of turret and line of movement of the bullet will be the same.

(2) is only for those games where the horizontal area is bigger than the screen. My 'guess' for how it is implemented is simply that when the player moves in the right or left direction the playing area also drifts by a proportional amount in such a way that when the player reaches the right-most position for example, the playing area is also at the right-most position of the actual game area.

(3) This is simple. It means that whether the relative velocity of the enemy firing a bullet is added to bullet's velocity. Obviously not every enemy has to be implemented in such a layered way in a game and so the same game might implement different enemies in a different way. Of course, we can even argue that how can we even tell what the original velocity of the bullet was intended to be (this argument is similar to the one in vertical scrolling).

But for example, in Battle Garegga this is most evident where turrets are placed on moving enemies. The bullets direction is markedly different for these enemies compared to the turret direction (at the time of fire obviously). The reason, it seems, is that relative velocity of the enemy is added to the bullet velocity.

Sorry for dozen repetitions of the word 'scrolling'

[Icarus]

(3) This is simple. It means that whether the relative velocity of the enemy firing a bullet is added to bullet's velocity. Obviously not every enemy has to be implemented in such a layered way in a game and so the same game might implement different enemies in a different way. Of course, we can even argue that how can we even tell what the original velocity of the bullet was intended to be (this argument is similar to the one in vertical scrolling).

But for example, in Battle Garegga this is most evident where turrets are placed on moving enemies. The bullets direction is markedly different for these enemies compared to the turret direction (at the time of fire obviously). The reason, it seems, is that relative velocity of the enemy is added to the bullet velocity.

… what?
Nowhere in any Raizing-styled game is there an example of this "slingshot effect".

[wiNteR]

Then I could be mistaken. I don't have extensive experience with the game. My impression was based on videos of the last boss and playing the first boss, which was years ago anyway. I think then I was simply misreading scrolling for this. Though if a game implements this it could be implemented in different ways. Just reading the onscreen movement speed instead of total movement speed could be one variation (for bosses particularly). This is why I had the impression that boss movement on the screen had an effect on actual direction of fire.

[Ed Oscuro]

The 'slingshot effect' would be warranted according to Galileo's physics, but it would be confusing. These are games after all!

I had a look at R-Shark and Twin Cobra II. In R-Shark, the first four-legged spider-like enemy (boat captain's stage, the first one) has two odd visual effects associated with its bullets: First, the wobbling. Second, the second wave of bullets coming from it is unaligned with the first, despite them coming from the same stationary position in the background.

Clearly, in R-Shark the bullets are calculated according to their absolute screen space, not according to their relationship with other elements of the game world. (The screen has a specific relationship to the ship in every game, but ultimately it is arbitrary, whereas the relationship of the ship, bullets, enemies, and background must have a close relationship.)

So back to Galileo for a second: We know that there are additional vectors of movement added to the bullet. You could think of the stationary position from which a bullet is fired as an additional vector of movement, just with zero motion (compared to the enemy firing it), with your ship's closing speed (as viewed from the cockpit of your plane, which we don't view the bullet from), or with the motion of the screen itself added.

Even if the movement of the scrolling background is discontinuous compared to the absolute frame of the arcade game's monitor (and the bullet as well), it is natural to see the two as linked.

Imagine how difficult it would be to judge something's movement if you always saw it with reference only to the rough frame of your vision - you wouldn't be able to tell if it was moving or at rest in some circumstances. The side effect of this is that the vision sees things with reference to their surroundings (something like the gestalt theory comes into play here), and so when other elements of the scene suggest movement, your brain will tend to calculate the movement of the one object as added to the apparent speed of the other items, and this can be an illusion. But it is far more useful than not, because people are constantly moving. As a result, it isn't important to pay too much deference to the absolute frame of the screen - concordance with the motions of other elements is more important, and it is the discontinuous motion with regard to other screen elements in R-Shark that throws people off.

I can confirm what udderdude, Dave K. and others are saying - in R-Shark, bullets fired straight downward always move straight downward (at least from that first enemy and the others I saw). By comparison, the floatplane miniboss in Twin Cobra II sometimes fires two short laser bursts straight downward - but you will notice that their position is more or less completely stationary with respect to the scrolling background, in terms of both X and Y coordinates. In theory this could work in the real world as well, though it does highlight the absurdity of slow ship bullet speeds in most games. To an observer at the edge of the canal in Twin Cobra II's first miniboss fight, any lasers fired by the floatplane would hover in place (or fall straight to the ground, if you add a third dimension). Of course, simple vector addition (subtraction in this case) will confirm that this can happen in real life, too - thank goodness for Einstein's theory of relativity and bullets that travel faster than a plane can fly.