Scene size

If I understand correctly, you want your game's resolution to be 1920x1080 and the game world to be 2500x1080. You have a player object/scene and you want your camera to follow the player, staying within the bounds of the 2500x1080 world?

You can set the camera's bounds with the limit variables. You can also set if from code, though I recall it was a tad confusing. If I remember correctly, Godot treats one pixel as one unit, so you'd set your right limit to 2500, left to 0, top to -1080 (since up on the Y-axis is negative in Godot), and bottom to 0.

This is assuming your working in 2D. The 3D camera has no built-in functionality for camera bounds like the 2D camera, though it shouldn't be terribly hard to write something that would work for a 2.5D camera. Let me know if you cannot get it working, I can probably find/make an example.

I'm a tad confused.

You have a background that's 2500x1080 and you want it to scroll with the level? Or your level is 2500x1080 and your background is of some other length? Does the background move even when the player is not moving? Is the background the same size as the level?

---

If the background moves even when the player is not moving, then there are a few ways to tackle it.

One way is making a separate scene for your background and render it with a different camera. Then take a viewport sprite and have the sprite in the foreground following the player.

Another way is having a background manager that spawns and destroys the background dynamically. When a background reaches the end of the level, it either spawns a new one at the beginning of the level (or vice versa, depending on which direction you want to background to be moving) or moves it back to the start.

There are several other ways, but those are the only two that come to mind.

If the background only moves when the player moves, then it's a little easier. You could place the background in the level statically, then it would seem to 'move' but in reality it would be the player that is moving. The problem with this method is that your background has to be the same size as your level, or some of the background gets clipped.

Another way to do it is to move the background with the player, but at a different speed. This would require the background knowing both the player's position, and also the size of the level. Then when the player moves, it would calculate how far the player is relative to the level, and then move its self relative to that length.

A final (and probably easier) way to handle it is by cheating a little bit. You could hard-code a value in your background so that when the player moves, it moves at the player's speed plus the hard-coded value. Technically this method is taking a risk, because your background has to be bigger than ALL of the levels that use it.

Like before, there are several other ways to handle it.

If the background is designed to be stitched together, then it's super easy! Just move the background by some factor (whether it be player speed or something else) and when it reaches the end of the level, spawn a new one. Since you're background doesn't move in the Y-axis (I'm assuming) then there isn't any semi-complicated code for managing another axis. You would just have to write a background manager, place the starting backgrounds, have the backgrounds send a signal when they reach the level bounds, and have the manager spawn another background at the end/beginning of level.

As to your question, it depends. I would recommend having only your player(s), entities (like power-ups, platforms, enemies, ect), and background(s) move through the level, and have the actual level geometry be static. This makes collision a little easier to setup and maintain, and should reduce bugs in the long run. The other way is possible, but I've never used it so I cannot say on it's pros and cons.

No problem! I hope it helps.