nice,
What you've done is calculate the player's field of view using line of sight algorithm to calculate whether each tile on the map is visible to the player. This is what I did at first, I prefer this because it is intuitive and works fine and like you said it's a nice piece of code you can reuse for aiming.
But just a heads up about something you might encounter (hopefully not) because you mentioned making the map larger. Unfortunately I found the performance was too bad with larger maps, because as the width and height of the map increases the time taken to calculate line of sight of every tile exponentially increases. Also there is additional hit if you want to calculate monster FOVs too.
You might have no problem depending on how big maps you intend and whether you intend to calculate monster FOVs each turn. But just in case you hit this wall, there are algorithms specifically for calculating field of view that are more efficient and can handle bigger maps because they reuse information and avoid checking tiles behind obstructions. Unfortunately those algorithms range from complicated to absurdly complicated to implement.
The one I used (because it seemed the simplest, performs almost the best compared to others and seems accurate enough...) is:
http://roguebasin.roguelikedevelopment.org/index.php?title=FOV_using_recursive_shadowcastingUnfortunately it's a bit of a mind-**** and took me weeks to understand it on paper before I could event attempt to implement it. Then it took me weeks more of bug tracing because I kept screwing up. In hindsight it would have been better to just understand it and then use someone else's code...
Just something to bear in mind if you find your turn-calculation takes too long with a larger map.
Although perhaps a better option (rather than wasting weeks on a more complicated algorithm) is to limit the maximum view range of the player so you don't need to calculate the visibility of all tiles on the map. The map could be infinite if the player can only see 20 tiles radius. A trick to largely hide this would be to make the map generator never (or rarely) generate huge open areas where the player would notice the restriction. Or just use the convenient excuse that the player is carrying a light source and it can reach go so far.
I know at least two years back when I last played it, minecraft was using a similar trick. Hugely inefficient, the client fetches entire 16x16x256 tile chunks from the server, even though the vast majority of those tiles are typically underground and the player can't see them. So they didn't spend time making a complex algorithm to only send the visible 3D tiles (if that's even possible), they just send them all (an unfortunate consequence of this is that people can create undetectable client x-ray hacks...). Then on the client I believe they just draw every tile and let the graphics api/driver/card deal with occlusion. They limit the performance hit (on the server and client) by putting in a shorter horizon view distance...although it's so short you often see the horizon loading in the distance. This is something that's always bugged be about minecraft from a purity point of view (plus the x-raying). Possibly there is something technical I don't understand which forces them to it this way. But on the otherhand the game was somewhat popular so it shows a complex algorithm isn't always necessary and tweaking things like view distance can work.
