1. Map format
Ok, theres two things here. One, how do you store your maps on disk to save, load and build them. Second, what is the actual data structure of the map.
For the first one you have (how to store map on file):
-Store the map as a picture (eg. png) where pixel color corresponds to tile type. Works for simple maps. You can edit it in an image editor. But its limited and you will eventually need to move forward when you need more features.
-Binary format. Create a protocol for storing the map as bits and bytes. This is the most flexible feature wise. It is not practical to edit this by hand, youll need to make an editor. It is also more vulnerable to bugs because you cant really see what you are doing.
-Human readable text format (like the xml shown by exOfde). Same benefits as binary excepts its in a human readable form, and thus easier to work with. The only problem is that it is not very compact in memory and thus will take more space than a binary format as well as likely take longer to load.
-An already existing format with editors available. This might be a good choice, so you dont have to worry about editing your map. Of course, being somewhat out of your control, you might at some point face limitations in what the format or editor for the format can do.
The second one, theres not so many ways you can arrange your data in memory. Its more about what features you need:
-Grid in memory (X*Y tiles). Use a format like this for the tile data, to tell what material each tile is.
*Use this only for data that most tiles have
*You can also add an ID to the tile data, and store the actual data in a different place. Eg if a tile has a list of objects contained, you want to store it in a separate structure because you dont know how many items there are. You dont want each tile to have space for 1000 items. You want each tile to point to a list of items that is resized to fit the items.
*Later you might want to be able to have multiple grids (chunks) which form a continuous grid made of many parts. This allows it to be easily resized by adding or removing chunks. This is if you want procedurally generated terrain, or if you want to load only a part of the terrain in at a time from disk or network.
-Freely placed objects (list of objects, each has x,y position)
*Consider this for things that are not really a part of a tile or are rare
*Players, other moving objects...
*Some special locations like spawns so you dont have to scan each tile to find what tile is the spawn in
2. Map access
The access pattern you described is easily achieved by flood filling limited to an amount of steps which is the range. Specifically:
-Have 2 list, one for tiles in range and second for recently flooded tiles.
a) From the center tile (the player) flood all the neighboring tiles. Add them to the list of tiles in range and the recently flooded tiles.
b) Treat all tiles in recently flooded tiles as center. Clear the recently flooded tiles list and flood from the tiles that were in it further out (dont flood back to tiles we already covered)
c) Repeat until RANGE steps
or something similiar. Google on flood fill algorithm. This isnt exactly filling because we terminate after X steps but the logic is the same.
3. Customization of player
The game logic of this should be simple, your player has slots you can equip stuff to (eg a WeaponType member, which you can use to find the weapon details such as appearance and damage. As in WeaponTypes[player.WeaponType.getID()].getDamage())
The appearance is more complicated. The weapon you can probably just draw as a separate sprite to the correct position when it exists. For smaller details you might need to do something like programmatically color the ring in the players hand or have a ton of sprites to cover all the possible combinations of things the player can wear.
The best would be to just figure out how to compose a player from multiple sprites so you can swap them easily.