Approach to manage multiple exit points in a map

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Approach to manage multiple exit points in a map

Post by rainwarrior »

thefox wrote:If I wanted something quick, I'd use the object system for it (assuming you have one in place). Simply make an invisible object that checks for collisions against the player.

Depending on your game you might not want to waste an object slot for this though.
I used this method for my entire game. ;)
User avatar
Sumez
Posts: 919
Joined: Thu Sep 15, 2016 6:29 am
Location: Denmark (PAL)

Re: Approach to manage multiple exit points in a map

Post by Sumez »

That's kind of surprising, considering your game fits really neatly into one huge grid.
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: Approach to manage multiple exit points in a map

Post by thefox »

rainwarrior wrote:
thefox wrote:If I wanted something quick, I'd use the object system for it (assuming you have one in place). Simply make an invisible object that checks for collisions against the player.

Depending on your game you might not want to waste an object slot for this though.
I used this method for my entire game. ;)
FWIW, I also used this approach for STREEMERZ (mainly because it was used by the original game as well :)).
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Approach to manage multiple exit points in a map

Post by rainwarrior »

Sumez wrote:That's kind of surprising, considering your game fits really neatly into one huge grid.
Well, it mostly does but not entirely. I specifically wanted to have areas that don't connect in a straightforward 2D grid (think "lost woods"), so the room links are arbitrary. There's also a room where the edges wrap, so that had to be representable as well.

Maybe to give a little more detail, there's a few kinds of objects for moving from room to room:
  • pass: touch this and you go to another room)
  • door: touch this while holding up and you go to another room, character facing will flip to represent being on the other "side" of the world)
  • horizontal pass: 8 pixels wide, full screen tall, takes you to another room but velocity and Y position is preserved (normally placed at an edge)
  • vertical pass: two screens wide, 8 pixels tall, takes you to another room but velocity and X position is preserved (normally placed at an edge)
Every game object has a "parameter" byte. For these it's an index into a list of 8 connecting rooms (part of the data for each room).

In the data for the editor every room has a position on the grid, but this is not exported because the game engine itself doesn't use that information. It's only to help me organize it and pick rooms from a map view. The tool has a button to automatically create the 4 objects and connections to the 4 map-adjacent rooms, but these can be removed or replaced, or linked to other rooms arbitrarily. A lot of rooms have a wall on one side, etc. that might let me free up a slot to use for another object.

Parallel to the list of 8 connecting rooms is a list of 8 X,Y entrance coordinates. This is used when entering the room, the coordinate used depends on which exit was taken in the previous room. If arriving by pass/door the player just takes on that coordinate, if it's the vertical/horizontal pass type it only sets one of the coordinates and retains the other.

There's probably other variations of this in there, and some weird rules to do with 1-screen vs 2-screen rooms, but this is the basic idea. It was pretty simple, and it didn't really feel like it had much impact on the object budget or performance (rooms with all 16 objects were rare, it usually seemed crowded to have that much stuff).

Dunno if I'd do other games the same way, but it was convenient for this one. If it was a game with big streaming rooms where objects come and go it'd probably need some "priority" concept so that doors and stuff can't get despawned... but for a different game I'd make a different evaulation about how to do this. This question is very much in the category of "game-specific", IMO.
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: Approach to manage multiple exit points in a map

Post by Banshaku »

@thefox

STREEMERZ... I have good memories of it :) One anecdote about it is at the time, I was playing games on the train with an emulator on the psp. When I first tried STREEMERZ, the music for the intro was "unusual", with high pitch and broken notes and I thought : "man, that's really makes it feels like some kind of action 52 game pack!" and had a blast. Later, I figured out that the broken music was not by design but the emulator didn't support illegal instructions, thus the broken intro music. Still, I like that version :lol:

@rainwarrior

That's a lot of interesting way to connect room, I will take notes of it. Right now, to debug the transition code between maps, since the amount is limited to 10~13 in my current samples and more or less goes from left to right (sometime connecting top or bottom), I just did a debug method which is called when the main actor is out of bound.

There is a switch that check what to do based on the map number. For example, when you are in map "0", if you go out of bound "up" and where in ladder mode and in the last screen of the map (based on actor X location), you go map 1. For "1", if out of bound and you go up ladder then go map 3, if falling down or ladder go back to 0 and adjust location of actor to be at end of screen so screens will be buffered properly, etc.

For now, this is quite crude but I think I could create some kind of lookup table that would tell what to do based on the map and this could be reused for other stages. But this is more than enough for debugging purpose and will refactor the code later.

After 10 years, to be able to transition between maps and the engine is starting to buffer the screen appropriately is a big enough milestone that I don't mind the debug code since once compiled, it doesn't matter much as long that it works, isn't it? :lol:
Post Reply