25
\$\begingroup\$

The NES classic Mega Man series uses a very specific scrolling technique that I'm having a hard time wrapping my head around implementing. Essentially, the level is divided into "screens" which are all the same size. Some of the screens smoothly scroll in to one another, creating the illusion of a wider fields of play. Some of the screens stop the camera from scrolling until the player has reached the edge of the screen, at which time a transition occurs and the next screen is shown. It is also possible for a single screen to have more than one transition, for example it has a ladder that goes up to one screen, but you could also walk forward to another screen.

How can these screen transitions be modeled?

Mega Man screen transition diagram

  • Screen 0 is the starting screen, where the player starts.
  • Screen 0-3 is horizontally smooth-scrolling and appears to the player as one continuous field of play.
  • Since there is a transition between Screen 3 and it's neighboring screens 4 and 5, the camera will not advance past the right or top edges of Screen 3 unless the player moves to that respective edge and "pushes" through to the next screen.

  • Once the player moves to either of the transition edges, user input is momentarily disabled and the camera transitions into the new area, after which user input is restored.

  • The blue screen (Screen 5) has disabled horizontal scrolling so that only vertical transitions are possible.

  • The green screen (Screen 6) has a vertical transition back to Screen 5 but also allows horizontal smooth-scrolling into Screen 7.

Edit: Implementing the transitions in terms of rooms lead me to this:

Room structure implementation diagram

The small notches with an arrow are the regions in which a transition can occur. Each region has a "direction" and lies just outside of the room's visible area. As soon as the player hits a region, a transition will be started.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ this behavior is also present in the 2D games in the Metroid series. \$\endgroup\$
    – Sparr
    Commented Dec 22, 2010 at 1:50
  • \$\begingroup\$ Yes, it is essentially the same. The difference being that IIRC Metroid allowed vertical smooth-scrolling in some rooms/shafts, whereas Mega Man never had vertical smooth-scrolling; there was always a transition. \$\endgroup\$
    – Zack The Human
    Commented Dec 22, 2010 at 2:14
  • \$\begingroup\$ I've heard this called 'flick screening'. \$\endgroup\$
    – Blecki
    Commented Dec 22, 2010 at 2:52

2 Answers 2

Reset to default
21
\$\begingroup\$

It sounds like what you need is the concept of rooms as opposed to screens. Screens 1-3 would be one room, e.g. Your rooms could then be of any size and shape, or even restricted to the size of multiples of a screen.

Your camera would follow the player through a given room, up until the player gets too close to the border (half a screen width). When the player moves across the border, and into another room, you perform the transition visualization.

Each room would have a set of access points, which are mapped to access points of another room--creating the transition points.

\$\endgroup\$
10
  • \$\begingroup\$ Thanks for the suggestion. This is what I initially wanted to do but I hit a mental roadblock when trying to deal with transitions. Say for example there is a long room with an entrance from the top on the left end of the room, and an exit at the top of the right end. I suppose the way to deal with this would be to have small regions defined which can trigger the transition, hmm? \$\endgroup\$
    – Zack The Human
    Commented Dec 21, 2010 at 22:57
  • \$\begingroup\$ A little further: the "room" concept is what I currently have in my game. Rooms can be arbitrary in size, but I have not yet defined how to transition from room to room. \$\endgroup\$
    – Zack The Human
    Commented Dec 21, 2010 at 23:00
  • 1
    \$\begingroup\$ @Zack: The Camera follows the Player around. The Camera bounds must never overlap a room outside the one the Player is in (i.e. if the right edge of the viewport is against the right edge of this room, camera cannot move to the right). If the Player passes through a room wall into an adjacent room, have the Camera quickly track until it is safely within the new Room (you only have to worry about up/down/left/right in your structure for this movement). Optionally, if the player walks up to a room wall, take automatic control and force them to walk forward to be completely inside the new room. \$\endgroup\$
    – doppelgreener
    Commented Dec 22, 2010 at 13:30
  • 1
    \$\begingroup\$ @Zack: Your question edit appears to correlate to what I was thinking. The player's position can only move out of a given room in those transition locations (between y1 and y2 on a vertical wall, or x1 and x2 on a horizontal wall), and as soon as it does, you place its position in the next room--thus avoiding a "back and forth" loop--and perform the visual transition. \$\endgroup\$
    – TreDubZedd
    Commented Dec 22, 2010 at 18:05
  • 1
    \$\begingroup\$ You might also consider a "border" around each room, which is generally non-playable area (except for the transition regions). You can graphically design your rooms such that the non-playable border always contains "wall" graphics, but the transition regions are left open, like the rest of the room. You can fake a transitional "overlap" by waiting for the player to cross into the (playable) border entirely, and in the next room, make sure the new position doesn't intersect the border at all. \$\endgroup\$
    – TreDubZedd
    Commented Dec 22, 2010 at 18:10
-8
\$\begingroup\$

The concept of larger smooth scrolling areas being made up of screen-sized chunks is an artifact of severe resource limitations on classic consoles, where performance gains could be had by keeping data in chunks of specific sizes (such as one memory page). There is very little reason to use such a system in a modern game.

\$\endgroup\$
5
  • 7
    \$\begingroup\$ I understand that the original developers had to implement scrolling this way in order to load tiles, sprites, etc. I don't need to implement the screen-based system described in my question, what I really want is to emulate the camera and/or scrolling movement. \$\endgroup\$
    – Zack The Human
    Commented Dec 22, 2010 at 2:17
  • 4
    \$\begingroup\$ -1 - The division of the play area into discontinuous chunks may not be relevant for loading anymore, but it still creates a particular feeling of place for players and helps them map the area mentally. \$\endgroup\$
    – user744
    Commented Dec 22, 2010 at 10:42
  • \$\begingroup\$ @Joe how is that relevant to my answer? I specifically and directly address the chunks being multiple-of-screen-sized. I said nothing about the chunks being discontinuous or not. \$\endgroup\$
    – Sparr
    Commented Dec 23, 2010 at 0:11
  • \$\begingroup\$ I wanted to let you know that I didn't downvote your answer, but I don't really think that it answers my question: 'How can these screen transitions be modeled?'. \$\endgroup\$
    – Zack The Human
    Commented Dec 23, 2010 at 1:38
  • \$\begingroup\$ @Zack thanks. if it goes too much more negative I'll delete it, but if it stays at -3 then I'll leave it since I think it's pertinent even if not a direct answer \$\endgroup\$
    – Sparr
    Commented Dec 23, 2010 at 6:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .