Hey, @DSSiege11! I saw you were talking about wanting more room for your map. Well, I know of a sneaky method that actually can save you some room. Seeing as you posted about 2 days ago saying you made some progress, I think this may still help you or may help anyone else in a similar problem. Let's take a look at the map system for Pokemon Red and Blue. (In later games, they did this differently.) I'm really going to simplify this for others reading the thread, so for your specific game, you can scale this up to have larger maps and however many tiles you need. I'm also going to ignore how you actually store the data, which can be in bytes or ints or whatever, honestly.
This is an example map in the Pokemon Red and Blue games. This map is made up of 20x16 spaces that the character can move unto.
Looking at it, you may think it'd be better to cut this map up and tile the data. (Each square is a space that the character can move to.)
In this pic, I have it sliced up and color-coded for easier viewing. Each color is its own tile. Counting the colors, you'll notice that there are 23 different tiles. Because of that, this map data would be stored as a 320-number sequence, ranging from 1 to 23.
What Pokemon Red and Blue did to save memory is to group 4 tiles together. There's an extra step to doing this, but let's look at how this would be illustrated before talking about that... Notice that the map goes to 10x8.
Color-coding these tile groups, you'll notice that there are now just 17 colors. Because of this, this map data would be stored as an 80-number sequence, ranging from 1 to 17, which would cut down on memory usage considerably.
To define these tile groups, you'll have to have 17 different 4-number sequences, ranging from 1-23. That would mean you have 68 numbers in that definition... Together, 80 + 68 is 148, which is how many numbers in memory you would be using. Remember, storing everything on a per-tile basis (in the first example) would cause you to use 320 numbers in memory. This means you'll have used only half of the memory as the original example if you group the tiles!
Now, if you go ahead and group the tiles into 4's, instead of referencing the tiles when generating the map, you'll have to reference the tile groups. This would mean that somewhere in memory, you'll have to define what each tile group is... The more variety of of tile groups you have, the more memory that will be required to define them. This can be annoying and lead to more memory usage than its worth, but for bigger maps with less variety, the trade-off actually saves you memory. Eventually, grouping tiles together will save you so much memory that defining them can take place in the area of memory that you've saved. This tile grouping can be done in 2x2, or 2x1, or even 3x3 if you want. Changing the size of the groups can allow you to find the right balance between tile variety and memory.
I hope this helps!
After reading what I posted, I just wanted to point out that within each tile group of the example that I posted, collision checking would be handled the same across all 4 tiles. However, each tile could be responsible for its own collision checking within the group so that it's not completely uniform, without losing memory.
This means that within a group, you can have areas that allow the player to roam, effectively creating fences and barriers that are more screen-conscious.
If you'd like an elaboration on this, lemme know. I figured it would be straight-forward enough for many to get from the original post, though.