difference in methods

I was looking at the Flying template that comes with Construct2, & I noticed that the bullet behavior is attached to a looping background, while the player's object (the pig or whatever it is) is static except for an up & down motion.

I've been experimenting with building this type of game on my own, & the method shown here is completely opposite of what I've been doing. I use an enormous non-looping static sprite for the background image (6800 pixels wide), & then I attach ScrollTo & Bullet behaviors to the player's object.

It works, but I was hoping to get some insight as to the meaningful differences in these methods....why choose 1 over the other? I'm obviously no programmer, I'm just kinda learning by trial & error. Any input?

First approach is more common, hence the genre name "Scrolling Shooter" - the player remains static (on one axis), while the stage is sliding past them.

In older games this also implied that stage elements (enemies, power-ups) were also loaded just as they were to pop into the view, and destroyed as soon as they are left behind the player.

This also helped to keep memory usage low and logic simpler, since it was known that any coordinate would always be in fixed range slightly larger than screen.

Second approach is less common for shooters but occurs more often in other genres (e.g. platformers) - if your player is moving through stage, it totally makes sense to just scroll around the camera alongside with them.

Functionally... nowadays these should not differ much.

A response from developer would help more, but generally engine is going to render images that overlap the view area one way or other.

With numeric values being stored in double-precision floating point format nowadays, you are also not going to see any kind of number precision problems unless your coordinates exceed about... 10�6. Which is an extremely unlikely scenario.

To sum it up, both will work, and in your game you choose, what feels right. Moreover that methods can be swapped quite easily.

An image that's 6800 pixels wide will eat up a HUGE amount of VRAM. Also, it's a bit awkward to teleport the player back to the start seamlessly.

Those two factors make an infinite scrolling game probably better with the first approach.

As — said, having the huge background image will take up a lot of memory which some low-end devices may not be able to handle.

miketv, it's all about the experience that you would like to provide for your users. There are successful games that design the entire pseudo-infinite levels and there are successful games that have entirely randomized infinite layouts. But, I doubt either has an image that is the size of the entire level. There are much more important aspects to the game that you probably want the users to experience.

thanks for the replies.

danialgoodwin, suppose the background image IS the most important aspect. Without going into too much detail, I'm experimenting with an "art game", & I have a series of illustrations that need to scroll past like a train in a certain order. They aren't all the same dimensions, but they're all bigger than the game's boundary. Would it be best, then, to just break the train of illustrations into individual giant sprites & attach the Bullet behavior to each of them individually?

(Also, is there a link where I could catch up on the differences between pseudo-infinite layouts & randomized infinite layouts?)

thanks again

miketv, okay, I can imagine scenarios where the background is most important. Maybe that sort of game would have different themes for the user to go through. In that case, you still don't need to load graphics that are nowhere near where the window the user is viewing. I think that idea to split the single very large image into multiple smaller images would work great. Then, when you only load the images as they are about to appear to the use (and destroy ones that leave), there will be less memory usage, thus a better performance.

When I said the "pseudo-infinite" layouts, I just meant that some game designers have manually created/programmed the level to look a certain way, and every time you play that level it will always look the same. Then, it could be made practically impossible to get to the end, or it could just loop around with more enemies, as an example. A somewhat popular game a while back that I tested was "Robot Unicorn Attack 2". In that game certain levels were always the same, but I never could reach the end.

For the randomized infinite layouts, the Construct 2 start dialog (Ctrl+n) has a great example called "Flying along". Also, the current game/app fad, "Flappy Bird" has an infinite random layout. And, when I say "random" with these games, there are typically restrictions on what can happen so that parts are impossible to complete.