Trying to make the frame viewport be limited to a certain X position and Y position

[Mason16YT]

I'm trying to achieve what a lot of topdown games do when it comes to scrolling and areas/rooms.

Basically, I have a huge frame size. But I want seperate areas the player can go to. The thing is, I want each area to have a specific "frame size"/frame viewport size, without seperating each area into a bunch of different actual frames; so the camera can still scroll in those areas, but then the scrolling gets cut off before you go into the next area. And then in the next area, it will have its own independent frame size to then have camera scrolling again. ( I'm pretty bad at explaining, but I hope you can understand this )

I can't figure out how to do it exactly, any help would be appreciated!

[Volnaiskra]

The way I do it in my game is by placing objects in the frame that I call 'Camera Marshals'. If you want to see the whole code, you can see it in my camera system called volCAMERA which you can get on the Clickstore. But the concept is simple enough, and you could easily do it yourself without volCAMERA.

In the top picture, you can see where my camera is naturally positioned in the centre of the screen (the light blue square with crosshairs). This reveals undesirable portions of the level towards the bottom. So I place Camera Marshals throughout the level (the large yellow/blue dotted objects in the middle picture). You can see how they force my camera upwards and rightwards, which results in the game looking as it does in the bottom picture.

Essentially, I place a little (invisible) square object in the centre of the screen, which represents my camera. Then I test whether it overlaps any marshals, and if so, I move it accordingly. If it overlaps a blue marshal, then push it right with set X("camera") to X("blueMarshal")+Owidth("blueMarshal"). If it overlaps a yellow marshal, then push it up with set Y("camera") to Y("yellowMarshal"). Finally, I Centre display at X=X("camera"), Y=Y("camera")

It gets a bit more complicated if you use slanted camera marshals instead of just rectangular ones, but that's the gist of it.

[Mason16YT]

The way I do it in my game is by placing objects in the frame that I call 'Camera Marshals'. If you want to see the whole code, you can see it in my camera system called volCAMERA which you can get on the Clickstore. But the concept is simple enough, and you could easily do it yourself without volCAMERA.

In the top picture, you can see where my camera is naturally positioned in the centre of the screen (the light blue square with crosshairs). This reveals undesirable portions of the level towards the bottom. So I place Camera Marshals throughout the level (the large yellow/blue dotted objects in the middle picture). You can see how they force my camera upwards and rightwards, which results in the game looking as it does in the bottom picture.

Essentially, I place a little (invisible) square object in the centre of the screen, which represents my camera. Then I test whether it overlaps any marshals, and if so, I move it accordingly. If it overlaps a blue marshal, then push it right with set X("camera") to X("blueMarshal")+Owidth("blueMarshal"). If it overlaps a yellow marshal, then push it up with set Y("camera") to Y("yellowMarshal"). Finally, I Centre display at X=X("camera"), Y=Y("camera")

It gets a bit more complicated if you use slanted camera marshals instead of just rectangular ones, but that's the gist of it.

I'm not sure if that would necessarily work with the way my camera works. It's a smooth scrolling camera that always follows the player (the event is: "X( "Camera" ) + ( X( "Player" ) - X( "Camera" ) ) * 0.05" ). Since the camera works like this, its always following the player to have a smooth camera movement, so I'm not sure if it would work with that sort of system. I was reading up on things and I came across the window control object, but I'm not entirely sure if it *will* work, since I couldn't figure it out myself

[Volnaiskra]

I'm not sure if that would necessarily work with the way my camera works. It's a smooth scrolling camera that always follows the player (the event is: "X( "Camera" ) + ( X( "Player" ) - X( "Camera" ) ) * 0.05" ). Since the camera works like this, its always following the player to have a smooth camera movement, so I'm not sure if it would work with that sort of system. I was reading up on things and I came across the window control object, but I'm not entirely sure if it *will* work, since I couldn't figure it out myself

Yep, you use a LERP-based camera (aka Linear Interpolation), just like I do. The trick is to introduce a middleman object, which I call the Target. Then, make the Target continually follow the player, and change your code to X( "Camera" ) + ( X( "Target" ) - X( "Camera" ) ) * 0.05. So far, it will behave exactly the same way as before. But now, you can constrain the target how you like (eg. with the above-mentioned Marshals). The camera will still LERP smoothly, but because it's now following the target - and not the player directly - you have more control over where it's allowed to go.


In the GIF below, notice how the blue square (my Camera) smoothly follows the faint grey square (my Target). The Target follows the player, but only within allowable areas. The Camera smoothly LERPs to the Target, and therefore remains within the allowable areas too.

I was reading up on things and I came across the window control object, but I'm not entirely sure if it *will* work, since I couldn't figure it out myself

I don't think the Window Control object is going to be relevant for this. It's more about stuff to do with the actual window that contains your game or application (eg. minimise, restore, resize window, set to always on top, etc.).

[danjo]

as was stated, you can prevent the camera from moving by setting up instructions (after) you do your camera follow; eg;
-camera follows player
-check if camera X and/or Y is past a certain area; and set it back. (& then you could check if player is too far away from the camera, limiting the players movement)

you could do that a number of ways - by checking X/y co ordinates, or by having invisible markers, and checking if the camera has gone past or overlaps etc.

[Mason16YT]

Yep, you use a LERP-based camera (aka Linear Interpolation), just like I do. The trick is to introduce a middleman object, which I call the Target. Then, make the Target continually follow the player, and change your code to X( "Camera" ) + ( X( "Target" ) - X( "Camera" ) ) * 0.05. So far, it will behave exactly the same way as before. But now, you can constrain the target how you like (eg. with the above-mentioned Marshals). The camera will still LERP smoothly, but because it's now following the target - and not the player directly - you have more control over where it's allowed to go.


In the GIF below, notice how the blue square (my Camera) smoothly follows the faint grey square (my Target). The Target follows the player, but only within allowable areas. The Camera smoothly LERPs to the Target, and therefore remains within the allowable areas too.







I don't think the Window Control object is going to be relevant for this. It's more about stuff to do with the actual window that contains your game or application (eg. minimise, restore, resize window, set to always on top, etc.).

Hey! Thank you so much, it actually worked out perfectly for me, and I was able to figure out screen transitions with keeping the camera smooth!

[Volnaiskra]

Glad to hear it

[Volnaiskra]

as was stated, you can prevent the camera from moving by setting up instructions (after) you do your camera follow; eg;
-camera follows player
-check if camera X and/or Y is past a certain area; and set it back....

That would work too, but it would negate the smoothness of a LERP camera. The camera would smoothly ease towards the player, but would abruptly halt whenever it hit a boundary. The 'middleman' method I mention above allows the camera to smoothly ease towards boundaries too. Both approaches may be desirable in certain scenarios.

[danjo]

i was being pretty general - but it all depends on your follow camera if its going to slow when it gets closer to player. that's what i normally do.