I suspect that this one is not going to have many specific answers, as it probably just comes down to the individual game and how it was programmed.
But even so, I'm wondering what limitations influenced the sizes of maps that games used.
Okay, I know some were influenced by the name table and things like status bars, which is why Mario 3 had most maps about two screens tall, and a lot of games were just one screen tall so they only had to scroll horizontally.
But then there are games like Castlevania II which had both vertical and horizontal scrolling, but the game was still divided into map sections. Most of the time this was because there would be different tiles and monsters in the different areas, but then they also had such divisions in the middle of the mansions, where those things did not change. This suggests that they may have had a logical limit of how large of a map the game could handle.
And yet there are also RPGs with world maps that are frikkin 4096x4096 (in pixels.) So, it looks to me that map sizes were largely arbitrary, and set up more for convenience and game logic rather than hardware limitations. (Well, to a point. obviously.)
Even so, I wonder if there were common restrictions or perhaps particular aspects to map sizes that most games faced. I am about to set up camera limits in my game, and logically the camera limits are the map sizes. So I'm curious what kind of restrictions I should conform myself to. (And in case there is anyone new here, I'm making a game with a modern engine, but trying to emulate the NES's restrictions 100%.)
I would venture a guess that perhaps a map's size ought to be limited by powers of two, or at least to multiples of a power of two. On top of that, a game could easily add an arbitrary "wall" that the camera can't scroll past at any point, so even if a map was technically 512 pixels long, the player might only see 400 of that. But knowing those limitations would influence how a map was designed; like if maps were stored in powers of two, then making a map that is 528 wide would result in a big chunk of data being wasted on empty space. That's the kind of stuff I need to be aware of.
For the sake of argument, we'll say the mapper is MMC3, since that is probably going to influence things. Though I'm also curious about the MMC1.
And on the subject of maps, I am also curious about the limitations for the number of maps a game could have overall. I was thinking I would set an arbitrary limit of 256 different maps, since that seems like a reasonable technical limit that probably no game on the NES ever hit. But I suspect one would hit limits in the PRG data first. This limit is probably more important to me; I have a tendency to go overboard and put in more and more in the games I design, and I want to establish a barrier to make sure that I don't make the game too big. So figured I would have a limit of 256 individual maps, including ones for the title and menu and such. That's a pretty outrageous limit though, so I wonder if there is a smaller one I should be more conscious of.
And on the final subject of maps, I want to confirm that they work the way I imagine.
Commonly they would store the data in blocks of 16x16 pixels, (though I understand some might use 32x32 or perhaps other amounts.) which would mean each address on the map contains data for four tiles, a palette, and a collision type. And from what I have seen of games from before my time, these are probably commonly stored as a set list of instructions, rather than a whole list for each block. So for a block at the location of 14 x 10, the map would store a single byte, say, the number 12. And then the game checks to see that a block of twelve uses the tiles 44, 45, 32, and 33, uses palette 2, and does not collide with the player.
And since these are set up arbitrarily, a game could put in whatever data it finds pertinent for itself in that data, and the blocks could be any size it wants. (Although the way the hardware renders things probably influences what kind of data they want to use.)
So if I'm right about that, maps would also have a logical limitation of 256 different types of blocks, which limitation no one came close to breaking, and would probably hit cost limits to store the PRG data first.
...Am I right about that?
But even so, I'm wondering what limitations influenced the sizes of maps that games used.
Okay, I know some were influenced by the name table and things like status bars, which is why Mario 3 had most maps about two screens tall, and a lot of games were just one screen tall so they only had to scroll horizontally.
But then there are games like Castlevania II which had both vertical and horizontal scrolling, but the game was still divided into map sections. Most of the time this was because there would be different tiles and monsters in the different areas, but then they also had such divisions in the middle of the mansions, where those things did not change. This suggests that they may have had a logical limit of how large of a map the game could handle.
And yet there are also RPGs with world maps that are frikkin 4096x4096 (in pixels.) So, it looks to me that map sizes were largely arbitrary, and set up more for convenience and game logic rather than hardware limitations. (Well, to a point. obviously.)
Even so, I wonder if there were common restrictions or perhaps particular aspects to map sizes that most games faced. I am about to set up camera limits in my game, and logically the camera limits are the map sizes. So I'm curious what kind of restrictions I should conform myself to. (And in case there is anyone new here, I'm making a game with a modern engine, but trying to emulate the NES's restrictions 100%.)
I would venture a guess that perhaps a map's size ought to be limited by powers of two, or at least to multiples of a power of two. On top of that, a game could easily add an arbitrary "wall" that the camera can't scroll past at any point, so even if a map was technically 512 pixels long, the player might only see 400 of that. But knowing those limitations would influence how a map was designed; like if maps were stored in powers of two, then making a map that is 528 wide would result in a big chunk of data being wasted on empty space. That's the kind of stuff I need to be aware of.
For the sake of argument, we'll say the mapper is MMC3, since that is probably going to influence things. Though I'm also curious about the MMC1.
And on the subject of maps, I am also curious about the limitations for the number of maps a game could have overall. I was thinking I would set an arbitrary limit of 256 different maps, since that seems like a reasonable technical limit that probably no game on the NES ever hit. But I suspect one would hit limits in the PRG data first. This limit is probably more important to me; I have a tendency to go overboard and put in more and more in the games I design, and I want to establish a barrier to make sure that I don't make the game too big. So figured I would have a limit of 256 individual maps, including ones for the title and menu and such. That's a pretty outrageous limit though, so I wonder if there is a smaller one I should be more conscious of.
And on the final subject of maps, I want to confirm that they work the way I imagine.
Commonly they would store the data in blocks of 16x16 pixels, (though I understand some might use 32x32 or perhaps other amounts.) which would mean each address on the map contains data for four tiles, a palette, and a collision type. And from what I have seen of games from before my time, these are probably commonly stored as a set list of instructions, rather than a whole list for each block. So for a block at the location of 14 x 10, the map would store a single byte, say, the number 12. And then the game checks to see that a block of twelve uses the tiles 44, 45, 32, and 33, uses palette 2, and does not collide with the player.
And since these are set up arbitrarily, a game could put in whatever data it finds pertinent for itself in that data, and the blocks could be any size it wants. (Although the way the hardware renders things probably influences what kind of data they want to use.)
So if I'm right about that, maps would also have a logical limitation of 256 different types of blocks, which limitation no one came close to breaking, and would probably hit cost limits to store the PRG data first.
...Am I right about that?