Okay, I think I understand.
I didn't see this mentioned in your post or in your code, so I'll bring it up. If the player is on the edge of the map, how do you handle it? If you have a grid of 100x100 tiles, the view is always centered on the player, and the player is located at (0,0) (top left corner), what happens? Do you keep the player centered or does the player move to the top left corner of the screen?
(x).ToString() + "_" + (y).ToString();
You don't need to surround your variables with parentheses.
I think your whole approach is flawed, and I'm not saying that to be mean. Here is what I'd change:
1. Use a camera.
2. Store your tiles in a 2D array.
3. Use a quad tree for collision detection.
4. Use "layers" in your map (terrain, static terrain objects, creatures & items, etc).
5. Break your map class up into more objects.
Use a camera:
What you want to do is to create a camera viewing rectangle. If map objects are within the viewing rectangle of the camera, then they are rendered. If you treat your view as a viewing rectangle, you can do a lot more with it (panning, zooming in and out, centering on an object, tweening between points, etc). Rather than rendering everything relative to the character position, you render everything relative to the center position of the camera and, for the most part, keep the camera centered on the player. This makes it much easier to handle the map-edge cases. You could also do interesting features, where if your character is moving in a particular direction very quickly, you can adjust the veiwing area of the camera to show more of the world space in front of the character so that they have more time to react.
Store your tiles in a 2D array:
You can either store the tile objects directly, or just store an index in a 2D array. How you store your tiles should be independent of how you're moving on the tiles and viewing the tiles. Your character movement can be simplified into an X & Y position, and handled with requests to the map manager. Character tells the map "I am at this position. I want to move left one space", and the map manager reads the map array and says "Okay, that's a legal move! you can set your position there." or "Nope, that can't be done. There's a tree there!" or "Nope, you're on the edge of the map and you can't go left any further!"
Use a quad tree for collision detection:
Once I understood the concept, it didn't take me more than an hour or two to get a quad tree datastructure up and running. The idea is to put your spatial objects into the smallest box which will contain them, and keep dividing the box into fourths until its empty. Then, when you're doing collision detection, you only need to compare the objects in the largest box against all of its child cells. This changes your collision checks from O(N*N) to O(log N) (best case). The tiles which are being viewed would be all the tiles which collide with the camera viewing rectangle (don't necessarily need a quad tree for camera rect, you can also do a rect.Contains() call against all tiles in the game model which is more computationally expensive but works)
Use layers in your map:
Terrain is the first, bottom layer. This tends to make for boring maps because they're plain. So, create another layer and add trees, flowers, rocks, and any other terrain objects. These static terrain objects are non-moving, so this simplifies collision detection a bit (you're not checking if a tree is colliding with another tree every frame). Then, you'll also have another layer for moving objects (monsters, player characters, bullets, pick ups, etc). These objects may move every frame, so they can collide with other objects in their layer or objects in the static objects layer. By layering your map, you can be a bit more flexible. A tree can sit on a dirt tile or a grass tile, instead of creating a tree-dirt tile and tree-grass tile.
Break your map class up into more objects:
You're currently trying to do too much "stuff" in one class. Break it up a bit. You've currently got a class which contains map metadata, tile information, character information, character movement logic, screen resolution logic, and resource loading logic all in ONE class. This makes your class design VERY rigid and all of your object interactions are hardcoded. This makes your class have 430 lines of code. You want all of your objects to be as decoupled as possible and interacting with each other via class method calls. I like to use the model view controller design pattern. The model doesn't know about screen resolutions, it only cares about maintaining the game state and game logic, and updating it. The view doesn't care about the game logic, it only cares about correctly rendering the game state to the current rendering settings (resolution, anti-aliasing, shadows, etc). The controller doesn't care about rendering very much (except for getting its controls rendered, such as buttons and drop down menus), it only cares about interacting with the game model.
Some people like to break it out even further and add a data layer to handle data read/writes to and from a file or database. I generally include that in my game model objects.
So, I'd create at least the following classes:
-Map
-Tile
-Character
-Camera
-Player (inherits from character)
-Monster (inherits from character)
The map class would contain one or more 2D arrays of tiles, any meta data about the map (like map name, map size, etc), and methods for loading and saving to disk.
A tile class would contain tile specific information, such as the tile texture, tile dimensions, tile type, movement point costs, etc.
The character class would be an abstract game actor class which contains generic data about a character (hitpoints, name, position, dimensions, etc)
A player class would mostly have UI and controller specific methods
The monster class would be an extension of the character class, maybe with some added AI scripts to control it and do monster specific logic.
I like to keep a global class of loaded art resources (and call it a texture database, or TextureDB for short). Whenever I create a new object, I set its texture to point to one of those stored art assets. By doing this, I can centralize all of my resource loading into one object. Then, all I have to worry about is making sure that the TextureDB has all of the correct art assets loaded up. I can also load art assets into the TextureDB by reading a file for a list of needed art resources (art manifest), so if I load a game level, the level data would contain a list of all the art resources it uses. The textureDB would load those assets into memory, and off we go!
Warning: general hand waving to follow:
As for your rendering code, all you should be doing in the draw function is calling each object and telling it to render itself according to its current state. So, if you have a map object, your render code should be this:
Map.draw(spriteBatch);
Since the map contains a list of tiles which will know how to render themselves, it'll do the following:
//you'd also do a foreach for each layer, so you render terrain first, followed by static objects layer from top to bottom, followed by moving objects layer, etc.
foreach(Tile t in TileList)
{
t.draw(spriteBatch, position);
}
To move a character on a map, you'd make a request call to the map manager, something like this:
if(KeyboardInput == MoveLeft)
MyCharacter.Position = Map.MoveTo(MyCharacter.Position, new Vector2(-1,0));
And the map manager would get the request and handle it something like this:
public Vector2 MoveTo(Vector2 Pos, Vector2 Dir)
{
Vector2 RequestedTile = new Vector2(Pos.X + Dir.X, Pos.Y + Dir.Y);
if(Tile[RequestedTile.X][RequestedTile.Y].isPassable() and not Tile[RequestedTile.X][RequestedTile.Y].isOccupied() and blah blah blah conditions)
{
return new Vector(RequestedTile);
}
else
{
return Pos;
}
}
