I have been thinking about how to implement camera "anchors". I don't know if there's an established name for them, but what I mean are some constraints in the level data that restrict/control the movement of camera in some way. The main use case (for me) would be to limit the camera's movement in vertical/horizontal sections of a level. I'd prefer having a flexible system instead of hardcoding the lock conditions into the levels.

Here's the basic idea of what I'm talking about: (Blue rectangle is the camera. Red line segments limit the camera's movement.)

Attachment:

anchor.png [ 40.11 KiB | Viewed 1123 times ]

My current idea is to simply store the horizontal and vertical line segments (as seen in the picture) sorted (similar to objects), and check them against the camera extents as the camera moves. Being able to specify the normal of the line segment might be useful as well (i.e. allow movement from one side but not from the other). I would also like to have dynamic control over the constraints (e.g. to make it possible for the player to access a new part of the level conditionally).

There are some potential problems with the above idea, like how the camera should align itself to that vertical section in the bottom of the picture when the player starts moving upwards. Maybe the constraints should be "soft" instead of "hard" (on case-by-case basis?), so that the camera is allowed to move upwards into the wall, but then starts slowly centering itself on the vertical opening.

Or maybe I'm overthinking this and should just go with a simple system that switches the camera's behavior based on player's (or camera's) position, or when the player touches certain objects.

The question is, have any of you implemented a system like this? How did you go about it? Of course ideas in general are welcome as well. This is on NES, so performance is naturally important.

Donkey Kong Country has something like this where there are boxes where the camera has to stay inside. However, I think only 3 boxes can be connected at a time and they have to be connected horizontally. (I think I remember the underwater levels and Slipslide Ride run entirely different camera code, but I don't think it's known how it works. I'm pretty sure DKC2 and DKC3 use a different camera system altogether, but I've never messed with those games.) This is really easy to code, as all you need to do is at whatever point horizontally there are two camera boxes, check to see if the camera's top and bottom fit vertically in the area you're trying to move into. If your game only moves horizontally, this is fine, but from your illustration, it doesn't seem to be the case. I might try and do some sort of system where there are several boxes in memory that have four different addresses for boxes that branch off of each side. (you could actually make it to where the camera of going to one area wouldn't be the same if you wanted to go back, although I'm not sure why you'd do this, other than maybe you could set it up to restrict the player from going backward at certain points.) Each box would also have information for its x and y position in the level, (from the top left corner) along with it's height and width.

Ditch the limit of each box being connected to 3 other boxes, and you can still use the model of boxes connected horizontally. If you make a box exactly the width or height of the screen, you might need to use some sort of logic to determine when to attract the camera toward the center of the adjacent box. But if the boxes are at least 16px larger than the width or height of the screen, or if they're aligned on the top or bottom (as seen in this illustration), you can keep the motion flowing.

I believe one system uses a kind of block that is "avoid scrolling this on-screen".

Another option is having the intersections and entry points marked for what directions of scrolling are permitted. You might have an object that, when it's loaded, sets scrolling to "vertical only". An object that says "scroll to center camera on me on X axis". You might have boundaries between the sections that change it and do this, so that if you leave an intersection-screen (or are in the up-quarter) up, then it says "vertical scroll okay, and center X-wise on me", but if in the sides, "horizontal scroll okay, but center Y-wise on me". Or you could implement this as an object that sits at the middle of an intersection screen and twiddles variables in the same manner.

Have the camera constraint map stored as a separate "collision" map. Instead of storing that map directly, store the Minkowski sum of the screen and the collision map, allowing to do single-point collision code (a bit like how Contra does its collision handling). This is practical, because the screen size won't change. This is about the most general you can get.

As for the "alignment" issue that I wrote about in the first post, maybe it would be sufficient to do this in the same way that e.g. A Link to the Past handles situations where Link pushes against a wall when he's close to a hole in the wall. If he pushes upwards, the game will move him horizontally until he's aligned with the hole, and only then start moving him upwards. I think the recent homebrew Legends of Owlia does the same thing.

Oh, camera locking? There's a few ways to do it, based on your needs for it.

My own method is to define the viewable room, as a minimum and maximum x/y, based on the number of subscreens (more efficient). Touching certain defined "lines" adjusts the scrolling, for the next "room", in a connected area. Allowing for seemingly seamless transitions, in a large area.

Super Metroid in particular had an interesting way of handling this, with "BTS" blocks, an attribute of a map tile, that could adjust the camera scroll, run scripts, etc.

Who is online

Users browsing this forum: No registered users and 7 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum