Old-school mapmovement

I have tried finding several ways of doing this, searched the forum and looked at all the plugins, and maybe i have missed something but i dont get this to work.

Basicly i want a movement-system in terms of Zelda: A Link to the past. In such a way that you can move around one square, and the camera doesnt go into the next square, until you actually enter that door or whatever.

Now, i can do this (and have done this) easily when all rooms / camera-views are the same size. The problem comes when for example 3/4 of the layout is supposed to be one part, with the 4th part being alone.

How to stop the camera from scrolling downwards while still scrolling right for example, even tho there's technicly still layout-space downwards as well? If i can just figure that out, the rest isnt much of a problem.

I just need a way to "shut out" the camera from scrolling into certain areas, while still following the character as best as possible.

Thanks in advance

/Mike

If you set unbounded scrolling to on, then the layout boundaries will not stop the scroll and keep in cental at all times, but failing that create an invisible sprite that acts as a camera attach and detach from your player when needed and set scroll to camera when needed rather than your player...

Im not sure if my question was a bit confusing, but i dont really understand your answer compared to what i asked :<

I dont want the camera to view outside of the layout, and im not sure what "set scroll to camera" means ^^; Rather than unbound, i want the camera super-bound and sort of on a rail :P

<img src="https://dl.dropboxusercontent.com/u/15195355/various%20crap/example.PNG" border="0" />

In the crude example created above, i want to be able to break up one single layout into several partitions, and want the camera to be able to scroll along the blue lines without line of sight leaking into the red enclosed area.

And then when entering from the purple arrow, have the camera jump into the enclosure, but not be able to have the line of sight leaking out of the enclosure.

I have an object (several objects in various tests actually) that keeps control of the camera already, im just not sure how to control it so it doesnt pan into "restricted" areas. Or rather, how to restrict areas in the first place in a way that stops the scrolling only into that area while still moving freely where there is no restriction.

dl.dropboxusercontent.com/u/15195355/RikardRemake/index.html

One system (NES-Zelda style, moves when you move to the edges)

dl.dropboxusercontent.com/u/15195355/RikardRemake2/index.html

The second system (Free-roaming camera)

I sort of want to mix them so i have free-roaming except for the parts that are shut off, and when the enclosure in the picture i posted is entered, the camera goes in NES-Zelda style and stays in there. Which doesnt really work very well if i have to start switching layouts and stuff.

Any hint is appreciated ^^;

I believe I understand what you're looking for. Here's one way to accomplish the effect using zones:

Demo

Capx (r131)

The method I used will only work for rectangular zones. I hope it helps

zatyka, that is what i was looking for yes! ^_____^

I havent updated to r131 yet and my internet is pretty slow so it will take a while to check your capx it seems. Might have to sleep before i can look at it :<

Its a huge leap forward compared to what i had accomplished myself, i really appreciate it ^^ Id really like it if it was possible to have like T-shaped zones as well connected to rectangular ones, but i guess that might be tricky?

Using the method in my example, you could overlap 2 zones for a T-shape, but the transition won't be as slick. It does get trickier if you want the camera "rails" to change directions smoothly.

Ahh i can look at your file now, and tho it seems really simple, things turned very mathematical, very quickly.

I have a fairly ok grasp of how to use the engine in many basic ways, but i start to realize that im not really bound in what i want to do because of the engine, but because my mathematical skills are not up to the test. I guess i should try to evolve my mathematical skills so i can use all the lerp:ing, derp:ing and other values correctly ^^

I loved the zone thing, tho i dont understand the math behind it clearly yet, i will look into it.

If i could understand it, maybe i could create something like this (which is basicly what i was working on myself, but havent been able to get working fully):

<img src="https://dl.dropboxusercontent.com/u/15195355/various%20crap/example2.PNG" border="0" />

(Again, its a bit crude, but i hope my point is clear ^^;; )

Basicly the purple box is my camera control item that has the "Scroll to" behaviour. The yellow box is the player. The lines are how im trying to get the object to simultaneously move. The red enclosure is again a theoretical place where i can only enter by the "door" and until then the camera wont go in.

So im trying to keep the player free to move (except into the enclosure), while keeping the purple camera object locked by not being able to leave the blue area. I tried using some sort of pathfinding, but then i would have to use solid objects in strange ways, and that would stop my player as well in very strange ways.

Is this system possible, or is using your zones the way i should try and create things? ^^

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:

<img src="http://i.imgur.com/BoztZOP.png" border="0" />

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:

<img src="http://i.imgur.com/7yXTky5.png" border="0" />

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.<img src="http://i.imgur.com/tmpDv7o.png" border="0" />

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.

<img src="http://i.imgur.com/ywIzEOP.png" border="0" />

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.

Wow, thanks for the explanation, i think i actually understood it all. Im still a bit confused as to _how_ the lerp does what it does, but i understand the thought behind it ^^;; I think.

And i see why it becomes more complex to use non-rectangular zones then :/

Now im just brain-storming here so if this is more difficult than i thought please do tell me, but shouldnt it be possible somehow (with some more magical math perhaps :D) to have 3 zones overlapping, and have the scroll variable calculate only from the zone that you are inside the clamp area of?

<img src="https://dl.dropboxusercontent.com/u/15195355/various%20crap/example4.png" border="0" /> (Schmexxeh photoshop skills~)

So like, as long as the character is more inside of zone 1 than 2, it does the clamp-lerping based on zone1, but if the character is more inside 2 than 1, it switches the clamp-lerping to zone 2, but should (and here's where my logic might be flawed) technicly be in the same spot?

But i just realized while writing this that even if my thinking works, it still is the problem with the corners you mentioned... err...

Guess it might be best for me to keep this one based on your wonderful zone-system, and while i level up my math and C2-skills i might find a working solution that isnt advanced over my head ^^

Short follow-up question if you dont mind helping me understand the lerp and clamping a bit better? ^^;

If i want to have a sprite follow the cursor over a grid, but lock into the middle of the square of which the cursor is currently over, should i go with your zone-system in some way, or is it easier to like:

Each tick: Set <sprite> to Mouse.X(Magical math), Mouse.Y(Magical math) or something based on how big the grid is?

Or something even simpler like "when mouse-over=gridtile, set <sprite> position to gridtile" and then just fill the grid with tile sprites?