Doing an in-game map, Metroid/CV style

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Doing an in-game map, Metroid/CV style
by on (#65406)
So, I've thought about this, though not sure if I want to try to implement it or a good way.

In games like Super Metroid or Castlevania: SotN, you can access a map and the map will show you where you've been.

The main problems I'd foresee with this is the memory that'd be needed for this as well as storing the thing in a password.

So another approach I thought of would be like this: You can obtain map pieces which have X amount of squares added into the map. It wouldn't show you where you've been, but it would be something. It could be something like the Guardian Legend, although it might not be the clearest of maps since it'd just be squares next to each other.

A more detailed one showing passages/impassables COULD work, but that'd pretty much involve having another map corresponding to this in the ROM and would need to be carefully evaluated.

So I don't know... I don't think the game is going to be super massive... BK1 was a 50x20 map with maybe 400 rooms actually used... There weren't lots of twists and turns either and players have gotten by without a map.

The bottom line... do we think an in-game map is worth doing?

by on (#65408)
For me, its a matter of the size and amount of variation in your overworld. Something like the original Metroid would benefit from a map since everything looks the same (other than palette changes). Zelda:ALttP and later, probably not so much since there are a lot of identifiable landmarks.

You might be able to get away with just giving areas a name and displaying that when you change areas. Not sure how feasible that would be with your map engine.

by on (#65416)
If it's a simple map, it should be no more than 4 bits per room.

by on (#65417)
In your password, imagine which plot coupons the player has already taken and the most likely routes to get to those coupons. Then when restoring a game from the password, light up those routes as seen.

First we'll need to estimate the bit budget for your password system; that will show how much we need to approximate when restoring. How many different obtainable items do you plan to have in your game?

by on (#65426)
tepples wrote:
First we'll need to estimate the bit budget for your password system; that will show how much we need to approximate when restoring. How many different obtainable items do you plan to have in your game?


Well... at least 5 items thus far, but don't forget other flags like bosses being dead, or cutscenes being seen.

I'm pretty sure I don't wanna do the "it highlights rooms explored and doesn't highlight rooms not explored" approach due to the memory use and password system. Too complex. The map piece approach would just be a few flags and that's it.

by on (#65429)
Sivak wrote:
Well... at least 5 items thus far, but don't forget other flags like bosses being dead

Assuming six bosses, we're now inferring 11 of the map pieces with no additional space in the 32-bit payload of an 8-character password. Assuming BK2 is structured like BK1, you can infer a bunch more from the last continue point.

Quote:
or cutscenes being seen.

Assume that any cut scene after a defeated boss but before an undefeated boss hasn't been seen, but make it skippable. (Unlike some disc-based platforms, the NES doesn't need to hide loading with an unskippable cut scene.)