The math used in my demo isn't nearly as hard as it may look. Here's an explanation of what's happening.
Let's start with the camera following the hero:
Now we want to confine the camera to be within the zone the hero is currently in. Let's use the clamp expression to limit the scroll to positions:
So what does this mean? Let's use the X coordinate as an example: clamp(hero.X,zone.X+160,zone.X+zone.Width-160)
This expressions returns the value of hero.x as long as it's in between a minimum and maximum value. Otherwise, the minimum or maximum value is returned.
When testing for minimum and maximum values, we need to keep 2 things in mind:
- The origin of each zone is in its top left corner.
- The width of the window is 320 pixels.
Setting the minimum value stops the camera from going beyond the left edge of the current zone. It's set to Zone.X + 160
. Zone.X is the left edge of the zone, and we must add 160 to compensate for half the width of the window.
Similarly, setting the maximum value stops the camera from going beyond the right edge of the current zone. It's set to zone.X+zone.Width-160
. Zone.X + Zone.Width is the right edge of the zone, and we must subtract 160 to compensate for half the width of the window.
This expression alone will make a very choppy transition from one zone to the other, so let's throw in a lerp. This allows for smooth scrolling when changing zones.
Every tick, the lerp expression moves the current scroll 10% closer to the to the calculated scroll position (the result of the above clamp expression).
I hope this explains things a bit more. Regarding non-rectangular zones, it's going to be difficult to have the camera scroll correctly around corners.
To accomplish this, you'd need a much more complex camera system, smart enough to recognize when it needs to move around corners based on the players movement.