How the scrolling is managed in a Shmup ?

A place for people with an interest in developing new shmups.
Post Reply
User avatar
9uile
Posts: 50
Joined: Mon Jan 13, 2020 4:57 pm

How the scrolling is managed in a Shmup ?

Post by 9uile »

Hi,
I wonder how the scrolling is managed in a Shmup
(let's take R-type as an example because i need obscacles across the level)
Thanks

1.
CAM : fixe, Stage : scrolls to the left, Player : With bounds to stay visible by the CAM


2.
CAM : scrolls to the right, Stage : fixe, Player : child of the CAM with bounds to stay visible by the CAM


3.
none of them ! (please specify in comments)
User avatar
Sumez
Posts: 8019
Joined: Fri Feb 18, 2011 10:11 am
Location: Denmarku
Contact:

Re: How the scrolling is managed in a Shmup ?

Post by Sumez »

Technically, what's the difference between 1 and 2?
Reads to me like it's the same thing, but a matter of perspective.

On a totally abstract level, of course you want to create the illusion that the stage is standing still, while the player is moving through it as the camera scrolls along a set trajectory (maybe with some panning).

But on a hardware level, obviously the screen doesn't move, and it's all the graphics you're seeing that gets offset according to scroll values.
User avatar
lkermel
Posts: 25
Joined: Sat Jun 22, 2019 11:06 pm
Location: California
Contact:

Re: How the scrolling is managed in a Shmup ?

Post by lkermel »

I think I understand your question and where you're coming from. However, I think there is a slight misconception on the notion of 'camera', mainly due to current programming packages such as Unity, which are 3D packages.

For 2D shmups, they used to directly write to the frame/screen buffer, so there is no notion of camera there. All the sprites are in the local space of the screen and the background is on a sort of "treadmill" where you have to offset the screen buffer and then draw new lines of pixels/scenery.

For 3D shmups, then yes, there is a notion of camera because you are dealing with a 3D world and you need to do a 2D projection onto the screen buffer of that world in order to see it. This is, I believe, your question - should you have a locked camera and move the world, or should the world be static and you move with the camera?

Both options work, but in the case where you move the world then try not to do that on each frame because this can dramatically affect your performance. Games that use that technique usually do it after the player moves N units, or every N seconds. In the case where you keep the world static and move the camera (which would be my preferred solution), make sure you don't go too far from the origin. I know Unity can have floating point precision issues if you do...

I hope this helps :)
User avatar
Sumez
Posts: 8019
Joined: Fri Feb 18, 2011 10:11 am
Location: Denmarku
Contact:

Re: How the scrolling is managed in a Shmup ?

Post by Sumez »

Yeah, if you're relying on a ready-made engine where coodinates are handled as floats (ew), definitely don't move your gameplay-centric objects too far from the lower numers :D
User avatar
9uile
Posts: 50
Joined: Mon Jan 13, 2020 4:57 pm

Re: How the scrolling is managed in a Shmup ?

Post by 9uile »

Sumez wrote:Technically, what's the difference between 1 and 2?
Reads to me like it's the same thing, but a matter of perspective.
In '2', there is a strange feeling about enemies bullets because they are affected by the scrolling.
Imagine that the scrolling speed is 2 and enemies bullets speed is 1.
While the level is scrolling, a bullet that goes to the right and a bullet that goes to the left seems to have different speeds.

In '1', every speeds are visualy correct.

Sumez wrote:In the case where you keep the world static and move the camera (which would be my preferred solution), make sure you don't go too far from the origin. I know Unity can have floating point precision issues if you do...
I didn't specify it but i'm in Unity in 2D. As i respond to Sumez, I think that '1' is better to deal with speeds of enemies ans bullets. e.g if i want an enemy goes left and then exit to the right, it has a lower (visual) speed when it goes to the right because it has to go against the scrolling speed.

First, i used '2' because i followed platformers tutorials where the cam is following the player acroos the level.

It's not easy to explain :)
User avatar
Sumez
Posts: 8019
Joined: Fri Feb 18, 2011 10:11 am
Location: Denmarku
Contact:

Re: How the scrolling is managed in a Shmup ?

Post by Sumez »

You did not mention bullets in your first post, and that definitely makes a difference in a shooter, so that's a good question. :)

In the way I've done it in the past, I have two separate scrolling variables - once a bullet has been fired, it's not affected by the stage scrolling, but it's still offset by player-controlled scrolling (panning). I like having immediate reliable feedback for dodging patterns like that.

If you look at games where the background suddenly changes scrolling speed, you'll usually notice that any bullets on screen at that time won't suddenly zoom off the screen either.
You may also want to make a difference between enemies that are tied to the stage scroll (such as ground units), and enemies that are free from it (flying enemies, like the player and projectiles).
User avatar
9uile
Posts: 50
Joined: Mon Jan 13, 2020 4:57 pm

Re: How the scrolling is managed in a Shmup ?

Post by 9uile »

Sumez wrote:You did not mention bullets in your first post, and that definitely makes a difference in a shooter, so that's a good question. :)

In the way I've done it in the past, I have two separate scrolling variables - once a bullet has been fired, it's not affected by the stage scrolling, but it's still offset by player-controlled scrolling (panning). I like having immediate reliable feedback for dodging patterns like that.

If you look at games where the background suddenly changes scrolling speed, you'll usually notice that any bullets on screen at that time won't suddenly zoom off the screen either.
You may also want to make a difference between enemies that are tied to the stage scroll (such as ground units), and enemies that are free from it (flying enemies, like the player and projectiles).
I didn't mention bullets to avoid a messy question :)
My bullets are not affected by the scrolling and also not affected if i decide to change the scolling speed.
I guess i was on a good way ! :)
User avatar
lkermel
Posts: 25
Joined: Sat Jun 22, 2019 11:06 pm
Location: California
Contact:

Re: How the scrolling is managed in a Shmup ?

Post by lkermel »

9uile wrote: I didn't specify it but i'm in Unity in 2D. As i respond to Sumez, I think that '1' is better to deal with speeds of enemies ans bullets. e.g if i want an enemy goes left and then exit to the right, it has a lower (visual) speed when it goes to the right because it has to go against the scrolling speed.
Well, all of this is relative, really. You could still use '2' and have all your flying enemies and bullets in camera space instead of world space :)

At the end it all depends on the kind of shooter you're making. You mentioned R-Type and bullets in such games are more connected with the background - they can collide with it or even crawl around it. So if you exclusively use '1' then it may be difficult for enemies/bullets and background to live in the same world. If you make a game like Crimzon Clover, then '1' is definitely the best approach because it is about having a zillion bullets on screen and you save a matrix transform per bullet in order to keep them in camera space. And well, who can actually see the background in games such as Crimzon? ;)
Licorice
Posts: 247
Joined: Wed Sep 25, 2019 10:04 am

Re: How the scrolling is managed in a Shmup ?

Post by Licorice »

Some random observations I've made. Might help someone out:

3D shmups simulate a camera looking into a 3D world.

2D shmups do the same, only much more approximately, and obey some rules contrary to the mathematics. The following relates to 2D shmups:

All objects move on the screen.

Objects may also "scroll" i.e. move on the screen as if due to the movement of a "camera" capturing the scene.

Scrolling may be:
+ automatic, or
+ due to the player "pushing" against an implicit box (most horizontal shmups along y), or otherwise
+ a function of the player's position (most vertical shmups along x)
separately along x or y.

Objects are drawn using the painter's algorithm i.e. in an order.

Objects drawn over other objects are understood to be closer to the camera than others.

If the player may be drawn over an object, that object is understood to be further away from the camera than the player.

These objects are called background objects.

Some objects may never overlap the player as this would result in a collision.

Such objects are understood to be on the same plane as the player.

These objects are called foreground objects.

Bullets are foreground objects, but are (usually) drawn on top of all other foreground objects.

Mathematically, when a camera moves, still objects further away from the camera will move less in the image captured than closer objects.

Generally, 2D shmups follow this rule when scrolling is automatic.

However, when scrolling is due to player movement, players expect all objects to scroll the same.

E.g. if bullets scroll at a different rate to the background, players will complain about "wobble".

But bullets are foreground objects.

i.e. players expect a contradiction where foreground objects are expected to scroll at the same rate as background objects, when the scrolling is induced by their movement.

Most games follow this contradiction. Refer to:
+ Garegga stage 1 (observe how the far background scrolls in relation to the near background when the player moves left and right)
+ Thunderforce 4 stage 1 (i.e. "strite", observe the clouds when the player moves up or down)

N.B. If an object is moving /slower/ than an object it's drawn over, it's understood to be in motion relative to that object.

If an object is moving /faster/ than an object it's drawn over, it may be understood to be stationary relative to that object and the difference explained by parallax.

Same!^3 and Kyuykyoku tiger backgrounds scroll ~30 pixels per second.

Image fight foregrounds scroll ~20 pixels per second.

So, if an Image fight foreground appeared over a Same!^3 background, and scroll speeds were maintained it would be understood as in motion.

Same!^3 does not seal bullets if a foreground object overlaps a background object.

In stage 3 of Mahou daisakusen large foreground objects are scrolled at the same speed as the background. Visually, the foreground objects are the tops of the background drawn in perspective.

As a result, any background enemies would never be obscured by the large foreground objects. Nevertheless, there are also no background enemies in this stage.

Thunderforce 4 features background enemies in stage 4, but no large foreground objects.

Examples of shmups with large foreground objects and background enemies appearing simultaneously are hard to find or do not exist.

However, both Mahou daisakusen and its sequel shift between the formats and also the "top" background layer.

Other observations:
+ Examples where enemies appear on background planes further than the first are hard to find or do not exist.
+ Push scrolling is avoided on axes with automatic scrolling
+ But Thunderforce 4 switches between automatic and push scrolling on the same axis e.g. in stage 1.
+ 2D graphics hardware scrolled tiles, so looping scrolling (e.g. Gradius 2 level 1) was trivial to implement without concerns about duplicating objects bigger than one screen e.g. one background quad in a modern engine.
User avatar
BryanM
Posts: 6116
Joined: Thu Feb 07, 2008 3:46 am

Re: How the scrolling is managed in a Shmup ?

Post by BryanM »

There's no contest between these two. It's better to have a camera frame and move it around. I can't even fathom doing the equivalent by altering the base value of stationary terrain, that's absolute madness. It'd make everything so much more complicated than it needs to be; this is the first time in my life I've ever thought about it.

Camera. Around five variables needed, max. CurrentX, CurrentY, MoveToX, MoveToY, and Speed. Add the current offsets to everything that's being currently drawn. Simple and clean.
DonnaYu
Posts: 1
Joined: Mon Apr 26, 2021 4:16 am

Re: How the scrolling is managed in a Shmup ?

Post by DonnaYu »

lkermel wrote:I think I understand your question and where you're coming from. However, I think there is a slight misconception on the notion of 'camera', mainly due to current programming packages such as Unity, which are 3D packages.

For 2D shmups, they used to directly write to the frame/screen buffer, so there is no notion of camera there. All the sprites are in the local space of the screen and the background is on a sort of "treadmill" where you have to offset the screen buffer and then draw new lines of pixels/scenery.

For 3D shmups, then yes, there is a notion of camera because you are dealing with a 3D world and you need to do a 2D projection onto the screen buffer of that world in order to see it. This is, I believe, your question - should you have a locked camera and move the world, or should the world be static and you move with the camera?
TalkToWendys
Both options work, but in the case where you move the world then try not to do that on each frame because this can dramatically affect your performance. Games that use that technique usually do it after the player moves N units, or every N seconds. In the case where you keep the world static and move the camera (which would be my preferred solution), make sure you don't go too far from the origin. I know Unity can have floating point precision issues if you do...

I hope this helps :)
Shoot 'em up is a sub-genre of shooter video games, which are in turn a sub-genre of action ... and Metal Slug. Run and gun games may use side scrolling, vertical scrolling or isometric viewpoints and may feature multidirectional movement.
KaceyHruby
Posts: 2
Joined: Fri Apr 30, 2021 7:40 am

Re: How the scrolling is managed in a Shmup ?

Post by KaceyHruby »

The genre commonly referred to as "shoot 'em up" (often abbreviated to Chase-view shooters).
User avatar
heli
Posts: 585
Joined: Fri Sep 13, 2019 3:58 pm

Re: How the scrolling is managed in a Shmup ?

Post by heli »

Foreground Camera :
stays at position (0,0,-viewdepth);
aims at position (0,0,0);

Background Camera :
at position (0,0,-viewdepth); and can move a bit around this position for cool looking background effects and moving
aims at position (0,0,0); and can move a bit around this position for cool looking background effects and moving

The camera can flip back for a repeating sequence, lets say loop the background.
You dont want increasing position, always keep your floating points close to zero.
User avatar
heli
Posts: 585
Joined: Fri Sep 13, 2019 3:58 pm

Re: How the scrolling is managed in a Shmup ?

Post by heli »

I just move the background meshes, and repeat when out of screen.
User avatar
heli
Posts: 585
Joined: Fri Sep 13, 2019 3:58 pm

Re: How the scrolling is managed in a Shmup ?

Post by heli »

I set viewdepth to 100, then the meshes are all small, and you can make background objects that have the same scale.
User avatar
vornaff
Posts: 4
Joined: Thu Feb 13, 2020 4:50 am
Location: San Diego

Re: How the scrolling is managed in a Shmup ?

Post by vornaff »

It is more flexible to separate the background scrolling behavior from the camera node that is driven by the player. The player camera can be used to determine which part of a large background is visible, and for perspective (such as the location of the listener for stereo sound). The play field should be separate so that it can scroll in an entirely different way if necessary.

For example, in my shmup there are stages that can rotate the game field from time to time. This means the background could be moving in weird directions (like a diagonal) while the player is still oriented horizontally and firing horizontally. The player can scroll the view vertically by moving near the top or bottom of the display, smoothly done by moving the camera; a different part of the background may become visible but the background itself can go any way it needs to. The physics then have to follow the apparent direction of the ground, e.g. gravity moving things along some angle instead of vertically.

The scroll position may also not be dictated by a single node. For example, when 2P mode is enabled in my shmup, I use the average of both player locations to determine if they are close enough to an edge to scroll the screen.
  I created the shmup “Celtreos” (for iOS/macOS), including its legendary soundtrack!
Post Reply